Bible Pay

Recent Posts

Pages: 1 2 3 4 5 [6] 7 8 9 10
51
We should technically re-sync better on this version (I mean the initial sync after upgrading only), as now we have classic's code for mandatory upgrades in.

BTW:  Please dont erase any files, just upgrade.
ha, to late. I deleted everything and now I have a problem, no peers
52
>>>Update on 5/8...I just received my daily autowithdrawal from the pool at 10:00 EDT so it appears to be working again.  I haven't tried a manual send from the pool but for now I won't worry about it..  Thanks!
53
We should technically re-sync better on this version (I mean the initial sync after upgrading only), as now we have classic's code for mandatory upgrades in.

BTW:  Please dont erase any files, just upgrade.

54
1.4.2.8b-Mandatory upgrade for TestNet

- Add testnet checkpoint
- Enhance ABN consensus rule to only require ABN when diff is greater
than threshhold (this should improve the SetBestChain business logic)
- Port biblepay-classic peer disconnect rules (enforcing network time
and minimum version)
- Ensure wallet does not crash in Prod when people click on Leaderboard
or Proposals
55
There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>
Code: [Select]
getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "[b]main[/b]",
  "genproclimit": 1,
  "networkhashps": [u][b]10394307548.78834[/b][/u],
  "hashps": 222.8212327270187,
  "minerstarttime": "05-07-2019 11:16:12",
  "hashcounter": 4675568,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "Submitting Solution 05-07-2019 17:04:52; ",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}

-version
Biblepay Core RPC client version [u][b]1.2.0.1[/b][/u]
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": [u][b]1418552.369007834[/b][/u],
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "[b]main[/b]",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3052,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}
Notice the great differences in networkhasps. Does this mean that early EVO (>v1.4.2.7) upgraders are at a severe disadvantage in terms of POBH mining when competing with v1.2.0.1? Or is this because I am the sole v1.4.2.7 on the mainnet? Difficulty appears to be similar though....

Can you kindly explain? Thank you. Testing is also a good educational experience for us all!

First of all, know that mining in Evo against prod (solo or against the pool) is virtually the same as mining in classic (as far as HPS, efficiency, and fairness) - there is no advantage to either client (except Evo might be 1% better due to its more optimized compiler and Depends environment etc).

Regarding the Network HashPS, first let me try to explain how Bitcoin calculates it.  Its a trailing average of chain hashpersecond found in the last 10 blocks or so (the blocks contain this data because we track the nonce req count and chain weight etc).  But, where this discrepency starts occuring is back in POBH v3, Alex and I were doing some testing and we realized due to our very unique hash algorithm we put waaaay more hashes in per hash than the networkhashps reported so we tweaked it in classic to be our new fangled estimate.

So the answer is in Evo its too low.  I remember now why this was not updated:  POBH changed in Evo.  I just made a punchlist item to fix this.
But in summary, its a barometer being affected by the wrong multiplier currently.

EDIT:  Actually Evo looks pretty accurate as-is (it seems this fig is too high in Classic).  Since I have the exact HPS in the pool, and the % of blocks solved by pool.bibepay.org, we really are doing about the Evo-hps right now in prod.







56
There are some differences in the output of the getmininginfo

>EVO -version
BiblePay Core RPC client version 1.4.2.7
>getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 10394307548.78834,
  "hashps": 222.8212327270187,
  "minerstarttime": "05-07-2019 11:16:12",
  "hashcounter": 4675568,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "Submitting Solution 05-07-2019 17:04:52; ",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}

-version
Biblepay Core RPC client version 1.2.0.1
biblepay-cli getmininginfo
{
  "blocks": 117855,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 9372.552218530582,
  "errors": "",
  "genproclimit": 2,
  "networkhashps": 1418552.369007834,
  "hashps": 187.8965827796162,
  "minerstarttime": "05-07-2019 14:17:00",
  "hashcounter": 1903566,
  "pooledtx": 1,
  "testnet": false,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "miningpulse": 3052,
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "poolmining_use_ssl": true
}

Notice the great differences in networkhasps. Does this mean that early EVO (>v1.4.2.7) upgraders are at a severe disadvantage in terms of POBH mining when competing with v1.2.0.1? Or is this because I am the sole v1.4.2.7 on the mainnet? Difficulty appears to be similar though....

Can you kindly explain? Thank you. Testing is also a good educational experience for us all!


57
General Support / Biblepay Pool autowithdrawal / withdrawal not working
« Last post by eyedoctrader1 on May 07, 2019, 11:54:34 am »
Hello.  I'm hoping this is the proper place to post this.  I just noticed that starting about 3 days ago the daily autowithdrawals from the biblepay pool to my account have stopped.  My pool balance continues to increase and is now up to 21K.  Today I decided to perform a manual withdrawal.  When I hit send it returns an error message saying invalid address.  I have verified my receiving address is correct and is the one I've always been using and have not changed.  Is anyone else experiencing this issue?  How does it get fixed?  Thanks for any help to address this.
58
$ ~/biblepay-evolution/src/biblepay-cli getblockcount
117799

$ ~/biblepay-evolution/src/biblepay-cli getblockhash 117799
1a038e93b4046038444f7a98abd546aa2a7a8580ade7771224a73685b79314b5

I don't know what exactly is required but here is the output of getmininginfo of EVO on the main chain pointed to purepool.

{
  "blocks": 117798,
  "currentblocksize": 1000,
  "currentblocktx": 0,
  "difficulty": 10211.68938254838,
  "errors": "",
  "pooledtx": 0,
  "chain": "main",
  "genproclimit": 1,
  "networkhashps": 14937188254.95241,
  "hashps": 28.84073865488929,
  "minerstarttime": "05-07-2019 10:24:22",
  "hashcounter": 4865,
  "pooledtx": 0,
  "chain": "main",
  "biblepay-generate": true,
  "poolinfo1": "",
  "poolinfo2": "",
  "poolinfo3": "",
  "gsc_errors": "",
  "poolmining": true,
  "pool_url": "https://pool.purepool.org",
  "required_abn_weight": 0
}


The progress can be followed here http://www.purepool.org/main/miner/BD9gmJ5vmPJtDewo9NyqUT7fJQgV39AW7R


Thanks a lot for doing this!  This is immensely helpful!

It appears from Purepools stats that you have successfully mined!

Sweet!


59
Interesting, I managed to send funds (BBP not tBBP) from my wallet on the mainnet to the wallet running EVO!

~/biblepay-evolution/src/biblepay-cli getinfo
{
  "version": 1040207,
  "protocolversion": 70732,
  "walletversion": 61000,
  "balance": 100.00000000,
  "privatesend_balance": 0.00000000,
  "blocks": 117804,
  "timeoffset": 0,
  "connections": 11,
  "proxy": "",
  "difficulty": 9338.691900918453,
  "testnet": false,
  "keypoololdest": 1557217142,
  "keypoolsize": 999,
  "paytxfee": 0.00000000,
  "relayfee": 0.01000000,
  "errors": ""
}

~/biblepay-evolution/src/biblepay-cli listtransactions
  {
    "account": "",
    "address": "BC2RsquwDER8sCKcMmDCy9rgKSusWLZpGn",
    "category": "receive",
    "amount": 100.00000000,
    "label": "",
    "vout": 1,
    "confirmations": 2,
    "instantlock": false,
    "blockhash": "49d1f7e4d26f8547da3ae9c25a40232080706293a95859f2e0c0770aa05d5270",
    "blockindex": 1,
    "blocktime": 1557225899,
    "txid": "29f1b61e84d4f6eae1ef9eb49b8ef3f9f49366576b3eeb57282e2e7367f9c917",
    "walletconflicts": [
    ],
    "time": 1557225892,
    "timereceived": 1557225892
  }

Yes, thats awesome, thanks for the tests.

Yes, the hash algorithm and miner is backwards compatible in evo up to a certain height.  After a certain height, we do switch to a newer version of POBH (with ABN), and the chained verses, but Evo works in all ways with the biblepay-classic nodes, Except it cant receive governance data from the classic sancs.

Hence the reason we have to fire up 50 or so Evolution sanctuaries for our mandatory cutover height (first).
So basically, the Evo sancs will become the official sancs at the cutover height.

60
~/biblepay-evolution/src/qt/biblepay-qt loads ok but perhaps to be expected crashed when you try to view leaderboard and proposals.

Ok, thanks a lot, that is something we missed, I am adding this to the list right now. 

Thats great that you synced to the top though, awesome!

On a side note, Dash added more messages and a protocol change to governance, so Evo cant load the governance objects from Biblepay-classic nodes (thats why the proposals dont show yet in prod). 


Pages: 1 2 3 4 5 [6] 7 8 9 10