📅 Original date posted:2014-08-06 📝 Original message:On 08/06/2014 11:42 AM, ...

Mark Friedenbach [ARCHIVE] /

npub1r3s…8d0u

2023-06-07 15:24:46

in reply to nevent1q…w87a

📅 Original date posted:2014-08-06
📝 Original message:On 08/06/2014 11:42 AM, Peter Todd wrote:
> On 6 August 2014 08:17:02 GMT-07:00, Christian Decker
> <decker.christian at gmail.com> wrote:
>> +1 for the new field, overloading fields with new meaning is
>> definitely not a good idea.
>
> To add a new field the best way to do it is create a new, parallel,
> tx format where fields are committed by merkle radix tree in an
> extensible and provable way. You'd then commit to that tree with a
> mandatory OP_RETURN output in the last txout, or with a new merkle
> root.
>
> Changing the tx format itself in a hard-fork is needlessly
> disruptive, and in this case, wastes opportunities for improvement.

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 format,
as we do in Freimarkets.

If the field is pre-consensus (a mempool gentleman's agreement), then it
has no business in the transaction structure at all and should be
packaged in some sort of envelope container.

Author Public Key

npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u

Seen on

wss://relay.noswhere.com wss://relay.nostr.band

Show more details

Published at

2023-06-07 15:24:46

Kind type

1 Short Text Note

Event JSON

{ "id": "3252c4a9220c06d2f6110c8f141dcae566eabe92d66ee015b2d0fd922c46815a", "pubkey": "1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069", "created_at": 1686151486, "kind": 1, "tags": [ [ "e", "862ea3dc96b72bff70fc377e79d0d6efd56d14bf0babb9aa995ab55fc1b92d18", "", "root" ], [ "e", "a318c0b7beb88f263053f0627be367ac7b66725d17859ce90f5c167921992f4c", "", "reply" ], [ "p", "b25e10e25d470d9b215521b50da0dfe7a209bec7fedeb53860c3e180ffdc8c11" ] ], "content": "📅 Original date posted:2014-08-06\n📝 Original message:On 08/06/2014 11:42 AM, Peter Todd wrote:\n\u003e On 6 August 2014 08:17:02 GMT-07:00, Christian Decker\n\u003e \u003cdecker.christian at gmail.com\u003e wrote:\n\u003e\u003e +1 for the new field, overloading fields with new meaning is\n\u003e\u003e definitely not a good idea.\n\u003e \n\u003e To add a new field the best way to do it is create a new, parallel,\n\u003e tx format where fields are committed by merkle radix tree in an\n\u003e extensible and provable way. You'd then commit to that tree with a\n\u003e mandatory OP_RETURN output in the last txout, or with a new merkle\n\u003e root.\n\u003e \n\u003e Changing the tx format itself in a hard-fork is needlessly\n\u003e disruptive, and in this case, wastes opportunities for improvement.\n\nI highly doubt that is the best approach.\n\nIf this nExpiry field is a consensus rule, then the Merkle tree or the\nappropriate paths through needs to be included with the transaction as\npart of the network and on-disk data structures, so that proper\nvalidation can be done. This would be both more disruptive and less\nefficient than simply adding an nExpiry field to the transaction format,\nas we do in Freimarkets.\n\nIf the field is pre-consensus (a mempool gentleman's agreement), then it\nhas no business in the transaction structure at all and should be\npackaged in some sort of envelope container.", "sig": "4c743122a6b9c9f7ac1383b18dd5cb1c50f099062f03626738e235da00bbabb9daf0cb899a048574dd5392f88f5a6c283913dce5fea7f773f2c01fff3560216c" }