Topic: Auxiliary block: Increasing max block size with softfork - page 2. (Read 13919 times)

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

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

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.

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.

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.

The complicated part should be transparent to users. Eventually, all tx will happen in the aux block, leaving only a dummy coinbase tx in the main block (which works as extended block header). The risk of hardfork is too high and I believe it should be used only in absolutely necessary cases like:

• Bug fix like BIP50
• Timestamp overflow in year 2106
• SHA256 is completely compromised

I believe these are the ONLY scenarios that a hardfork is unavoidable. Please point out other scenario if anyone finds one.

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.

I still think it is mush safter to phase-in an agreed change instead of a fork. A fork is very likely to create some confusion and unpredictable behavior for miners/nodes/merchants

Right, the question was what happens if 51% violate the rules of the soft fork, after it has been accepted.

The miners of 750 of the last 1000 blocks add "/AUXBL/" to their coinbase

This proves that miners support the (soft) fork

Once that happens, the change is "locked-in".  New blocks that violate the new rules are simply rejected and new clients have the rule built in.

New clients and old client all track the same main chain.  Miners still using the old rules are orphaned almost immediately.

An attacker arrives (with 51%) and violates the new rules.  This converts a (correctly implemented) soft fork into an actual fork.  All old clients follow the attacker and all new clients follow the updated rules.

The attack has split the network.

If the soft fork rule allowed reversion, then after 1000 blocks, even the new clients will follow his chain, since less than 750 of the last 1000 blocks will have the coinbase message.

You can see someone attempting this right now with "mastercoin" which is apparently supposed to be an alt-coin which forces Bitcoin nodes to store its data by stuffing them in perpetually non-redeemable utxo... so it even goes a step beyond undermining the rules with an alternative system, it moots pruning in Bitcoin and would eventually— if successful— make it much harder to run a validating node.

If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition)

Unfortunately, this also means that 51% miners could violate the Satoshi philosophy. They could print as many  aux coins as they want, steal ancient aux UTXO,  etc. Minority users need to hardfork if they don't like these rules.

With this approach, we could change pretty much everything in the protocol with soft-fork. Just some examples:

• The way to calculate tx hash
• Coin divisibility
• New fields in block header and transaction
• Native color coin support
• Shorten block time interval
• Ultimately, we could trim the original Satoshi protocol to absolutely minimal (probably except the few involving block headers like double SHA256 PoW and Merkle Tree), and implement a completely new set of rules

For the fungibility problem, a very aggressive solution is to create a genesis-aux-block with all UTXO in the main chain. New miners will collect their reward in the aux-chain only, and they will reject any main chain tx except the dummy coinbase tx with zero value. So all old nodes are broken immediately, but it's still a softfork because the PoW is still valid for them. I call this the ultimate-51%-attack.

If an attacker did that, then he would fork the chain.  "Soft-fork" is actually relative.  It means that there are 2 sets of rules, but the majority of the hashing power supports the more restrictive rules.

This means that blocks that are banned by the restrictive rules are orphaned by a majority of the hashing power.

A soft fork switches to an actual fork (2 incompatible chains), if the majority of the hashing power deserts it.

Once a transaction is in the aux block all of its children must forevermore be in the aux block.

This was also how I thought we could implement a new transaction syntax (one that makes the scriptsigs prunable) and switch to using hash-sum trees to make the coinbase value provable: move all txn into a separate tree eventually, and eventually require that the only txn in a block be the coinbase.

The downside is that until the transition is complete you have degraded fungibility with two kinds of Bitcoins.

But, wouldn't the system be incompatible for miners with old software (without the upgrade).
Some attacker (does not need to be a miner, just a regular client) might create transactions to redeem the coins in the aux-block. These transactions would seem valid for old miners. These miners with old versions would accept these transactions and therefore their blocks would be invalid for upgraded miners.

Or maybe I didn't understand something of the idea?

I thought just the contrary: With more than 50% you could steal all coins in the aux-blocks of upgraded users, because

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.
The only incentive for miners to not do this, is that they know that these blocks would be considered invalid by more than 50% of hashing power if most miners have upgraded.

You can only steal coins from people who don't upgrade.  A soft fork is a fork that the obsoleted clients will still accept (if it has enough POW).


I would strongly recommend that it also includes an alt-header.  That way new fields can be more easily added.  It is not possible to indefinitely use 32 bytes of coinbase space for everything.

If the alt-block had a variable length header field (old clients ignore new fields), then you can use the same 32 coinbase bytes for all extensions.

Get majority hash power, steal all the coins?  (Or at least a very large amount, potentially.)  This creates a huge incentive to commit a "51% attack", does it not?

With aux-block, some other hardforks could also become softforks. For example, the calculation of tx hash in aux-block may exclude scriptSig, so transactions are identified purely by their inputs and outputs.