public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability 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.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pieter.wuille@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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