Block size hard-fork an opportunity to make other changes

[TierNolan]

The probable upcoming change to allow increased block sizes is the first planned hard fork in a while (and maybe for a while).  It seems a shame to let this opportunity go to waste.

It would be the perfect time to make other changes to the rules.  The key would be to focus on low effort/risk changes that have high payoff.

What is the timeline for the block size change?  If it was being targeted for the middle of next year, then contributors for hard fork changes could be given a timeline.

Example Timeline

End February: BIP describing change must be completed
End April: Code (including tests) must be completed
End June: Block size hard fork client is released

The hard fork wishlist has some.

Block size/SIG OP

In addition to the block size, the number of signature ops per block would have to increase.

Mandatory P2SH

The transaction format could be modified so that input scripts are included for spending legacy transactions.

This would mean that all elements in the UTXO set could be stored as a simple hash.

Clients would have to manually store the scriptPubKeys for any transactions in their wallet.  Though for standard transactions, they could be regenerated anyway.

This might be doable with a soft fork though by creating a new tx message and having nodes "upgrade" transactions received from legacy nodes.

Add Input value to transctions

This is to help with offline wallets.   It means that a transaction would have an extra 4 bytes per input to say how much that input was worth.  This means that you can tell how much a transactions is spending without having to have the input transaction.

See: https://bitcointalk.org/index.php?topic=181734.0

With a hard fork, it could be implemented with a transactions format change.

Sum Merkle Tree

This is where the sum of all transaction fees in transactions below that node are included.

(Sum_parent | Hash_parent) = {(Sum_left + Sum_right) | Hash(S_left | Hash_left | S_right | Hash_righ)}

This means that random spot checks can be performed to check that inflation has occurred and compact fraud proofs produced.

Changing the header size is likely unacceptable, so the merkle hash could be reduced to 28 bytes instead of 32.

Hash(x) = lower 28 bytes of (SHA256(SHA256(x)))

The sum could be 4 bytes.

If RIPEMD160 is acceptable, then 20 bytes could be used.  That would mean that the sum could be 8 bytes, to allow for future proofing.

Auxiliary Header

This isn't on the wiki.  This would be a change to the merkle tree format.  The merkle root entry in the header would be replaced with Hash(Merkle TX Root | Auxiliary Header).

The auxiliary header could be any length and maybe have a key/value system.  This would make merged mining easier and help with things like p2pool, where they want to embed extra data in blocks.

It would allow fields to be added without modifying the main header.  These headers could be obtained with new messages or extending the get header message.

UTXO Commitments

This is where the UTXO set is committed in each block.  

If the Auxilary header change was added, then this wouldn't require a further hard fork.  

[Edit]
Timewarp Fix

This is where the difficulty re-target is based on the time difference between every 2016th block and the block 2015 before it.  Ideally, the "end" block on the previous section should be used as the first block for the subsequent section.  

I think this could be fixed using a soft fork by requiring that the two blocks have a timestamp within (say) 1 hour of each other.

Increased Nonce

This would be where the nonce is made larger.  The auxiliary header would allow something similar, since you could change the merkle root without recalculating the entire way down to the coinbase.

[Edit2]

Extend Merkle Tree to TX Inputs and Outputs

The merkle tree currently ends at the transaction level.  This means that to prove that a particular output is valid, you need to provide the entire transaction.  If the merkle tree continued down to the inputs and outputs of the transaction, then only a merkle path would be required to prove that an output is valid.

[CIYAM]

I would really love to see an optional op code for specifying the *change amount* (the tx would be invalid if it doesn't match what the change amount actually is).

This would allow offline tx signing to be able to show the user the change amount without needing any blockchain info (a huge benefit if you want to do offline signing with a QR code like CIYAM Safe does).

[TierNolan]

I would really love to see an optional op code for specifying the *change amount* (the tx would be invalid if it doesn't match what the change amount actually is).

This would allow offline tx signing to be able to show the user the change amount without needing any blockchain info (a huge benefit if you want to do offline signing with a QR code like CIYAM Safe does).

That is what the "Add Input value to transctions" change would do.  It allows users to sign on the basis that the input they are signing has a particular value.

[CIYAM]

That is what the "Add Input value to transctions" change would do.  It allows users to sign on the basis that the input they are signing has a particular value.

Great! I should have read that a bit closer sorry.

I really hope we can get that one in as it greatly simplifies offline tx signing (am willing to offer a bounty if that will help). I'm not sure why others don't like QR codes but I think they are the most secure method of doing offline tx signing.

BTW - have you noticed this? http://ciyam.org/at/at_atomic.html

It was inspired by your atomic cross-chain transfer in Bitcoin Script (I will add a link to your webpage for credit when we've got it completed).

[justusranvier]

Mandatory P2SH

The transaction format could be modified so that input scripts are included for spending legacy transactions.

This would mean that all elements in the UTXO set could be stored as a simple hash.

Clients would have to manually store the scriptPubKeys for any transactions in their wallet.  Though for standard transactions, they could be regenerated anyway.

This might be doable with a soft fork though by creating a new tx message and having nodes "upgrade" transactions received from legacy nodes.

P2SH should not be made mandatory, although it might make sense to make P2SH the default script type in regular clients instead of P2PKH.

Script types that include public keys are useful for applications that want to use Diffie-Hellman derivations (stealth addresses).

[TierNolan]

P2SH should not be made mandatory, although it might make sense to make P2SH the default script type in regular clients instead of P2PKH.

Script types that include public keys are useful for applications that want to use Diffie-Hellman derivations (stealth addresses).

P2SH should be able to do anything that normal scripting does (with the exception of limits on the scriptPubKey length).

[justusranvier]

P2SH should be able to do anything that normal scripting does (with the exception of limits on the scriptPubKey length).

Except expose pubkeys in outputs prior to those outputs being spent.

[jl2012]

P2SH should not be made mandatory, although it might make sense to make P2SH the default script type in regular clients instead of P2PKH.

Script types that include public keys are useful for applications that want to use Diffie-Hellman derivations (stealth addresses).

P2SH should be able to do anything that normal scripting does (with the exception of limits on the scriptPubKey length).

Putting a permanent limit on the format of scriptPubKey will likely lead to another hardfork in the future. For example, when we want to replace HASH160 with something stronger

[mmeijeri]

An advantage of making P2SH mandatory is that censoring P2SH becomes more difficult because it means censoring Bitcoin completely.

[justusranvier]

An advantage of making P2SH mandatory is that censoring P2SH becomes more difficult because it means censoring Bitcoin completely.

All it does is move the censoring from the creation of outputs to the spending of outputs.

[gmaxwell]

Script types that include public keys are useful for applications that want to use Diffie-Hellman derivations (stealth addresses).

That isn't how stealth addresses work. (http://sourceforge.net/p/bitcoin/mailman/message/31813471/) The DH nonce is not a txout pubkey.

I don't know about the wisdom of packing changes together, it just increases the ability of someone to take issue with something exponentially (as we've seen here!).

(Incidentally, the making of P2SH mandatory is that it would make utxo handling completely uniform and constant size; and remove a lot of corner case handling in implementations; not that I think that there is much chance of that happening)

Funny that this list is more or less disjoint with the list I'd already made for obvious changes. What,  e.g. no timewarp attack fix?

It means that a transaction would have an extra 4 bytes

The value can be under the signature without a single byte being added into the transaction itself.

In any case, some of these things are huge changes with scaling impacts (e.g. UTXO commitments) and have non-obvious competing alternatives (STXO commitments), so I think we're not near at all being able to say what should be done there.

[justusranvier]

Script types that include public keys are useful for applications that want to use Diffie-Hellman derivations (stealth addresses).

That isn't how stealth addresses work. (http://sourceforge.net/p/bitcoin/mailman/message/31813471/) The DH nonce is not a txout pubkey.

That's not how your stealth addresses work.