📅 Original date posted:2016-09-22
📝 Original message:On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote:
> > «The way towards that flexibility is to use a generic concept made
> > popular various decades ago with the XML format. The idea is that we
> > give each field a name and this means that new fields can be added or
> > optional fields can be omitted from individual transactions»
>
> That argument is not applicable to required fields:
The argument that optional fields can be omitted is not applicable to
required fields, you are correct. That should be rather obvious because
required fields are not optional fields.
> the code to get the
> fields from the extensible format is every bit as complex as the very
> simple code required to deserialize/serialize objects in the current
> system.
Probably a tiny bit more complex as the current format assumes a lot more.
You may have misread my email because there was no argument made towards
complexity. The argument was towards flexibility.
> In any case your BIP needs to give some explicit examples of hypothetical
> upgrades in the future, how they'd take advantage of this, and what the
> code to do so would look like.
Why?
> > > Also, if you're going to break compatibility with all existing
> > > software, it makes sense to use a format that extends the merkle
> > > tree down into the transaction inputs and outputs.
> >
> > Please argue your case.
>
> See my arguments re: segwit a few months ago, e.g. the hardware wallet
> txin proof use-case.
Please consider that I'm not going to search for something based on a vague
reference like that, if you want to convince me you could you at least
provide a URL?
You want me to see the value of your idea, I think you should at least
provide the argument. Isn't that fair?
Thanks for your email Peter, would love you to put a bit more time into
understanding flexible transactions and we can have a proper discussion
about it.
Tom [ARCHIVE] /
npub1h3…8z4k5
2023-06-07 17:53:26
in reply to nevent1q…st0v
Author Public Key
npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5Published at
2023-06-07 17:53:26Event JSON
{
"id": "3ee4878115b6711ebb6e81ec3eaecaf1884a2b57107619a752d4c9eb4c9264b7",
"pubkey": "bc4b5c3c366f36f93aa3e261f5c7832ecb85137537baf5e8f00a4321e85f0477",
"created_at": 1686160406,
"kind": 1,
"tags": [
[
"e",
"1a569d98e0e6ce5c9d61181fddad681419ffdb691b73a42ccb4919035df06596",
"",
"root"
],
[
"e",
"da38b66990c19dc015d4f55bfbc6d346ebae83425542b0a9ea8264f6d0aed2d5",
"",
"reply"
],
[
"p",
"daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa"
]
],
"content": "📅 Original date posted:2016-09-22\n📝 Original message:On Thursday, 22 September 2016 14:26:18 CEST Peter Todd wrote:\n\u003e \u003e «The way towards that flexibility is to use a generic concept made\n\u003e \u003e popular various decades ago with the XML format. The idea is that we\n\u003e \u003e give each field a name and this means that new fields can be added or\n\u003e \u003e optional fields can be omitted from individual transactions»\n\u003e \n\u003e That argument is not applicable to required fields: \n\nThe argument that optional fields can be omitted is not applicable to \nrequired fields, you are correct. That should be rather obvious because \nrequired fields are not optional fields.\n\n\u003e the code to get the\n\u003e fields from the extensible format is every bit as complex as the very\n\u003e simple code required to deserialize/serialize objects in the current\n\u003e system.\n\nProbably a tiny bit more complex as the current format assumes a lot more.\n\nYou may have misread my email because there was no argument made towards \ncomplexity. The argument was towards flexibility.\n\n\u003e In any case your BIP needs to give some explicit examples of hypothetical\n\u003e upgrades in the future, how they'd take advantage of this, and what the\n\u003e code to do so would look like.\n\nWhy?\n\n\u003e \u003e \u003e Also, if you're going to break compatibility with all existing\n\u003e \u003e \u003e software, it makes sense to use a format that extends the merkle\n\u003e \u003e \u003e tree down into the transaction inputs and outputs.\n\u003e \u003e \n\u003e \u003e Please argue your case.\n\u003e \n\u003e See my arguments re: segwit a few months ago, e.g. the hardware wallet\n\u003e txin proof use-case.\n\nPlease consider that I'm not going to search for something based on a vague \nreference like that, if you want to convince me you could you at least \nprovide a URL?\nYou want me to see the value of your idea, I think you should at least \nprovide the argument. Isn't that fair?\n\nThanks for your email Peter, would love you to put a bit more time into \nunderstanding flexible transactions and we can have a proper discussion \nabout it.",
"sig": "29f97c5d860362ea9734d53c4c6216569afc76ec728b6cda515a6ab1a8b804becfbec42b89ba2a26d1f01fa8cb0c8b90c92c6d20d4522b3acbb437fb1059a71f"
}