From: Peter Todd <pete@petertodd•org>
To: Stephen Morse <stephencalebmorse@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Date: Mon, 27 Apr 2015 15:21:12 -0400 [thread overview]
Message-ID: <20150427191855.GE5223@muck> (raw)
In-Reply-To: <CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote:
> Hi William,
>
> I personally prefer this solution, since it nails the problem
> > completely with one simple and obvious change. The BIP 62 approach is
> > more like a game of wac-a-mole.
> >
>
> The two are complementary, not competing. BIP62 prevents *non-signers* from
> mutating the transactions, which is very important.
I strongly disagree.
There are exactly two cases where mutation matters to normal wallets:
1) Spending unconfirmed change. This can be more efficiently done by
double-spending the first tx with a second that pays both recipients.
2) Large reorganizations. Making mutation impossible makes it more
likely that after a large reorg all previously confirmed transactions
will make it back to the blockchain succesfully.
Meanwhile, the "whack-a-mole" aspect of BIP62 is worrying - it's very
likely we'll miss a case. Even right now there are edge cases without
good solutions, like how in a multisig environment any of the key
holders can mutate transactions. Building wallets that make strong
assumptions about malleability and fail if those assumptions turn out to
be wrong is poor engineering.
> The 'Build your own
> nHashType' proposal enables chained transactions even in the face of
> *signers* mutating the transaction. I believe that integrating both will
> lead to the best defense against transaction malleability, and will enable
> more complicated uses of chained transactions (such as micropayment
> channels).
While I think there are better ways to do 'Build your own nHashType'
than what was recently proposed, I strongly agree that for protocols
that really, truly, need malleability resistance it's far better to use
a purpose-built signature hashing algorithm.
--
'peter'[:-1]@petertodd.org
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-04-27 19:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-15 23:43 s7r
2015-04-16 2:04 ` Allen Piscitello
2015-04-16 5:22 ` Pieter Wuille
2015-04-16 16:12 ` s7r
2015-04-16 17:34 ` Mark Friedenbach
2015-04-16 23:17 ` s7r
2015-04-17 9:02 ` Pieter Wuille
2015-04-18 14:49 ` s7r
2015-04-24 8:55 ` Jorge Timón
2015-04-24 8:58 ` Jorge Timón
2015-04-24 19:58 ` William Swanson
2015-04-24 20:16 ` Gregory Maxwell
2015-04-25 15:40 ` Stephen Morse
2015-04-26 0:01 ` s7r
2015-04-26 6:51 ` Joseph Poon
2015-04-26 16:48 ` Joseph Poon
2015-04-25 14:32 ` Stephen Morse
2015-04-27 19:21 ` Peter Todd [this message]
2015-04-28 10:17 ` Oleg Andreev
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=20150427191855.GE5223@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=stephencalebmorse@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