From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5yOS-0005x8-FZ for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:39:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of bitpay.com designates 209.85.214.180 as permitted sender) client-ip=209.85.214.180; envelope-from=jgarzik@bitpay.com; helo=mail-ob0-f180.google.com; Received: from mail-ob0-f180.google.com ([209.85.214.180]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5yOQ-00082f-6n for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:39:48 +0000 Received: by obbgp2 with SMTP id gp2so76715572obb.2 for ; Fri, 19 Jun 2015 08:39:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=L5b0sL1VJs/MZcFR3KjKo7tL/e+n79EezXlQEohnON4=; b=GIlNyPwhUHcwcxUo5WUvthkWV3OCD01F9JcwQntznfWQy1XeBhRzbmuJ1wpxIogOQX tm8EUOo052cPsTciwcT6e1uVEEugQLNzgH+H9BJqqqhRXH0NbOOiq1E6O5PyNoulWuJi NPESUTYa/i+j0B+isEKbXPiFjdQEtvwXdgmWv9iGZg3mTeBIp1NI6oRZKnhCmWgbg/3w oQIDEMH4F+nVuNxSKIxDgM9StzPRgOULRPKrnxQklCrLIisM1mTIw7PCKEpXqrYM/I+n EALz0lpIAy+KXq6cnfdr+z2/y8jbvXBIwf/b7MrrLRKUW4O2v8SdPSqiG4Qm6AD9UwWs bGOA== X-Gm-Message-State: ALoCoQm5V9ZaWxpl9AJAjp8+oe8eDDwUeg4ChjjkN2XiS/j/6PQSwDPJno0E1gkQNaQAM/7PFnFh X-Received: by 10.182.86.9 with SMTP id l9mr14162172obz.61.1434728380704; Fri, 19 Jun 2015 08:39:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.108.149 with HTTP; Fri, 19 Jun 2015 08:39:20 -0700 (PDT) In-Reply-To: <20150619103959.GA32315@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> From: Jeff Garzik Date: Fri, 19 Jun 2015 08:39:20 -0700 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary=089e014954c87b4ea50518e0bba3 X-Spam-Score: -0.4 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.2 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5yOQ-00082f-6n Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2015 15:39:48 -0000 --089e014954c87b4ea50518e0bba3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable This is very disappointing. "scorched earth" replace-by-fee implemented first at a pool, without updating wallets and merchants, is very anti-social and increases the ability to perform Finney attacks and double-spends. The community is progressing more towards a safer replace-by-fee model, as indicated by the following code change: https://github.com/bitcoin/bitcoin/pull/6176 On Fri, Jun 19, 2015 at 3:39 AM, Peter Todd wrote: > 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 r= elay > 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 l= ess > 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.= The > 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 t= he > 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 > > ...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/msg= 07795.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-transaction= s-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/m= sg07829.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/msg= 07813.html > > 7) "Tampering with the Delivery of Blocks and Transactions in Bitcoin", > Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and Srdjan > Capkun, > Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015, > http://eprint.iacr.org/2015/578 > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad > > > -------------------------------------------------------------------------= ----- > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --=20 Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ --089e014954c87b4ea50518e0bba3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is very disappointing. =C2=A0"scorched earth&quo= t; replace-by-fee implemented first at a pool, without updating wallets and= merchants, is very anti-social and increases the ability to perform Finney= attacks and double-spends.

The community is progressing= more towards a safer replace-by-fee model, as indicated by the following c= ode change:=C2=A0h= ttps://github.com/bitcoin/bitcoin/pull/6176

<= div class=3D"gmail_extra">
On Fri, Jun 19, 20= 15 at 3:39 AM, Peter Todd <pete@petertodd.org> wrote:
Yesterday F2Pool, currently the largest pool w= ith 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'v= e
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; non= e
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 pay= ment
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 get= ting
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 les= s
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<= br> 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

...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<= br> 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<= br> those miners won't or can't sign contracts with CoinPayCypher the o= nly
next step available is to reject their blocks entirely.


3) Legal contracts give the advantage to non-anonymous miners in
=C2=A0 =C2=A0Western 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<= br> 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<= br> 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:

=C2=A0 =C2=A0 https://github.com/pet= ertodd/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:

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

You can watch double-spends on the network here:

=C2=A0 =C2=A0 http://respends.thinlink.com/


References
----------

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

2) "From Zero to Hero: Bitcoin Transactions in 8 Seconds",
=C2=A0 =C2=A0June 2nd, 2014, Erik Voorhees,
=C2=A0 =C2=A0https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-= transactions-in-8-seconds-7c9edcb3b734

3) Coinbase Merchant API, Accessed Jun 19th 2015,
=C2=A0 =C2=A0https://developer= s.coinbase.com/docs/merchants/callbacks#confirmations

4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Net= work",
=C2=A0 =C2=A0March 14th 2015, Grace Caffyn, Coindesk,
=C2=A0 =C2=A0http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-= bitcoin-network/

5) "First-Seen-Safe Replace-by-Fee",
=C2=A0 =C2=A0May 25th 2015, Peter Todd, Bitcoin-development mailing list, =C2=A0 =C2=A0ht= tp://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07= 829.html

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

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

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

---------------------------------------------------------= ---------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/= listinfo/bitcoin-development




--
Jeff Garzik
Bitcoin core developer and open sourc= e evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2=A0https://bitpay.com/
--089e014954c87b4ea50518e0bba3--