Bible Pay

Read 41195 times

  • Rob A.
  • Administrator

    • 1219


    • 20
    • 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 A.
  • Administrator

    • 1219


    • 20
    • 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
  • Full Member

    • 122


    • 14
    • 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

    • 571


    • 22
    • 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 A.
  • Administrator

    • 1219


    • 20
    • 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 A.
  • Administrator

    • 1219


    • 20
    • 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
  • Full Member

    • 122


    • 14
    • 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



  • Rob A.
  • Administrator

    • 1219


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



  • jaapgvk
  • Hero Member

    • 571


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

Thank you for the clear explanation :) I understand.

In other news: I got an unbanked pool-payment again!!  ;D


  • T-Mike
  • Sr. Member

    • 395


    • 3
    • February 06, 2018, 06:12:58 pm
    more
Rob, Don't know if you know but there seems to be a problem with the blockchain. We are stuck on 36079.


  • jaapgvk
  • Hero Member

    • 571


    • 22
    • September 01, 2017, 08:02:57 pm
    • Netherlands
    more
Didn't get a payment again with my pool-unbanked-account  :'(

Code: [Select]
36285 3/23/2018 9:35:55 AM jaapgvk_unbanked_poolCPID 8791a036b545f35e9ebd9333922738ac 0.059 1986929 15044 0 0 5069682 1 0 299 299 1 4
I did get a payment today :) Just keeping you updated. Let's see how it rolls from here...
« Last Edit: March 24, 2018, 04:28:17 am by jaapgvk »


  • T-Mike
  • Sr. Member

    • 395


    • 3
    • February 06, 2018, 06:12:58 pm
    more
I'm trying to change the number of threads on a linux machine but I'm getting this error:

biblepay-cli setgenerate true 4
terminate called after throwing an instance of 'std::runtime_error'
  what():  CWallet::GenerateNewKey(): AddKey failed

It crashes the daemon and I have to restart it.

Noticed setgenerate true will only go up to 3. Set to 4 threads and it will crash.

Debug.log
Code: [Select]
2018-03-26 03:25:18  ** Started 3.000000 BibleMiner threads. **
2018-03-26 03:25:20
BiblepayMiner -- terminated
2018-03-26 03:25:20
BiblepayMiner -- terminated
2018-03-26 03:25:21  Starting Thread #0.000000 with Bible #0.000000      2018-03-26 03:25:21 BibleMiner -- started thread 0.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #1.000000 with Bible #0.000000      2018-03-26 03:25:21 BibleMiner -- started thread 1.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #2.000000 with Bible #0.000000      BibleMiner -- started thread 2.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  Starting Thread #3.000000 with Bible #0.000000      BibleMiner -- started thread 3.000000
2018-03-26 03:25:21  MinerSleep 0.000000
2018-03-26 03:25:21  ** Started 4.000000 BibleMiner threads. **
2018-03-26 03:25:22 keypool added key 1102, size=1000
2018-03-26 03:25:22 init message: Loading wallet... (110.09 %)
2018-03-26 03:25:33
« Last Edit: March 25, 2018, 09:38:47 pm by T-Mike »


  • madmurphy
  • Newbie

    • 21


    • 1
    • January 01, 2018, 07:50:31 pm
    • Manchester, England
    more
Is anyone else getting the message in Boinic that there is no work to do ?


  • jaapgvk
  • Hero Member

    • 571


    • 22
    • September 01, 2017, 08:02:57 pm
    • Netherlands
    more
Is anyone else getting the message in Boinic that there is no work to do ?

Yeah, it seems like Rosetta@home has run out of work for the moment. You can check the server-status here:
https://boinc.bakerlab.org/rosetta/server_status.php

(It does say 'Tasks ready to send 18124'  on that page somewhere, but I don' t know what that means exactly.)

There is work trickling down, probably from workers who have passed the due-date. Can' t really find any news about this. Maybe they are adjusting the work. There was something similar going on with the Android tasks about two weeks ago.

Or maybe it' s because they can't handle the growth of Biblepay ;)
« Last Edit: March 26, 2018, 02:37:16 am by jaapgvk »


  • jaapgvk
  • Hero Member

    • 571


    • 22
    • September 01, 2017, 08:02:57 pm
    • Netherlands
    more
Didn't get a payment again with my pool-unbanked-account  :'(

Code: [Select]
36285 3/23/2018 9:35:55 AM jaapgvk_unbanked_poolCPID 8791a036b545f35e9ebd9333922738ac 0.059 1986929 15044 0 0 5069682 1 0 299 299 1 4
I did get a payment today :) Just keeping you updated. Let's see how it rolls from here...

Also got a payment today. And I also signed up another pool-unbanked-testaccount that also got payed.

Seems that not getting payed a few superblocks ago was just a one-off thing...