Announcement - Bitcoin project to full fork to flexible blocksizes

[Peter Tschipper]

@freetrader I only use debug=thin.

but if you want track orphans you can use debug=mempool but most people don't need that and it really bloats the log file.

 

[freetrader]

@Peter Tschipper : I was referring to the public test of SatoshisBitcoin - it doesn't have thin blocks AFAIK (since it is currently a build derived from Classic 0.11.2) ?

But I take the useful advice about the debug=mempool parameter for orphan checking ...

 

[molecular]

allright, I'm off to bed. Too bad I can't observe the test, will be too late for me, have to work tomorrow. You guys have fun, I'll just leave the nodes running unobserved. If rocks has done a good job, they should be fine

 

[rocks]

@freetrader
I think the best thing is to monitor your debug.log and report if you see anything off, even if the chain works we want to make sure nodes are behaving well, this includes everything from orphan rates being reasonable with the new POW to making sure the network partitions well and connections to the main network are dropped while forked nodes become well connected. I ran a few test forks myself and everything worked and was fully automated, this is a double check of a process with a larger number of people and nodes spread around (there have 3 in the EU right now).
[doublepost=1458510511][/doublepost]

@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

Thanks for this! I had not seen it before. We're only a couple hours from the fork, but it looks it will help towards preparing the binaries for the main fork.
[doublepost=1458510816][/doublepost]

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?

Yes, this would be great feedback to get on both the hash you are seeing per CPU core and the orphan rate you are experiencing.

The miner issues enough messages to the debug.log to track what is happening. You should be able to back out rough estimates on hash rate per miner thread from the log file. Same for orphan rates, stale rates, etc.

If the CPU is pegged at 100% I'd assume you are running with the miner turned on. This would happen if you passed -gen on the command line. The miner will try to build new POW blocks before the fork, but given the difficulty level nothing will be found, after the fork the difficulty resets and the miner should start to find valid blocks.
[doublepost=1458511300][/doublepost]

allright, I'm off to bed. Too bad I can't observe the test, will be too late for me, have to work tomorrow. You guys have fun, I'll just leave the nodes running unobserved. If rocks has done a good job, they should be fine

They should but that is why we're having a test

I picked a block that was estimated to come noonish eastern time in the US, which is a reasonable time for the west coast US through EU, but that was 4 days ago and the network has run a little slower than it should have....

 

[freetrader]

Interesting - bitnodes reports my post-fork node as down even though it's running fine. Not sure yet _why_ ...

Forked chain is now 27 blocks ahead.

EDIT: just realized this could be due to my aggressive maxconnections setting for this test (16).

 

[rocks]

@freetrader
It is because the node is no longer compatible with bitnode's client. Each time nodes on one branch sends a block to a node on the other branch that block is invalided and the sending node is tagged as misbehaving. After sending a few blocks the nodes are dropped. This is part of the normal partitioning process. Soon bitnodes will see none of our clients as valid clients.

The fork seems successful so far, my nodes are all on block 403597 right now. Some have been mined by myself and some have been sent from other people's nodes. We have a fully functioning branch right now. The goal is to let it run through a difficulty re-targeting or two in order to make sure everything functions as it should.

 

[freetrader]

I was a little worried by the fact that my node was the first not to be listed by bitnodes, whereas all the others still appear (at least in what bitnodes displays to ME)

Gonna let it run and check back later.

 

[rocks]

You can run "bitcoin-cli getpeerinfo" to see who you are connected to. The debug.log file will also show if you are receiving new blocks on the forked chain.

Yes it would be strange if your node was the only one not listed, but in prior trials I found bitnodes would drop some nodes and keep others.

 

[molecular]

Good morning, I'm soon off to work, but I see the test may have been a success.

I'm rich for one thing (found 8 blocks on my hosted node and 10 at home), so that's good ;-)

The dialup node I had set to maxconnections=2 and it is connected to 2 SB nodes, cool.

The hosted node was set to maxconnections=100 and is currently connected as follows:

• 5 SatoshisBitcoinFullFork
• 2 Satoshi 0.9.*
• 6 Satoshi 0.11.*
• 4 btcwire 0.3.0
• 1 Classic: 0.11.2
• 1 BitcoinUnlimited:0.12.0
• 1 Dain 0.0.1

Interesting: no 0.12 nodes other than the BU one.

 

[rocks]

@molecular
Thanks for posting your connection information. My nodes are seeing the same.

So far the trial seems to be a success. We had several nodes join and all participating nodes moved together to a new branch correctly. Mining on my end is working better with lower stale/orphan rates even though blocks have been coming somewhat quickly.

Partitioning did not happen to the extent I expected though. We both have continued connections to the main P2P, whereas I'd expect most connections to be dropped by now. My nodes have been dropping standard nodes, but new connections keep being made or requested by others.

This probably is something that should be improved and I think the network should partition a bit better. Let's see how it goes for a few days and then I'll post a couple options to see what people think.

Overall thanks to everyone who joined trial. I think it was largely a success so far.

 

[freetrader]

Just like to say at this stage that I've also been able to confirm that my "quick 'n dirty" datadir backup & recovery scheme worked fine during this test.

I've started a separate thread to document it here:

https://bitco.in/forum/threads/how-to-safeguard-datadir-when-switching-clients-on-a-node.1015/

 

[corsaro]

just a curiosity... trying to cross compiling windows binaries from linux, fails..

I used same identical procedure as for bitcoinclassic (who gives success for classic binaries)

 

[hellobitc0inworld]

I like all the changes proposed for this fork, with the exception of changing the PoW method.

If it is possible to do it without the change of PoW I think this may be best.

This is mainly because so much of the Bitcoin infrastructure and mining investment has been invested built up around SHA256.

While I agree that other proof of work methods are more effective and more decentralized, If we remove SHA256 I believe the value of this fork would quickly drop to near zero purely because none of the existing miners would be able to secure it. This means it would be starting from scratch, and as such I suspect its value would drop suddenly as well. And since its value will drop so suddenly, what incentive would anyone have to use this over any other alt coin?

Right now the only thing that really sets Bitcoin apart from other coins is its price is higher (due to network effect and first mover advantage). Other coins are more advanced. So if we lose this final redeeming quality (Bitcoin's higher price per coin), then what is left as a motive for keeping this fork versus using another coin such as Dash or Ether?

 

[freetrader]

@hellobitc0inworld :
IMO the only way a hard fork of Bitcoin - same POW or different - would retain something close to the current value of Bitcoin would be if it uses the election methods that e.g. Classic is using, and can win over the ecosystem very gradually.

If a fork does what Satoshi described and forks off hard at a certain block height - it will no doubt be demonized as a hostile takeover / altcoin / attack by evil corporate forces etc. We know sort of what to expect in terms of that, although I do believe the response will exceed our expectations.

Let's take a low price per coin as a given, and think how this may play out.

If the fork persuades the market that it is useful, it will gain support. How quickly that might happen depends on how much work is put in by those who want to see it succeed.
A reset of mining difficulty will attract new miners.
A low price will attract new buyers.
Those who may not hold much might decide to gamble sell their small holdings on the old chain in order to purchase a more sizeable number of cheaper Bitcoins on the new chain (fork arbitrage).
Those businesses who see the need for capacity growth might lend support in terms of running nodes and even mining in the initial stages, when mining once again becomes a much more egalitarian affair.

The existence of one or more forks will put tremendous additional stress on today's centralized development and mining powers, as well as the current price of Bitcoin. It is certainly possible that the price will be more volatile than it is now while two or more forks compete for mindshare. The price is also propping up the currently centralized miners, who according to the opinions I've read, would be hard hit by large price drops as the time of the halving draws closer.

Who knows, perhaps if they reflect on the situation a little more, they might come to some unexpected conclusions that might be good for Bitcoin as a whole. For a change.

 

[priestc]

I think a POW change should only be considered as a nuclear option. Simply put, a blocksize increase is not worth going nuclear over.

An example of when changing the POW *is* appropriate:

Lets say 10 years from now a mining cabal forms, and also takes advantage of their cabal, and actually restricts certain people from using the blockchain. For instance a cabal of Chinese miners who decide to not mine any transactions coming from Korean wallets. This would be an example of misbehaving miners that should be dealt with by changing the POW.

Just like its not appropriate to drop a nuclear bomb on a country for not accepting your trade deal, its not appropriate to change the POW because miners won't increase the max blocksize. The outcome of changing the POW means overall hashrate sharply declining, which means decreased security, inconsistent block intervals, among other things.

By the way, changign the POW will not fix mining centralization, it will still centralize again given enough time. Mining centralization is not much of a threat anyways.

 

[freetrader]

@priestc :

For instance a cabal of Chinese miners who decide to not mine any transactions coming from Korean wallets. This would be an example of misbehaving miners that should be dealt with by changing the POW.

Oh, but this can be done at the gates (the Great Firewall).

It won't be the miners misbehaving, we'll even have to recognize that they might be completely innocent, but that we have been foolish in ignoring an elephant in the room.

The government of China can claim "national security", an excuse that has served well in the West for all sorts of censorship and oppression, and surely cannot to be criticized too much by our own governments and politicians who are, in some cases, just dreaming of the same kind of control that they see in the People's Republic.

https://www.washingtonpost.com/opinions/in-visit-with-chinese-president-xi-jinping-david-cameron-sells-out/2015/10/23/85debeb2-79a1-11e5-b9c1-f03c48c96ac2_story.html

The only difference between China and some Western nations is that China has a very elaborate Great Firewall about which it is relatively open.

If we carry on relying on this elephant to bear Bitcoin's load as it grows up, the inevitable realization that our financial freedoms now depend in part on the mercy of the Chinese (or any other similarly disposed) government will be a hard but valuable lesson to us in the rest of the world. Let's skip that lesson.

 

[rocks]

Quick status update.

Overall the trial seems to be a success. A few different nodes joined the test fork and are still mining together after more than a week. All nodes are still on the same chain and went through the next difficulty adjustment fine.

One item to improve is network partitioning. I thought after some time that the nodes on different chains would naturally separate as they are marked as misbehaving from sending invalid blocks. However my forked nodes are still receiving new connections from standard main chain nodes, and I'm consistently seeing over 20 cross network connections.

This probably should be improved. I am thinking now of adding a new node protocol version greater than the 70012 that core 0.12 uses and rejecting main chain connections after the fork. This would quickly partition the forking nodes into a separate P2P network after the fork. Anyone could obviously manually re-broadcast transactions across both networks so transactions are not guaranteed to be only seen by one network, but it would create better behavior.

After making these changes I'll publish the code on github and then start the process of getting the binaries built, a basic website up for promotion, etc. After working on this a bit the first half of March I was slammed by day job and family commitments the past couple weeks but hopefully can have the client ready by later next week.
[doublepost=1459314940][/doublepost]

I think a POW change should only be considered as a nuclear option. Simply put, a blocksize increase is not worth going nuclear over.

An example of when changing the POW *is* appropriate:

Lets say 10 years from now a mining cabal forms, and also takes advantage of their cabal, and actually restricts certain people from using the blockchain. For instance a cabal of Chinese miners who decide to not mine any transactions coming from Korean wallets. This would be an example of misbehaving miners that should be dealt with by changing the POW.

Just like its not appropriate to drop a nuclear bomb on a country for not accepting your trade deal, its not appropriate to change the POW because miners won't increase the max blocksize. The outcome of changing the POW means overall hashrate sharply declining, which means decreased security, inconsistent block intervals, among other things.

By the way, changign the POW will not fix mining centralization, it will still centralize again given enough time. Mining centralization is not much of a threat anyways.

What's going on now is a mining cabal that refuses to process transactions in a timely manner. These miners are refusing to process blocks with more than 1MB and are refusing to meet user demand in a timely manner.

That said there should be two fork options for people choose from offering both a same POW and a different POW option. I'm not sure they are open about it yet, but a couple people on this forum are considering offering a same POW fork option for those that want it

 

[rocks]

just a curiosity... trying to cross compiling windows binaries from linux, fails..

I used same identical procedure as for bitcoinclassic (who gives success for classic binaries)

Yes I had a horrible time with building a windows binary, but I also couldn't get classic 0.11.2 to build either. Will obviously have to figure this out for the real fork. I might have forked from the wrong version of classic 0.11.2....

 

[Tick]

Interesting Idea, but why not just use litecoin or start from scratch?

Whats the big idea about "forking" bitcoin, with all the old worthless data unless it goes through official channels eg. Classic.

Just make a fresh bitcoin/altcoin, mine the genesis block, and use bitcoin unlimited code that will change based on usage.

Lastly without famous big name devs who agree to constantly update it, user confidence will be hindered.

 

[freetrader]

Hi @Tick, the idea behind preserving the existing data is that you don't punish the innocent.

This data is not "worthless" as you called it - it contains the sweat, blood and tears of many who invested a lot to see Bitcoin become what it is.

Selling one's Bitcoin - even on the old chain - is always a hard thing to do, even if you believe in the future of a fork.

Retaining the data offers those that want to hop on a fork a much less painful way.
If all goes well, the Bitcoins on the old chain will naturally become worth less over time, while their Bitcoins on the new chain will become worth more, without requiring the active intervention of holders.

Wiping the slate completely as you suggest is indeed no different than starting any other altcoin, and would damage the confidence of all those who held coins previously.

If my explanation wasn't sufficient, may I suggest you peruse the history of this particular thread - these arguments have been made more cogently by others. I think in the next few days you will also have a chance to read a better exposition of this concept of "genesis forks".