Bible Pay

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Rob Andrews

Pages: 1 ... 209 210 211 212 213 214 215 [216] 217 218 219 220 221 222 223 ... 277
3226
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: March 31, 2018, 07:24:08 AM »
Yes, just approval for the idea. The commission is supposed to handle the ins and outs of everything related to charity. I thought we could start small and first create an address for donations. Now sure, there is the foundation address also so maybe we can use that but it's tied to the Compassion fund and it's only handled by one person. There is currently no plan to spend it on another charity and it is not for me to decide anyways. Whatever goes into the fund will first support the current charities and if a large enough of a buffer is created we can consider using it for other charities.

If the fund is approved, there will be 2 people who keep each other accountable. And yes it will take load off of you because you wouldn't have to deal with storing the coins, selling coins, and transferring it to Compassion. Everything that is BBP will be accountable on the blockchain, and everything that is converted to cash will be posted on the website for transparency. All of these things take precious time off from our only dev.

Sure, it makes everything easier when there is only 1 person that handles everything but you also become the single point of failure. In fact, and I've told Togo this, I don't want to be the one that has to handle the wallet with the donation address since it is a big responsibly. How about if you and someone else keep each other accountable instead?

I have to say, you often make me sound like a bad person, saying I was greedy, now saying everything is going into my pocket. I don't know what your deal is but I hope you repent from your unloving ways. I am here for the children, if I wasn't, I would be long gone than have to stand up to your insults.


Mike,

You just made a quote before my post, stipulating that I've placed an address on everyones wallet where we have NO ACCOUNTABILITY for funds sent to it.  You basically said "Rob handles this" but we dont even know what was sent to it.  (Which I explained is not the case - I wrote an RPC report to show every BBP that goes to it).  That insinuates that I created a system to hide money.  But in reality I had a vision for accountability.biblepay.org to be able to reconcile every bbp In, and every bbp Out so it is all tied to an expense that has a receipt.  So it felt like an attack on the system, meaning your system was going to replace my faulty one.   So I pointed out how this new system does not actually solve anything, it creates less accountability.    So I would suggest asking more questions and learning more about whats actually going on before making misleading posts and creating a system that adds complexity and attempts to work around the problem.

Regarding Greed, you created a Good botnet that pulls in 20% of all Biblepay mining revenue for yourself, and then wrote a post in the vote for StakeRequired-Per-RAC that we shouldnt have any requirement.  Obviously this triggers the personal feeling - of course, then you could control even more of the pie.  I apologized for that, because I realize it was an ASSUMPTION on my part.   Nevertheless it does point to some potential vote bias on your end.

Anyway, please dont insinuate that I need to repent when Im defending the Orphans System, the system created for the orphans, only because you have a warped view - and have had your feelings hurt on this flawed idea, that automatically Im an evil person.  Im also here for the children, and the system has to be designed properly, not in a fly by night manner. 

First of all there is a difference between single point of failure for funds that are handled for long periods of time vs funds that are immediately spent. 
The other issue is when you attack the compassion.com system, you are attacking one that is spent immediately.  The superblock funds come in, they are converted and spent, they are not sitting around for months like they would be in a charitable sanctuary. 

In my view we have been doing quite fine splitting up the load on charities by creating different people to handle each charity- BLOOM handles their own dispursement, Jaap for Cameroon, Me for compassion, etc.  Im all for splitting the load and having more accountability.  Its being doing through the proposal system naturally as it is.

Thats why Im so confused as to what this Charity commission would be, I dont know what "ins and outs are". 





3227
Archived Proposals / Re: Biblepay Charity Commission - Revised
« on: March 30, 2018, 07:03:32 PM »
Togo, I meant for the address in general that there is no accounting for all the transactions, especially when we start taking donations.

Hmmm- what do you mean there is no accountability to that address?    Every BBP received is recorded in SQL as a reconcilable expense, and then reported on the web site, and every BBP goes to compassion.  So this "commission" is set up to make the donations go to your personal wallet instead?  Im not sure how that adds accountability. 

The thing is, we sponsor 205 children at $8000 a month, we always need more donations for compassion.  Im just not understanding how realigning the donate-to-foundation address is going to ease my workload.  The accountability web site in my opinion is a big plus for auditors who want to see the expenses in one place.  You dont have access to write records to it, so I assume I would need to get with you every month and make 2 records and then have a 2nd orphan fundraiser etc, sounds like double the work.

Yes there is a report in the wallet that shows all the amounts tithed to the foundation address also, since we started.

What are your plans on spending this on, what type of charities?  What is the projected amount you are looking to raise per month?

The proposal itself is for only 2500 bbp.  So Im confused what its for - is this just to seek approval for the idea?





3228
Archived Proposals / Re: BiblePay mobile wallet (Android & iOS)
« on: March 30, 2018, 09:48:50 AM »
This is really exciting, and extremely worth it.

Thats probably fine if we dont have instantsend, even for a couple years.
I assume even though the wallet keys are stored in a proprietary format, you can send BBP from your pc to your phone and from phone to PC and empty wallet out that way correct?  (sounds like a dumb question lol).  So if I had an email on the android, could I copy the bbp address to the clipboard and paste it into the breadwallet to send BBP to someone random? 

On this item:
 Create BiblepayWallet java and C layer (chain params and basic behavior)

I was wondering, do we need to modify the core (the biblepay-qt) client at all, or what is the c layer you are modifying is this on the breadwallet side or on the core side?  Is breadwallet entirely java based?  If on the corewallet side, have you already forked biblepay and modified your version locally to handle the call, and that is how you got it running?

On block storage, how does the wallet on the android store the blocks?

Thanks a million for your efforts, they are astounding!




3229
Votes 'yes'  :)

Btw, a question of interest: last time we accidentally exceeded the superblock budget after all votes were in, and we had to fix that by manually removing one of the proposals. I can't remember if it's now fixed in a permanent way? Like: if total budget is exceeded, the proposal with the least votes will get dropped or something?

Sweet, yes I see 9 votes for No on the extra.  Interesting, I wonder who would be voting No for orphans.  Looks like the same Sanc who is voting No for Togos "Mixed Bag" proposal. 

Anyway Yes, it was caused because the Pool was not using the deflation equation.  Now the pool is asking the wallet how much budget we have- so it should be fixed.

Plus when we create the budget tomorrow, Ill double check to make sure its sum of proposals are less than the wallet shows for the budget (which should be unecessary as wallet shows > limit right now than total open proposals).


3230
It worked! The funny thing is that I didn't even have to exec podcupdate to see the utxoamount again.

Some samples

2hr before updating (still with 1.1.1.1):
3abf4bdd39b918de8354df6143ac53f5948d7a16ea1b454ea7ee82e6570923b7

After updating to 1.1.1.2
632d8ec195e01a3679d0928196da7739e2e3912592dab84afa353bd1880c9a4a

Great!  Yes looking at getrawtransaction 632d8, it looks correct now.  Awesome.

Yes, doing the exec search utxoweight 9689, I can see your weight now.

Thats good we have this flowing out earlier in the cycle before we have a lot of researchers, as that malformed sig could be a crash risk, although I see the code handled the malformed sigs OK but would rather not see it iterating over hundreds of malformed sigs obviously.


3231
Great! I'm going to keep a close watch. Also, awesome that the average blocktime finally is 7 minutes. I'm curious what kept the blocktime around 10 minutes all this time :)

It was the biblehash functions late block threshhold feature.  The feature considers a block late after 15 mins, then reduces difficulty to make it 90% easier to solve by anyone (including non cpids).  The average amount of late blocks added 20% to the daily duration of blocks, despite having 420 seconds set in DGW (which is our difficulty algorithm).  So to fix it we now undershoot it by 20% - that teamed up with some 15.01 minute blocks averages out to 7 mins now.


3232
Great! I will wait, anyway I'm out of tomorrow´s reward too so no hurry.

Thank you for the incredible efforts.
Ok, 1.1.1.2 is out there if you want to give it a try, let me know a txid and Ill look at the 'getrawtransaction txid 1'.


3233
Biblepay 1.1.1.2
Leisure Upgrade

- Resolve bug in corrupted outbound PODC Updates due to inbound change
duplicating a portion of the cpid signature


* * Windows is Compiling * *

3234
OS: Windows Server 2012 R2 Standard
BBP compile version: 1.1.1.1
Alright, I found the bug!  You definitely were not at fault, you exploited something very interesting.
So we have alot of sigs in the chain already, probably 4000 or so, and we have 12 that are bad.  Im guessing that maybe 6-12 are yours.
So whats happening is there is a piece of math in the code that tacks your CPID signature on the back of a PODC update.  Since we only allow up to 3000 characters of free ascii space per Coinstake recipient, we add on more recipients (from your own address book) for space and change (change as in money owed to you if you broke a large bill in the coinstake).
So there is a funny behavior that occurs if the PODC update is between 3000 and 3100 long, the ceiling function returns like 1.01 (which gets rounded to 2), but for some reason when that happens, the change recipient (you) gets duplicated and it mangles the CPID base64 portion of the sig.  This only happens for PODCs that are between 3000 and 3100.  If they are 3101 or lower than 3000 they are OK.
Yours is 3100.

So anyway I am patching this now, windows is going to take hours to compile and Ill be out meeting someone soon, but Ive unit tested it and I believe its going to solve the problem globally.

Ill check in the unix version in about 15 mins, so if that helps you send it out you can grab that soon... Otherwise Ill check in windows tonight before the end of the night.

Im glad you found this, thanks!


3235
Sure, thank you

Getting closer; what OS and BBP compile version are you currently running that is emitting this particular sig?


3236
I just created a clean wallet, imported the address to stake with, re-associated and made podcupdate true, waited for confirmations,

Code: [Select]

exec getboincinfo

{
  "Command": "getboincinfo",
  "CPID": "96892ec0fc8a2710fa84f26c9c84cd3e",
  "Address": "BE2XrQurnfzbqAGgMX9F8dXEyReML2Zr6H",
  "CPIDS": "96892ec0fc8a2710fa84f26c9c84cd3e;",
  "CPID-Age (hours)": 422657,
  "NextSuperblockHeight": 35670,
  "NextSuperblockBudget": 1197260,
  "96892ec0fc8a2710fa84f26c9c84cd3e_ADDRESS": "BE2XrQurnfzbqAGgMX9F8dXEyReML2Zr6H",
  "96892ec0fc8a2710fa84f26c9c84cd3e_RAC": 19534.21,
  "96892ec0fc8a2710fa84f26c9c84cd3e_TEAM": 15044,
  "96892ec0fc8a2710fa84f26c9c84cd3e_TaskWeight": 100,
  "96892ec0fc8a2710fa84f26c9c84cd3e_UTXOWeight": 0,
  "Total_RAC": 19534.21,
  "Total Payments (One Day)": 5543,
  "Total Payments (One Week)": 70287,
  "Total Budget (One Day)": 1197260,
  "Total Budget (One Week)": 13036836,
  "Superblock Count (One Week)": 7,
  "Superblock Hit Count (One Week)": 7,
  "Superblock List": "35465,35260,35055,34850,34645,34440,34235",
  "Last Superblock Height": 35465,
  "Last Superblock Budget": 1197260,
  "Last Superblock Payment": 5543,
  "Magnitude (One-Day)": 4.629737901541854,
  "Magnitude (One-Week)": 5.391415524441666
}


 :(

The PoDC transactions:
172bd33f5ee7757d82464b071bc312cf4f570fa1d6d473c94bb42c84ab50ee5d
8a4df3cdc03ad31be3a4acf7d20edc2229cd0c96c1bed6756ec20c7add5c7bce

How can you check that it's valid or it is rejected?

Yeah, there is something funny going on here.  I see your taskweight in the chain, I see your Tx, and I see your updated CPID, but its almost as if it is ignoring your UTXO weight only.  This time it does look valid (probably what caused you to change it to begin with was the fact that you had no utxo weight), I see the CPID matches the sig and the key, so now its an interesting problem.

Im going to have to add a command to the RPC to diagnose this one.

Hang on please, I have an appointment in an hour but Ill try to work on this now.


3237
I don't really know which is the last one that worked, How can I know? to me all seem exactly the same.

And I have been using the same address for a week without a problem. In fact I got payments until yesterday ...

Edit: ok I will start again with a "new" wallet file and re-associate from scratch to avoid interferences with other addresses.

I meant last one sent by timestamp, not last one that worked (last one that worked for you is probably the one that is invalid for me).

Anyway, if you reassociate your CPID with force, and try to sign with a different wallet.dat, this type of forge will happen.

Nothing changes in the chain, so it must have changed on your end - otherwise I would have over 1,250 messages telling me the system is broken completely.  Unless we have a bug that is only transmitting half of the public key or half of the cpid in the chain, but these messages you pasted earlier are complete (as they end in an XML suffix with an end character + a suffix).  The data all comes from your wallet, so there is no way other peoples data is intermingled into your data either.

You should never have to start over, unless you accidentally reassociated with a second wallet.dat.


3238
I understand, but that's the issue because I've been sending Podc updates regularly... I post the PoDC update txids since yesterday

1b21f2b352383ca00cd3c51e494cd99d032c540ba3af3f8963bd36c9b49c9ac0
2c43abb2fb1ae9e9e2db25005fb784dd045ce5fe304632f653aa0d91d2c2adbf
19ffe0b8cff60ae1939a9bf90dbff7794c99fb057090ccd6c3e73b0ea0d2f608
ed77dc115de82127c2e939594ee64993b151e80ed007172b72e7bcf70fe6e4d0
bcc9ce63827c6c29d7afea01d8068511fc7d7ebb7db2740d7f14d7aa707a0a3d
6d351f1e193535d6aa8622390374e9bc3fd1108bdfdb239d661a7ef0adfdb253
2f55f35dbabcd0fed7175e039f677533342a0442adc1b789d0a88de4735b2236
99b7bada905b0fb2c81f97e49b2468e52df341a39f91b0d351b74dc5491a6a87
9b3e2af19849bbaf2fa9a9250004f7ab69eeb4e82bfb5173dbfad5f3d747030c
05ae2f2d9776175ab37758b2bee3c73c12d7fbf7cf5847beb0b27f07bd9fb2fc
af897c9d4eb63eb8e538392c63b556a8f654eae2b397d6b83058fa9a2042c4bf
c9938257ee11646f6eb0984aaaadd08e08c71048c5aff802db7c6a8617a5d066
ea695770ba3708dbaec396777c2b8940a693574b52444191c832a640557981ab

Some of them were forced

I tried to re-associate but nothing. I'll try podcupdate true and see..

Edit:
Code: [Select]
exec podcupdate true

{
  "Command": "podcupdate",
  "PODCUpdate": "Processed (128) over 1 CPID(s) successfully."
}


I will wait and see.

By the way I remember the only change is that yesterday afternoon I password locked the wallet. But when I reloaded I unlocked it for PoDC. I don't know if it may be the cause.


Hmmm, it looks like these transactions were signed by a wallet not associated to the CPID - another words, to the foreign nodes these transactions look forged.

The first few on the list were signed by BE2XrQurnfzbqAGgMX9F8dXEyReML2Zr6H, yet when I look in the chain, exec search dcc 96892, I see your CPID is associated with a different public wallet key.

The controller doing the podcupdate should be the one associated with the CPID.

(Otherwise nodes will disregard your podcupdates as if the signature is forged).

EDIT: Whats the TXID of the one you just did successfully, I can check it?


3239
I don't know what happened but I got dropped down from the next payment list. I see utxoamount=0 even if PoDC payments have been happening for the latest hours without apparent trouble. I even changed utxoamount=100001 in conf file just in case...

Code: [Select]
exec getboincinfo
{
  "Command": "getboincinfo",
  "CPID": "96892ec0fc8a2710fa84f26c9c84cd3e",
  "Address": "BE2XrQurnfzbqAGgMX9F8dXEyReML2Zr6H",
  "CPIDS": "96892ec0fc8a2710fa84f26c9c84cd3e;",
  "CPID-Age (hours)": 422649,
  "NextSuperblockHeight": 35670,
  "NextSuperblockBudget": 1197260,
  "96892ec0fc8a2710fa84f26c9c84cd3e_ADDRESS": "BE2XrQurnfzbqAGgMX9F8dXEyReML2Zr6H",
  "96892ec0fc8a2710fa84f26c9c84cd3e_RAC": 19239.3,
  "96892ec0fc8a2710fa84f26c9c84cd3e_TEAM": 15044,
  "96892ec0fc8a2710fa84f26c9c84cd3e_TaskWeight": 100,
  "96892ec0fc8a2710fa84f26c9c84cd3e_UTXOWeight": 0,
  "Total_RAC": 19239.3,
  "Total Payments (One Day)": 5543,
  "Total Payments (One Week)": 70287,
  "Total Budget (One Day)": 1197260,
  "Total Budget (One Week)": 13036836,
  "Superblock Count (One Week)": 7,
  "Superblock Hit Count (One Week)": 7,
  "Superblock List": "35465,35260,35055,34850,34645,34440,34235",
  "Last Superblock Height": 35465,
  "Last Superblock Budget": 1197260,
  "Last Superblock Payment": 5543,
  "Magnitude (One-Day)": 4.629737901541854,
  "Magnitude (One-Week)": 5.391415524441666
}

Any ideas? Thank you

I dont see you sending any UTXO weight out on the network:
exec search utxoweight 9689

Although I do see your cpid is present... 
I would try 'exec podcupdate true'
Lets see what kind of error you receive. 

With no UTXO stake, the utxoweight will remain 0, resulting in no superblock payments and no daily magnitude.


3240
It seems like I missed the last two payments from my pool unbanked account.

CPID: 8791a036b545f35e9ebd9333922738ac
BBP adress: 8791A036B545F35E9EBD9333922738AC

Code: [Select]
21:42:51

exec search dcc 8791a036b545f35e9ebd9333922738ac


21:42:51

{
  "DataList": "DCC",
  "8791A036B545F35E9EBD9333922738AC (03-11-2018 16:50:26)": "8791a036b545f35e9ebd9333922738ac;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;BNfb6uMyeAHDwZs538gzxS2k2iqbz8NWQj;1986929;;1"
}

This phone is only calculating for Rosetta when it's on the charger (about 10-12 hours every day). But that shouldn't need to be a problem, right?

Hi Jaap,

I finally got a chance to look at this- and the great news is it was just a network setting set improperly and it has been corrected, so now looking at the

cat filtered | grep 8791a -B7 -A11
I see that you do have the <unbanked> indicator showing as 1 on sancs now.  This will go into effect during the next contract, so please lets see if you start receiving payments now.  It might take 24 more hours for it to cascade. 

Note that in the pool, you can look for the unbanked flag on your superblock row, to see if it shows as "1".  At that point you can expect a payment.


Pages: 1 ... 209 210 211 212 213 214 215 [216] 217 218 219 220 221 222 223 ... 277