Bitcoin 'Breakthrough' Claims Block Size Increase Possible Without Hard Fork

Bitcoin ‘Breakthrough’ Claims Block Size Increase Possible Without Hard Fork

View Reddit by jthawksView Source


  1. This article never discusses the technology. The talk referenced can be found on YouTube video “Scaling Bitcoin 2018 “Kaizen”_day1_Part2”. It is 30 minutes long and starts at 1:02:00.

    It was just uploaded and has a grand total of 124 views right now. It will take time for people to find the material… but also very long to process the concept of “Forward Blocks”.

    Edit: Some thoughts after watching the video:

    These changes are much more complex than segwit or anything that’s been done before.

    His idea of forward blocks should be considered separate from his other ideas… although he talks about them together. His ideas include sharding (wants 28 forward chains), proposed changes to the miner rewards (he wants to replace halvening with slow change over time to eliminate the ‘event’), flexcap for block sizes (he wants to allow miners to change their proof of work target and in doing so increase or decrease size of block in a manner that would incentivize ‘good block size’). So a lot of very ambitious ideas here that probably don’t belong on BTC, at least not until they have been applied to litecoin and other altcoins.

    It’s a neat idea, hard to know if it can work right now, but sounds interesting. It more complicated than I would like on Tier 1 BTC, and it breaks in-use functionality of bitcoin, such as time-locking (because the compatibility chain would be mined at faster than 10 minutes using a bug, and the forward chain would be mined slower than 10 minutes to ‘increase security’).

    Just that fact that he is exploiting a bug to manipulate the legacy chain into keeping up with the forward chain is grounds to say this is an attack… And there are other things about his idea that make it sound like an attack.

    Personally I think any large change to BTC should be considered a potential attack, even if it does not involve exploit bugs, forks, and changes to the base protocol. Especially after recent events where we found out bugs were introduced during very small code upgrades. Imagine what a bad actor could sneak into a big upgrade like this. If a change is adopted on other coins first, such as LTC, for very long periods, it is more palatable.

  2. > it’s worth noting the two upgrades Friedenbach emphasizes – block sizes and proof-of-work

    It isn’t appropriate to call raising the block size in this way an ‘upgrade’. It’s a security downgrade, not a scalability upgrade.

    Bitcoin is the most secure when coins are fully validated — and can be refused as invalid — by a receiver who is running a full node under their own control. Even that maximum possible security level may be insufficient to withstand the attacks that may be coming, but it is our best shot.

  3. Of course an effective block size increase is possible with softfork only.

    Without having read that link, here is the solution for this that I always had on my mind since years (but never talked about it until now):

    * Define a new data structure blockchain (call it “blockchain B” or “bcb” from now on). In this blockchain B (bcb), each block hash of bcb block M is a function of (a) the transactions in bcb block M, (b) bcb block hash M-1 and (c) Bitcoin blockchain block hash of block “M+*offset*”, where *offset* is a fixed value fixed by SF protocol enhancement. This way there is a 1:1 relation between each bcb block and each original bitcoin blockchain block for block height > “offset”.

    * The normal bitcoin block contains a certain standard dummy transaction (generated by the miner) that includes a special bit pattern in the optional OP_RETURN field. This 40 bytes (320 bit) field is seperated into 64 bit + 256 bit as follows: The first 64 bit (8 bytes) are a fixed bit pattern defined by the standard acc. to the SF and says “attention, this is a special pointer to the bcb block belonging to this block”. The remaining 256 bits are a sha256 hash of the corresponding block of the bcb. A miner will only mine the bitcoin block if it knows the corresponding bcb block and deems it valid. So mining this bitcoin block also confirms the corresponding bcb block!

    * How to “transition” from standard blockchain to bcb? Well: Assume 1 BTC was sent from A to B on standard blockchain in some earlier block. Now the owner of address B creates a TX sending 0.8 BTC from B to C. He forms this TX such that it shall be included in a bcb block instead of standard block, and broadcasts it to the network (the tx format shall be slightly different, so each broadcasted tx can only be added to standard block OR bcb block, as decided by the sender,, not the miner).

    * If, 2 days later, the owner of B wants to send the same 0.8 BTC to D (double spend), that would be rejected by new miners because of an obvious double-spend of course. However, old miners not supporting this SF would accept it because they would not know about
    the earlier tx from B to C. This is in analogy how non-segwit miners would consider a segwit tx an “anybody can spend tx”. Of course, if an old miner accepted this tx from B to D and included it into a newly mined block, that new block would be considered invalid by the new miners (or any new nodes operating acc. to the SF), so the double spend could not prevail.

    * If the owner of address C wants to spend some of his 0.8 BTC to E, he can readily do so with a normal TX for bcb. It has to be noted that this cannot happen on standard blockchain, because standard blockchain does not know that C has these 0.8 BTC. So any bitcoins that arrive on bcb remain on bcb forever and can never get back to standard blockchain. But that’s ok, as bcb is just as valid as the standard blockchain after the SF.


    Seems what I have decribed is pretty much the extension block idea ( (which is a SF) so sorry for that.


Please enter your comment!
Please enter your name here