📅 Original date posted:2016-09-23
📝 Original message:On Friday, 23 September 2016 13:42:36 CEST Christian Decker via bitcoin-dev wrote:
> > I have to disagree. That is not malleability. Creating a new document
> > and re- signing it is not changing anything. Its re-creating.
> > Something that the owner of the coin has every right to do.
> Same thing I was arguing back then, however Luke pointed out that
> malleability just refers to the possibility of modifying a transaction
> after the fact.
I am not a fan of redefining dictionary words. I'll stick to the
universally excepted one, thanks.
> Nope, that is exactly the kind of dependency I was talking
> about. Instead of nesting a construct like the current transactions
> do, you rely on the order of tokens to imply that they belong
> together.
> if we
> add new fields that a non-upgraded node doesn't know about and it
> rejects transactions containing it, we'll have a hard-fork. It should
> probably not reject transactions with unknown fields if the
> transaction is included in a block.
This is addressed here;
https://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki#future-extensibility
Tom [ARCHIVE] /
npub1h3…8z4k5
2023-06-07 17:53:29
in reply to nevent1q…quq7
Author Public Key
npub1h394c0pkdum0jw4rufslt3ur9m9c2ym4x7a0t68spfpjr6zlq3msu8z4k5Published at
2023-06-07 17:53:29Event JSON
{
"id": "613cd81e184d10b6e5fcafe1e5397decee2a7d1d4561da7a2668748a43b4eefa",
"pubkey": "bc4b5c3c366f36f93aa3e261f5c7832ecb85137537baf5e8f00a4321e85f0477",
"created_at": 1686160409,
"kind": 1,
"tags": [
[
"e",
"1a569d98e0e6ce5c9d61181fddad681419ffdb691b73a42ccb4919035df06596",
"",
"root"
],
[
"e",
"b7e5dcc4b027d246b995ca9d59d077549b6c69324bb0f315264bc8e6f353000d",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2016-09-23\n📝 Original message:On Friday, 23 September 2016 13:42:36 CEST Christian Decker via bitcoin-dev wrote:\n\u003e \u003e I have to disagree. That is not malleability. Creating a new document\n\u003e \u003e and re- signing it is not changing anything. Its re-creating.\n\u003e \u003e Something that the owner of the coin has every right to do.\n\u003e Same thing I was arguing back then, however Luke pointed out that\n\u003e malleability just refers to the possibility of modifying a transaction\n\u003e after the fact.\n\nI am not a fan of redefining dictionary words. I'll stick to the \nuniversally excepted one, thanks.\n\n\u003e Nope, that is exactly the kind of dependency I was talking\n\u003e about. Instead of nesting a construct like the current transactions\n\u003e do, you rely on the order of tokens to imply that they belong\n\u003e together.\n\n\n\u003e if we\n\u003e add new fields that a non-upgraded node doesn't know about and it\n\u003e rejects transactions containing it, we'll have a hard-fork. It should\n\u003e probably not reject transactions with unknown fields if the\n\u003e transaction is included in a block.\n\nThis is addressed here;\nhttps://github.com/bitcoin/bips/blob/master/bip-0134.mediawiki#future-extensibility",
"sig": "749d45141de77477249cd067eefb94b06db02112fd81221014746dff7900a003f066751274be7eebcaf432c0a46b3ca08c8953077b6904ecb567ab841475c74d"
}