public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: s7r <s7r@sky-ip.org>
To: Matt Whitlock <bip@mattwhitlock.name>,
	 bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] SPV clients and relaying double spends
Date: Fri, 26 Sep 2014 19:27:01 +0300	[thread overview]
Message-ID: <542593D5.20907@sky-ip.org> (raw)
In-Reply-To: <6165581.aoAyGZkGge@crushinator>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On 9/26/2014 5:16 AM, Matt Whitlock wrote:
> Probably the first double-spend attempt (i.e., the second 
> transaction to spend the same output(s) as another tx already in 
> the mempool) would still need to be relayed. A simple
> "double-spend alert" wouldn't work because it could be forged. But
> after there have been two attempts to spend the same output, no
> further transactions spending that same output should be relayed,
> in order to prevent flooding the network.
> 
This sounds rational - is this already implemented nowadays or *SHOULD
BE* implemented to prevent this attack type in the future?
> 
> On Thursday, 25 September 2014, at 7:12 pm, Aaron Voisine wrote:
>> Something like that would be a great help for SPV clients that 
>> can't detect double spends on their own. (still limited of
>> course to sybil attack concerns)
>> 
>> Aaron Voisine breadwallet.com
>> 
>> 
>> On Thu, Sep 25, 2014 at 7:07 PM, Matt Whitlock 
>> <bip@mattwhitlock.name> wrote:
>>> What's to stop an attacker from broadcasting millions of
>>> spends of the same output(s) and overwhelming nodes with
>>> slower connections? Might it be a better strategy not to relay
>>> the actual transactions (after the first) but rather only
>>> propagate (once) some kind of double-spend alert?
>>> 
>>> 
>>> On Thursday, 25 September 2014, at 7:02 pm, Aaron Voisine 
>>> wrote:
>>>> There was some discussion of having nodes relay
>>>> double-spends in order to alert the network about double
>>>> spend attempts.
>>>> 
>>>> A lot more users will be using SPV wallets in the future,
>>>> and one of the techniques SPV clients use to judge how likely
>>>> a transaction is to be confirmed is if it propagates across
>>>> the network. I wonder if and when double-spend relaying is 
>>>> introduced, if nodes should also send BIP61 reject messages 
>>>> or something along those lines to indicate which
>>>> transactions those nodes believe to be invalid, but are
>>>> relaying anyway.
>>>> 
>>>> This would be subject to sybil attacks, as is monitoring 
>>>> propagation, however it does still increase the cost of 
>>>> performing a 0 confirmation double spend attack on an SPV 
>>>> client above just relaying double-spends without indicating 
>>>> if a node believes the transaction to be valid.
>>>> 
>>>> Aaron Voisine breadwallet.com
>>> 
> 
> ------------------------------------------------------------------------------
>
>
> 
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
> Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS 
> Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download 
> White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with 
> EventLog Analyzer 
> http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
>
>
> 
_______________________________________________
> Bitcoin-development mailing list 
> Bitcoin-development@lists.sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUJZPVAAoJEIN/pSyBJlsRfgoIAI4x4qITdCDyYx/I1+z4eGz3
u7zDbVGQEPsUlrgEZLf503TNUIKmEgYQvgQDGEdOQk615XlkrTJeqt5oLh9DVJKj
TaXRqKgBp4iNd6BIIs1gKl0CzmH9sJ7U9ojhTS5aV7ZUhinO0WZlgISYaBZ3t9Kw
t//jb8QNLqISOeotiO9A2jb06UVRf9Gh0FUSBYTJ/st0UvLWt286zT+4XOaeVI/c
9I9nkTsd/jdw1Eorfcd5T8iHBORcdn9g+5+UpuXVq7d3KA5FA6oetzBVHgUfTMjF
q9LAe0W9IUVSiRj+wWvADzlxeUwWjsHnJDxdGihBg/g+k6SfPnOAxEC1UjCH+OU=
=kaIX
-----END PGP SIGNATURE-----



      parent reply	other threads:[~2014-09-26 16:27 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-26  2:02 [Bitcoin-development] SPV clients and relaying double spends Aaron Voisine
2014-09-26  2:07 ` Matt Whitlock
2014-09-26  2:12   ` Aaron Voisine
2014-09-26  2:16     ` Matt Whitlock
2014-09-26  2:37       ` Aaron Voisine
2014-09-26  3:34         ` Christophe Biocca
2014-09-28  2:55         ` Tom Harding
2014-09-28  5:15           ` [Bitcoin-development] replace-by-fee v0.9.3 release Peter Todd
2014-09-28 17:03             ` Luke Dashjr
2014-09-26 16:27       ` s7r [this message]

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=542593D5.20907@sky-ip.org \
    --to=s7r@sky-ip.org \
    --cc=bip@mattwhitlock.name \
    --cc=bitcoin-development@lists.sourceforge.net \
    /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