Announcement - Bitcoin project to full fork to flexible blocksizes

[VeritasSapere]

@Christoph Bergmann It is good to be clear with our definitions here. If you send Bitcoins with Satoshi's vision to Bitcoin before the fork it will also be on Bitcoin since they will still be part of the same currency and network, after the fork the currencies are separate and therefore transactions are not shared between these two currencies.

A good way to understand this, is that the chain simply splits in two, creating two separate currencies with the same distribution of the old Bitcoin, meaning that any private keys before the split that have coins attached to them will have those coins attached to them under the new genesis fork.

It is not possible to transact directly between chains after the split. It is possible to transact between chains in the same way that it is possible now to convert Bitcoin to any altcoin using a service like shapeshift for example, cryptocurrencies are highly inter operable after all.

After the split there will be the same amount of Bitcoins in each separate chain, each with their own twenty one million limit minus any lost coins of course.

I will be doing a more in depth write up explaining the mechanics of genesis forks in more detail soon.

 

[freetrader]

@Christoph Bergmann :

Or, you can of course run a plurality of clients (Satoshi's Bitcoin and e.g. Classic) as long as you keep them nicely separated (separate IPs are a must at least since they currently use the same ports).

The nice quantum future is not quite here yet - much software still needs to be written to make that easy
In that future you could have wallet software which operates directly on several blockchains.

 

[rocks]

If you make an adress with satoshi's vision and I send you bitcoins - is the transaction also made in bitcoin core?

Just to expand on @VeritasSapere response a bit.

Any coins (actually spendable outputs) you have at the point of the fork will exist on both chain. For these outputs if you spend that output on one chain, that transaction is spendable on the other. In fact it is likely that there will be some connections between partitions and transactions send will spend on both chains. This in fact has happened during my tests.

Any new coins (again spendable outputs) that confirm AFTER the fork, will only be spendable on the chain they were confirmed on.

The easy way to see it is whether a coin is spendable depends on where and when the original confirmation took place. If the original confirmation took place before the fork then the coin exists on both chains. If the original confirmation took place after the fork, then the coin only exists on that chain.

So at first most coins will be spendable on both, but over time the networks will fully partition and separate.

 

[VeritasSapere]

@Christoph Bergmann @rocks There is indeed that exception at the point of the fork itself, the status of coins transacted before and after the split will be much more clear. Fortunately transactions that do happen on both chains at the time of the split itself should not effect users negatively, at least they will see the transaction on the whatever chain they are using.

I am planning on keeping a fraction of my Bitcoins in deep cold storage for at least a decade or longer. There could be more genesis forks in the future beyond the ones we are discussing here, most likely over completely different issues, by keeping the old keys from the original Bitcoin before the split it ensures that you will have coins in any of the future genesis forks that might happen in the future as well, like branches in a tree.

If you think about it a genesis fork really is a win win scenario for the users, as long as their private keys are managed well, it definitely is one of the nice things about this mechanic.

 

[freetrader]

The easy way to see it is whether a coin is spendable depends on where and when the original confirmation took place. If the original confirmation took place before the fork then the coin exists on both chains. If the original confirmation took place after the fork, then the coin only exists on that chain.

It guess the before/after is easy to establish, but whether an "after" confirmation took place on one chain only, or on both - it requires looking carefully at what happened to the transaction during the transition period, doesn't it? (because as you say, it could be that the transaction still "tunneled" across to the "other" network...

 

[molecular]

@molecular This looks like it may be your node
https://bitnodes.21.co/nodes/188.40.93.205-8334/

If so, you might have the wrong branch from github.

yep, my node. forgot to stop it.

I'm using master branch. <- scratch that. master isn't right. Using 0.11.2_PublicTest_At403562 now.

I like this commit: https://github.com/satoshisbitcoin/satoshisbitcoin/commit/1241eae310d3de6e017c56e62502541d2433e85e , especially that comment .

Who currently has access to the postfork alert key?

Good idea to put a stop to the trial after 1000 blocks, too.

 

[rocks]

@molecular
Great to see someone has actually been looking at the code

I have the alert key and will possibly test using it towards the end of the trial.

As said in the readme, if this branch takes off and the original developers who have stayed true to satoshi's plan want to take over, I am happy to pass control over. That includes the alert key

 

[AdrianX]

The public test trial fork for Satoshi’s Bitcoin is now ready for use.

To participate you only need to compile and start the trial client, everything has been setup to automatically run from there. The public trial fork is scheduled for this coming Sunday at around noon eastern time US (block 403562 specifically). The actual launch will follow this test and activate mid-April. I have run many trial tests and everything is working great. To participate in the test:

• Download and compile the public test branch “0.11.2_PublicTest_At403562” from github. The build environment is identical to Classic (link below).
• Backup your datadir, after the fork the datadir may not be compatible with the core client anymore
• Run bitcoind or bitcoin-qt

The public test branch is here:
https://github.com/satoshisbitcoin/satoshisbitcoin/tree/0.11.2_PublicTest_At403562

You can compare all code changes from Classic 0.11.2 here:
https://github.com/bitcoinclassic/bitcoinclassic/compare/0.11.2...satoshisbitcoin:0.11.2_PublicTest_At403562

I hope you will join the public trial, there is zero risk to participate and you are able to run a true full node that mines blocks at home again for fun. If the project does not take off there is nothing lost, but if it does you have the chance to mine early adopter blocks.

Difficulty for the trial is set so a smaller number of nodes will find blocks every 10 minutes. If more nodes join it will create faster blocks, this is being done intentionally to both stress test a fast block scenario and to allow the test to run through a few difficulty adjustments without waiting months. Also the test client will only run for 10K blocks post-fork before automatically stopping to prevent the test chain from continuing.

For the actual fork difficulty will be adjusted so the number of nodes that join the trial test mine at the expected 10 minute interval.

It was a lot of fun digging into the code to figure out how to implement this fork. Below is a list of some of the main work that went in. If you feel something else is needed please let me know.

• Following BIP009 conventions for parallel soft forks, a higher block version byte is used to tag blocks as full fork compatible. Version 0x00000100 (256) is used for the fork.
• The block height for the fork is set to 403562. At this point only blocks tagged for the full fork are accepted
• The block size post-fork automatically increases to 2MB (follows Classic)
• A new DNSSeed server was setup to help forked peers find each other after the fork
• The difficulty adjustment at the fork point is re-set to a value where the expected number of nodes will create blocks every 10 minutes.
• A difficulty retargeting overflow bug in core was found and fixed
• A new modified scrypt POW algorithm was implemented in the crypto library to re-enable CPU mining
• The new POW algorithm activates at the fork height by using the new version tag to select which algorithm
• To improve performance due to how long the new hash algorithm takes (~1 sec / hash), a caching method was implemented to save previous block hashes.
• Startup performance issues related to the new POW were found and fixed
• Multiple performance improvements were made to the bitcoind miner
• The difficulty adjustment band was increased to allow for faster difficulty adjustment in case hash power increases rapidly
• Informational debug.log messaging was improved to better communicate block rejection after the fork
• The alert key was update since it has been compromised by Theymos

Assuming the public trial is successful, the official release client will be made publicly available within a few days. The release version will be identical to the public test with just the fork height changed and the automatic stop removed. The official release will be set to fork in mid-April. This will provide several weeks to enable and build the ecosystem. The idea is that as more clients appear on the P2P network this will generate interest and encourage others to run a client as well.

If you would like to help make this project a reality, here are a few things that would be great if interested people could help with

• Setup a simple satoshisbitcoin.org website with the purpose and download links
• Create installation binaries for people to install
• Run multiple DNSSeed servers
• Promote the client

is there a windows build?

 

[rocks]

@AdrianX
The bitcoinclassic repo now includes build instructions for windows, which it didn't in the 0.11.2 branch that was forked. You can find the windows build instructions for classic here, the steps for satoshi's bitcoin should be identical.
https://github.com/bitcoinclassic/bitcoinclassic/blob/develop/doc/build-windows.md

I haven't tried this myself yet, but obviously will need to build this for the actual launch. If you have problems let me know and I'll see if I can build a windows version for you.

[USER=59]@theZerg kindly provided instructions on how to make linux installation builds, he did this perfectly for BU. Will have to figure this out for Windows too.[/USER]

 

[rocks]

yep, my node. forgot to stop it.

I'm using master branch. <- scratch that. master isn't right. Using 0.11.2_PublicTest_At403562 now.

I like this commit: https://github.com/satoshisbitcoin/satoshisbitcoin/commit/1241eae310d3de6e017c56e62502541d2433e85e , especially that comment .

Who currently has access to the postfork alert key?

Good idea to put a stop to the trial after 1000 blocks, too.

My nodes found yours! Thanks for running a node and joining the trial. FYI I added your node to the list of seeders participating in the trial. You can see this by running "nslookup seed.satoshisbitcoin.org" and you should see your IP in the list.

 

[molecular]

...
[doublepost=1458285067][/doublepost]

My nodes found yours! Thanks for running a node and joining the trial. FYI I added your node to the list of seeders participating in the trial. You can see this by running "nslookup seed.satoshisbitcoin.org" and you should see your IP in the list.

Oh, I guess my node found yours, not the other way around: I have your nodes in bitcoin.conf. Maybe I should remove them to get a better understanding of the joining-behaviour? What about peers.dat

 

[rocks]

To better help the network partition after the fork, the client stops using the list of peers in peers.dat and creates a new list in a new file. It then connects to a new dnsseed server I run to provide IP addresses. Before the fork it will provide a mix of standard nodes and forking nodes, but after the fork will only provide forked nodes. This will help nodes find the right peers and minimize the number of connections made to nodes on a different branch. After a bit nodes should connect to the new partition only

 

[freetrader]

@rocks:

Is there a way to back up only a subset of the datadir in such a way that only the subset of files which will be modified are backed up, without having to back up the entire ~70GB?

e.g. if I back up last week's modified files in blocks/ , plus the entire chainstate/ and the .dat files, would restoring that (and deleting any files that weren't there before running the fork) get me sufficiently restored to the old chain?

If that were possible it would make it easy to play around with it on my somewhat space-constrained cloud node.

---

Another question:

I remember reading (I think it during discussions of changing the alert key for BU) that if the key was changed, an alert message sent between nodes with different keys would cause these nodes to distrust each other and speed up partitioning of the network.

Have you considered this effect in your change of the alert key, and are you planning to make use of it to speed up the segregation from the old network?

Would a public test of this feature have a persistent effect (on the non-SatoshisBitcoin nodes) that might pose a problem for later production running?

 

[rocks]

Good questions.

For the datadir files, I'm not sure you can try it and let us know how it goes.

For using the alert key, I hadn't considered that but it is a good idea. What I saw from the trials so far is the nodes partition pretty quickly on their own. Each block they send across the partition is invalided by the other node and the connections are dropped pretty fast. But if we need to speed the the process up using the alert key is a good method.

 

[rocks]

Just 110 blocks to go till the test fork.

BTW, I have had a horrible time trying to make a Windows build. It is not a Satoshi's Bitcoin issue but a Classic 0.11.2 issue which it is based on. I even tried building Classic 0.11.2 for windows and haven't been able to. From looking at the core and classic repos it looks that Windows instructions were added for the 0.12 branch but are not in the 0.12 branch.

If anyone is able to successfully build either Classic 0.11.2 for Windows or Satoshi's Bitcoin 0.11.2 for windows please let me know. I have spend a couple days on this off and on and haven't gotten anywhere. Linux build of course is fine....

 

[molecular]

I'm ready with 2 nodes. 1 is in a datacenter in germany, high bandwidth (the one I used before: nil.0x0000.de). The other will actually be on my crappy (6mbit down, 700 kbit up) dialup connection.

I'd like to evaluate at least

• hashrate
• orphan rate

is that doable after the fact through debug.log or should I take some additional preparations?
[doublepost=1458466563,1458465614][/doublepost]hmm. bitcoind is saturating 1 cpu to 100%. Is that the miner running?

 

[ethought]

Not able to sync at the moment.

Has anyone got some active nodes?

Thanks

 

[sickpig]

Just 110 blocks to go till the test fork.

BTW, I have had a horrible time trying to make a Windows build. It is not a Satoshi's Bitcoin issue but a Classic 0.11.2 issue which it is based on. I even tried building Classic 0.11.2 for windows and haven't been able to. From looking at the core and classic repos it looks that Windows instructions were added for the 0.12 branch but are not in the 0.12 branch.

If anyone is able to successfully build either Classic 0.11.2 for Windows or Satoshi's Bitcoin 0.11.2 for windows please let me know. I have spend a couple days on this off and on and haven't gotten anywhere. Linux build of course is fine....

@rocks

@Peter Tschipper is able to build BU on windows just fine using mingw, maybe you should give it a try.

 

[Peter Tschipper]

@rocks Have you looked at this: https://bitcointalk.org/index.php?topic=149479.0

EDIT: I forgot I reported this issue months ago and it's never been fixed. I've gotten so used to the workaround that it slipped my mind. We should probably submit a workaround to BU, it's quite an annoyance to have to do this each new build on mingw for windows https://github.com/bitcoin/bitcoin/issues/6458

 

[freetrader]

@rocks, others:

Any last minute recommendations on any debugging options that should be used for the public run, to capture useful data?