Auxiliary block: Increasing max block size with softfork - page 3.

jl2012

legendary

Activity: 1792

Merit: 1111

Quote from: Peter Todd on August 29, 2013, 11:38:41 AM

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.

jl2012

legendary

Activity: 1792

Merit: 1111

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.

Quote from: TierNolan on August 29, 2013, 11:23:37 AM

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,

Peter Todd

legendary

Activity: 1120

Merit: 1152

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.

TierNolan

legendary

Activity: 1232

Merit: 1094

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,

jl2012

legendary

Activity: 1792

Merit: 1111

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: OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to . 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 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: 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 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 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)

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