* [Bitcoin-development] Double spending and replace by fee @ 2015-03-28 13:58 Mike Hearn 2015-03-28 14:22 ` Peter Todd 0 siblings, 1 reply; 4+ messages in thread From: Mike Hearn @ 2015-03-28 13:58 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1140 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 1557 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Double spending and replace by fee 2015-03-28 13:58 [Bitcoin-development] Double spending and replace by fee Mike Hearn @ 2015-03-28 14:22 ` Peter Todd 2015-04-09 6:28 ` Adrian Macneil 0 siblings, 1 reply; 4+ messages in thread From: Peter Todd @ 2015-03-28 14:22 UTC (permalink / raw) To: Mike Hearn, Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 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 -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVFrj2 AAoJEMCF8hzn9LncxH8IAIFVwBvpNQfDJTJGEHT8LHQEIB0hLmEMSWwYRovHdwob u3mUigF7dpYoQfL9eU7NqSaNsAkL2WEhBYS9C/OF81AFApxuugnH/VOGz9X4PvJ/ zy5wP12onOrL//8/H9PoGH2dP3fmEe/rdhLelWUABuzyPQaoIaMLTZGREipbbBPK mJ6lBbNhtGGSxV3RgKvkkFYYBCAci/S/ntzpTOuYsgvZIjiXVsxD1uZZ/SiGfS3M R+RIrDX6W/xRdct0gm07KrHMNWo2kPE6uT6egZDxPNP308ddLwGWcvQWTe73bmEL FXsb6gUnfoXwBZfhDav41H4gRdZhLC+gOwVIcx0qLOY= =t0aZ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Double spending and replace by fee 2015-03-28 14:22 ` Peter Todd @ 2015-04-09 6:28 ` Adrian Macneil 2015-04-21 11:37 ` Peter Todd 0 siblings, 1 reply; 4+ messages in thread From: Adrian Macneil @ 2015-04-09 6:28 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3535 bytes --] 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 > 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 [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 801 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Bitcoin-development] Double spending and replace by fee 2015-04-09 6:28 ` Adrian Macneil @ 2015-04-21 11:37 ` Peter Todd 0 siblings, 0 replies; 4+ messages in thread From: Peter Todd @ 2015-04-21 11:37 UTC (permalink / raw) To: Adrian Macneil; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2215 bytes --] On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote: > 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. -- 'peter'[:-1]@petertodd.org 0000000000000000089abd68efc18c03d2a294295f3706a13966613a3ff3b390 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-04-21 11:37 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-03-28 13:58 [Bitcoin-development] Double spending and replace by fee Mike Hearn 2015-03-28 14:22 ` Peter Todd 2015-04-09 6:28 ` Adrian Macneil 2015-04-21 11:37 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox