jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Auxiliary block: Increasing max block size with softfork August 29, 2013, 04:10:56 PM

Last edit: August 29, 2013, 04:22:20 PM by jl2012 #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: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: Auxiliary block: Increasing max block size with softfork 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

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Auxiliary block: Increasing max block size with softfork August 29, 2013, 04:40:23 PM #4



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, 04:23:37 PM 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,

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. Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Auxiliary block: Increasing max block size with softfork August 29, 2013, 04:54:47 PM #5 Quote from: retep on August 29, 2013, 04:38:41 PM 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. 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: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: Auxiliary block: Increasing max block size with softfork August 29, 2013, 06:39:19 PM #8 Quote from: d'aniel on August 29, 2013, 06:30:21 PM 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).



Quote from: jl2012 on August 29, 2013, 04:54:47 PM 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. 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. 1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF

nomailing



Offline



Activity: 126

Merit: 100







Full MemberActivity: 126Merit: 100 Re: Auxiliary block: Increasing max block size with softfork 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

Legendary





Offline



Activity: 3178

Merit: 4298









ModeratorLegendaryActivity: 3178Merit: 4298 Re: Auxiliary block: Increasing max block size with softfork August 29, 2013, 07:39:04 PM

Last edit: August 29, 2013, 08:06:08 PM by gmaxwell #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.

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: Auxiliary block: Increasing max block size with softfork August 29, 2013, 08:03:28 PM #12 Quote from: nomailing on August 29, 2013, 07:17:49 PM 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 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



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Auxiliary block: Increasing max block size with softfork August 30, 2013, 01:15:57 AM

Last edit: August 30, 2013, 01:59:05 AM by jl2012 #13 Quote from: gmaxwell on August 29, 2013, 07:39:04 PM 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.



With this approach, we could change pretty much everything in the protocol with soft-fork. Just some examples: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: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Auxiliary block: Increasing max block size with softfork 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: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

jl2012



Offline



Activity: 1792

Merit: 1010







LegendaryActivity: 1792Merit: 1010 Re: Auxiliary block: Increasing max block size with softfork August 30, 2013, 07:04:22 AM #15 Quote from: TierNolan on August 29, 2013, 08:03:28 PM Quote from: nomailing on August 29, 2013, 07:17:49 PM 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 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) If a soft fork is implemented correctly, there will be no fork at all. (see the v1 to v2 block transition) Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)

LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)

PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517

TierNolan



Offline



Activity: 1232

Merit: 1006







LegendaryActivity: 1232Merit: 1006 Re: Auxiliary block: Increasing max block size with softfork August 30, 2013, 08:16:43 AM #17 Quote from: jl2012 on August 30, 2013, 07:04:22 AM 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. 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 coinbaseThis proves that miners support the (soft) forkOnce 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