From: Stephen Morse <stephencalebmorse@gmail•com>
To: Gregory Maxwell <gmaxwell@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
Date: Sat, 25 Apr 2015 11:40:37 -0400 [thread overview]
Message-ID: <CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com> (raw)
In-Reply-To: <CAAS2fgSay0DqeWXfZwX-sN71sLHdRLD51PBmnJfJ5+TC0BQ8zg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]
Hi Gregory,
In particular not covering the ID allows for transaction replay which
> can result in monetary losses far more severe than any possible
> mishandling of malleability could result in. Byzantine attackers can
> costlessly replay your old transactions any time anyone reuses an
> address, even accidentally (which cannot be easily prevented since
> they can race).
>
With the SIGHASH_WITHOUT_PREV_VALUE flag, signatures have to explicitly
specify that they are to be signed without the previous UTXO's
value/amount. This means that, at worst, replay attacks can send the money
to the same place it was sent before (which in many cases is likely not be
a loss of funds), and only if the amount sent to the reused address is the
exact same as it was before. I don't think this is worse than an attacker
being able to mutate their transaction and extort a merchant who accepts
zero-conf transactions. Anyway, not signing the input ID wouldn't exactly
be the norm, there would be a defined set of flags for standard use cases.
Not signing the input TXID would only be used in specialized cases, such as
setting up micropayment channels.
> There are no free lunches; the proposal linked to there is itself a
> game of wack-a-mole with assorted masking flags;
I agree that it is also a bit of wac-a-mole, but the defined space of
issues is possibly more limited here. There are only X number of things
that can be signed/not signed in a transaction, and the 'Build your own
nHashType' proposal enables you to fully specify which of those are being
signed. If you don't want to get burned by not fully signing your
transactions, then don't use the non-standard sighash flags.
many of which we have
> no notion of if they're useful for any particular application(s);
A few of the flags, indeed, may not ever be useful. But we can't predict
the future, and I think it's better to build in a more flexible solution
now than to wish we had more flexible nHashTypes later.
To the original point of this thread, hopefully the suggested proposal
won't be necessary as wallets will upgrade to use version 3 transactions
and the rules associated with them over time.
Best,
Stephen
[-- Attachment #2: Type: text/html, Size: 3016 bytes --]
next prev parent reply other threads:[~2015-04-25 15:40 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 [this message]
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
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='CABHVRKS0EYV0CqKW1MVtUZC3u4KvSxMB=Uks9UrCUBQbozO9xQ@mail.gmail.com' \
--to=stephencalebmorse@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gmaxwell@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