From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1XXYMi-00037k-7s for bitcoin-development@lists.sourceforge.net; Fri, 26 Sep 2014 16:27:28 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of sky-ip.org designates 162.222.225.21 as permitted sender) client-ip=162.222.225.21; envelope-from=s7r@sky-ip.org; helo=outbound.mailhostbox.com; Received: from outbound.mailhostbox.com ([162.222.225.21]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1XXYMZ-0001PU-PY for bitcoin-development@lists.sourceforge.net; Fri, 26 Sep 2014 16:27:28 +0000 Received: from [0.0.0.0] (exit4.telostor.ca [62.210.74.137]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: s7r@sky-ip.org) by outbound.mailhostbox.com (Postfix) with ESMTPSA id B14B9639999; Fri, 26 Sep 2014 16:27:07 +0000 (GMT) Message-ID: <542593D5.20907@sky-ip.org> Date: Fri, 26 Sep 2014 19:27:01 +0300 From: s7r User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Matt Whitlock , bitcoin-development@lists.sourceforge.net References: <1447373.AzvO89eGJS@crushinator> <6165581.aoAyGZkGge@crushinator> In-Reply-To: <6165581.aoAyGZkGge@crushinator> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-CTCH-RefID: str=0001.0A020202.542593E2.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-CTCH-SenderID: s7r@sky-ip.org X-CTCH-SenderID-TotalMessages: 1 X-CTCH-SenderID-TotalSpam: 0 X-CTCH-SenderID-TotalSuspected: 0 X-CTCH-SenderID-TotalBulk: 0 X-CTCH-SenderID-TotalConfirmed: 0 X-CTCH-SenderID-TotalRecipients: 0 X-CTCH-SenderID-TotalVirus: 0 X-CTCH-SenderID-BlueWhiteFlag: 0 X-Scanned-By: MIMEDefang 2.72 on 172.18.214.134 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1XXYMZ-0001PU-PY Subject: Re: [Bitcoin-development] SPV clients and relaying double spends X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list Reply-To: s7r@sky-ip.org List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:27:28 -0000 -----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 >> 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-----