From: Michael Gronager <gronager@mac•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability
Date: Wed, 19 Feb 2014 21:28:24 +0100 [thread overview]
Message-ID: <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com> (raw)
In-Reply-To: <CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the fly, but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support it.
Rational use cases of #3 will be pretty hard to find given the fact that they can be changed on the fly. We are down to inclusion in blocks by miners for special purposes - or did I miss out something?
I think that we could guarantee fewer incidents by making version 1 transactions unmalleable and then optionally introduce a version 3 that supported the malleability feature. That way most existing problematic implementations would be fixed and no doors were closed for people experimenting with other stuff - tx v 3 would probably then be called experimental transactions.
/M
On Feb 19, 2014, at 3:38 PM, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager <gronager@mac•com> wrote:
>> 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.
>
> I consider actively mutating other's transactions worse than not
> relaying them. If we want people to make their software deal with
> malleability, either will work.
>
> Regarding deterministic hash: that's impossible. Some signature hash
> types are inherently (and intentionally) malleable. I don't think we
> should pretend to want to change that. The purpose is making
> non-malleability a choice the sender of a transaction can make.
>
> Most of the rules actually are enforced by IsStandard already now.
> Only #1 and #7 aren't. #1 affects the majority of all transactions, so
> changing it right now would be painful. #7 only affects multisig.
>
>> 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.
>
> The problem in making these rules into consensus rule (affecting
> tx/block validity) is that some rules (in particular #3) may not be
> wanted by everyone, as they effectively limit the possibilities of the
> script language further. As it is ultimately only about protecting
> senders who care about non-malleability, introducing a new transaction
> version is a very neat way of accomplishing that. The new block
> version number is only there to coordinate the rollout, and choosing
> an automatic forking point.
>
> --
> Pieter
[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 496 bytes --]
next prev parent reply other threads:[~2014-02-19 20:28 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-09 23:33 Pieter Wuille
2014-02-10 3:00 ` Peter Todd
2014-02-12 15:12 ` Rune Kjær Svendsen
2014-02-12 16:22 ` Alan Reiner
2014-02-12 16:38 ` Allen Piscitello
2014-02-12 16:44 ` Alan Reiner
2014-02-12 20:27 ` Mark Friedenbach
2014-02-12 22:52 ` Luke-Jr
2014-02-13 0:39 ` Alex Morcos
2014-02-13 0:47 ` Gregory Maxwell
2014-02-19 14:11 ` Michael Gronager
2014-02-19 14:38 ` Pieter Wuille
2014-02-19 20:28 ` Michael Gronager [this message]
2014-02-19 20:39 ` Gregory Maxwell
2014-02-19 20:49 ` Peter Todd
2014-02-19 21:05 ` Gregory Maxwell
2014-02-19 21:11 ` Pieter Wuille
2014-02-20 0:22 ` Natanael
2014-02-20 1:29 ` Allen Piscitello
2014-02-20 7:50 ` Natanael
2014-02-20 10:59 ` Michael Gronager
2014-02-20 14:08 ` Mike Hearn
2014-02-20 14:15 ` Gregory Maxwell
2014-02-20 14:29 ` Gavin Andresen
2014-02-20 14:36 ` Gregory Maxwell
2014-02-20 14:58 ` Gavin Andresen
2014-02-20 15:11 ` Pieter Wuille
2014-02-20 15:24 ` Gregory Maxwell
2014-02-21 6:07 ` Mike Hearn
2014-02-21 6:30 ` Gregory Maxwell
2014-02-19 19:15 ` Jeremy Spilman
2014-02-12 17:13 ` Jeff Garzik
2014-02-12 17:21 ` Pieter Wuille
2014-02-12 18:03 ` Gregory Maxwell
[not found] ` <CALf2ePyQeOxL3d+QoaWSYy_cCKaF9qq1StBwXFms9NyedUg3eg@mail.gmail.com>
2014-02-12 18:21 ` Alan Reiner
2014-02-10 4:39 ` Luke-Jr
2014-02-12 16:56 ` Pavol Rusnak
2014-02-12 17:22 ` Pieter Wuille
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com \
--to=gronager@mac$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pieter.wuille@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox