-----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 >> <b...@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----- ------------------------------------------------------------------------------ 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
