From: Peter Todd <pete@petertodd•org>
To: Michael Gronager <gronager@mac•com>,
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 15:49:32 -0500 [thread overview]
Message-ID: <ec7ad616-1596-420f-8101-6f1d86429638@email.android.com> (raw)
In-Reply-To: <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
While we might be able to get away with a retroactive change in meaning right now in the future that won't be so easy. There are lots if proposed applications for nLockTime-using protocols that depend on transactions (or parts of transactions) being possible to mine as is. Making existing transactions impossible to mine in the future will break those types of applications. We might as well use this as a learning experience for what a version bump would look like infrastructures wise.
Note how the above is a particularly bad example of gmaxwell's generic "don't break things" objection. Equally, remember that lots of infrastructure *does* handle malleability just fine already.
On February 19, 2014 3:28:24 PM EST, Michael Gronager <gronager@mac•com> wrote:
>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
>
>
>
>------------------------------------------------------------------------
>
>------------------------------------------------------------------------------
>Managing the Performance of Cloud-Based Applications
>Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
>Read the Whitepaper.
>http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development@lists•sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9
iQFQBAEBCAA6BQJTBRjcMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhbuuCADHHZvCbWNR+hj3lq2u
Xjr8POSsMWk4XorvLftgXSzAzypr7n0BP7+fmz/v0J98XfeOHxf8NHB2VXzFMCzI
mstYyFC+gdsPf9eIMoN2S9EB9d4Lh1Y7Zv5BGqopuHCUIVMpzk2QDaFlLe+gW8Ai
p4Yv/jGib8ym1ahJ24nZ89l7Psa+uXDw8N2VX5PcyDNVRwzuXwa0h2Kix/gt8uJb
RV5Sj3duxUE6mOGN07j6lPu9VcrtD0ydvAO3DoEJqkBqjhbC33h05H96KPQKuGcg
5DOKXUV5ChW5CF3DH5HN/LdduLgbTevtLbkBhdLKo+z5GKaU7Qpc5i6dIeAKl3uA
KCQE
=DiAE
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2014-02-19 20:50 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
2014-02-19 20:39 ` Gregory Maxwell
2014-02-19 20:49 ` Peter Todd [this message]
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=ec7ad616-1596-420f-8101-6f1d86429638@email.android.com \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gronager@mac$(echo .)com \
--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