Michael Gronager [ARCHIVE] on Nostr: đź“… Original date posted:2014-02-19 đź“ť Original message:Why introduce a new ...
đź“… 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>;
đź“ť 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>;