Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.173 as permitted sender)
	client-ip=209.85.217.173;
	envelope-from=christophe.biocca@gmail.com;
	helo=mail-lb0-f173.google.com; 
MIME-Version: 1.0
In-Reply-To: <CACq0ZD6sMHW6QEHHqDkaZwEwyfuk1CUjb0BRhzt3B+g+8CoP5A@mail.gmail.com>
References: <CACq0ZD4Ki=7Tba_2UhmuH-dPCbOnfXrJRcLPc+fP6Uur4FpG_A@mail.gmail.com>
	<1447373.AzvO89eGJS@crushinator>
	<CACq0ZD55G7sAXuu-UxoVJuuk1rwxKKwAPg4qkRoTreD1X2fc9Q@mail.gmail.com>
	<6165581.aoAyGZkGge@crushinator>
	<CACq0ZD6sMHW6QEHHqDkaZwEwyfuk1CUjb0BRhzt3B+g+8CoP5A@mail.gmail.com>
Date: Thu, 25 Sep 2014 23:34:50 -0400
Message-ID: <CANOOu=8-x_eLXP7JARyqjVs6YbM+NRk3N_ProJ6D+U2rqeAohw@mail.gmail.com>
From: Christophe Biocca <christophe.biocca@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [Bitcoin-development] SPV clients and relaying double spends
Precedence: list

A lot of this discussion has already occured. Some code was even
merged into master, then reverted.

See:
https://github.com/bitcoin/bitcoin/issues/4550
https://github.com/bitcoin/bitcoin/pull/4570

It would probably be a good idea to start from that code, as it
addresses many of the possible pitfalls you've been discussing.

On Thu, Sep 25, 2014 at 10:37 PM, Aaron Voisine <voisine@gmail.com> wrote:
> Of course you wouldn't want nodes to propagate alerts without
> independently verifying them, otherwise anyone could just issue alerts
> for every new transaction.
>
> Aaron Voisine
> breadwallet.com
>
>
> On Thu, Sep 25, 2014 at 7:16 PM, Matt Whitlock <bip@mattwhitlock.name> wr=
ote:
>> 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.
>>
>>
>> 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 th=
e same output(s) and overwhelming nodes with slower connections? Might it b=
e 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 ord=
er
>>> >> 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 whi=
ch
>>> >> 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 confirmati=
on
>>> >> double spend attack on an SPV client above just relaying double-spen=
ds
>>> >> 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=3D154622311&iu=3D/4140/ostg=
.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development