[XBC] BitcoinPlus Official Thread

[egghead123]

There will be about 75 hours of work to be done before new client is ready for stress testing so after months we are at the final stages.Once testing is complete and things run well in beta and dangers of forking are minimised we should be good for release into the wild.

Came across another "ERROR: CDataStream::read() : end of data" error when loading the wallet but we can safely ignore this one. Bitcoin changed the format of keys in the wallet from [pubkey] => [privkey] to [pubkey] => [privkey][hash(pubkey,privkey)] in a backwards compatible way. It tries to read the missing hash on old wallets which fails and throws the above error.
After a few updates to the client it says it is staking, if it actually generates a block is another matter and if that block is accepted by the rest of the network another matter still, but I can see in the logs that it is trying to mine a PoS block.

[BitcoinPlusBus]

2018-07-09 15:23 UTC

Difficulty
POW: 0.01442156
POS: 0.00024585
Coin Supply (XBC)
111603.47926356
628178 blocks
31 connections

Last Price
0.00387862
24hr Change
-1.88%
24hr High
0.00394546
24hr Low
0.00387862
24hr Volume:
0.20878871 BTC / 53.63731552 XBC

[BitcoinPlusBus]

Something is amiss with the address import, we have compared against another coin, when importing an old wallet.dat the client goes through a rescan of the blockchain and you do not see the "ERROR: CDataStream::read() : end of data" message as we guess it imports and updates addresses as it goes along. Will investigate and find where the process is broken.

Create a new wallet and you do not get the "ERROR: CDataStream::read() : end of data" on keys but there are two other occurrences of it before and after key loading. The one after occurs when loading an old 0.7 based wallet or a newly created 0.13 wallet but not when a wallet.dat is not present, the one prior happens every single time.

Without the rescan the client relies on the TXs listed in the wallet and does not even spot incoming TXs however it can find coins in the wallet to try and generate PoS blocks. Wallet handling is where we are focusing on now.

[BitcoinPlusBus]

2018-07-10 05:19 UTC

Difficulty
POW: 0.01442156
POS: 0.00025362
Coin Supply (XBC)
111618.89953594
628513 blocks
27 connections

Last Price
0.00385000
24hr Change
-0.77%
24hr High
0.00394441
24hr Low
0.00384121
24hr Volume:
0.26462890 BTC / 68.06420822 XBC

[BitcoinPlusBus]

2018-07-11 05:12 UTC

Difficulty
POW: 0.01442156
POS: 0.00026592
Coin Supply (XBC)
111649.68419056
629090 blocks
24 connections

Last Price
0.00376174
24hr Change
-2.29%
24hr High
0.00385000
24hr Low
0.00366947
24hr Volume:
0.44635973 BTC / 118.68239008 XBC

[BitcoinPlusBus]

2018-07-12 05:27 UTC

Difficulty
POW: 0.01442156
POS: 0.00024414
Coin Supply (XBC)
111680.34555719
629745 blocks
33 connections

Last Price
0.00372750
24hr Change
-0.91%
24hr High
0.00387863
24hr Low
0.00366948
24hr Volume:
0.31436246 BTC / 84.36701983 XBC

[BitcoinPlusBus]

2018-07-13 05:52 UTC

Difficulty
POW: 0.01442156
POS: 0.00024414
Coin Supply (XBC)
111717.18610142
630481 blocks
28 connections

Last Price
0.00399452
24hr Change
+2.99%
24hr High
0.00435333
24hr Low
0.00362286
24hr Volume:
1.42679735 BTC / 363.31566708 XBC

[BitcoinPlusBus]

Peter has got some good ideas on how to solve the first "end of stream" error but is also very interested in when it started as Bitcoin does not have those errors.

He is going to start what will be the final commit history of XBC on 0.13 now that we have certain things completed. We will change name, logo, PoW subsidy and other basics then apply XBC bespoke components like blocks, transaction, PoS and so on compiling and testing at each addition to check that everything works and if not be able to identify where errors creep in.

If we have to refactor at the end of the commit chain we will rebase to keep it tidy and keep the new branch the final version.

We set up seeders on some nodes and new 0.13 branch has XBC blocks, transactions, X13 and chainparams. Enough to fire up on the XBC network but not enough to sync yet. No "end of stream" error but in a state that we can run and debug if it does appear.

[BitcoinPlusBus]

2018-07-14 05:00 UTC

Current Block
631244
Difficulty
0.00024414
Supply
111745.70609755
Connections
29

Last Price
0.00386286
24hr Change
-4.35%
24hr High
0.00428707
24hr Low
0.00385000
24hr Volume:
1.08473884 BTC / 274.06992856 XBC

[BitcoinPlusBus]

In the process of adding PoS block sync support. Last time there was just one unholy "Convert to XBC" commit with everything in it from primitives to Qt modifications. Never a good look.


Small incremental changes so we have some hope of replicating this again on another codebase in the future. Commits are applied such that it should compile after each one for testing, this does mean that some commits will be larger than others but there's no point having a commit that cannot be compiled as there's no way to test the binary.

[BitcoinPlusBus]

2018-07-15 12:41 UTC

Current Block
632339
Difficulty
0.00024414
Supply
111793.83321549
Connections
31

Last Price
0.00385001
24hr Change
-0.40%
24hr High
0.00391835
24hr Low
0.00385000
24hr Volume:
0.17267650 BTC / 44.29463334 XBC

[BitcoinPlusBus]

Got the PoS block sync completed. Still seems like there's a lot to go in. There's still some tidying and changes to go into the next branch but only minor.

That "end of stream" error has not returned yet and we just added PoS variables to the database.We now know where it was coming from, the "fix" the developer supplied for the version message basically removes the throw statement from the Read serialisation function. Other new BTC elements actually rely on that throw for backwards compatibility, like key storage adds a new hash of pub and priv key, read an old key and the hash is not present so you get a throw from the Read function, execution stops and you catch the error with an empty catch statement.


The fix provided kept trying to progress beyond the failure when it should have halted execution. To be fair it would have been very hard to spot this obscure knock on effect and Peter can code a better way to handle the version error now using an empty catch statement.
Staking next, then RPC, then Qt, then make sure that staking is working. Get AcceptBlock/CheckBlock bespoke rules from the old client and rebase everything once more.

[BitcoinPlusBus]

2018-07-16 05:17 UTC

Current Block
632880
Difficulty
0.00024414
Current Supply
111824.52691142
Connections
29

Last Price
0.00386181
24hr Change
+0.31%
24hr High
0.00399999
24hr Low
0.00380000
24hr Volume:
0.28089432 BTC / 72.59171605 XBC

[BitcoinPlusBus]

2018-07-17 05:45 UTC

Current Block
633640
Difficulty
0.00024414
Supply
111853.33074338
Connections
30

Last Price
0.00413776
24hr Change
+6.10%
24hr High
0.00419055
24hr Low
0.00383106
24hr Volume:
0.44355709 BTC / 110.35206690 XBC

[BitcoinPlusBus]

We need to create NS records to point to the seeders. The seeders have A records but the client needs NS records that point to those A records. We can then verify that the DNS seeders are working correctly and update the records in chainparams.cpp to the NS addresses. The new NS records will not interfere with the old A records.
We've added an empty catch statement for reading the subvert without changing the read function. We should not encounter the previous "end of data" error on this new branch.Have to make a note of future versions.We've told the client to set the subver string based on the PROTOCOL_VERSION, when incrementing a release increment the PROTOCOL_VERSION accordingly. We would assume that come 2.9 this bespoke handling of subver could be dropped.

It's a bit cumbersome but a temp fix until some future version and the main thing is that it works as does not interfere with reading serialised data.
Time to add staking We've already got the code to copy across.
The client thinks it is staking. If it generates a block we'll know for sure, or when we see errors in the log about the block it though it generated.

We've added a small fix for TXs, another bespoke feature is to set the TX time to the network time, do not do this and the network will possibly reject the TX. We've successfully sent a TX from 2.7 to 2.6 and then back from 2.6 to 2.7. At this point in the previous codebase the client could not send or receive but that was likely due to the "end of data" error which is now rectified.

Some commits should be combined. We can work on a perfect history once it is working. Compiling and testing with an existing wallet, it should stake though you will not see anything in the log unless you set the debug argument.
Next up is updating RPC for PoS. Then you could at least check staking via the console/cli.
Then PoS in the Qt GUI.
Then acceptblock/checkblock and any other bespoke checks in the original client that needs to be restored.
Once done we may need to find some beta testers with big wallets that stake regularly to give feedback.
Code for RPC and Qt is done in the master-0.13-experi branch though do not build from that branch as it has issues that have been resolved in the 0.13 branch.

[BitcoinPlusBus]

2018-07-18 11:55 UTC

Difficulty
POW: 0.01442156
POS: 0.00024414
Coin Supply (XBC)
111893.21402616
634630 blocks
23 connections

Last Price
0.00409555
24hr Change
+2.49%
24hr High
0.00430000
24hr Low
0.00385923
24hr Volume:
0.83233602 BTC / 205.00885344 XBC

[BitcoinPlusBus]

Here is the first block minted by 0.13.
http://block.bitcoinplus.org/block/210e4569feab64e24ae282335d9270cca7cd46bc58ad4a42a28c41bab8658850

Minting PoS in 0.13 is a big milestone for us.

The first VersionBits block. Check the version on block 634770.

http://block.bitcoinplus.org/api/getblock?hash=285d2e7b396aca69bfe51089c8d166f1c28fa503c291e16b56f900423bb80058
"version": 536870912

That is the baseline VB which in hex is 0x20000000. The CSV soft fork adds 1 and 2 which will be 0x20000003 or 536870915 in decimal when we start signalling soft fork support.

We've set those soft forks to start signalling next month.

[MarketMagic]

Here is the first block minted by 0.13.
http://block.bitcoinplus.org/block/210e4569feab64e24ae282335d9270cca7cd46bc58ad4a42a28c41bab8658850

Minting PoS in 0.13 is a big milestone for us.

The first VersionBits block. Check the version on block 634770.

http://block.bitcoinplus.org/api/getblock?hash=285d2e7b396aca69bfe51089c8d166f1c28fa503c291e16b56f900423bb80058
"version": 536870912

That is the baseline VB which in hex is 0x20000000. The CSV soft fork adds 1 and 2 which will be 0x20000003 or 536870915 in decimal when we start signalling soft fork support.

We've set those soft forks to start signalling next month.

Schweet.

[BitcoinPlusBus]

2018-07-19 05:24 UTC

Current Block
635238
Difficulty
POW: 0.01442156
POS: 0.00024414
Supply
111924.81785877
Connections
27

Last Price
0.00408368
24hr Change
-1.04%
24hr High
0.00416106
24hr Low
0.00400029
24hr Volume:
0.49033645 BTC / 120.19275790 XBC

[BitcoinPlusBus]

2018-07-20 05:40 UTC

Current Block
635987
Difficulty
0.00024414
Token Supply
111956.30771811
Connections
28

Last Price
0.00406410
24hr Change
-0.55%
24hr High
0.00442364
24hr Low
0.00399225
24hr Volume:
1.09970513 BTC / 264.02308163 XBC