[Bitcoin-development] Double spending and replace by fee

[Bitcoin-development] Double spending and replace by fee

[Mike Hearn]

[-- 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 --]

Re: [Bitcoin-development] Double spending and replace by fee

[Peter Todd]

-----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-----

Re: [Bitcoin-development] Double spending and replace by fee

[Adrian Macneil]

[-- 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 --]

Re: [Bitcoin-development] Double spending and replace by fee

[Peter Todd]

[-- 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 --]