[Bitcoin-development] deterministic transaction expiration
pete at petertodd.org
Wed Aug 6 17:20:25 UTC 2014
-----BEGIN PGP SIGNED MESSAGE-----
On 6 August 2014 09:31:24 GMT-07:00, Mark Friedenbach <mark at monetize.io> wrote:
>I highly doubt that is the best approach.
>If this nExpiry field is a consensus rule, then the Merkle tree or the
>appropriate paths through needs to be included with the transaction as
>part of the network and on-disk data structures, so that proper
>validation can be done. This would be both more disruptive and less
>efficient than simply adding an nExpiry field to the transaction
>as we do in Freimarkets.
The general case doesn't require transmission of any merkle data; it is derived from the tx data. Equally changing a data format is certainly: note how Freimarkets has no third-party library support because you've made it incompatible with the standard Bitcoin data structures. Merkle radix tree formatting OTOH is just a cryptographically committed extension of the tag-value concept seen in protobuf, among others.
re: efficiency, we need fundamental improvements in efficiency, not little micro-optimisations everywhere done at high cost to maintainability.
re: validation, note how the merkle radix tree meets that need by allowing the absence of data to be proven.
>If the field is pre-consensus (a mempool gentleman's agreement), then
>has no business in the transaction structure at all and should be
>packaged in some sort of envelope container.
It's also rather useless without consensus. Expiry is only useful if it is a guarantee, if not you might as well just implement tx replacement directly.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1
-----END PGP SIGNATURE-----
More information about the bitcoin-dev