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-----
prev 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 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$(echo .)org \
--cc=bip@mattwhitlock$(echo .)name \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/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