Double spending and replace by fee
4 messages, 28 Mar to 21 Apr 2015. Started by Mike Hearn.
Peter Todd (2), Mike Hearn, Adrian Macneil
I've written a couple of blog posts on replace by fee and double spending mitigations. They sum up the last few years (!) worth of discussions on this list and elsewhere, from my own perspective.
I make no claim to be comprehensive or unbiased but I keep being asked about these topics so figured I'd just write up my thoughts once so I can send links instead of answers :) And then so can anyone who happens to agree.
(1) Replace by fee scorched earth, a counter argument:
https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d
This article lays out the case against RBF-SE and argues it is harmful to Bitcoin.
(2) Double spending and how to make it harder:
https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008
This article summarises a couple of double spending incidents against merchants and then discusses the following techniques:
1. Risk analysis of transactions 2. Payment channels 3. Countersigning by a trusted third party 4. Remote attestation 5. ID verification 6. Waiting for confirmations 7. Punishment of double spending blocks
I hope the material is useful / interesting.
Would you so us all a favor and make a list of companies *actually* relying on "first-seen" mempool behaviour. Because I've been having a hard time actually finding anyone who does who hasn't given up on it. Not very useful to talk about attacks against hypothetical defences.
On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn <mike@plan99•net> wrote:
Quoted text (56 lines)
>I've written a couple of blog posts on replace by fee and double >spending >mitigations. They sum up the last few years (!) worth of discussions on >this list and elsewhere, from my own perspective. > >I make no claim to be comprehensive or unbiased but I keep being asked >about these topics so figured I'd just write up my thoughts once so I >can >send links instead of answers :) And then so can anyone who happens to >agree. > >(1) Replace by fee scorched earth, a counter argument: > >https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d > >This article lays out the case against RBF-SE and argues it is harmful >to >Bitcoin. > >(2) Double spending and how to make it harder: > >https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 > >This article summarises a couple of double spending incidents against >merchants and then discusses the following techniques: > > 1. Risk analysis of transactions > 2. Payment channels > 3. Countersigning by a trusted third party > 4. Remote attestation > 5. ID verification > 6. Waiting for confirmations > 7. Punishment of double spending blocks > >I hope the material is useful / interesting. > > >------------------------------------------------------------------------ > >------------------------------------------------------------------------------ >Dive into the World of Parallel Programming The Go Parallel Website, >sponsored >by Intel and developed in partnership with Slashdot Media, is your hub >for all >things parallel software development, from weekly thought leadership >blogs to >news, videos, case studies, tutorials and more. Take a look and join >the >conversation now. http://goparallel.sourceforge.net/ > >------------------------------------------------------------------------ > >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge•net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants.
Adrian
Quoted text (75 lines)
> On Mar 28, 2015, at 7:22 AM, Peter Todd <pete@petertodd•org> wrote: > > Signed PGP part > Would you so us all a favor and make a list of companies *actually* relying on "first-seen" mempool behaviour. Because I've been having a hard time actually finding anyone who does who hasn't given up on it. Not very useful to talk about attacks against hypothetical defences. > > On 28 March 2015 09:58:53 GMT-04:00, Mike Hearn <mike@plan99•net> wrote: > >I've written a couple of blog posts on replace by fee and double > >spending > >mitigations. They sum up the last few years (!) worth of discussions on > >this list and elsewhere, from my own perspective. > > > >I make no claim to be comprehensive or unbiased but I keep being asked > >about these topics so figured I'd just write up my thoughts once so I > >can > >send links instead of answers :) And then so can anyone who happens to > >agree. > > > >(1) Replace by fee scorched earth, a counter argument: > > > >https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d > > > >This article lays out the case against RBF-SE and argues it is harmful > >to > >Bitcoin. > > > >(2) Double spending and how to make it harder: > > > >https://medium.com/@octskyward/double-spending-in-bitcoin-be0f1d1e8008 > > > >This article summarises a couple of double spending incidents against > >merchants and then discusses the following techniques: > > > > 1. Risk analysis of transactions > > 2. Payment channels > > 3. Countersigning by a trusted third party > > 4. Remote attestation > > 5. ID verification > > 6. Waiting for confirmations > > 7. Punishment of double spending blocks > > > >I hope the material is useful / interesting. > > > > > >------------------------------------------------------------------------ > > > >------------------------------------------------------------------------------ > >Dive into the World of Parallel Programming The Go Parallel Website, > >sponsored > >by Intel and developed in partnership with Slashdot Media, is your hub > >for all > >things parallel software development, from weekly thought leadership > >blogs to > >news, videos, case studies, tutorials and more. Take a look and join > >the > >conversation now. http://goparallel.sourceforge.net/ > > > >------------------------------------------------------------------------ > > > >_______________________________________________ > >Bitcoin-development mailing list > >Bitcoin-development@lists•sourceforge•net > >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for all > things parallel software development, from weekly thought leadership blogs to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge•net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote:
Quoted text (1 line)
> Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards payments to large merchants.
Some questions:
1) Are you contractually obliged to accept zeroconf transactions with existing customers?
I keep hearing rumors of this, but would like some confirmation. In particular, it would be good to know if you have the option of turning zeroconf off at all, contractually speaking.
2) What are your double-spend losses to date?
3) Are you actively marketing zeroconf guarantees to new customers?
You're API is a bit unclear as to what exactly those guarantees are; looks like they only apply if a merchant has "convert to fiat" turned on.
4) What are your short, medium, and long term plans to move away from dependency on "first-seen" mempool policy?
e.g. hub-and-spoke payment channels, Lightning network, off-chain, etc.
5) What is your plan for new Bitcoin Core releases that break zeroconf via changed tx acceptance rules?
Basically every release we've ever made has added a zeroconf exploit due to different tx acceptance rules. (e.g. my 95% success rate last summer)
6) What are your plans for Bitcoin Core releases that fundementally break zeroconf?
For instance changes like limiting the mempool size create zeroconf vulnerabilities that can't be avoided in many situations. Yet they may also be unavoidably needed for, for instance, DoS protection. Will you oppose these improvements?
7) If a mining pool adopts adopted policy that broke zeroconf, e.g. replace-by-fee, would you take any action?
8) Would you take legal action against a mining pool for adopting replace-by-fee publicly?
9) Would you take action against a mining pool who is mining double-spends without explanation?
e.g. one that claims not to be running non-Bitcoin Core policy, but keeps on mining double-spends.