đź“… Original date posted:2014-02-19
đź“ť Original message:Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:
1. the next bitcoin version "prettify" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash.
2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.
To non-standard conforming clients this "prettify" change of hash would be seen as a constant malleability attack, but given the "prettify" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.
There is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:
* Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.
On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos at gmail.com> wrote:
>> I apologize if this has been discussed many times before.
>
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>
>> As a long term solution to malleable transactions, wouldn't it be possible
>> to modify the signatures to be of the entire transaction. Why do you have
>> to zero out the inputs? I can see that this would be a hard fork, and maybe
>> it would be somewhat tricky to extract signatures first (since you can sign
>> everything except the signatures), but it would seem to me that this is an
>> important enough change to consider making.
>
> Because doing so would be both unnecessary and ineffective.
>
> Unnecessary because we can very likely eliminate malleability without
> changing what is signed. It will take time, but we have been
> incrementally moving towards that, e.g. v0.8 made many kinds of
> non-canonical encoding non-standard.
>
> Ineffective— at least as you describe it— because the signatures
> _themselves_ are malleable.
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/95dc03a4/attachment.sig>;
Michael Gronager [ARCHIVE] /
npub1nc…gw452
2023-06-07 15:13:24
in reply to nevent1q…veh2
Author Public Key
npub1nc78dlt7hp3v5dl32qu3m678h2j0ss374glcjnz8df75xcx7ngpq4gw452Published at
2023-06-07 15:13:24Event JSON
{
"id": "029f01533963d31b066060d1801e592f51e7b22f7241c7f4eebcfc5bbf3393cc",
"pubkey": "9e3c76fd7eb862ca37f150391debc7baa4f8423eaa3f894c476a7d4360de9a02",
"created_at": 1686150804,
"kind": 1,
"tags": [
[
"e",
"76969a008b621e54c247029127aebdfbea1794fb79dd58e07b32a76157512d29",
"",
"root"
],
[
"e",
"2a600dc9bbc62e3359e09abcad7cf4310e7ee106039116f7f6f5e03f04e77f4a",
"",
"reply"
],
[
"p",
"4aa6cf9aa5c8e98f401dac603c6a10207509b6a07317676e9d6615f3d7103d73"
]
],
"content": "📅 Original date posted:2014-02-19\n📝 Original message:Why introduce a new transaction version for this purpose ? Wouldn't it be more elegant to simply let:\n\n1. the next bitcoin version \"prettify\" all relayed transactions as deterministic transactions fulfilling the scheme 1-6 effectively blocking any malleability attack? If miners would upgrade then all transactions in blocks would have a deterministic hash. \n\n2. In a version later one could block relay of non deterministic transactions, as well as the acceptance of blocks with non-confirming transactions.\n\nTo non-standard conforming clients this \"prettify\" change of hash would be seen as a constant malleability attack, but given the \"prettify\" code it is to fix any client into producing only conforming transactions, just by running the transaction through it before broadcast.\n\nThere is a possible fork risk in step 2. above - if a majority of miners still havn't upgraded to 1 when 2 is introduced. We could monitor % non conforming transaction in a block and only introduce 2. once that number is sufficiently small for a certain duration - criteria:\n* Switch on forcing of unmalleable transactions in blocks when there has been only conforming transactions for 1000 blocks.\n\n\nOn Feb 13, 2014, at 1:47 AM, Gregory Maxwell \u003cgmaxwell at gmail.com\u003e wrote:\n\n\u003e On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos \u003cmorcos at gmail.com\u003e wrote:\n\u003e\u003e I apologize if this has been discussed many times before.\n\u003e \n\u003e It has been, but there are probably many people like you who have not\n\u003e bothered researching who may also be curious.\n\u003e \n\u003e\u003e As a long term solution to malleable transactions, wouldn't it be possible\n\u003e\u003e to modify the signatures to be of the entire transaction. Why do you have\n\u003e\u003e to zero out the inputs? I can see that this would be a hard fork, and maybe\n\u003e\u003e it would be somewhat tricky to extract signatures first (since you can sign\n\u003e\u003e everything except the signatures), but it would seem to me that this is an\n\u003e\u003e important enough change to consider making.\n\u003e \n\u003e Because doing so would be both unnecessary and ineffective.\n\u003e \n\u003e Unnecessary because we can very likely eliminate malleability without\n\u003e changing what is signed. It will take time, but we have been\n\u003e incrementally moving towards that, e.g. v0.8 made many kinds of\n\u003e non-canonical encoding non-standard.\n\u003e \n\u003e Ineffective— at least as you describe it— because the signatures\n\u003e _themselves_ are malleable.\n\u003e \n\u003e ------------------------------------------------------------------------------\n\u003e Android apps run on BlackBerry 10\n\u003e Introducing the new BlackBerry 10.2.1 Runtime for Android apps.\n\u003e Now with support for Jelly Bean, Bluetooth, Mapview and more.\n\u003e Get your Android app in front of a whole new audience. Start now.\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=124407151\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 496 bytes\nDesc: Message signed with OpenPGP using GPGMail\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140219/95dc03a4/attachment.sig\u003e",
"sig": "423bfa7ef8923f80ba274bac7c82dbe65a79ecff1a8820cd98879c55d74e3b0dd0a8f9f3a63deeb78aa34bb121aa4f7ec24f5f8144174ee664c9a114a0148941"
}