Announcement - Bitcoin project to full fork to flexible blocksizes

[molecular]

ddd
[doublepost=1457871266,1457870455][/doublepost]

Hmm, that is not great. We are generating blocks faster than normal but not that fast, orphan rates shouldn't be that high. I will check my nodes tomorrow and report back on their orphan rates.

How many CPUs cores and how many miner threads are running. I have just one miner thead per node.

One issue is the new PoW takes ~1-2 sec to process a single hash. I adjusted the miner so it runs for only 16 hashes before stopping to check for new transactions to include or a new block. That means the miner runs for up to 30 seconds blindly. We probably want to bring that down. Also multiple miners will stall and compete with each other for the memory block, so if you have multiple threads that delay goes up. This is on my to do list to improve.

that explains it...

We're actually hashing much faster than 3-4 minutes per block.

Back of the envolope, still using the numbers from before: my node found 29 blocks in roughly 5 hours.
I found 10 of the 72 blocks of the valid chain, so I had 14% of the hashing power. So in total we probably found around 200 Proofs of Work during that period. That's 1.5 minutes per PoW.

I guess we just got a lot closer to explaining the high orphan rate (65%)

I think I'm running one miner thread only. (set gen=1, is that the number of threads?)

----------------

Strange: my node stopped finding proofs around 11:00 (2 hours 15 minutes ago). Still found only those 10 blocks. Still well-connected to your 6 nodes. Not sure what's up...

 

[molecular]

EDIT: see EDITs at end of post

hmmm.

I updated to your newest git and now I'm having trouble:

2016-03-13 12:55:02 CreateNewBlock(): total size 1000
2016-03-13 12:55:02 HashModifiedScrypt(): Allocating large memory region
2016-03-13 12:55:02 HashModifiedScrypt(): Allocated 128MB at 0x7fafcbfff010
2016-03-13 12:55:03 BitcoinMiner 0: Running with 1 transactions in block (182 bytes)
2016-03-13 12:55:03 BitcoinMiner 0: nVersion - 00000100
2016-03-13 12:55:03 BitcoinMiner 0: hashPrevBlock - 000000000000000003efead50db13683e434d60cb966d9d4315bff37bffa026f
2016-03-13 12:55:03 BitcoinMiner 0: hashMerkleRoot - a032d4b254a4fa404fbf662d647e1be9cae4ec8f281bade9b758550e4872c1e9
2016-03-13 12:55:03 BitcoinMiner 0: nTime - 1457873702
2016-03-13 12:55:03 BitcoinMiner 0: nBits - 1806f0a8
2016-03-13 12:55:03 BitcoinMiner 0: nNonce - 00000000
2016-03-13 12:55:03 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=402473, us=[2a01:4f8:100:70ed::2]:8334, peer=1
2016-03-13 12:55:03 Added time data, samples 2, offset -533 (-8 minutes)
2016-03-13 12:55:03 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=402473, us=[2a01:4f8:100:70ed::2]:8334, peer=4
2016-03-13 12:55:03 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=402474, us=[2a01:4f8:100:70ed::2]:8334, peer=8
2016-03-13 12:55:03 receive version message: /bitnodes.21.co:0.1/: version 70002, blocks=402474, us=188.40.93.205:8334, peer=11
2016-03-13 12:55:03 Added time data, samples 3, offset -30 (+0 minutes)
2016-03-13 12:55:03 keypool added key 145, size=101
2016-03-13 12:55:03 keypool reserve 45
2016-03-13 12:55:03 keypool return 45
2016-03-13 12:55:04 receive version message: /SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/: version 70002, blocks=402566, us=188.40.93.205:59187, peer=12
2016-03-13 12:55:04 Added time data, samples 4, offset -1 (+0 minutes)
2016-03-13 12:55:05 ERROR: CheckProofOfWork(): hash doesn't match nBits
2016-03-13 12:55:05 ERROR: CheckBlockHeader(): proof of work failed
2016-03-13 12:55:05 Misbehaving: 52.36.121.43:8333 (0 -> 50)
2016-03-13 12:55:05 ERROR: invalid header received
2016-03-13 12:55:05 ProcessMessages(headers, 13609 bytes) FAILED peer=12
2016-03-13 12:55:07 receive version message: /SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/: version 70002, blocks=402570, us=188.40.93.205:50496, peer=14
2016-03-13 12:55:07 Added time data, samples 5, offset -1 (+0 minutes)
2016-03-13 12:55:07 nTimeOffset = -1 (+0 minutes)
2016-03-13 12:55:07 ERROR: CheckProofOfWork(): hash doesn't match nBits
2016-03-13 12:55:07 ERROR: CheckBlockHeader(): proof of work failed
2016-03-13 12:55:07 Misbehaving: 52.26.44.93:8333 (0 -> 50)

So my node is kicking all your nodes and I end up connected to only core nodes

chain of events:

• I noticed I wasn't mining any more
• since I saw the 5 -> 256 version change I git pulled new version from your repo
• wouldn't start, asking to "resync the blockchain", then quitting or something. Not in debug.log for some reason.
• copied over blockchain data from satoshi client
• this resynced up to : UpdateTip: new best=000000000000000003efead50db13683e434d60cb966d9d4315bff37bffa026f height=402472
  
• observe all your nodes getting kicked (see log above)

hmm...

EDIT: AAAH, I see what's happened. Damnit. I got the core chain ;-(. Let's see if I can get it to reorg back by connecting ONLY to you. will be a good step towards test #3

EDIT2: I think I'm banned by your nodes now. Cannot connect.

2016-03-13 13:14:44 socket recv error Connection reset by peer (104)

EDIT3: Now I'm wondering. Why did my satoshibitcoin accept the core chain beyond 402421. Just looked in my consensus.h (accidentally didn't update because file was locally changed, so it was still at forkpoint 402421, so it should've rejected any core blocks beyond that, no? Well, they were already in the database (I copied that from a classic node), so maybe that's why?) and I see you fixed the new forking point to HEIGHT_TO_FULL_FORK_1 = 407232

sorry for the wall of text and confusion on my part...

 

[rocks]

The current repo is incompatible with the version my nodes are running. This is because of the version number change I just put in to make sure there is no conflict with possible future core block version tags. I am not surprised your nodes were rejected by mine. I'll have this cleaned up for the next test.

 

[rocks]

ddd
[doublepost=1457871266,1457870455][/doublepost]

that explains it...

We're actually hashing much faster than 3-4 minutes per block.

Back of the envolope, still using the numbers from before: my node found 29 blocks in roughly 5 hours.
I found 10 of the 72 blocks of the valid chain, so I had 14% of the hashing power. So in total we probably found around 200 Proofs of Work during that period. That's 1.5 minutes per PoW.

I guess we just got a lot closer to explaining the high orphan rate (65%)

I think I'm running one miner thread only. (set gen=1, is that the number of threads?)

Yes, this was meant to be a functional test, there are still some obvious performance improvements to put in and I think you got hit by those. This was intentional, first test that functionally the new PoW works (and it did we were building a chain together), then add in some new performance improvements to the miner.cpp code. I did this to verify the changes one at a time. The next test should have lower orphan rates.

 

[molecular]

ok, very good, everything fine, then. Thanks for your explanations.

I'm looking forward to the test next week.

 

[rocks]

Quick status update, after making several more performance updates to the miner, finding and fixing an overflow bug in the POW re-targeting code (which exists in core but SHA256 diff levels won't run into), and creating a new DNSSeed so the forked clients can easily find each other, I ran a few more test forks involving 3-5 nodes. Everything worked perfect. The client seemed ready for general public use.

Then I tried restarting a node and ran into a boot time issue. When the core client starts, as it loads the blocks from disk it recalculates the hash for each block header on the fly. When your bitcoin-qt start it apparently re-computes the hash for the 400K headers it has. With SHA256 hashing that is not a problem. But since the modified scrypt algorithm takes ~1 second per hash, this quickly starts to take hours/days.

I came up with a straight forward solution that fits right in with the hash cache I already created, but it will take a couple days to implement and test. After that a publicly available trial fork will be available. Hopefully we'll be ready to go by the weekend.

 

[molecular]

ok, so new timeline: public test hopefully on the weekend. check.

There are some things that are still a bit unclear to me I'd like to ask about. One of them is how we'll handle Transactions.

• As I understand they will be compatible accross networks and we'll be mining the transactions from the legacy network?
• While the networks will partition, it's probably likely that at least one guy will cross-broadcast everything, right?
• I'm thinking about how people will react: for example when receiving legacyBTC (say I buy some on an exchange and withdraw BTC), when everything is still in sync, the withdraw tx will be valid on both forks.
• I for one would try to separate my coins between the forks by getting different tx' mined on the two forks and moving all coins in this way.
• One could even move coins back and forth between an exchange and the own wallet on the old fork and siphon off coins each time on the new fork, no?

You can probably tell I haven't yet thought a lot about how this would look like.

Can someone who has thought this through more thoroughly expand a bit on what would happen. How would people behave and so on?

 

[rocks]

Good questions, here are my thoughts on them.

• As I understand they will be compatible accross networks and we'll be mining the transactions from the legacy network?

Yes, initially after the fork and for some time afterwards transactions broadcast on one partition/chain will be confirmed on the other partition/chain. I just ran another test last night and my nodes were mining main chain transactions well past the fork point.

• While the networks will partition, it's probably likely that at least one guy will cross-broadcast everything, right?

This is a good question and there are a couple ways to go about it. At first I thought of changing the node's protocol version tag and kicking off older nodes (non-fork nodes). However I decided against this for a couple reasons. The first is you can not prevent cross spending across chains, someone will create a bridge to mine spendable transactions across partitions. The second is this approach is not dependable or secure, Bitcoin's security model is build on block headers, so that is the place to enforce the change.

This is why I ended up using the block version embedded in the header as the fork mechanism.

The DNSSeed will connect clients to a mix of old nodes and forked nodes before the fork. After the fork the DNSSeed will be updated to only connect forked nodes. This should hopefully minimize the number of cross connections, and eventually eliminate them. The forked client also resets the peers.dat file to clear out old nodes from the list to try. But someone will probably always create a bridge.

Both the old nodes and the forked nodes will reject each other for sending incompatible blocks. We can't stop the connections from happening, but the clients are smart enough to partition on their own.

• I'm thinking about how people will react: for example when receiving legacyBTC (say I buy some on an exchange and withdraw BTC), when everything is still in sync, the withdraw tx will be valid on both forks.

Unless you manually separate your coins onto different outputs on each chain, any transaction you spend on one chain can be spent on the other, there is no way to stop this.

This may be a big positive. Consider this scenario, let's say a few days before the fork transaction volume goes up and a huge backlog of transactions builds up in the mempool, 2-3 days worth. The main chain will be stuck with few transactions confirming. The forked chain however will process the backlog quickly.

We could then say "your transaction is stuck on Blockstreamcoin, but already confirmed on Satoshi's Bitcoin

• I for one would try to separate my coins between the forks by getting different tx' mined on the two forks and moving all coins in this way.

Anyone smart should do this. I plan to do this.

• One could even move coins back and forth between an exchange and the own wallet on the old fork and siphon off coins each time on the new fork, no?

Yes, you can do this at each fork point. My suspicion is only a small number of fork will have value. Litecoin got there by being the first, I am hoping Satoshi's Bitcoin benefits from the same being first advantage.

>You can probably tell I haven't yet thought a lot about how this would look like.
It seems you've thought through a lot

 

[VeritasSapere]

Just pointing out the obvious here, but make sure when the genesis fork really begins it is well publicized and very importantly that none of the coins have been mined before the announcement, since that can be considered as a type of pre-mine and would majorly set back this project.

Literally from the first block where the chain splits, it needs to be publicly announced and made highly accessible otherwise it can be considered as a type of pre-mine, which is highly unfair. People also need to know in advance so they can prepare their private keys adequately for the split.

@rocks We might steal some of that "first mover" advantage, by releasing our own genesis fork at the same time, however we feel strongly enough about keeping the original PoW algorithm that it justifies this action. This way the market has both options, and we will be able to test the viability of both hypothesis.
[doublepost=1458089473,1458088798][/doublepost]@molecular I think the best way to manage our own coins is to keep a copy of your private keys separately and backed up. This way those set of keys will give you access to those coins on any genesis forks that happens past this point.

You could even imagine that these keys could become very valuable in the future since they could represent value in several important chains, like branches in a tree, if you have private keys in the roots of the tree so to speak then you will have coins in all of the branches that grow from this foundation.

 

[rocks]

"Literally from the first block where the chain splits, it needs to be publicly announced and made highly accessible otherwise it can be considered as a type of pre-mine, which is highly unfair. People also need to know in advance so they can prepare their private keys adequately for the split."

That is not enough, you can't give people 10 minutes notice and then start to mine.

A better approach is to have it pre-announced for weeks to both gain traction and give anyone interested a chance to participate at the beginning. That is the approach I am taking and the only path that seems fair. I haven't even make the real announcement yet nor released the SW yet, but after both are in place there will be plenty of time for people to get started.

BTW, have you tested your fork on the main net yet? You come across quite a bit that needs to be done during trials.

 

[freetrader]

@rocks

I like the open way in which you are going about your fork.

A better approach is to have it pre-announced for weeks to both gain traction and give anyone interested a chance to participate at the beginning. That is the approach I am taking and the only path that seems fair. I haven't even make the real announcement yet nor released the SW yet, but after both are in place there will be plenty of time for people to get started.

I would dearly like to do the same for the POW-retaining fork, but I feel (perhaps I'm wrong on this) that because we will be directly competing with mainchain w.r.t. current mining power, we will be on the receiving end of many more attacks.

Therefore, to us, from the start an element of surprise seemed essential - we do not want to give potential attacking powers more preparation time than we absolutely need to.
Code release will be a much shorter (comparatively) duration before the activation of the fork. It has not been decided yet, but it's not going to be 10 minutes, more like days.

Thus our current plan is to carefully prepare our code and documentation, and only release when we deem they are up to scratch and the timing is right.

We might still change our mind about the degree of advance publicity which we want to attract. That is something we welcome open discussion about.

That is not enough, you can't give people 10 minutes notice and then start to mine.

We are planning to publish detailed documentation well ahead of time - days in fact - enough time to give everyone a chance to join the fork, if they decide so.
We think that should be enough to ensure a clean, fair fork.
If you have reservations, please elaborate on them - we want to do everything possible to ensure that our fork is clean and fair.

From my side, the intention of our fork was - and is - that it is a measure of last resort, to be released in a contingency if the chances of Classic preventing a calamity look dim.
I suppose we will take an internal vote in the project to determine the exact right moment.
I don't want to rush anything, I want our code to be expertly reviewed and tested beforehand, without actually putting it into the hands of untrusted parties in advance.

Unfortunately our strategy does mean that we are not able to attract as much participation in the early stages of development and testing. But our development is also not as complex as your POW fork work, at least we have that working in our favor.

We have hoped (and I know @VeritasSapere desires) that our fork activation height could be the same as your POW fork, but I am quite skeptical whether this is achievable in practice, for a variety of reasons.

Firstly, there is no way we can prevent another fork from releasing at any time, and we would not want to either. The best we can do is discuss and co-operate as we are doing now.

Secondly, we don't know yet if our own development timeline can line up with your plans. Indications are positive, but there are a lot of variables.

BTW, have you tested your fork on the main net yet? You come across quite a bit that needs to be done during trials.

No, and I fully agree. We hope to start within the next few days. We are thankful for the experiences we observe from your trials. We will also notify participants of your fork (probably PM initially) when we are starting our own tests, so you will be aware, and you will have a chance to participate if you wish.

 

[rocks]

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

 

[VeritasSapere]

@freetrader I think you are mistaken on this actually, if anything Satoshi's Bitcoin represents a much greater threat to the miners. I think the genesis fork with the original PoW will also need at least two weeks notice in my opinion before actual launch, which is when the chain actually splits.

A difference to our approach is that we are not officially announcing it before we have more of the documentation, planning and coding ready. Even though we are openly discussing it here.

After we officialy announce it and make a lot of noise I think the release should come, I would suggest two weeks after the official announcement would be a good timeline.

In regards to the timing I would like to release at the same time as Satoshi's Bitcoin but this does very much depend on what is happening with Bitcoin at the time. If the adoption of classic is looking more likely then we would not want to take hashing power away from that cause prematurely. So the timing does depend a lot on these different factors. I would like to give the market this option at the same time and share in the obvious advantages of being one of the first genesis forks. But it does very much depend on a number of different variable's so Satoshi's Bitcoin might enjoy that honor for itself after all.

@rocks I will be mining Satoshi's Bitcoin as well, I do support what you are doing here, obviously I think a genesis fork that does not change the PoW is better but regardless, I think what you are doing here is a great thing and it will certainly put more pressure on Bitcoin for change.

Will you be developing the optimizations required for GPU mining? I have not looked to closely at the algorithm yet but I presume it gives similar benefits to CPU/GPU like the cryptonight and dagger algorithms do? I would not mind deploying some of my GPU rigs towards Satoshi's Bitcoin and begin the inevitable process towards economies of scale and centralization around low electricity cost.

Joking around a bit there, I do run a small GPU farm next to my ASIC's however, with the state of Bitcoin right now it certainly is tempting to build more GPU rigs instead of investing into the next generation of ASIC's considering the profitability of Ethereum and the rise of genesis forks.
[doublepost=1458189039,1458188381][/doublepost]I am also planning on doing a few a write ups explaining the dynamics and mechanics of genesis forks. Including ideological justifications and practical advice. These write ups will obviously also benefit both of our projects so I am sure much of this material can be cross referenced since these two projects do have this in common.

 

[Cconvert2G36]

As much as I understand where the energy comes from. I can't help but think of this as a sort of bizarre inverse of something Mircea Popescu would do.

 

[freetrader]

@rocks : great work on your fork! I am planning to support your test as well.

@VeritasSapere :

As you know I am open to discussion re: the announcement and release strategy of our non-POW fork.

Regarding the threat level posed, I think a lot of people are going to be fed the opinion that any such hard fork, whether PoW or not, is 'malicious'.

This is of course a narrow-minded view that runs counter even to Satoshi's original description of hard forking. But it has been propagated for a long time by the incumbent in order to cloud the debate, so it's ingrained and will take a lot of education to overcome.

I think it is important that all of us stand together to defend each other's right to fork Bitcoin in the way that we feel best serves it.
In this way, we are allowing the market to make a proper choice, as opposed to depending on the whims of the over-centralized mining community.

I agree with you, @VeritasSapere, that "Satoshi's Bitcoin represents a much greater threat to the miners" - but I see it being recognized as such only over a longer term (which I think is its advantage).

Short-term, those mining a SHA256 fork will be seen as more direct competition to the existing chain by the current miners, because they will realize that it's possible for the fork to gain security much quicker if existing hashpower switches. Conversely, it will be obvious to them that they can attack it using their existing hardware, whereas attacking the POW fork will be somewhat more difficult.

The above is my opinion of course, and I look forward to seeing how things turn out, even if it proves me wrong

In my view a lot of the threat perception will also depend on which fork is deployed first, because whoever goes first will attract focused attention and set a precedent.
That is one reason I could see for it being advantageous for both forks to release / deploy either simultaneously or in pretty quick succession, so as to dilute the attacking powers a little.

 

[VeritasSapere]

Diluting the attacking powers might indeed be a good reason to launch simultaneously. I had not thought about that, the way I see it, the security a genesis fork gains depends on the value users give to that genisis fork. Miners will follow the profit so we can expect the amount of PoW security each chain will have should correlate with the value of the block reward. The bottom line is what the cost of attacking such a chain is, becomes somewhat irrelevant whether the chain is secured by GPU/CPU or ASIC's since both can be rented or deployed against a genesis fork.

I am pretty tempted to purchase more GPU rigs, thinking of deploying a few more 6x970 rigs, not just because it is profitible but also because it will help to secure Satoshi's Bitcoin.
[doublepost=1458231266,1458230301][/doublepost]It might be worth while to develop the software and optimizations necessary for GPU mining, including the setting up of several pools. This would significantly increase the potential security for Satoshi's Bitcoin since it would allow larger miners like myself to participate in a way that we are used to. Much of the non ASIC mining power today is represented by GPU's. The requirement of running a full node and the use of CPU would discourage the participation of larger GPU farms like myself. There is also the danger that someone else develops this capability after launch opening up opportunities for attack that would otherwise not exist.

 

[Christoph Bergmann]

What happens with my blockchain?

I need to make a copy of my blockchain to run this bitcoin?

I don't think this bitcoin will prevail. If you have the chance to reconstruct bitcoin while keeping the blockchain, you play to low. But it can be the start of something bigger: a fragmentation of bitcoin in several chains. Let them keep their 1mb4ever chain, let's build a chain that's good for payment, let's build another chain that's good for micropayment, and another chain to store data. And so on. Let's build bitcoin ng, microblocks, 1s blocks, smart contracts, etc.

Our old bitcoin are everything! They are the 1mb4ever coins, the pay coins, the micorpayment coins, the data coins, the contract coins. Everything.

That's so much better tha sidechains.

There will be confusion, much confusion, wow, on the markets, the exchanges, the paymet providers, but in the end we could create something crazy, new, the quantum theory of money - it's every state as long as it is not spend - schroedingers money. Yeah!

(this, btw, is the ultimate solution for the "what happens when every bitcoin is mined" problem)

 

[rocks]

@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. The version tag should read "SatoshisBitcoinFullFork_PublicTest_At403562" (in clientversion.cpp) and the fork point should obviously be 403562 (in consensus/consensus.h). Make sure the version you build is from the “0.11.2_PublicTest_At403562” branch. If you are having trouble getting github to change branches correctly (it can be a pain) github also provides a download link for the branch on the website.

For the actual launch I will provide pre-built binaries to install.
[doublepost=1458232971][/doublepost]

What happens with my blockchain?

I need to make a copy of my blockchain to run this bitcoin?

I don't think this bitcoin will prevail. If you have the chance to reconstruct bitcoin while keeping the blockchain, you play to low. But it can be the start of something bigger: a fragmentation of bitcoin in several chains. Let them keep their 1mb4ever chain, let's build a chain that's good for payment, let's build another chain that's good for micropayment, and another chain to store data. And so on. Let's build bitcoin ng, microblocks, 1s blocks, smart contracts, etc.

Our old bitcoin are everything! They are the 1mb4ever coins, the pay coins, the micorpayment coins, the data coins, the contract coins. Everything.

That's so much better tha sidechains.

There will be confusion, much confusion, wow, on the markets, the exchanges, the paymet providers, but in the end we could create something crazy, new, the quantum theory of money - it's every state as long as it is not spend - schroedingers money. Yeah!

(this, btw, is the ultimate solution for the "what happens when every bitcoin is mined" problem)

It is a fork at the specified height, all of your bitcoins from before the fork will exist on both chains. If there is a transaction backlog on the main blockstream chain, the fork'ed chain will process those transactions faster.

There is no risk to using running the test node or full node for the actual launch.

Just make sure you backup your datadir and wallet before running the Satoshi's Bitcoin client. After the fork the datadir will contain blocks not compatible with the main chain, so I would backup the full datadir before running so that you can go back to it. Worse case is you have to re-download the blockchain later, but no BTC are lost.

Just remember coins you spend on one branch are also spendable on the other branch.

 

[VeritasSapere]

@Christoph Bergmann I suppose my conception of Bitcoin in the spirit of the original vision of Satoshi. Is that Bitcoin can do all of these things on the same chain. This is part of the power and utility of Bitcoin. Blockstream has set up a false dichotomy by making some people think that they must choose between these features when in reality Bitcoin is capable of doing almost all of these things directly and on the same chain.

 

[Christoph Bergmann]

Just remember coins you spend on one branch are also spendable on the other branch.[/USER]

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