Auxiliary block: Increasing max block size with softfork

[Maged]

The thing I don't like is that all of the workarounds to create soft-forks make bitcoin unnecessarily more complicated. A hard fork set for some date in the future allowing people time to upgrade would be much more simple.

Yeah, that's one thing that really worries me. This works, but it's a complete hackjob. That is one of many reasons why I decided against releasing this idea earlier this year, but it looks like someone else independently thought of it. Oh well.

Anyway, let me add my thoughts to this. First off, in the main-chain to aux-chain transaction, you could use that script with P2SH to make these transactions fully transparent, backward compatible, and standard all the way back to 0.6.0. The script for these transactions would only need to be revealed once the transaction is spent in the aux-chain. An interesting benefit of doing it this way is that it allows transactions to be sent to aux-addresses even in blocks that contain no aux-block. These transactions also don't need to be recorded in the aux-coinbase, since each client can independently convert the transaction to an aux-transaction once they have the script.

Secondly, on the return trip from the aux-chain to the main-chain, the transactions being sent should be sent to fees and picked up in the coinbase and sent to the designated scripts, that way they get locked for 100 blocks for all clients. This is important because a reorg would otherwise result in a different transaction hash for the aux-to-main transaction on the main chain side, breaking any transaction that may have depended on that transaction, even if that wasn't intended.

And yes, pretty much any hardfork short of changing the monetary supply can be done with a softfork using this technique. And even that can be done if auxcoins aren't redeemable 1:1 with mainchain bitcoins. That is why I opted not to release this idea. This is extremely powerful and must be handled with care.

[1714026716]

1714026716

[1714026716]

1714026716

[1714026716]

1714026716

[1714026716]

1714026716

[gmaxwell]

That is why I opted not to release this idea. This is extremely powerful and must be handled with care.

I guess it was kinda pointless to not bother talking about it, a lot of people realized the same thing and amusingly also decided to not brag about it.

Llike the stuff I was proposing in the covenants thread: it feels like it has a lot of danger to be used in powerfully stupid ways that hurt fungibility.

That said...  Say there was change to core blockchain functionality that  51% of the bitcoin owners (however you want to measure it) really wanted... and 49% thoroughly opposed.  I think it would be immoral for the majority to force that onto the minority (if you make the minority small enough, I think this argument fails at some point— but for 49% it holds fine).   And yet, I think it's also wrong (if not immoral— after all, they adopted foo by their own free choice as it was—, just unoptimal and probably not stable) to not give the _majority_ what they want.

I think I've thought situations would be resolved through things like altcoins and gradual market forces. ... if you have foo and you want bar.. you don't _force_ with your majority-clique-power all the foo users to become bar users, you sell your foo and buy bar.  And if both foo and bar are good local design-space minima which are distinct from each other (e.g. I don't think ~any of the altcoins existing have this property) perhaps they'll both happily coexist without one forcing the other out of the market through network effect.

The point being, that it may be ultimately better for foo users if bar exists as part of foo but in a way which minimally disrupts foo, instead of as something wholly distinct. Degrading fungibility is sad, but I don't think its more sad than coercive action by the majority through protocol changes, or more sad than an even greater fungibilty loss switching to an entirely separate system.

So while I certainly wouldn't rush out to create such a thing, I think there is room for us to entertain ideas in this space without feeling that it is abhorrent to the idea of Bitcoin.

[jl2012]

And yes, pretty much any hardfork short of changing the monetary supply can be done with a softfork using this technique. And even that can be done if auxcoins aren't redeemable 1:1 with mainchain bitcoins. That is why I opted not to release this idea. This is extremely powerful and must be handled with care.

I didn't realize it is so powerful when I first proposed it. Now I believe everything can be done with a softfork, except changing the format of block header and coinbase tx. I wonder if Satoshi was aware of this when he designed the protocol.

Anyway, I have (unintentionally) opened the Pandora's box. This reminds us that a 51% attacker could do a lot more than we usually think.

[jl2012]

With the aux-block technique, we could release CoinCovenants from limbo 

Llike the stuff I was proposing in the covenants thread: it feels like it has a lot of danger to be used in powerfully stupid ways that hurt fungibility.

[gmaxwell]

This reminds us that a 51% attacker could do a lot more than we usually think.

Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks.

[jl2012]

This reminds us that a 51% attacker could do a lot more than we usually think.

Dunno there: someone with a bunch of hashpower can't make anyone actually use whatever crap they add to their blocks.

Attackers can reject any tx that is not following their rules. Other people could either follow, or hardfork

[gmaxwell]

Fortunately since it would take a conspiracy or compromise of at least _three_ people to have control over 50% of Bitcoin's mining hashpower today, so we can be quite confident that such an outcome is completely infeasible.

[Maged]

This reminds us that a 51% attacker could do a lot more than we usually think.

With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.

[gmaxwell]

With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.

Woah woah, you've taken a reasonable point and exaggerated it here. A softforking rule that just denies some kinds of transactions is not the same as having clients that have to accept whole different kinds of invisible bitcoins. You still have to change the client software to be able to see or spend your bloatcoins.

(But then again with 200k users or whatever being on BC.i we can probably just dispense with the blockchain in any case…)

[Maged]

With this, it's not attackers we should be worried about. Think about it: changing the max block size just became as painless to the community as changing the protocol to prevent duplicate transaction ids was. Take that as you will, for better or for worse.

Woah woah, you've taken a reasonable point and exaggerated it here. A softforking rule that just denies some kinds of transactions is not the same as having clients that have to accept whole different kinds of invisible bitcoins. You still have to change the client software to be able to see or spend your bloatcoins.

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.

[gmaxwell]

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.

I think you need to think through your attack a bit more.

If you are imagining something as simple as "deny all new transactions, mine just blocks committing to MegaBitcoin auxblocks with 21 trillion coins instead" then it would be simple enough for the honest Bitcoin users to ignore blocks with the MegaBitcoin Commitments in them.

So instead I think your attack is a weaker versions of an attack where you merge mine Bitcoin with an altcoin and DOS bitcoin and do all your stuff in your altcoin. At least then it's harder for Bitcoin users to fork off your blocks by their shape.

Of course, if you're using a majority of hashpower to DOS bitcoin you've disprove one of the fundamental security assumptions (arguably the current hashpower distribution is already disproving them, but its not clear how fast that would change if there was an attack) and so what would be the point of your MegaBitcoin?  If you want to trust a cooperating conspiracy, there are far more efficient ways to interact with them for finical purposes.

So really this just sounds like "if you can get a conspiracy of a majority of hashpower you can kill bitcoin" but we've always known that— thats what it said on the tin.

... When I stop having problems with people paying to me on a P2SH address, adopted at the beginning of 2012— you can't send to them in half the clients apps, including ones promoted on Bitcoin.org, or via many popular webwallets or commercial services, even though the change is a couple lines of code and is economically neutral... I might start worrying more about "in practice" more. Experience shows that having some network rules does far less than you might guess.

[jl2012]

Anyway, let me add my thoughts to this. First off, in the main-chain to aux-chain transaction, you could use that script with P2SH to make these transactions fully transparent, backward compatible, and standard all the way back to 0.6.0. The script for these transactions would only need to be revealed once the transaction is spent in the aux-chain. An interesting benefit of doing it this way is that it allows transactions to be sent to aux-addresses even in blocks that contain no aux-block. These transactions also don't need to be recorded in the aux-coinbase, since each client can independently convert the transaction to an aux-transaction once they have the script.

Secondly, on the return trip from the aux-chain to the main-chain, the transactions being sent should be sent to fees and picked up in the coinbase and sent to the designated scripts, that way they get locked for 100 blocks for all clients. This is important because a reorg would otherwise result in a different transaction hash for the aux-to-main transaction on the main chain side, breaking any transaction that may have depended on that transaction, even if that wasn't intended.

Interesting idea. So an aux-coinbase is needed only for collecting aux-fee and it's more block space efficient. A drawback is the need to store all genesis aux-transactions as they are required to redeem the locked fund in the main chain (though the people who want to redeem may supply such info to miners)

There are different approaches to push the new protocol.

1. The one in OP is (I believe) the gentlest way. It allows people move between old and new protocol, and guarantee full fungibility of old and new coins. If there is any value difference between old and new coins, arbitrageurs will close the gap. The problem is that would make the protocol more complicated. After the majority of people have moved to aux block, we may stop processing any traditional transaction in the main chain*, and stop allowing people to redeem main-coin with aux-coin. All these could be done with further soft-forks. However, we can never completely obsolete the main block because some main-UTXO (e.g. lost coins) will always exist. (* with the P2SH suggested above, one needs to spend the coin at the aux-block immediately to show that's not a traditional P2SH transaction.)

2. The other solution is to create a no-return system from the beginning, as gmaxwell suggested at https://bitcointalk.org/index.php?topic=283746.msg3037821#msg3037821 . Actually I think this is not a good idea because no one would want to be the guinea pig to send bitcoins to the aux block, with the risk of being locked in limbo. As a result, the value of aux-coin will be lower than main-coin, and further reinforce the reluctance to the transition. Even if the aux system is superior than the old one, it still won't be adopted. Therefore, any no-return system must be accompanied by banning any traditional transaction, as suggested above.

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

4. We can combine approaches 1 and 3. Approach 1 is implement at first. The code, however, further indicates that the approach 3 will be adopted if >95% miners agree and >70% of UTXO are in the aux-chain.

[TierNolan]

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

It is similar to a scheduled hard-fork.  Old clients will just stop working.  

It wouldn't be possible to send an old client fake transactions, since they will still track the block chain.  All blocks will just be empty.  

When someone tries to send a transaction, they will wonder why it never confirms (and find out that they need to download a new client).

This is pretty much equivalent to destroying Bitcoin v1 and salting the earth, so it can't be revived in its original form, while simultaneously creating a new coin on the ashes.

Having said that, if people wanted to continue, they could just blacklist the now empty blocks.

[jl2012]

It wouldn't be possible to send an old client fake transactions, since they will still track the block chain.  All blocks will just be empty.  

This is probably the strongest argument for doing a softfork instead of hardfork.

Having said that, if people wanted to continue, they could just blacklist the now empty blocks.

Yes. In any fork, soft or hard, people always have the option to follow the original one.

[Maged]

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.

I think you need to think through your attack a bit more.

The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).

Interesting idea. So an aux-coinbase is needed only for collecting aux-fee and it's more block space efficient. A drawback is the need to store all genesis aux-transactions as they are required to redeem the locked fund in the main chain (though the people who want to redeem may supply such info to miners)

We get that for free. When the main-to-aux txout gets spent on the aux chain, the script needed to redeem the transaction on the main chain is revealed and is stored in the aux chain as part of that transaction's txin. The txout that is left behind on the main chain would remain in the main chain's UTXO tree, since you have to keep that separate tree for compatibility, anyway. All of the information needed to redeem those transactions later on the main chain can therefore be gathered from the raw, unpruned blocks, just like how our UTXO tree is today. Miners could safely drop the information linking the UTXOs to their redemption script, true, but I'd question how much memory that would really save, especially because miners could safely defrag the main-to-aux UTXOs by adding more inputs than needed for the aux-to-main transaction and creating a single change anyone-can-redeem output.

There are different approaches to push the new protocol.

1. The one in OP is (I believe) the gentlest way. It allows people move between old and new protocol, and guarantee full fungibility of old and new coins. If there is any value difference between old and new coins, arbitrageurs will close the gap. The problem is that would make the protocol more complicated. After the majority of people have moved to aux block, we may stop processing any traditional transaction in the main chain*, and stop allowing people to redeem main-coin with aux-coin. All these could be done with further soft-forks. However, we can never completely obsolete the main block because some main-UTXO (e.g. lost coins) will always exist. (* with the P2SH suggested above, one needs to spend the coin at the aux-block immediately to show that's not a traditional P2SH transaction.)

3. A very rude way is to move all UTXO to the aux chain at a pre-defined block height, and prohibit any main-transaction forever. This is also the cleanest way as it will leave nothing but a dummy coinbase tx in the main block. However, its impact is same as a hardfork since all old nodes will be broken immediately, so it may be easier to implement a hardfork directly.

4. We can combine approaches 1 and 3. Approach 1 is implement at first. The code, however, further indicates that the approach 3 will be adopted if >95% miners agree and >70% of UTXO are in the aux-chain.

And if we want, after we've DoSed Bitcoin v1 for some time, we could drop support for the Bitcoin v1 chain altogether, allowing us to create a new blockheader for the aux-chain, therefore making it completely independent of Bitcoin v1. This should be safe, because the difficulty would be absurdly high and there would be no fees that could be collected by main-chain-only miners, so almost every miner would switch. It would take years for someone to generate a single block on that chain after the drop-dead date, so old clients couldn't be abused. If needed, we could even drop the v1 UTXO tree at that time, but that shouldn't be necessary unless we fundamentally change the way transactions work (like if we don't allow ECDSA for signatures in aux-transactions) and we want to drop the legacy transaction code.

God, now I feel like we're engineering the IPv4 to IPv6 transition...

[gmaxwell]

Technically, that's correct. Practically, my statement is dead on. Usurping Bitcoin is as easy as getting 51% of the hashing power and some number of users (doesn't need to be a majority, just a few percent) on your side. We need to think long and hard about the implications this will have in the future.

I think you need to think through your attack a bit more.

The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).

This wouldn't have news to us, go look at bitcoin-dev logs around june-july 2011.  I wish you wouldn't have ignored the rest of my message.

It's isomorphic to a majority hashpower DOS attack and an altcoin.  The challenge in saying that its different is that if a majority of hashpower violates the contract then the security assumptions underlying Bitcoin (and any similarly constructed altcoin) are invalid.

Bitcoin is secure if:

(0) Various cryptographic constructs do what they're supposed to.
(1) A majority of the involved computing power behaves honestly (correctly imposed the rules of the contract)
(2) If information is easy/cheap to spread and hard to stifle so that its participants cannot be isolated (including excessive delays) from the honest majority.

And we argue that (1) is probable because faithful behavior is what makes performing computing valuable.

[jl2012]

The problem is that I'm not referring to what is generally accepted to be considered an "attack". If that were the case, I would have contacted Gavin about this issue long ago. The problem with this, which is far more subtle than an "attack", is that now the Bitcoin "contract" can be violated with a mere simple-majority support. That's why I didn't tell any developers about this method (although I would have if the block size became a major issue and no hardfork was in sight).

There are many easier ways for a 51% attacker to violate the contract without major coding effort:

• 1. collect fee according to bitcoin-days-destroyed, effectively turning Bitcoin to Friecoin.
• 2. request AML registration for every addresses, so bitcoin becomes the most traceable currency on the planet
• 3. turn it to SolidCoin by rejecting all blocks that are not signed by a central server
• 4. blacklist tainted addresses and transactions
• 5. collect miner tax: the 49% miners have to pay part of the reward to the attacker
  

1, 3, 5 are already happening in some altcoins.

[Maged]

I think the confusion here is that I'm not arguing any technical points, but rather political points. Does this fundamentally change security properties that we thought to be true? Of course not. An attacker can do much worse with much less effort than implementing this. What this does fundamentally change is that the "good guys" now have a method to modify the Bitcoin contract that doesn't require absolute consensus and incentives them to do it in a way that forces people to make a choice about what chain to follow (because the default choice is a non-functional client).

Is this a good thing? I say yes. We just need to be very cautious about how we use this. I'm just worried that now that things that used to require a hard-fork no longer require a huge event where everything changes at once that we will slowly, over time, make enough compromises in the design of Bitcoin that were the changes made all at once today, they would have been rejected.

This wouldn't have news to us, go look at bitcoin-dev logs around june-july 2011.

Interesting. What keywords/topics should I be looking for?

I wish you wouldn't have ignored the rest of my message.

I figured that my comments on the rest of your post would be very uninteresting, since it seemed to me that you were misinterpreting what I was trying to say. However, if you insist...

If you are imagining something as simple as "deny all new transactions, mine just blocks committing to MegaBitcoin auxblocks with 21 trillion coins instead" then it would be simple enough for the honest Bitcoin users to ignore blocks with the MegaBitcoin Commitments in them.

Indeed it would. However, it would require downloading a special client to do this. A conscious decision about which chain to follow would have to be made. I would argue that this is a good thing, but many people who want to see 1 MB blocks forever would disagree.

So instead I think your attack is a weaker versions of an attack where you merge mine Bitcoin with an altcoin and DOS bitcoin and do all your stuff in your altcoin. At least then it's harder for Bitcoin users to fork off your blocks by their shape.

Pretty much, except no effort would be made to actively make it hard to fork from the DoSed chain. So yes, it is a weaker version of that.

Of course, if you're using a majority of hashpower to DOS bitcoin you've disprove one of the fundamental security assumptions (arguably the current hashpower distribution is already disproving them, but its not clear how fast that would change if there was an attack) and so what would be the point of your MegaBitcoin?

To solve real problems with Bitcoin's current design without a hard fork. Whether those changes are good or not would be debatable, but a large amount of people would at least see the changes as a good thing.

If you want to trust a cooperating conspiracy, there are far more efficient ways to interact with them for finical purposes.

Agreed.

So really this just sounds like "if you can get a conspiracy of a majority of hashpower you can kill bitcoin" but we've always known that— thats what it said on the tin.

Agreed.

... When I stop having problems with people paying to me on a P2SH address, adopted at the beginning of 2012— you can't send to them in half the clients apps, including ones promoted on Bitcoin.org, or via many popular webwallets or commercial services, even though the change is a couple lines of code and is economically neutral... I might start worrying more about "in practice" more. Experience shows that having some network rules does far less than you might guess.

That's disappointing, but the point is that backwards-compatibility would already exist in some form, so we wouldn't have to seed it for a few years before we started using it. Using this method, we could get around the 1 MB block limit in as little as one month after this is deployed, because a large chuck of the userbase would already be compatible.

It's isomorphic to a majority hashpower DOS attack and an altcoin.  The challenge in saying that its different is that if a majority of hashpower violates the contract then the security assumptions underlying Bitcoin (and any similarly constructed altcoin) are invalid.

Bitcoin is secure if:

(0) Various cryptographic constructs do what they're supposed to.
(1) A majority of the involved computing power behaves honestly (correctly imposed the rules of the contract)
(2) If information is easy/cheap to spread and hard to stifle so that its participants cannot be isolated (including excessive delays) from the honest majority.

And we argue that (1) is probable because faithful behavior is what makes performing computing valuable.

But what does it mean to behave honestly? Is a node that cashes in all the outstanding P2SH transactions that they have the original script for (but not the keys to redeem) behaving honestly? After all, the original protocol says that you only need the data that hashes into the script hash to redeem these transactions.

[jl2012]

By definition, soft-fork means making currently valid block invalid, hard-fork means making currently invalid block valid. However, I think soft-forks could be further divided into 4 levels.

"Level I soft-fork" will only affect miner. An example of level I soft-fork is the recent upgrade to v2 block. Upgrade is optional for non-miner. If they don't upgrade, their effective security will decrease to SPV level. However, they can still enjoy the full functionality of bitcoin. Developers of alternative SPV clients do not need to take any action.

"Level II soft-fork" will introduce new functions to bitcoin. Examples of level II soft-fork are P2SH and my proposal for native colored coin support (https://bitcointalk.org/index.php?topic=253385.0) Upgrade is still optional for non-miner. If they don't upgrade, they won't be able use the new function. However, they can still use Bitcoin the currency as usual. Developers of alternative SPV clients do not need to take any action if they don't want to support the new functions. Actually, most SPV clients are still not supporting P2SH.

"Level III soft-fork" will introduce currency changes to bitcoin. Examples of level III soft-fork is the OP proposal and my proposal for further currency divisibility (https://bitcointalk.org/index.php?topic=256516) Upgrade is still optional for non-miner. If they don't upgrade, they will have some troubles in transacting with new nodes. However, they can still spend and receive "old bitcoin" as usual. If SPV clients do not upgrade, the users will have the said trouble.

"Level IV soft-fork" will denial some or all existing services. Non-miner could only either follow the new rules or follow a hard-fork. Although by definition this is a soft-fork, politically and practically it is very similar to a hard-fork.

Any aux-block softfork would be at least Level III because it will introduce aux coins that are invisible to existing clients. That might not be as easy as we think.

EDIT:

I find an interesting point. When there is a hardfork, the original fork will become a de facto Level IV softfork, because the original fork 1. has stricter rules, and 2. denials to serve any transactions related to the hardfork. So we shouldn't exaggerate the power of a high level soft-fork.

[Peter Todd]

jl2012: What's interesting about SPV nodes is that because they don't really verify anything, there are cases where a hard-fork for a full node is a soft-fork for a SPV node. One such example is the merkle tree itself - and SPV node wouldn't know the difference if we, say, moved the coinbase transaction to the top of the tree.