1

It appears that the BitcoinCash chain is still on its original BCH main chain, and non-upgraded mines/exchanges/wallets can still transact there.
What then would happen if nine (or more) 1MB transactions were created by padding the comments so each transaction was just under 1MB. Assuming that these none-or-more transactions all had attractive Satoshi's per byte, is the following scenario possible? If not why not?

  • Upgraded mines would try and fill a new block with nine (or more) 1MB transactions while non-upgraded nodes would try and fill a new block with exactly eight of them.
  • If an upgraded mine won the next block, then it would create a physical 32MB consensus rule fork with an initial 9MB block off of the main chain, and we would be able to see this >8MB block in a BitcoinCash block explorer (at least for a while).
  • Subsequent blocks mined by non-upgraded nodes would extend original 8MB non-upgraded main chain, whereas subsequent blocks mined by upgraded nodes would extend the upgraded now hard fork chain.
  • Meanwhile exchanges/wallets which have not been upgraded (possibly some major players due to non-consensus seeking nature of this release) would operate only on the original main chain, while those that have upgraded would operate on the upgraded chain, assuming it is longer.
  • Periodically the chain with the largest cumulative work would cause transactions on the other chain to be sent back back into the mempool, potentially allowing this process to repeat assuming that the new upgraded chain had less cumulative work and that the new upgraded chain again won the next block race and wrote a new 9MB hard fork block.
  • Should this work, the overall effect of this could be tantamount to a temporary denial of service attack on the BitcoinCash network.
|improve this question|||||
  • By "none-or-more" on the 4th line, I meant "nine-or-more", apologies for the typo, thanks.. – jimhash May 18 '18 at 15:14
1

No, the hard fork also brought new opcodes. Transactions using those new opcodes have already been made, which caused the chains to become separated. If the only change were a block size limit increase, the developers would (?) put a consensus rule that says "The size of the first block after the fork must be bigger than 8 MB.", similar to Bitcoin Cash's first block, after forking the Bitcoin blockchain. "...must be bigger than 1 MB..."

Trivia: Rawpool continued to mine for the old blockchain for one day. More information

|improve this answer|||||
  • I am aware of the "new" (really just reinstated) opcodes. To this argument, I keep falling back on the point that you can put anything in the script (including opcodes which are not recognized by non-upgraded nodes), but good luck redeeming/unlocking-funds, especially on a non-upgraded nodes. Assuming your unbiased(?) argument holds water, then may I also ask – jimhash May 18 '18 at 15:22
  • (1) Wouldn't a >8MB block on the main chain cause the real disruption I'm driving at here which is that non-upgraded exchanges/wallets would no longer be able to transact on that chain? and (2) If creation of a block >8MB were such a non-issue, why then wouldn't BitcoinCash maximalists create such a block (possibly as outlined above) to prove once and for all to potential adopters that their chain really does scale? – jimhash May 18 '18 at 15:23
  • (1) Yes. That's why hard forks are opposed. (2) There are no obstacles. A miner can fill their block completely if they want, for free. However, big blocks increase the risk of orphaning, which means it only looks like "free", and has a hidden price. Such a block would be different than a 30 MB block filled by real transactions. In that case, since the transactions would have been broadcast, Xthin/Compact Blocks/Graphene can significantly reduce the probability of an orphan block. So, a miner either has to broadcast their transactions to reduce the prob of orph. (lose money by fees) or deal – MCCCS May 18 '18 at 16:10
  • with orphaning @jimhash – MCCCS May 18 '18 at 16:13
  • A change to the block size (May 15 upgrade) is a hard fork by definition, so sounds like my (1) is valid; creation of such a block would be disruptive. For my (2) I'm down to "show me a block >8MB". I feel we getting a little off topic into biased(?) "arm waving" at this point, I never mentioned anything a 30MB block. I am hoping a committed BitcoinCash or Bitcoin Maximalists will fund/probe this from their side. The former to prove their upgrade works, the latter to prove it doesn't. In the meantime I advise large miners to revert to pre upgrade release assuming they did upgrade at all. – jimhash May 18 '18 at 16:57

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.