Bible Pay

Read 410475 times

  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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?

« Last Edit: March 20, 2018, 09:53:42 AM by Rob A. »


  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more

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?

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.

« Last Edit: March 20, 2018, 10:05:06 AM by MIP »


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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.



  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
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?


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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.



  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
Sure, thank you


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
Sure, thank you

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



  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
Getting closer; what OS and BBP compile version are you currently running that is emitting this particular sig?

OS: Windows Server 2012 R2 Standard
BBP compile version: 1.1.1.1


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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!



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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 * *


  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
Great! I will wait, anyway I'm out of tomorrow´s reward too so no hurry.

Thank you for the incredible efforts.


  • jaapgvk
  • Hero Member

    • 558


    • 31
    • September 01, 2017, 08:02:57 PM
    • Netherlands
    more
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.

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 :)


  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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'.



  • Rob Andrews
  • Administrator

    • 4090


    • 97
    • June 05, 2017, 08:09:04 PM
    • Patmos, Island Of
    more
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.



  • MIP
  • Sr. Member

    • 365


    • 47
    • February 13, 2018, 11:55:52 AM
    more
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'.

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