* [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
@ 2013-06-27 10:23 Arthur Gervais
2013-06-27 11:04 ` Gregory Maxwell
0 siblings, 1 reply; 5+ messages in thread
From: Arthur Gervais @ 2013-06-27 10:23 UTC (permalink / raw)
To: bitcoin-development; +Cc: Ghassan Karame, Hubert Ritzdorf
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Dear Bitcoin developers,
We would like to report a vulnerability which might lead, under some
assumptions, to a double-spending attack in a fast payment scenario.
The vulnerability has been introduced due to signature encoding
incompatibilities between versions 0.8.2 (or 0.8.3) and earlier
Bitcoin versions.
Please find at the following link a detailed description of this
vulnerability:
ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf
We contacted and informed Gavin earlier about this problem.
With best regards,
Arthur Gervais
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQEcBAEBAgAGBQJRzBKLAAoJEI2AYXeasI8/eNYH/2b45o8JPjuiOXeE0MgiYO4g
HgGorNBvH3hLlSZkGh/7GxeGWi3tiEq8DKAgqFd8p+1Ay4YVHK86jJMBxAc8lzpx
TqS6Szrhlx7slamMGhjeem4BJ2RmfVqSRQjidYxwdee8bMQRVH5DiBzndpZwCeHa
AvlP8ojTUFozOJs5PvjEqE+sDKDe5nDC96uiZyMROK8neoiLZpJzV3+ScTUjLCeB
zg34wttX80WKpkXJFvq88FTIvO5E42NGP3APnt2J/HZcey4Mi9UIhLt+/TJ7Z07l
HuxFlzyXdCgRkJWvU13yn8bUP0cbeoox6Cwn7rDAIisVLn4KB9XPThPjfJbKEkg=
=Y6bs
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
2013-06-27 10:23 [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1 Arthur Gervais
@ 2013-06-27 11:04 ` Gregory Maxwell
2013-06-27 16:03 ` Arthur Gervais
0 siblings, 1 reply; 5+ messages in thread
From: Gregory Maxwell @ 2013-06-27 11:04 UTC (permalink / raw)
To: Arthur Gervais; +Cc: Ghassan Karame, bitcoin-development, Hubert Ritzdorf
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
<arthur.gervais@inf•ethz.ch> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Dear Bitcoin developers,
>
> We would like to report a vulnerability which might lead, under some
> assumptions, to a double-spending attack in a fast payment scenario.
> The vulnerability has been introduced due to signature encoding
> incompatibilities between versions 0.8.2 (or 0.8.3) and earlier
> Bitcoin versions.
>
> Please find at the following link a detailed description of this
> vulnerability:
> ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf
It would be kind if your paper cited the one of the prior discussions
of this transaction pattern:
E.g. https://bitcointalk.org/index.php?topic=196990.msg2048297#msg2048297
(I think there are a couple others)
The family of transaction patterns you describe is one of the ones I
specifically cite as an example of why taking non-reversible actions
on unconfirmed transactions is unsafe (and why most of the Bitcoin
community resources) council the same. You can get similar patterns
absent changes in the IsStandard rule through a number of other means.
One obvious one is through concurrent announcement: You announce
conflicting transactions at the same time to many nodes and one
excludes another. By performing this many times and using chains of
unconfirmed transactions and seeing which family your victim observes
you can create input mixes that are only accepted by very specific
subsets of the network.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
2013-06-27 11:04 ` Gregory Maxwell
@ 2013-06-27 16:03 ` Arthur Gervais
2013-06-27 16:13 ` Gregory Maxwell
2013-06-27 16:16 ` Jeff Garzik
0 siblings, 2 replies; 5+ messages in thread
From: Arthur Gervais @ 2013-06-27 16:03 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Ghassan Karame, bitcoin-development, Hubert Ritzdorf
On 6/27/13 1:04 PM, Gregory Maxwell wrote:
> On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais
> <arthur.gervais@inf•ethz.ch> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Dear Bitcoin developers,
>>
>> We would like to report a vulnerability which might lead, under some
>> assumptions, to a double-spending attack in a fast payment scenario.
>> The vulnerability has been introduced due to signature encoding
>> incompatibilities between versions 0.8.2 (or 0.8.3) and earlier
>> Bitcoin versions.
>>
>> Please find at the following link a detailed description of this
>> vulnerability:
>> ftp://ftp.inf.ethz.ch/pub/publications/tech-reports/7xx/789.pdf
>
> It would be kind if your paper cited the one of the prior discussions
> of this transaction pattern:
>
> E.g. https://bitcointalk.org/index.php?topic=196990.msg2048297#msg2048297
> (I think there are a couple others)
>
> The family of transaction patterns you describe is one of the ones I
> specifically cite as an example of why taking non-reversible actions
> on unconfirmed transactions is unsafe (and why most of the Bitcoin
> community resources) council the same. You can get similar patterns
> absent changes in the IsStandard rule through a number of other means.
> One obvious one is through concurrent announcement: You announce
> conflicting transactions at the same time to many nodes and one
> excludes another. By performing this many times and using chains of
> unconfirmed transactions and seeing which family your victim observes
> you can create input mixes that are only accepted by very specific
> subsets of the network.
>
Thank you for the reference! This is indeed a very interesting issue,
affecting the same Bitcoin version. However we think it is
complementary, since our reported problem has nothing to do with fees,
dust, nor is it necessary to send the two double-spending transaction at
the same time. In our setting, double-spending still works if the second
transaction is sent after minutes (and the first transaction has not yet
been included into a block).
Clearly, we have outlined the limits of the security of
zero-confirmation payments in an earlier work.
Our only intention is to raise the awareness for merchants who have to
accept zero-confirmation transactions. They should be aware of the
signature encoding difference between Bitcoin versions and the possible
consequences.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
2013-06-27 16:03 ` Arthur Gervais
@ 2013-06-27 16:13 ` Gregory Maxwell
2013-06-27 16:16 ` Jeff Garzik
1 sibling, 0 replies; 5+ messages in thread
From: Gregory Maxwell @ 2013-06-27 16:13 UTC (permalink / raw)
To: Arthur Gervais; +Cc: Ghassan Karame, bitcoin-development, Hubert Ritzdorf
On Thu, Jun 27, 2013 at 9:03 AM, Arthur Gervais
<arthur.gervais@inf•ethz.ch> wrote:
> affecting the same Bitcoin version. However we think it is
> complementary, since our reported problem has nothing to do with fees,
> dust, nor is it necessary to send the two double-spending transaction at
> the same time. In our setting, double-spending still works if the second
> transaction is sent after minutes (and the first transaction has not yet
> been included into a block).
It works just the same for dust based or any other criteria that makes
transactions non-standard— including the double spending working if
the second transaction is sent minutes after. Exactly the same code is
executed and the same behavior observed for any case of a non-standard
transaction being used to achieve inconsistent forwarding.
> Our only intention is to raise the awareness for merchants who have to
> accept zero-confirmation transactions.
That is great and I'm certainly glad to see people doing that.
Though take care it that your focus on signature encoding differences
doesn't create a misunderstanding. This isn't only an issue with these
particular versions: There is always mining and relay behavior
inhomogeneity in the network. The level of inhomogeneity changes over
time— I believe its greatest when new reference client software that
changes IsStandard but it is never zero as there are large miners with
customized acceptance rules (also mempool state also creates
inhomogeneity). The greater inhomogeneity results in higher success
rates which may be important since some service could conceivable only
be profitable exploited with a high enough success rate.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1
2013-06-27 16:03 ` Arthur Gervais
2013-06-27 16:13 ` Gregory Maxwell
@ 2013-06-27 16:16 ` Jeff Garzik
1 sibling, 0 replies; 5+ messages in thread
From: Jeff Garzik @ 2013-06-27 16:16 UTC (permalink / raw)
To: Arthur Gervais; +Cc: Ghassan Karame, bitcoin-development, Hubert Ritzdorf
On Thu, Jun 27, 2013 at 12:03 PM, Arthur Gervais
<arthur.gervais@inf•ethz.ch> wrote:
> Our only intention is to raise the awareness for merchants who have to
> accept zero-confirmation transactions. They should be aware of the
> signature encoding difference between Bitcoin versions and the possible
> consequences.
Certainly. Though given current P2P network node version
distributions, it is increasing difficult to relay the older version
of transaction, and will only become more so in the future.
It also remains the case that merchants who accept zero confirmation
transactions are likely already aware of the risk level, and make a
business decision. One can see tiny digital downloads often at zero
confirmation, but rarely a Porsche or house or bitcoin exchange
deposit.
--
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc. https://bitpay.com/
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-06-27 16:16 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-06-27 10:23 [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1 Arthur Gervais
2013-06-27 11:04 ` Gregory Maxwell
2013-06-27 16:03 ` Arthur Gervais
2013-06-27 16:13 ` Gregory Maxwell
2013-06-27 16:16 ` Jeff Garzik
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox