Subject: Re: [Bitcoin-development] SPV clients and relaying double spends

From: s7r <[email-masked]>
Date: Fri, 26 Sep 2014 19:27:01 +0300

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 
>> <[email-masked]> 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 
> [email-masked] 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
s7r
PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11