Announcement - Bitcoin project to full fork to flexible blocksizes

[VeritasSapere]

@largerblocks I will have a thorough response for you in the next few days. I do appreciate what you are doing here. I think ideologically we have more in common then not, I also support splitting the chain, however just not with an POW algorithm change. Maybe we will have three chains on that date because of this disagreement but we will see. Like I said I will write up a more thorough response in the next few days.

 

[satoshis_sockpuppet]

@largerblocks Great initiative! This is exactly what we need to fix Bitcoin.

A few thoughts:

• Changing the PoW definitely is a must:

1. It prevents an attack on the network. Contrary to @VeritasSapere's belief I'm convinced there will be an attack by Bitcoin miners, if such a fork is somehow successful.
   
2. It sets the needed precedent to show miners, that a large enough number of users can make all their investments useless. One successful fork of this kind might be enough to prevent misbehaviour by miners in the future. We don't want BitFury to mine on a working coin after they destroyed the first coin with their stupidity. It's sink or swim.

• The schedule might be a bit to ambitious. 1st of May or something like that sounds better to me, but on the other hand we actually need the pressure yesterday..So I'm not really sure.
  
• Imho the roadmap laid out by Bitcoin Classic about scaling could be adopted 1:1.
• Is the name Bitcoin Original already burned?

I love it!

 

[largerblocks]

@VeritasSapere
It is a reasonable thing to have different opinions on. It would be possible to put two versions out, one with a POW change and one as-is, resulting in three chains as you said. My worry is that would be too confusing for most people. I think a binary option is easier for people to understand, i.e. do you want to stay with the Blockstream limit, or follow a new branch that scales.

Another thing to consider is this change encourages people to run full node to mine. This could help drive the count of full nodes as people try to mine early post-branch, which helps to promote the branch.

@satoshis_sockpuppet
Thanks for the comments. The schedule I think is reasonable, but as stated will adjust it based on dev progress.

On that topic the hard fork logic is now coded which triggers the blocksize change and the POW change. Adding the new POW should be straightforward now, the hooks to switch to it are already there.

I've decided to switch to following classic's 2MB bump. I started to code the adjustable limit in and had completed most of it, but then saw that with headers first block downloading having the prior blocks' blocksize is not guaranteed, which makes it difficult to calculate an adjustable limit based on prior block sizes. There are several options but rather than make a potentially sub-optimal choice in the short time frame available, I thought it better to follow Classic's lead. The adjustable limit changes were also potentially more impactful to the code. Post fork we can debate the various adjustable limit options and select one after proper consideration.

I am targeting to have a trial fork later this month. i.e. run a node or two on the main P2P network through a scheduled fork to see if it works as it should. If that test functions, then we can discuss final dates.

 

[VeritasSapere]

@largerblocks You would gain my complete support if you decided to put out two versions, I suppose otherwise I would aim to do so myself any way creating a parallel project, we might as well work together. Considering that we pretty much agree besides that one parameter. I suspect there are a lot people that feel strongly enough about this as well on both sides of the arguments to create two new chains on this date, and if you are correct the original POW algorithm chain will swiftly just be attacked and destroyed anyway.

If it is not then my arguments could have more merit, it will be good to put this to the test.

In regards to a binary option, it is in part why I favor keeping the original POW, it is more simple only changing the blocksize limit, and difficulty adjustment out of necessity I should say. Changing the POW has far reaching consequences and represents much more complexion, and in my opinion a reset of the Bitcoin experiment, not changing the POW I would consider more of a continuation giving the market a real choice for bigger blocks while allowing the miners to return to the real Bitcoin which when it becomes the longest chain for all intends and purposes would be Bitcoin again. That would not be the case with a POW algorithm change however.

Having three chains does add more complexion but it will be able to capture everyone's thinking representing a more complete spectrum of free choice, after all this project should be an expression of that very volunteerism.

I will still do a thorough write up of this issue countering some of the points you made in your post, so that we have a good source to point towards for the reasoning behind not changing the POW. I plan to be very thorough so that is why I will do so on a day when I have more time. For now I will say if you do decide to put out two forks I think that would be great, you would have my full support, of both chains by the way and I will work to promote this project as well, I post often on Bitcointalk so I can help in that regard as well.

I hope we can do this under the same banner so to speak, otherwise like I said I will start another project in parallel since I do feel very strongly about this issue. I also think that the first of may is a better date as @satoshis_sockpuppet mentioned, that day also has certain historic significance that would make it a fitting day for such an action.

 

[VeritasSapere]

Every significant change from the original design can cause a split, this is what we are seeing here. Creating a fork with a changed POW algorithm and a blocksize limit increase, is two changes, therefore justifies two splits, it also makes sense that they split at the same time so that all three chains will start with the exact same distribution.

 

[Christoph Bergmann]

I like the idea and think it is worth a try. At least we'll learn something about full forks. I have two suggestions, one questions and an argument, why I think, it will not work.

Suggestions
1. Change the name. Satoshi's Bitcoin has no melody and confuses the name with "Satoshi", the bitcoin-cent
2. Mirco Popescu, the rumanian guy from mpex and trilema, postet sometime a suggestion to change the mining-algorithm in a way that the hashes have to contain a proof that the miners saves the blockchain. I suggest you consider this, because it brings back Satoshi's vision of Miners === Full Nodes, which is an important part to keep decentralization live when scaling to visa-level where nodes are data-centres.

Question
1. Can you outline how your full fork and the old bitcoin would interoperate? Ist it possible that transactions are received in both networks? Or would we have two separate systems with incompatible nodes / transactions?

Argument why it will not work
1. If your forkcoin comes to altcoin-markets, early adopters of bitcoin can dump their coin and nearly destroy it, just to make some profit or to destroy your coin.

 

[YarkoL]

1. If your forkcoin comes to altcoin-markets, early adopters of bitcoin can dump their coin and nearly destroy it, just to make some profit or to destroy your coin.

I don't see how it would destroy the coin, only devalue it. But then investors can buy them off cheaply. It is form of redistribution integral to spin-off model.

I would be in favor of changing the p2p port though, no need to add to network congestion since this departs so largely from the existing Bitcoin.

 

[freetrader]

@YarkoL : Changing the default ports sounds interesting.

I'd like to think about the pros and cons a little here.

Pros:

* We don't get in each others way on the network: the new and old

Cons:

* everyone needs to add/modify their firewall rules. Not a problem for miners. But makes life a little more difficult for relay node operators and end users who already forgot how. Sad faces when new client does not work out of the box. Could be mitigated by publishing clear instructions.

* more code changes to point fingers at and say it's not a good thing to do

* something that would need to be co-ordinated among such fork attempts, lest they get in the way of each other (I am imagining several people trying to get on a bus all at one here)

Unfortunately I can't think of more pros/cons either way. Perhaps too tired.

It would be great if persons with businesses operating on Bitcoin (e.g. exchanges, pools) could pitch in and say whether this technical change would be favored or not.

 

[satoshis_sockpuppet]

2. Mirco Popescu, the rumanian guy from mpex and trilema, postet sometime a suggestion to change the mining-algorithm in a way that the hashes have to contain a proof that the miners saves the blockchain. I suggest you consider this, because it brings back Satoshi's vision of Miners === Full Nodes, which is an important part to keep decentralization live when scaling to visa-level where nodes are data-centres.

I heard ideas like this before and I think they are very much worth consideration. It goes in the direction of using something like scrypt and instead of some random data you have to work on the (sorted) existing UTXO set.
Honestly I think that is the way to go, a PoW fork (sorry @VeritasSapere and all honest miners) that is more asic resistant (some specialization will always happen and imho isn't bad in itself) and forces miners to have the current UTXO set present.
I'm not sure this can be done in short time so I think a fork to an existing different PoW with the clear announcement that it will be changed in a few months might be the right direction.

 

[Christoph Bergmann]

Honestly I think that is the way to go, a PoW fork (sorry @VeritasSapere and all honest miners) that is more asic resistant (some specialization will always happen and imho isn't bad in itself) and forces miners to have the current UTXO set present.

Yes, I think it will be a bit complicated.

But if this kind of coin succeeds - and giving that I want a cryptocurrency not a settlement network, I'm ok with that- that it needs to offer some real advantage. Letting it be mined by CPU with a minor GPU advantage like neoscrypt is one part. Forcing miners to save the blockchain - to be a node - would be another part.

No complicity explosions like Bitcoin NG and lightning and sidechains, but simple and stupid bitcoin like it was outlined ...

 

[satoshis_sockpuppet]

@Christoph Bergmann
I don't think the whole blockchain is a good idea and I don't know a straightforward way to use it in a mining algorithm. Apart from that imho keeping the last n blocks of the blockchain as a full node gives enough security so keeping the whole blockchain isn't necessary. A mining algorithm where you need the current utxo set should be preferred. Imho that's the easiest and most straightforward way.

 

[satoshis_sockpuppet]

Haha there might be an unexpected fan of such a fork:
https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas

• POW which involves queries against the UTXO set (set of spendable coins)
  • Basically a special kind of memory hard POW that proves that the miner has a complete copy of the UTXO set and that the miner is good at querying it
  • Can still be combined with merged mining.
  • (This is entirely Amiller's idea, but I like it a fair bit)
  • One exciting enhancement to this idea I have is making the power H(header||nonce||H(utxo_lookup(H(header||nonce))). This way if you have a stream of utxo queries coming in, you can make the work of them mine for you. Validation then, is mining. If you don't have enough queries coming in you just make some up at random

I'm pretty sure I got that idea from somewhere else than Maxwell or Miller but who cares, the idea is great nonetheless.

 

[VeritasSapere]

In regards to finding an ASIC resistant algorithm I would recommend either dagger or cryptonight, they are both very good ASIC resistant algorithms. Dagger is used by Ethereum whereas cryptonight is used by Monero. Even though when ASICS are developed for these algorithms mining centralization will be much worse because of a higher barrier to entry because of the difficulty of actually developing these chips in the first place, but we can agree to disagree on this point. I am still planning to write a response to @largerblocks post but I do not think I will convince him or some of you other good folk here since you have already heard the bulk of my arguments in previous posts. I just thought it would be good posting these disagreements here so there is a single place where these thoughts are focused.

I have not heard back from @largerblocks yet regarding working together with this project, but the genesis fork with the same PoW is definitely happening, on the same block that this "satoshi's Bitcoin" forks. I also think May first or even after May first is a better date, and I think maybe the name could be better, does not roll of the tongue as well. There is obviously a separate name for the same PoW genesis fork. Might I suggest putting "Bitcoin" first in the name like the other projects have done, Bitcoin Classic, Bitcoin Unlimited, Bitcoin Core etc.

If anyone is interested with what I am doing and wants to help, please contact me. There is a lot to be done to make such a genesis fork viable. Something that has occurred to us is that we will need to setup several pools before the chain even splits, so that is something you guys will have to do as well.

 

[freetrader]

Good point @VeritasSapere : I also think such split-offs might need to immediately pool resources.

Unless there is some adjustment in the difficulty - but that comes with its own huge risks, no?

Anyway, this seems an interesting thread in which to discuss these ideas.

 

[VeritasSapere]

Definitely, I think it would be best if we pool our resources indeed. Talking about Difficulty that will need to be adjusted for the original PoW chain. Otherwise it can become a possible attack vector, adjusting the difficulty every block or at the very least every few blocks like many of the altcoins already do today will become necessary since otherwise it will not be able to handle large swings in hash power. Without severely effecting block times.

The difficulty adjustment is a significant change but it is necessary unfortunately, it will have to be done in such a way that it does not effect supply, but that is absolutely possible. Dash's "dark gravity wave" difficulty adjustment might be a good example, since that adjust after each block.

 

[freetrader]

Without looking at the dark gravity wave just yet (thanks for the tip - will definitely study), I'd have some constraints that I would wish any fork to preserve:

- keep coin supply at 21M (easy to effect)
- converge back to the planned emission schedule in a stable way after temporary re-adjustment

According to Wikipedia, Bitcoin's supply is estimated to be mined to completion somewhere between the years 2110–40.

My view is that a feasible approach is to plan a given timeframe (in number of blocks) by when the emission rate must be "back on track". I don't know if that should 3 months, 6 months, 1 year or more. Or if such a magic number should not be estimated - but it appears one has to set a goal if one does not want to sacrifice re-convergence to the original plan.

Interesting problem.

 

[VeritasSapere]

You have identified the problem exactly, when the coding is actually done this needs to be considered and accounted for, with something like dark gravity wave it should return to a normal emission schedule that is "back on track" so to speak, within a few days.

This is the function difficulty adjustments serve, keeping the coin emission consistent and in line with the original plan. The problem with Bitcoin is that this only happens every fourteen days, this is way to slow. Malicious mining power could abuse this by switching back and forward at key times, dramatically slowing down blocktimes.

Interesting to point out here, that with full blocks if Bitcoin lost a lot of hashpower it would suffer from this same problem as well, though it would be much worse exactly because of the lack of blockspace. 1hr long blocks is not fatal if transactions still get included. With the original Bitcoin that is not the case exactly because of the blocksize limit, ironically.

 

[freetrader]

@VeritasSapere :

Now that you mention it, my naive idea to use "number of blocks" for this re-adjustment time seems rather pointless if the objective is to converge roughly in time and the inter-block time depends on the difficulty.

I am not sure I fully understand the negative aspects of the current 2-week difficulty evaluation.
I believed this was chosen roughly to be commensurate with the anticipated much longer cycle of hashpower upgrades / bringing new capacity online.

To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases.

In a fork which doesn't change POW, in my view two things ought to happen (feel free to correct me):

1. difficulty should start low

2. difficulty should react fast to ramp up in reaction to increased hashpower (which is hopefully due to the fork being favorably adopted - but we can't distinguish it from an attack either)

If there is much evidence that the current "normal" 2-week cycle is too long [citation?], then there ought to be a re-evaluation of the new retargeting period. Otherwise I'd favor a "hard-reset" or smooth reconvergence - whichever is deemed better - to the 2-week cycle.

 

[VeritasSapere]

I suppose the main reason why I favor changing the difficulty adjustment in this way, is in the case of where we do have a minority chain in terms of hashpower, because the hashpower of Bitcoin is so vast it does not take much of that hashpower to completely mess up the blocktimes for over a month even on the smaller chain. This all depends on the exact hash power involved though. Though the re convergence to the two week cycle is an interesting idea, since I do favor changing as little as possible.

However this fourteen day period is generally considered problematic which is why most altcoins have much faster adjustments. This is especially important in an environment where there are several cryptocurrencies with the same hashing algorithm where the hashpower can move back and forward between chains, I suspect Bitcoin will face this problem as well if a genesis fork like this one really takes off. It has even been suggested on the Bitcoin dev list. Ignoring the hypocrisy of Luke-jr saying this is not controversial, he is making a good point.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-March/012489.html

I recall Gavin saying something along the lines that if it was up to him the halving and the difficulty adjustments would be smoothed out, I can not recall where I heard that but it was some Podcast a while ago now.

I suppose part of my reasoning is that we need to plan for the worst case scenario, if we do not attract a lot of hashpower at first it would be trivial for any large miner to "attack" the minority chain in this way. Having a quickly adjusting difficulty solves this problem, which Bitcoin itself is still vulnerable to this especially with the rise of new genesis forks. You are also correct in saying that if we do not change this, at the very least the starting difficulty would most definitely have to be changed.

Definitely an interesting idea, of maybe having a quickly adjusting difficulty which would later revert back to the "normal" adjustment schedule of every 14 days. If it was not necessary to make this change I would not advocate for it. In this case however I do see any way around it.

 

[freetrader]

Your view is always very educational to me.

For example, I realized belatedly that no-where in the whitepaper did Satoshi defend any sort of "fixed 2 week" difficulty period. I guess he might have anticipated that this was a constant much like the 1MB spam limit - and should be subject to consideration of technological evolution.

Philosophical side-track : if scientists found out today that an extinction-level sized asteroid would impact the earth in the year 2100 with probability 99%, what sort of change to the emission schedule of Bitcoin - if any at all - might be viewed as reasonable on Earth...