Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.98 as permitted sender)
	client-ip=62.13.148.98; envelope-from=pete@petertodd.org;
	helo=outmail148098.authsmtp.com; 
Date: Fri, 19 Jun 2015 06:39:59 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20150619103959.GA32315@savin.petertodd.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="6c2NcOVqGQ03X4Wi"
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list


--6c2NcOVqGQ03X4Wi
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Yesterday F2Pool, currently the largest pool with 21% of the hashing
power, enabled full replace-by-fee (RBF) support after discussions with
me. This means that transactions that F2Pool has will be replaced if a
conflicting transaction pays a higher fee. There are no requirements for
the replacement transaction to pay addresses that were paid by the
previous transaction.


I'm a user. What does this mean for me?
---------------------------------------

In the short term, very little. Wallet software aimed at average users
has no ability to reliably detect conditions where an unconfirmed
transaction may be double-spent by the sender. For example, Schildbach's
Bitcoin Wallet for Android doesn't even detect double-spends of
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes
that propagate them. The least sophisticated double-spend attack
possibly - simply broadcasting two conflicting transactions at the same
time - has about 50% probability of success against these wallets.

Additionally, SPV wallets based on bitcoinj can't even detect invalid
transactions reliably, instead trusting the full node(s) it is connected
too over the unauthenticated, unencrypted, P2P protocol to do validation
for them. For instance due to a unfixed bug=C2=B9 Bitcoin XT nodes will rel=
ay
double-spends that spend the output of the conflicting transaction. I've
personally tested this with Schildbach's Bitcoin Wallet for Android,
which shows such invalid transactions as standard, unconfirmed,
transactions.

Users should continue to assume that unconfirmed transactions could be
trivially reversed by the sender until the first confirmation. In
general, only the sender can reverse a transaction, so if you do trust
the sender feel free to assume an unconfirmed transaction will
eventually confirm. However, if you do not trust the sender and/or have
no other recourse if they double-spend you, wait until at least the
first confirmation before assuming the transaction will go through.

In the long term, miner support of full RBF has a number of advantages
to users, allowing you to more efficiently make transactions, paying
lower fees. However you'll need a wallet supporting these features; none
exist yet.


I'm a business. What does this mean for me?
-------------------------------------------

If you use your own node to verify transactions, you probably are in a
similar situation as average users, so again, this means very little to
you.

If you use a payment processor/transaction API such as BitPay, Coinbase,
BlockCypher, etc. you may or may not be accepting unconfirmed
transactions, and they may or may not be "guaranteed" by your payment
processor even if double-spent. If like most merchants you're using the
API such that confirmations are required prior to accepting orders (e.g.
taking a meaningful loss such as shipping a product if the tx is
reversed) nothing changes for you. If not I recommend you contact your
payment processor.


I'm a miner. Why should I support replace-by-fee?
-------------------------------------------------

Whether full or first-seen-safe=E2=81=B5 RBF support (along with
child-pays-for-parent) is an important step towards a fully functioning
transaction fee market that doesn't lead to users' transactions getting
mysteriously "stuck", particularly during network flooding
events/attacks. A better functioning fee market will help reduce
pressure to increase the blocksize, particularly from the users creating
the most valuable transactions.

Full RBF also helps make use of the limited blockchain space more
efficiently, with up to 90%+ transaction size savings possible in some
transaction patterns. (e.g. long payment chains=E2=81=B6) More users in less
blockchain space will lead to higher overall fees per block.

Finally as we'll discuss below full RBF prevents a number of serious
threats to the existing level playing field that miners operate in.


Why can't we make accepting unconfirmed txs from untrusted people safe?
-----------------------------------------------------------------------

For a decentralized wallet, the situation is pretty bleak. These wallets
only have a handful of connections to the network, with no way of
knowing if those connections give an accurate view of what transactions
miners actually know about.

The only serious attempt to fix this problem for decentralized wallets
that has been actually deployed is Andresen/Harding's double-spend
relaying, implemented in Bitcoin XT. It relays up to one double-spend
transaction per double-spent txout, with the intended effect to warn
recipients. In practice however this functionality makes it easier to
double-spend rather than harder, by giving an efficient and easy way to
get double-spends to miners after the fact. Notably my RBF
implementation even connects to Bitcoin XT nodes, reserving a % of all
incoming and outgoing connection slots for them.

Additionally Bitcoin XT's double-spend relaying is subject to attacks
include bandwidth exhaustion, sybil attacks, and Gervais's non-sybil
interactive attacks=E2=81=B7 among many others.


What about centralised wallets?
-------------------------------

Here the solutions being deployed, planned, and proposed are harmful,
and even represent serious threats to Bitcoin's decentralization.


Confidence factors
------------------

Many services such as BlockCypher=C2=B2 have attempted to predict the
probability that unconfirmed transactions will be mined, often
guaranteeing merchants payment=C2=B3 even in the event of a double-spend. T=
he
key component of these predictions is to sybil attack the P2P network as
a whole, connecting to as many nodes as possible to measure transaction
propagation. Additionally these services connect to pools directly via
the getblocktemplate protocol, repeatedly downloading via GBT the lists
of transactions in the to-be-mined blocks to determine what transactions
miners are attempting to mine.

None of these measures scale, wasting significant network and miner
resources; in one instance a sybil attack by Chainalysis even completely
blocked the users of the SPV wallet Breadwallet=E2=81=B4 from accessing the
network. These measures also don't work very well, giving double-spend
attackers incentives to sybil attack miners themselves.


Transaction processing contracts with miners
--------------------------------------------

The next step after measuring propagation fails is to contract with
miners directly, signing contracts with as much of the hashing power as
possible to get the transactions they want mined and double-spends
rejected. The miners/pools would then provide an authenticated API
endpoint for exclusive use of this service that would allow the service
to add and remove specific transactions to the mempool on demand.

There's a number of serious problems with this:

1) Mining contracts can be used to double-spend

=2E..even when they're being used "honestly".

Suppose Alice is a merchant using CoinPayCypher, who has contracts with
75% of the hashing power. Bob, another merchant, meanwhile uses a
decentralized Bitcoin Core backend for payments to his website.

Mallory wants to double-spend Bob's to buy his expensive products. He
can do this by creating a transaction, tx1, that pays Alice, followed by
a second transaction, tx2, that pays Bob. In any circumstance when
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,
the chance of Malory's double-spend succeeding becomes ~75% because
CoinPayCypher's contracts with mining ensure the transaction paying
Alice will get mined.

Of course, dishonest use and/or compromise makes double-spending
trivial: Malory can use the API credentials to ask miners to reject
Bob's payment at any time.


2) They still don't work, without 51% attacking other miners

Even if CoinPayCypher has 75% of the hashing power on contract, that's
still a potentially 75% chance of being double-spent. The 25% of miners
who haven't signed contracts have no _decentralized_ way of ensuring
they don't create blocks with double-spends, let alone at low cost. If
those miners won't or can't sign contracts with CoinPayCypher the only
next step available is to reject their blocks entirely.


3) Legal contracts give the advantage to non-anonymous miners in
   Western jurisdictions

Suppose CoinPayCypher is a US company, and you're a miner with 1%
hashing power located in northern China. The barriers to you succesfully
negotiating a contract with CoinPayCypher are significant. You don't
speak the same langauge, you're in a completely different jurisdiction
so enforcing the legal contract is difficult, and being just 1%,
CoinPayCypher sees you as insignificant.

Who's going to get the profitable hashing power contracts first, if at
all? Your English speaking competitors in the west. This is inherently a
pressure towards centralization of mining.


Why isn't this being announced on the bitcoin-security list first?
------------------------------------------------------------------

I've had repeated discussions with services vulnerable to double-spends;
they have been made well aware of the risk they're taking. If they've
followed my own and others' advice they'll at minimum have constant
monitoring of the rate of double-spends both on their own services and
on the P2P network in general.

If you choose to take a risk you should accept the consequences.


How do I actually use full RBF?
-------------------------------

First get the full-RBF patch to v0.10.2:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2

The above implementation of RBF includes additional code to find and
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.
Secondly, try out my replace-by-fee-tools at:

    https://github.com/petertodd/replace-by-fee-tools

You can watch double-spends on the network here:

    http://respends.thinlink.com/


References
----------

1) "Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel
    variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet",
   Peter Todd, May 23rd 2015, Bitcoin-development mailing list,
   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms=
g07795.html

2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
   June 2nd, 2014, Erik Voorhees,
   https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transactio=
ns-in-8-seconds-7c9edcb3b734

3) Coinbase Merchant API, Accessed Jun 19th 2015,
   https://developers.coinbase.com/docs/merchants/callbacks#confirmations

4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",
   March 14th 2015, Grace Caffyn, Coindesk,
   http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on=
-bitcoin-network/

5) "First-Seen-Safe Replace-by-Fee",
   May 25th 2015, Peter Todd, Bitcoin-development mailing list,
   http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/=
msg07829.html

6) "Cost savings by using replace-by-fee, 30-90%",
   May 25th 2015, Peter Todd, Bitcoin-development mailing list,
   http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/ms=
g07813.html

7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin",
    Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan Cap=
kun,
    Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,
    http://eprint.iacr.org/2015/578

--=20
'peter'[:-1]@petertodd.org
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad

--6c2NcOVqGQ03X4Wi
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVg/F7XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwYzRjZjM1MDdlN2M3NjEzYTEzZWJhYTQ5MzQyNmM0ZWQw
OTQ3NWZkODYxZWNkNTYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkftw2Af7BMfacX56+IB/a2xRZb/5PzjI
XgPWX0j2zQ2oOMqrSshwctNLRU376TTI2blDd3ZK+2IQmU3xNBcW/oV7TNVBUx2b
M085kZmiL/5/0/iRPTLYST/XvqJbJmZ74oqZ9dk6oT365A8aZHgaDJ6yS90qn0Wt
7ibX7Y3/QYMSzZqe0TRXML7GCjFPwkKuLygiusdxdGUEpCDNH4PhrNEPp1gEeo69
9tsRDy/OaRoPxnFcjgCeoyb8VZRDWX+gXBJMSjpEGM7xUfrJUha7f2/47F3nowNA
zUEus0xmw32UvRJvTGlVI7jMGTZVVTjx34kdPpTesYwQGKzhQO2Az2gfZ4y2JQ==
=l8wL
-----END PGP SIGNATURE-----

--6c2NcOVqGQ03X4Wi--