Bitcoin Forum
August 23, 2017, 12:55:59 AM *
News: Latest stable version of Bitcoin Core: 0.14.2  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 3 »  All
  Print  
Author Topic: Auxiliary block: Increasing max block size with softfork  (Read 12341 times)
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:10:56 PM
 #1

I just realize that the 1MB block size limit could be increased with a softfork. I call it auxiliary block:

1. An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.

2. OP_NOP1 is redefined as OP_AUX

3. Initially, auxiliary blocks are empty, until someone sends X bitcoin to a scriptPubKey of this format: <serialized script x> OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to <deserialized script x>. The Merkle Root of the auxiliary block will be included in the coinbase of the main block. All upgraded nodes will check whether the bitcoins are correctly transferred from the main chain to the aux chain

4. People can transfer aux chain bitcoins like in the main chain. Miners can also collect fee in the aux chain using the same mechanism as the main chain. The only difference is there is no generation bonus in aux chain. New aux coins are generated if and only if someone send bitcoins to <serialized script> OP_AUX in the main chain

5. When someone want to transfer Y aux coins back to the main chain, he will send Y aux coins to a scriptPubKey of this format: <serialized script y> OP_AUX OP_RETURN. Seeing this, the miner will randomly choose some OP_AUX UTXO in the main chain, with value exactly equals to Y bitcoins, and pass them to <deserialized script y> in the main chain.

Backward compatibility:

1. Since old nodes will not see the aux block, the aux block could be indefinitely big

2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.

4. Old nodes can still mine. As long as they are not trying to include or redeem OP_AUX transactions, their blocks are still valid.

(More extremely, we may disallow people transferring aux coin back to the main chain by requesting them to send bitcoin to <serialized script x> OP_AUX OP_RETURN on the main chain. This will provide better backward compatibility since such outputs are not redeemable in both new and old nodes, and old miners would see these as non-standard and won't mine them)

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
1503449759
Hero Member
*
Offline Offline

Posts: 1503449759

View Profile Personal Message (Offline)

Ignore
1503449759
Reply with quote  #2

1503449759
Report to moderator
1503449759
Hero Member
*
Offline Offline

Posts: 1503449759

View Profile Personal Message (Offline)

Ignore
1503449759
Reply with quote  #2

1503449759
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1503449759
Hero Member
*
Offline Offline

Posts: 1503449759

View Profile Personal Message (Offline)

Ignore
1503449759
Reply with quote  #2

1503449759
Report to moderator
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 04:23:37 PM
 #2

This means that there is always a one to one mapping of aux-block to main block?

What happens if there is a block with no aux-block (say mined by an old miner)?  I assume it is just like a main chain block, but with no transactions?

Miners would refuse to build on new blocks if there is no aux-block?  Would you foresee a new message type? 

In fact, what happens if you send extra data in a "block" message?  I assume it is basically ignored?

The extended block, could be of the form


...
...
varInt: n = number of transactions in main block
tx[n]: transactions
varInt: m = number of extra transactions
aux-tx[m]

I think the current client basically ignores extra fields.

This would allow blocks of 32MB.  You need a way to split blocks over multiple messages to go above that,

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Peter Todd
Legendary
*
expert
Offline Offline

Activity: 1106


View Profile
August 29, 2013, 04:38:41 PM
 #3

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:40:23 PM
 #4

If there is no aux transaction, there will be no aux-block, even from a upgraded miner. So basically aux-blocks do not form a chain. They are the extension of the main blocks, indicated by the Aux-Merkle-Root in the main-coinbase.

For backward compatibility, aux-block will not be sent to old nodes. A new command like getauxblock will be used among new nodes.


This means that there is always a one to one mapping of aux-block to main block?

What happens if there is a block with no aux-block (say mined by an old miner)?  I assume it is just like a main chain block, but with no transactions?

Miners would refuse to build on new blocks if there is no aux-block?  Would you foresee a new message type? 

In fact, what happens if you send extra data in a "block" message?  I assume it is basically ignored?

The extended block, could be of the form


...
...
varInt: n = number of transactions in main block
tx[n]: transactions
varInt: m = number of extra transactions
aux-tx[m]

I think the current client basically ignores extra fields.

This would allow blocks of 32MB.  You need a way to split blocks over multiple messages to go above that,

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 04:54:47 PM
 #5

What's really interesting about this approach is how users and miners are both required to buy into a larger blocksize, which means that adopting a larger blocksize requires the economic majority to convincingly show that they do in fact wish it to happen. Note how SPV users are required to accept the change as well if they want to accept aux-block coins as payment.

And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code)

Just a minor note: just like v2 block, the aux-coinbase must include the height of the corresponding main block to avoid crash of tx hash.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 29, 2013, 05:08:33 PM
 #6

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.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
d'aniel
Sr. Member
****
Offline Offline

Activity: 461


View Profile
August 29, 2013, 06:30:21 PM
 #7

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.
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?
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 06:39:19 PM
 #8

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?

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

And since this is a soft-fork, it avoids a lot of political considerations. Anyone with 51% hashing power could implement this (if they can code)

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
nomailing
Full Member
***
Offline Offline

Activity: 126


View Profile
August 29, 2013, 07:17:49 PM
 #9

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?
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 thought just the contrary: With more than 50% you could steal all coins in the aux-blocks of upgraded users, because
2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

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.

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
nomailing
Full Member
***
Offline Offline

Activity: 126


View Profile
August 29, 2013, 07:22:00 PM
 #10

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?

BM-2D9KqQQ9Fg864YKia8Yz2VTtcUPYFnHVBR
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
August 29, 2013, 07:39:04 PM
 #11

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.

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 29, 2013, 08:03:28 PM
 #12

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 01:15:57 AM
 #13

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.

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.


Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 01:56:35 AM
 #14

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.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 07:04:22 AM
 #15

So old nodes wouldn't complain if a miner would transfer all coins from the aux-blocks to his own address.

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.

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

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2268



View Profile
August 30, 2013, 07:07:15 AM
 #16

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

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1120


View Profile
August 30, 2013, 08:16:43 AM
 #17

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

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.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
johnyj
Legendary
*
Offline Offline

Activity: 1820


Beyond Imagination


View Profile
August 30, 2013, 11:05:36 AM
 #18

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

MatthewLM
Legendary
*
Offline Offline

Activity: 1092



View Profile WWW
August 30, 2013, 11:12:47 AM
 #19

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.

Bitcoin Extra Wallet | Peercoin Android Wallet
BTC: 1D5A1q5d192j5gYuWiP3CSE5fcaaZxe6E9  PPC: PH7fVn1Xs7nkUFmdwCX2ZRYfLPCSwGxAq9
jl2012
Legendary
*
Offline Offline

Activity: 1652


View Profile
August 30, 2013, 04:49:07 PM
 #20

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.

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.

Donation address: 1GdBAuFihJVxypysnkF7jKwcKAoAn8dbvg
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
Pages: [1] 2 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!