Topic: Auxiliary block: Increasing max block size with softfork (Read 13919 times)

So we have at least 4 levels of hardforks:

Level I hardfork: a hardfork that is completely transparent to SPV nodes, such as the BIP50 bug fix, increasing MAX_BLOCK_SIZE, increasing block reward (too bad!!!)

Level II hardfork: a hardfork that adds new functions while all existing functions are still supported, such as SIGHASH_WITHINPUTVALUE (https://bitcointalksearch.org/topic/sighashwithinputvalue-super-lightweight-hw-wallets-and-offline-data-181734) . Old SPV nodes can still function as usual, just not supporting the new function.

Level III hardfork: a hardfork that will partially break SPV nodes, such as fixing the OP_CHECKMULTISIG bug. SPV nodes can still receive bitcoin from bug-fixed OP_CHECKMULTISIG but cannot send with it properly

Level IV hardfork: a hardfork that will completely break SPV nodes, usually something fundamentally change block or transaction format, such as increasing coin divisibility, 64bit block timestamp.

However, this pretty depends on how an SPV node exactly works. With the examples here I assume that SPV will only 1) make sure blocks have adequate PoW; 2) find the chain with highest PoW; 3) look for related transaction outputs in the chain. It would not check the validity of the signature (otherwise SIGHASH_WITHINPUTVALUE signatures of bug-fixed OP_CHECKMULTISIG would look invalid).

Please feel free to add more levels to the list (both softfork and hardfork).

That's essentially what this is. The main (only?) reason that this would require a softfork is that it allows someone to send a transaction from BTC2 back to BTC1. Other than that, it's basically a merged-mined chain.

You're not thinking deviously enough.

Lets suppose I define a new merkle-sum-product-christmas-tree which sums all the transaction values up and even distributes presents to the homeless; we'll call the top level digest of that tree D2, and the top level digest of the old merkle tree D1.

Now ask yourself, can a SPV node know if rather than setting hashMerkleRoot to D1 as before, we've set it to Hash(D1 | D2)? A full node certainly can - they have a full list of transactions and will immediately see that something isn't adding up - but what about a SPV node?

Also, it'd be interesting to know if any SPV clients out there would even notice if they were given two transactions, ostensibly from the same block, whose merkle paths back to the block header were of different lengths.

IMO, even a soft fork is unneeded.

Just make BTC2, which transits upon, and wholly depends upon, BTC.  Have the BTC2 proof-of-work depend on information in the BTC chain, and timestamp BTC2 blocks inside the BTC chain.

Many "simple" hard-forks are transparent to SPV, such as the BIP50 bug fix and increasing MAX_BLOCK_SIZE.

For your example of moving the coinbase transaction to the top of the tree, new full nodes need to somehow cheat the old SPV nodes to make it works. 

More complicated changes, e.g. merkle sum tree, will break SPV nodes

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.

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://bitcointalksearch.org/topic/opcheckcolorverify-soft-fork-for-native-color-coin-support-253385) 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://bitcointalksearch.org/topic/increase-currency-divisibility-with-soft-fork-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.

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.


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

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...

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.

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.

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.

Agreed.

Agreed.

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.

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.

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.

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.

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).

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.


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...

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


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

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.

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://bitcointalksearch.org/topic/m.3037821 . 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.

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.

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.

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…)

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.

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.

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