Add May 2018 hardfork specification

[avl42]

I'm somewhat surprised about any need to raise to 32mb already so soon... and isn't replay-protection of future hardforks something that future forks should have to deal with?

On Sat, Feb 3, 2018 at 8:14 PM, dexX7 notifications@github.com wrote:

@dexX7 commented on this pull request.

In may-2018-hardfork.md https://github.com/bitcoincashorg/spec/pull/53#discussion_r165822713:

@@ -0,0 +1,33 @@ +# May 2018 Hardfork Specification + +Version Draft 0.2, 2018-02-01 + +## Summary + +When the median time past[1] of the most recent 11 blocks (MTP-11) is greater than or equal to UNIX timestamp 1526400000 Bitcoin Cash will execute a hardfork according to this specification. Starting from the next block these consensus rules changes will take effect: + + Blocksize increase to 32 MB + Re-enabling of several opcodes + +The following are not consensus changes, but are recommended changes for Bitcoin Cash implementations: + + Automatic replay protection for future hardforks + Increase OP_RETURN relay size to 223 total bytes

To be pedantic: the actual payload size really depends on the number of push operations used, which also count in terms of this limit. The +3 overhead comes from the opcode and two pushes and is inherited from bitcoin/bitcoin#6424 https://github.com/bitcoin/bitcoin/pull/6424.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/bitcoincashorg/spec/pull/53#discussion_r165822713, or mute the thread https://github.com/notifications/unsubscribe-auth/AFAwsthSMJ4dxEKtayRk9pbYK7UkRTabks5tRLAHgaJpZM4R2NFc .

[schancel]

@sickpig Yeah, the opcodes spec should be merged with this PR prior to going in, as well as the OP_DATASIGVERIFY

[schancel]

@avl42 Why is this surprising? We have quite a lot of work to do to get to terabyte blocks...

[josephNLD]

@avl42 The purpose of the replay protection is to give exchanges and other community participants assurance that if there are hostile forks that they will be replay protected against. What this accomplishes is that it puts the burden of getting support on the hostile fork, and it assuages the concerns of the exchanges that the upgrade is done safely. It is not expected that it will be needed, but it is useful for gaining acceptance from exchanges.

Irrespective of any NEED to raise the max block size to 32mb, the code is capable of doing so. The miners set the block size limits always, if developers are limiting it, it is because development has not found a way to address the market with the bitcoin protocol. Getting anywhere close to the developer limits is a failure of development. The actual limits are not set by developers any more since the beginning of Bitcoin Cash.
The notion that developers control block size is not accurate. The developers set the capacity for block sizes based on the advancements in scaling, but all block sizes are managed by mining only.

The 32mb is just what the software is capable of managing. Mining limits are currently mostly at 2, 4, and 8mb depending on the miner, and this will likely remain so unless it becomes profitable to increase these (based on actual usage).

[dgenr8]

What is the situation with historical appearances of the re-enabled opcodes? Presumably the chain still validates but are historical appearances listed anywhere? Some of these have changed semantics.

[Danconnolly]

The numeric value of 0x80000000000001 is -1. The point of this test was that this number can fit in a minimally encoded integer.

EDIT: I think there was some confusion here from me about endianess. Please check the latest version.

[DesWurstes]

Won't there be any DAA improvements in this hard fork? It seems Scott's latest algorithm can be used and is well tested: https://github.com/kyuupichan/difficulty/issues/28#issuecomment-375020770 Well, am I late to ask this now? Well, Bobtail will be presented tomorrow. We'd better wait for an implementation of it until the next hard fork.

[zawy12]

I was wondering the same as @DesWurstes. It seemed like we all agreed Tom Harding's inverted simple form of Jacob Eliosoff's EMA was the best thing to do. I only objected (as before) that the value of N=100 was too large. That would be like WT-144 with an N=230 in the speed of response.

The following graphs compares Simple EMA N=50, SMA N=144, LWMA N=60 (my version of WT-144), and Digishield v3 (which is like an improved version of SMA N=68). You have to use N~=50 to 60 to make the long-term speed of EMA equal to SMA=144. The EMA will have a lot faster in short term response. N=100 for EMA is as fast as SMA N=144 only in short term response. Digishield and LWMA N=60 are a lot faster. The second chart shows how speed comes at a price in stability.

I've been guiding Monero micro clones to use LWMA N=60 and it's working great on 5 of them, attracting fewer hash attacks and usually fewer delays than BCH's DAA. Not counting the startup, the DAA has had 6 episodes of attracting excessive mining resulting > 11 solvetimes averages to be less than 2.5 minutes which is the result of difficulty being a lot slower than price changes. In 7 months of data on these micro coins, there haven't been any instances of this on 4 of them despite having much larger attackers. For EMA to act similarly, it's N would need to be 60/2.3 = 26. But N=50 is safer since SMA N=144 is not broken.

All of these Monero clones were using N=720 which for their T=120 is the same as BCH's DAA N=144. They're both daily averages. The small coins have the advantage getting 4x more sample points. But the daily SMA average reliably results in a disaster for them. Using N=144 is the same as hoping BCH's price does not fall too much. That seems like a security risk based on a presumption.

SMA N=144 is working fine so far, as long as the coin stays big and the miners stay nice. EMA N=100 will probably work better. SMA N=100 or EMA N=50 will work better.

The Simple EMA is next_target = prev_target*(N+ST/T/adjust-1)/N Where adjust=0.99 for N=50 and 0.995 for N=100. With BTC default MTP and 7200 future time limit, no timestamp protection is needed. This assumes ST is allowed to go plus and minus so that it can correct the effect of a bad timestamp. Otherwise, other timestamp protection is needed. I would also limit ST to 7xT.

[zawy12]

If Bobtail is used, N can be reduced a lot to get a faster response to hash rate changes without a loss in stability (equally smooth). If solvetime goes to 2.5 minutes, then N=144 will work a lot faster and better. EMA may need changing if Bobtail is used. Bobtail by itself will not allow SMA N=144 to work any better (faster in response), only a little more stable.

[avl42]

@josephNLD I apologize for not anwering earlier, but here is my reply:

The purpose of the replay protection is to give exchanges and other community participants assurance that if there are hostile forks that they will be replay protected against.

Why would anyone care for a hostile fork? If the hostile fork happened after some tx of mine, the tx would be "there", as well, anyway. Anyone can fork whatever they like, and if they're hostile enough, they might just as well disable the protection on their fork. Most forks go more or less straight to oblivion, so why care?

What this accomplishes is that it puts the burden of getting support on the hostile fork, and it assuages the concerns of the exchanges that the upgrade is done safely. It is not expected that it will be needed, but it is useful for gaining acceptance from exchanges.

I can't imagine that exchanges ask for something like that, but if they actually do, then ... well ... so be it.

Irrespective of any NEED to raise the max block size to 32mb, the code is capable of doing so. The miners set the block size limits always, if developers are limiting it, it is because development has not found a way to address the market with the bitcoin protocol. Getting anywhere close to the developer limits is a failure of development. The actual limits are not set by developers any more since the beginning of Bitcoin Cash. The notion that developers control block size is not accurate. The developers set the capacity for block sizes based on the advancements in scaling, but all block sizes are managed by mining only. The 32mb is just what the software is capable of managing. Mining limits are currently mostly at 2, 4, and 8mb depending on the miner, and this will likely remain so unless it becomes profitable to increase these (based on actual usage).

I see this slightly differently (and still not in the way bitcoin-core does, to be clear) If the software accepts blocks up to 32mb at a time where typical block size is much smaller, then each miner will think like that: "if I set my limit any lower, I might miss a block that others accept and my mining goes awry." No miner will dare to set the limit lower than what he thinks most of other miner might set it to, so equilibrium is only reached at the maximum of what the software allows.

I'd much more prefer if the maximum blocksize would be auto-adjusted by the average size of the last 8 blocks, times a factor in range(1..2), e.g. golden ratio, or just 1.6. Once demand rises, the limit will rise (unlike with "old" bitcoin), but it wouldn't accept a single troll block of 32mb while all other blocks are below 1mb.

[avl42]

Also, there is still the unanswered question about the motivation to add those new opcodes. WHY?

Does anyone have a usecase for it? Some new challenge/response patterns?

I'd like to read about at least one pair of output- and input-scripts using the new opcodes that open a new paradigm for funds control.

[DesWurstes]

https://www.yours.org/content/use-cases-for-re-enabled-op-codes-8b150b6a0deb

[avl42]

@DesWurstes I appreciate your reply, but it doesn't yet satisfy me.

If it were about a real scripting language, I'd certainly not raise the same questions. But it isn't. It isn't even turing complete, and that's by design.

This script language has a special purpose: allowing to specify a challenge and a response for funds transfer control. Furthermore, these scripts are created by untrusted individuals to be executed by (at least) all miners. In Bitcoin network, most miners wouldn't even care to actively mine a transaction that isn't following the common patterns for all its scripts. (not sure how BCH miners usually handle that)

With this premise, anything that isn't explicitly useful for the specific purpose really ought to be removed from this language. I think, even the remaining opcodes are too many, but either they already were in use, or they were added for likely future needs.

Essentially out of an abundance of caution and lack of time to fully explore and fix the edge cases that needed to be addressed, the decision was taken to simply disable any op codes around which there were doubts or even hints of doubts.

That serendipitously did a nice Ockham's shave.

That was my opinion about "why does even anyone ask for a reason".

Now for the single opcodes' reasonings:

OP_CAT: where would the arguments to be CAT'd come from? If all the arguments were all in the same script, then the creator of that particular script could just push the pre-concatenated vector instead (wouldn't take more space than the individual components.

OP_SPLIT: This seems to be for tx's that move funds to "whoever wastes some CPU to claim it". It's not likely that anyone would donate his funds for that... The other usecase opens yet another can of worms, namely a signed message from a third party (exchange). All in all it doesn't convince me ... if it convinces others, then so be it.

for the other ones it essentially just: "it's so basic it just needs to be there and the uses are going to appear like mushrooms in the woods", which I myself don't buy.

It's not like I could stop this train, but I think it's good to have a discussion. Even if this discussion triggers people to come up with more convincing usecases, that would be a win already.

[Danconnolly]

@avl42, I appreciate your concern. I think most people would agree that Bitcoin Cash's primary purpose is to enable the transfer of value through simple transactions. However, it is capable of many more functions, including sophisticated transaction types. It is a challenge to enable more sophisticated functionality without impacting the primary purpose and it must be done carefully, but I think we have achieved that with this update.

The question of whether Bitcoin Cash should be capable of supporting additional functionality has been discussed at length in other places. I think those other places, such as the Bitcoin Unlimited forums, are a more appropriate place for that discussion.

[schancel]

I've aggregated all the feedback and updates and will be merging this now. We should open new pull requests for future changes so history is properly recorded.

[zawy12]

There was a new exploit conducted on Graft. All cryptonote coins who might find themselves facing a miner with >50% hash power need to immediately apply the non-fork Jagerman MTP Patch. It has background discussed here and summarized here.

BCH should do something similar if its nodes create block templates with the current time even when the MTP is ahead of current time. Otherwise, they will be creating a template that they are not going to accept, if it is solved before the MTP goes into the past (relative to that template time).

The MTP can get ahead of current time by a >57% miner assigning timestamps into the future (when MTP=11 and FTL =~ 11. FTL= future time limit which I think is 7200 seconds (FTL =12) in BCH as in BTC. The result is that no one but those with forwarded timestamps on their template can mine. The attacker will be the only one getting blocks until current time passes his fake MTP. He can do it selfishly so that even when the MTP passes current time and blocks start getting accepted, he can continue to mine privately until the public blockchain's work starts approaching his. It enables makes selfish mining easier. If BCH does not have code to stop this already in place (from BTC) my calculations indicates a 68% miner can get 22 blocks out in the open, or use them to jump-start a selfish mining attack. ( @jagerman )

[deadalnix]

Bitcoin ABC already ensures that the timestamp chosen in a block template is ahead of the MTP.

2018-04-28 11:15 GMT+02:00 zawy12 notifications@github.com:

There was a new exploit conducted on Graft. All cryptonote coins who might find themselves facing a miner with >50% hash power need to immediately apply the non-fork Jagerman MTP Patch https://github.com/graft-project/GraftNetwork/pull/118/commits/5b349daf08993c694ff9a05022dee432852832a2. It has background discussed here https://github.com/graft-project/GraftNetwork/pull/118 and summarized here https://github.com/loki-project/loki/pull/26.

BCH should do something similar if its nodes create block templates with the current time even when the MTP is ahead of current time. Otherwise, they will be creating a template that they are not going to accept, if solved before the MTP goes into the past (relative to that template time).

The MTP can get ahead of current time by a >57% miner assigning timestamps into the future (when MTP=11 and FTL =~ 11. FTL= future time limit which I think is 7200 seconds (FTL =12) in BCH as in BTC. The result is that no one but those with forwarded timestamps on their template can mine. The attacker will be the only one getting blocks until current time passes his fake MTP. He can do it selfishly so that even when the MTP passes current time and blocks start getting accepted, he can continue to mine privately until the public blockchain's work starts approaching his. It enables makes selfish mining easier. If BCH does not have code to stop this already in place (from BTC) my calculations indicates a 68% miner can get 22 blocks out in the open, or use them to jump-start a selfish mining attack. ( @jagerman https://github.com/jagerman )

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/bitcoincashorg/spec/pull/53#issuecomment-385156444, or mute the thread https://github.com/notifications/unsubscribe-auth/AA0IaWv8ONwPaFrJB2C5jgGavCIjJ6wKks5ttDMigaJpZM4R2NFc .