Announcement - Bitcoin project to full fork to flexible blocksizes

[steffen]

The new thread is at https://bitco.in/forum/threads/bitcoin-avf-a-full-fork-project-for-escaping-segwit-and-1-mb-blocksize-limit.962/. I have called it Bitcoin AVF, a full fork project for escaping segwit and 1 MB blocksize limit

 

[largerblocks]

Status update

Success!!! The initial coding work is complete and the first tests ran smoothly. The next set of tests are currently running on the main net and can be seen live here.
https://bitnodes.21.co/nodes/?q=/SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/

Test 1 - Complete
This was a series of tests to make sure that a single node running on the main chain would fork at a specific height and then mine and build a new chain. This was done multiple times without issue. BTW it was really fun to run a node that was mining full blocks...

Test 2 - In Progress
This test is the same as above but now with a group of nodes (>10) to make sure that after forking a group of nodes will work together to build a single new chain that is a branch of the main chain. These nodes will run on the main net and fork at block height 402421 (estimated midnight Saturday eastern time).

Next set of coding
After Test 2 completes successfully, the only additional coding work needed is to create mechanisms to change to a new group of peers post-fork. After the fork the client needs to both drop peers not following the fork and to find new peers using the fork. This also requires setting up a new CDNSSeedData server to provide seed nodes that followed the fork.

Test 3 - To do
The final series of tests will test the new peer functionality above. Here nodes will fork and then use new seed lists to find clients following the fork. In Test 2 above I manually connect nodes to each other, in this test nodes will lose all of their peers post-fork and go to the seed server to find each other.


The code is all up on github and you can try to build and run this yourself. The project is forked from Classic 0.11.2 and you can verify every code change from the Classic repo. The fork height is currently set for mid-April, so the only change needed for you to test is to adjust the fork height to an earlier block.
https://github.com/satoshisbitcoin/satoshisbitcoin

The new PoW algorithm code and explanation is below. It is the standard scrypt algorithm with two major changes, the first is a 128MB memory size which is large enough to not economically fit onto CMOS die (Litecoin used 128K), and the second is a new sequence of reads that are unpredictable and random in a manner which prevents a hardware pipeline from being built, ASIC implementations are possible, but a light-weight CPU core attached to DRAM will be just as effective and cheaper.
https://github.com/satoshisbitcoin/satoshisbitcoin/blob/0.11.2/src/crypto/modified_scrypt_smix.cpp#L193

The Plan
My goal is to complete the rest of the work and Test 3 within 2 weeks. After that there will be 3-4 weeks until the current fork height at the mid-April difficulty adjustment.

The plan is to use those 3-4 weeks to run real nodes that will fork on the main net and promote the client and others to join. So far /r/btc and /r/bitcoin have censored this project. I hope people here can understand how unacceptable that is. Well this time there will be hundreds of SatoshisBitcoin clients running on the main net and viewable by every on bitnodes.21.co, that will make it hard to censor the project.

Please join or help if you can. This project brings back CPU mining and there is zero risk to trying it. Run the client on your home computer and if the branch does not take off just delete it, but if the fork does take off you have the opportunity to miner early adopter coins on you home computer starting in mid-April.

Lastly, I started this project under a new 'largerblocks' alias. From now on I will post using my standard ID of "rocks". Originally I wanted to reserve the option to stay completely anonymous, but decided to just use my original ID instead, many here have known me under the rocks ID for years.

 

[freetrader]

@largerblocks: Thanks for taking up this initiative.

Q1: what's the best way for people to help right now?

Q2: is your fork going to reset the alert key to hand its control back to trusted parties (or rather, to take back control from untrusted parties), and if so how do you propose to go about that?

Hmm, I see @jtoomim raised an interesting partitioning dilemma re: such a change:

 

[rocks]

@freetrader

A1: There are lots of ways to help which is why I opened everything up.

One way is to contribute to the code development, this includes everything from simply suggesting work to be done to making changes. For example your comment about resetting the alert key was helpful, I forgot about that.

Another way is to promote the project. My initial announcement was censored on /r/btc. The coding work is easy, getting adoption is harder. If we want this to work helping to promote the effort will be needed.

Yet another way is to help put the infrastructure in place. This includes making a simple website explaining the project and where people can download pre-built binaries to run the client. Other website infrastructure includes new blockchain viewers, etc.

A2: Since this is a full partition and fork, it makes things somewhat more straightforward and easier. Block versions are used for the fork. At the fork height the block version is bumped to 5 and consensus rules reject blocks below 5 (and above 16 to reject Classic blocks too). The block version is then used for all consensus rules with blocks <5 using the old rules and >= 5 using the new rules.

There are a few items that need to be reset at the fork height. Resetting the seed list and peers is one item that needs to change. Resetting the alert key is another (which I hadn't thought of thanks!).

So feel free to look and recommend things to be done and help how you want and are able.

 

[freetrader]

I will open up the topic of conversation that I contacted you with at the @largerblocks alias.
We might as well talk about this openly since you are going with an open mode of discussion about the technical details.

The question I raised was:

I haven't found any major change to the difficulty retargeting algorithm in your fork. Are you interested in fitting one, or do you feel the difficulty will be robust enough without a change to that?

If you decide not to drastically alter the algorithm, are you considering shortening the retargeting period down from 2 weeks to something more reactive?

I am following up on the suggestion of @VeritasSapere and looking at refitting Dark Gravity Wave 3 (*) to the Bitcoin client. This would move to a per-block difficulty retargeting - I would like to hear any expert opinions on the pros and cons of that approach in the context of the upcoming hard forks. I am particularly interested in the downstream effects such a change would have (if any). Anyone basing decisions on a 2-week targeting interval?

The DGW is in use in many cryptocurrencies, the specific version I am looking at is the latest (DGW3) created by Evan Duffield (Dash).

Of course there would be details to work out, such as how best to transition from the existing algorithm to the new one after the fork triggers, and how to adapt the DGW3 to keep Bitcoin's 10-minute block times (instead of Dash's 2.5 minutes) and still work well. Since a change to the 10-minute interval is probably out of scope for a change and certainly affects downstream.

I would be keen to participate with a VPS node in testing of the POW fork - PM me if you feel I can help.

(*) General info:
https://www.cryptocompare.com/coins/guides/what-is-a-kimoto-gravity-well-dark-gravity-wave-or-digishield/

http://en.wiki.dashninja.pl/wiki/Dark_Gravity_Wave

https://github.com/dashpay/dash/blob/v0.11.2.x/src/main.cpp#L1584

 

[rocks]

I agree that there are better options for difficulty re-targeting than Bitcoin uses today, and I like the methods you outline above.

That said, I'd prefer to keep the fork as simple as possible and changing the difficulty adjustment might be too much to do at once, it can be an item to explore and implement down the line.

Currently at the fork height the difficulty will be reset to a level 50 nodes should find a block every 10 minutes. I think that is a reasonable number of nodes to expect and also provide motivation to run a node.

From there the standard difficulty adjustment will function and adjust difficulty up or down as needed. Currently Bitcoin is capped to only allow difficulty to increase by 4x each period. I don't know why core added this. Since post-fork difficulty may need to adjust faster I plan to increase the adjustment cap to 10x or more. This way after just 1 or 2 adjustments difficulty will normalize.

The problem is if a large number of nodes come online and then leave, that could leave the chain stuck, which is where your suggestions work very well.

 

[VeritasSapere]

@VeritasSapereI tend to agree when we talk about Bitcoin, but if you think about this, it's a Spin-Off, its going to be competition to Bitcoin.

It has the same distribution as bitcoin today, it has very few coins left for distributing, its effectively going to survive as an Altcoin if it doesn't supersede bitcoin.

Agreed, however without the PoW network I do not think it will be able to compete with the altcoins. It really would not have much going for it except for its distribution, which it will not be the only cryptocurrency with the same distribution as Bitcoin.

Long term its going to have better fundamentals if bitcoin does not reform its governance issues. the ASIC resistant here gives more time to resolve that issue. I see this as a bonus, but a risk too, if someone does develop an ASIC its going to centralize very fast so I like the idea of changing the algorithm every few years to prevent such an outcome.

The fundamentals remain the same, if anything like I said before, the situation becomes worse when ASIC's are developed because of the higher barrier to entry to develop chips for such an ASIC resistant algorithm. Leading to greater centralization of manufacturing which today is one of the greatest centralization pressures along with economies of scale.

A worst case scenario is that ASIC's are never developed because it does not gain the value necessary for this development, having a community that is quick to change algorithm would also discourage large investment into the mining space for a considerable amount of time as well I would imagine.

I think having a new algorithm will attract more miners.

I have heard this said before, but I do not see why that would be the case, anyone can mine altcoins today, the release of Satoshi's Bitcoin would not be any different, just another altcoin that can be mined, it is nothing new or special, except for it being the first genesis fork along with others, but that is the point it will still have to compete with the others.

 

[VeritasSapere]

@VeritasSaperePoW is part of Bitcoins essentials but not the particular PoW algorithm used. PoS vs. PoW would be a reset and a change in principles, the change of PoW merely a parameter adjustment, definitely not
a reset. It has always been part of the design if SHA256 would have been cracked for example.

With the exception of SHA256 being cracked I do not think that changing the PoW algorithm is part of the governance mechanism or as you say part of Bitcoins essentials.

I have summed up Bitcoins governance like this:

Consensus is an emergent property which flows from the will of the economic majority. Proof of work is the best way to measure this consensus. The pools act as proxy for the miners, pools behave in a similar way to representatives within a representative democracy. Then in turn the miners act as a proxy for the economic majority. Since the miners are incentivized to follow the economic majority. In effect the economic majority rules Bitcoin, in other words the market rules Bitcoin. Bitcoin relies on the economic self-interest of the masses to govern consensus.

Now if we have to change the PoW algorithm in order to increase the blocksize, and it is clear that the economic majority sides with an increased blocksize then I would argue that this governance mechanism has failed. If we setup a Parliament or a congress, which are supposed to represent our interests. Similar to the miners, however miners are supposed to have a positive incentive acting upon them often unlike state democracies which can have perverted incentives.

In this analogy however can we impeach the entire congress or parliament when they fail to make the right decisions and still say that this governance model has been a success? No, it can not, it can be considered a clear failure, and just repeating the same experiment again would not fix the underlying and fundamental issues.

In the second part you make wrong assumptions, 1. that Bitcoin failed and 2. that something like the current situation must happen again.

I do not think Bitcoins experiment in decentralized governance has failed yet, which is why I prefer not changing the PoW in a genesis fork. However since Satoshi's Bitcoin is determined to make this happen the next best thing we can do is release our alternative at the same time.

Secondly if we conclude that it has failed, which a change in PoW would imply to me at least, then resetting this experiment would most likely fail again in the long term as well. I think if the governance mechanism of Bitcoin fundamentally flawed then the answers most likely lie in incentivized full nodes, self funding blockchains and more complex governance mechanisms. Which are unlikely to be ever be implemented in Bitcoin and already exist in several of the altcoins.

1. If you see a fork by a PoW change as a part of Bitcoins methods to solve governance issues, Bitcoin hasn't failed yet. It is just at a critical point.

This is where I suppose we disagree, as I have just explained.

As I said before, if you change the PoW to make current mining hardware (worth millions) worthless and succeed, you set a precedence, that future miners are always in fear of losing their investments if the act against the wishes of users.

I think you are setting a bad precedent here, especially considering that a genesis fork with the same PoW can achieve the same thing while maintaining all of that value in the PoW network.

A genesis fork that does not change the PoW simply allows users to move their value over to the alternative chain that does scale, miners will simply follow whatever chain has the most value over the long run.

This is why I don't think an asic resistant PoW is necessary (although I think it would be a nice addon) at all. You just have to make the current generation of asics worthless. Some advantage for asics might be desirable actually.

I think ASIC ressistance might even be detrimental as I have already explain, if you really do want to change the PoW I would seriously consider @freetrader's suggestion to simply invert SHA256 instead.

A genesis fork will already have a huge advantage over altcoins, all Bitcoin users/holders are potentially users/holders of your fork. ATM all altcoins are competition to your bitcoin holdings, if you aren't equally diversified. Apart from the current governance issues I think that genesis forks should be the way to create new altcoins with new features. You have the chance to get Bitcoiners on board, and if your fork is traded somehow, you have the chance to get new people into your fork if it isn't priced at a high level from the start.

I think many Bitcoiners might just need to accept that they need to diversify into the altcoins if they want to stay ahead in their investments. The distribution of the genesis fork is the only advantage it has, in almost every other way Bitcoin is a dinosaur compared to most altcoins. The only two big advantages Bitcoin has now is both in its network effect of mining and users. Satoshi's Bitcoin would lose one of those advantages yet the project that is being run in parallel to it that will not change the PoW algorithm would not lose this important advantage.

Just now, we are seeing that the current generation of the guys, who should secure the network, are actually endangering the network and peoples holdings. By the way, I think some ASIC advantage in PoW might very well be important, so people with a lot of common computing power (NSA etc.) don't have a chance to undermine your coin.

This is a good point which is why a genesis fork that has changed the PoW algorithm is much more vulnerable from this type of attack from outside forces. A highly ASIC resistant algorithm is even more problematic considering that it would require a high degree of technological sophistication to even develop the first generation of ASIC's which could even be carried out in secret by an outside force in order to attack the network, having ASIC's already highly distributed and available makes a genesis fork much more resilient against such an attack.

For your believe, that a Bitcoin fork with the same PoW might coexist:
Assume we fork away from Bitcoin with some success, let's say the coin is traded at some exchanges
and the new chain B has about 5% of the hashpower of the main chain A. What hinders Blockstream to take some of their VC money and pay a A chain miner from time to time to mess up chain B? They will never let a coin coexist if they can prevent it.

Your argument is flawed, especially considering that they can do the exact same thing with Satoshi's Bitcoin, if we assume they have the same value then it would cost the same amount to attack both chains. It does not make any difference whether ASICS or consumer hardware is used, both are available for hire. I would like to see them try though, they would burn their VC money much quicker that way, weakening BlockStream, while both genesis forks would survive such an attack as long as the believe of its participants is strong enough.

Seriously though, you should be able to see, that Satoshi's Bitcoin is equally vulnerable to fifty one percent attacks compared to a genesis fork that does not change the PoW. If anything Satoshi's Bitcoin would be more prone to attacks since it represents a greater threat to peoples investments.

Your argument, that Altcoins with the same PoW coexist is a weak argument b/c none of these altcoins are any danger to Blockstream at the moment. If they were, they were eaten by tomorrow.

When it comes to BlockStream funding attacks on alternative chains, I do not see how the particular PoW that is used is even relevant. If what you where saying where true then they should be attacking Ethereum right now, yet nobody is attacking the Ethereum network right now. Considering that Ethereum certainly is a danger to Blockstream by being a competitor to Bitcoin, just like any genesis fork would be as well.

Furthermore, I think a change in PoW which would give hobbyists a chance to mine for some time, would lead to quicker adaption of the new chain.

I find this to be a peculiar statement, I have been running a mining operation with several GPU rigs for over a year now, there is plenty of opportunity for mining especially since the introduction of Ethereum which is presently very profitable to mine. I do not see how having another alternative cryptocurrency with the same distribution makes any difference in terms of mining. It might motivate some people because of ideology but it does not change the economics in any fundamental way.

Who defines when "an asic is developed" is true? But anyways, this should be another topic imho

In the case of VertCoin the community and developers decide, which I agree is not a decentralized or automated solution, though it is not that different compared to what Satoshi's Bitcoin is doing here however. Agreed this is probably the wrong thread for that discussion. Ask me about VertCoin in my altcoin thread and we can discuss that more in there.

 

[VeritasSapere]

@rocks The parallel project would require faster difficulty adjustments because of the existence of ASICS. Because of this massive difference fifty nodes would not be anywhere near the relative difficulty we would need. It would be better to point some ASIC miners towards it for a baseline. This I think is a difference between these two projects which will require one to change the speed of difficulty adjustments whereas arguably this will not be as necessary for Satoshi's Bitcoin.
[doublepost=1457813827][/doublepost]@freetrader I think you made a really good point before, about a non PoW change genesis fork being like a wooden stick, whereas the PoW change genesis fork being more akin to a sharp sword.

I would think we should try the wooden stick first, then the sharp sword, however Satoshi's Bitcoins seems determined to release on their already determined timeline so I guess the next best thing we can do is offer the market a wooden stick at the same time. The users will determine which chain will gain the most value. By putting both genesis forks out there we are giving users the choice, the miners will follow whatever chain has the most value, not changing the PoW algorithm at least does give the miners the opportunity to return to a scalable Bitcoin.

 

[molecular]

So I'm running the version from your git, connected to a bunch of your testnodes, too (should I?).

I set the fork block to 402381.

Stupid question: how do I actually mine?

pooler cpuminer says:

Unrecognized block version: 5

EDIT: f..ck me, I'm mining! (minerd was falling back to getwork due to missing coinbase-addr, retried with coinbase-addr, now it's mining)

however, my miner seems to be configured wrongly:

2016-03-12 20:43:03 ERROR: CheckProofOfWork(): hash doesn't match nBits
2016-03-12 20:43:03 ERROR: CheckBlockHeader(): proof of work failed
2016-03-12 20:43:03 ERROR: ProcessNewBlock: CheckBlock FAILED

Interesting: When 402381 (sha) was just relayed, a couple of nodes got kicked for misbehaving.

2016-03-12 20:43:26 ERROR: ContextualCheckBlockHeader: incorrect proof of work of 1806f0a8 should be 1f7fffff
2016-03-12 20:43:26 Misbehaving: 121.44.249.97:8333 (0 -> 100) BAN THRESHOLD EXCEEDED
2016-03-12 20:43:26 ERROR: invalid header received

I guess this is the expected behaviour? Not all nodes got kicked.

I'm "stuck" at block 402380, so that part is working

 

[molecular]

looking at sources I discovered the built-in miner and set "gen=1" in bitcoin.conf and HEIGHT_TO_FULL_FORK_1 = 402421 in consensus.h
[doublepost=1457817404][/doublepost]did you make any code changes except setting subver to

/SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/

the github is still an older version it seems.

 

[rocks]

@molecular

Yes, was just about to post how to correct this, but you already figured it out. I only expected to run Test #2 myself so I did not update the public github repo with the correct height to fork. If you recompiled with the changes above you should fork with my nodes.

The error messages you received were because your node forked at block 402381 which had already happened, and so your node started to reject blocks on the main net and started to build a new chain.

The error messaging here is confusing and due to the fact that the core client verifies the nBits difficulty value in the block header before the block version. I will make a change soon that will change the order of validation so that the error messaging is clearer.

If you are running the 402421 test, you can find my nodes' IP addresses here:
https://bitnodes.21.co/nodes/?q=/SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/

You will need to run
> bitcoin-cli addnode [IPxx.xx.xx.xx] add
to connect to my nodes after the test fork, which is happening in 13 blocks from now.

The next test will use a DNSSeed server to automatically find forked nodes. This DNS server is already running at "seed.satoshisbitcoin.com"

You can check the seed server by running:
> nslookup seed.satoshisbitcoin.com

And the results are some IP addresses running the fork.

Edit: It probably will be hard for our nodes to find each other in this test because the DNSSeed server was not configured for it and our nodes will likely only connect to standard nodes. Test #3 will handle this much better. At the very least your node should start to mine it's own chain, and if our nodes find each other then they should merge onto one chain. But I've only gotten a few of my 10 nodes connected so far, the "addnode" command isn't very functional apparently. Again this would work better in the next Test after some additional changes.

 

[rocks]

did you make any code changes except setting subver to

/SatoshisBitcoinFullFork_Trial_2_At402421:0.11.2/

the github is still an older version it seems.

There were several updates throughout the code needed to make this work. Github has a compare option that lets you see the differences from Classic. It is a fairly straightforward project but still required a bit of work.
https://github.com/bitcoinclassic/bitcoinclassic/compare/0.11.2...satoshisbitcoin:0.11.2

I did not update the fork height in the public repo for this test run since I only expected to run it myself.

The next test will be ready for public use and should work with zero changes needed.

 

[rocks]

Quick update, the 2nd test worked as expected, I have 9 nodes working together on a forked chain.

At the fork height of 402421 each node switched to new consensus rules and started to build a new branch. As of now 9 out of 10 nodes found each other (I manually connected them with the "addnode" command) and are working together to build a new chain (currently at height 402449). @molecular none are connected to your node, if you are running one try "bitcoin-cli addnode 52.37.17.214 add" to connect to the forked network. As expected the network has started to partition as standard peers are slowly rejected as being unreliable (for using older consensus rules).

The next test will be a public one that will replicate the full fork. It will use a new DNSSeed server to help forked nodes find each other instead of manually connecting them. I will also make updates to make the error messaging more informational as older nodes are rejected.

 

[molecular]

@molecular none are connected to your node

are you sure? I had "addnode=52.32.128.29:8333" and 5 others of your nodes in my configfile all along and "bitcoin-cli getpeerinfo" reports those 6 and 5 others (satoshi 0.11 ones):

satoshi@nil:~$ bitcoin-cli getpeerinfo | grep addr\"
"addr" : "52.32.128.29:8333",
"addr" : "52.36.121.43:8333",
"addr" : "52.32.87.19:8333",
"addr" : "52.26.44.93:8333",
"addr" : "52.11.81.14:8333",
"addr" : "52.37.17.214:8333",
"addr" : "52.24.121.109:59974",
"addr" : "129.13.252.36:39243",
"addr" : "129.13.252.47:46086",
"addr" : "148.251.249.69:51982",
"addr" : "[2a01:4f8:202:81b1::2]:18638",

Please look for nil.0x0000.de:8334 (188.40.93.205:8334) in your peer lists, looks to me I should be there.

You didn't think you could fork Bitcoin all for yourself and mine all the blocks, did you? ;-)

I definitely part of a fork, at block 402470 currently. I suspect it's your fork, too because of the peers I have.

Currenlty mining with

2016-03-13 07:31:44 BitcoinMiner 0: hashPrevBlock - 00495997066246e40621c7b52cb4e12f1f904205c5c589d6b16b6725970289f0

Oh, and I also mined a couple of blocks:

satoshi@nil:~$ bitcoin-cli listtransactions | grep blockhash
"blockhash" : "0074c2ec6da5bb088cd2bfdcb44dc7ab5f1a06a9a05fa123b7ed9ce1b2f393a0",
"blockhash" : "00532ac10998fa20c1aa8c3092dcc4d38a30734d6165b3b6aa53d818d5cd29b6",
"blockhash" : "003c57cad1413f314dfdea5d96d00fbf63cbe71eeb7f452e28899c3b660465e1",
"blockhash" : "0043afa5119fa5c39d44cba370c7919d3a8e78d31b47d2c00894df59d36f3a68",
"blockhash" : "000154dc3b182a287cd9d18d606a6392eae8e2ac4ecbffe143fa3639d6dc01a0",
"blockhash" : "0009682669a9fe4d0925e56392d2f6d524242fea036a625bc7568d714e30b9c9",
"blockhash" : "0037302e0f9a788258e299fd7d40ccab5a846595fc6dc2233df011fb967af4b4",
"blockhash" : "0016e1bbe6a56ff332d81c455ccd2a6a6e097d4c6cdb8aabc8e4eb707a2fb9fd",
"blockhash" : "0019b8991f86cfe8d184c553bb370195abf9b3e948f04aa88107c0ca5bcb5e2b",
"blockhash" : "00537fb0ed3832460a5850947874909d8793234418cbdb93f3b70746016937a6",

maybe this wasn't planned (me mining) and that's why we're on the fast side? (how is difficulty set in the beginning?)

"errors" : "WARNING: abnormally high number of blocks generated, 48 blocks received in the last 4 hours (24 expected)"

It's all looking good and it feels GREAT to take the power back and be a bitcoin miner again.

Nakamoto consensus ftw!!

 

[Bloomie]

Do you guys intend to brand this as an independent currency or a version of Bitcoin? The answer will determine the best way to promote it.

Does "hard fork" in this case mean that people start with empty wallets or do they keep their current coins and only newly mined coins will be incompatible with current implementations?

 

[molecular]

There were several updates throughout the code needed to make this work. Github has a compare option that lets you see the differences from Classic. It is a fairly straightforward project but still required a bit of work.
https://github.com/bitcoinclassic/bitcoinclassic/compare/0.11.2...satoshisbitcoin:0.11.2

Yes, I looked at your changes (roughly).

I was asking about additional changes you hadn't pushed to github yet for test #2. At least the subver was bumped and that's not reflected on github, so I was wondering if you had done anything apart from that and the fork height.

[doublepost=1457856088][/doublepost]

@Bloomie

Do you guys intend to brand this as an independent currency or a version of Bitcoin? The answer will determine the best way to promote it.

Does "hard fork" in this case mean that people start with empty wallets or do they keep their current coins and only newly mined coins will be incompatible with current implementations?

It's a "spinoff". We'll fork at a certain height and everyone will have the coins he had at that point on the old bitcoin chain, even when he joins years later (with caveats because I'm assuming transactions are going to be compatible and probably selectively broadcast cross-chain, but that's a whole other topic)

I can only speak for myself, but I'd brand it as "the real bitcoin", "satoshis Bitcoin", true to the original vision of decentralized Nakamoto consensus - one [c|g]pu, one vote, fuck the banks, this is the people's money.

Being able to mine yourself is incredibly attractive for both existing bitcoiners and newcomers.

 

[rocks]

are you sure? I had "addnode=52.32.128.29:8333" and 5 others of your nodes in my configfile all along and "bitcoin-cli getpeerinfo" reports those 6 and 5 others (satoshi 0.11 ones):

Please look for nil.0x0000.de:8334 (188.40.93.205:8334) in your peer lists, looks to me I should be there.

Yes, we are connected and mining together. Your node is not attached to the couple I checked but is connected to some of the others. This also means that mined blocks are successfully being passed around the new partitioned P2P network, as all of my nodes received your mined blocks even if they were not directly connected.

maybe this wasn't planned (me mining) and that's why we're on the fast side? (how is difficulty set in the beginning?)

The minimum difficulty was reset to 1-out-of-256 hashes (SHA256 minimum difficulty is 2^32 which would take years with the new POW). At the fork block difficulty is reset one time to this minimum level. It will run here until the next difficulty adjustment and then start to auto adjust. In prior tests this worked fine and I saw the difficulty start to go up.

Since we are running at it seems one block every 3 minutes on average, that means that our 11 nodes (my 10 and your 1) are producing around 256 hashes every 3 minutes and the entire network is producing 1.4 hashes / sec across all nodes....

For the "real" fork we will need to balance both setting the initial difficulty at a reasonable level while providing some incentive to try it out.

It's all looking good and it feels GREAT to take the power back and be a bitcoin miner again.

Nakamoto consensus ftw!!

Thanks so much for compiling, running a node and joining this test, I wasn't expecting anyone to join this test and it is great everything worked so well. Your joining and showing that the new network works validates the approach.
[doublepost=1457857414][/doublepost]

Do you guys intend to brand this as an independent currency or a version of Bitcoin? The answer will determine the best way to promote it.

Does "hard fork" in this case mean that people start with empty wallets or do they keep their current coins and only newly mined coins will be incompatible with current implementations?

Exactly what @molecular said. All of your coins from the fork point will be on the new chain. Everything comes over. After the fork point the two branches will start to diverge. What you also get is a chance to mine coins on your home computer again.

Also, transactions sent over the P2P network are spendable on both networks. Right now the branched network is till receiving transactions from the main net and confirming those transactions in the branch.

What this means is that at the "real" launch, if there is a spam backlog, the new network will confirm those transaction faster than the current network. This would be a powerful statement on how larger blocks can and do work.
[doublepost=1457857695][/doublepost]

Yes, I looked at your changes (roughly).

I was asking about additional changes you hadn't pushed to github yet for test #2. At least the subver was bumped and that's not reflected on github, so I was wondering if you had done anything apart from that and the fork height.

I (think) the only two changes from the github repo were the subver and the block height to fork, everything else should have been the same.

I pushed a few new changes into the repo since the fork, which you can see on github. The first changes the block header validation to check for the fork version first, this makes messaging much clearer when rejecting older non-fork blocks. The second changes the DNSSeed list to the new seed server. The third changes the forked block version to number 256, this will keep the versioning more separate from the main net in case they increase the version for their own purposes.

Before the next test I will make sure the repo is up to date and all that will be needed is to compile and run.

FYI, sometime later tomorrow I will shut my nodes down and prepare for the next test, probably middle of next week.

 

[molecular]

Yes, we are connected and mining together.

yay!

I understand about the initial difficulty. We'll have to find a way to set this into the correct ballpark at least.

Since we are running at it seems one block every 3 minutes on average

I calculate about (5*60.0) / (402493 - 402421) = 4.16 minutes/block. But some timestamp might be off by an hour. In that ballpark anyways.

There's one thing that doesn't add up, though: my orphan rate seems to be really high. I'm getting stale block messages and most of my blocks end up orphans, it seems.

satoshi@nil:~/.bitcoin$ cat debug.log | grep "Proof-Of-Work Found" | nl | tail -n 1
29 2016-03-13 08:37:10 BitcoinMiner 0: Proof-Of-Work Found!!

satoshi@nil:~/.bitcoin$ cat debug.log | grep "ERROR: BitcoinMiner: generated block is stale" | nl | tail -n 1
7 2016-03-13 08:23:41 ERROR: BitcoinMiner: generated block is stale

satoshi@nil:~/.bitcoin$ bitcoin-cli listtransactions | grep amount | nl | tail -n 1
10 "amount" : 25.02482456,

So I found 29 proofs of work. 7 of the resulting blocks were detected as stale right away (a new block must've arrived from your nodes in the meantime?), but in the end only 10 made it into the longest chain?

 

[rocks]

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.