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 <vois...@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 <b...@mattwhitlock.name> 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. >> >> >> 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 ------------------------------------------------------------------------------ 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
