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; 
MIME-Version: 1.0
In-Reply-To: <20150619103959.GA32315@savin.petertodd.org>
References: <20150619103959.GA32315@savin.petertodd.org>
From: Jeff Garzik <jgarzik@bitpay.com>
Date: Fri, 19 Jun 2015 08:39:20 -0700
Message-ID: <CAJHLa0PHT6SPi9u4o59TMy1XTpqM+2QQYAD4YXg=izDU=vet6A@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=089e014954c87b4ea50518e0bba3
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Precedence: list

--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 <pete@petertodd.org> 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

<div dir=3D"ltr">This is very disappointing. =C2=A0&quot;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.<div><br></div><div>The community is progressing=
 more towards a safer replace-by-fee model, as indicated by the following c=
ode change:=C2=A0<a href=3D"https://github.com/bitcoin/bitcoin/pull/6176">h=
ttps://github.com/bitcoin/bitcoin/pull/6176</a></div><div><br></div></div><=
div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Jun 19, 20=
15 at 3:39 AM, Peter Todd <span dir=3D"ltr">&lt;<a href=3D"mailto:pete@pete=
rtodd.org" target=3D"_blank">pete@petertodd.org</a>&gt;</span> wrote:<br><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Yesterday F2Pool, currently the largest pool w=
ith 21% of the hashing<br>
power, enabled full replace-by-fee (RBF) support after discussions with<br>
me. This means that transactions that F2Pool has will be replaced if a<br>
conflicting transaction pays a higher fee. There are no requirements for<br=
>
the replacement transaction to pay addresses that were paid by the<br>
previous transaction.<br>
<br>
<br>
I&#39;m a user. What does this mean for me?<br>
---------------------------------------<br>
<br>
In the short term, very little. Wallet software aimed at average users<br>
has no ability to reliably detect conditions where an unconfirmed<br>
transaction may be double-spent by the sender. For example, Schildbach&#39;=
s<br>
Bitcoin Wallet for Android doesn&#39;t even detect double-spends of<br>
unconfirmed transactions when connected to a RBF or Bitcoin XT nodes<br>
that propagate them. The least sophisticated double-spend attack<br>
possibly - simply broadcasting two conflicting transactions at the same<br>
time - has about 50% probability of success against these wallets.<br>
<br>
Additionally, SPV wallets based on bitcoinj can&#39;t even detect invalid<b=
r>
transactions reliably, instead trusting the full node(s) it is connected<br=
>
too over the unauthenticated, unencrypted, P2P protocol to do validation<br=
>
for them. For instance due to a unfixed bug=C2=B9 Bitcoin XT nodes will rel=
ay<br>
double-spends that spend the output of the conflicting transaction. I&#39;v=
e<br>
personally tested this with Schildbach&#39;s Bitcoin Wallet for Android,<br=
>
which shows such invalid transactions as standard, unconfirmed,<br>
transactions.<br>
<br>
Users should continue to assume that unconfirmed transactions could be<br>
trivially reversed by the sender until the first confirmation. In<br>
general, only the sender can reverse a transaction, so if you do trust<br>
the sender feel free to assume an unconfirmed transaction will<br>
eventually confirm. However, if you do not trust the sender and/or have<br>
no other recourse if they double-spend you, wait until at least the<br>
first confirmation before assuming the transaction will go through.<br>
<br>
In the long term, miner support of full RBF has a number of advantages<br>
to users, allowing you to more efficiently make transactions, paying<br>
lower fees. However you&#39;ll need a wallet supporting these features; non=
e<br>
exist yet.<br>
<br>
<br>
I&#39;m a business. What does this mean for me?<br>
-------------------------------------------<br>
<br>
If you use your own node to verify transactions, you probably are in a<br>
similar situation as average users, so again, this means very little to<br>
you.<br>
<br>
If you use a payment processor/transaction API such as BitPay, Coinbase,<br=
>
BlockCypher, etc. you may or may not be accepting unconfirmed<br>
transactions, and they may or may not be &quot;guaranteed&quot; by your pay=
ment<br>
processor even if double-spent. If like most merchants you&#39;re using the=
<br>
API such that confirmations are required prior to accepting orders (e.g.<br=
>
taking a meaningful loss such as shipping a product if the tx is<br>
reversed) nothing changes for you. If not I recommend you contact your<br>
payment processor.<br>
<br>
<br>
I&#39;m a miner. Why should I support replace-by-fee?<br>
-------------------------------------------------<br>
<br>
Whether full or first-seen-safe=E2=81=B5 RBF support (along with<br>
child-pays-for-parent) is an important step towards a fully functioning<br>
transaction fee market that doesn&#39;t lead to users&#39; transactions get=
ting<br>
mysteriously &quot;stuck&quot;, particularly during network flooding<br>
events/attacks. A better functioning fee market will help reduce<br>
pressure to increase the blocksize, particularly from the users creating<br=
>
the most valuable transactions.<br>
<br>
Full RBF also helps make use of the limited blockchain space more<br>
efficiently, with up to 90%+ transaction size savings possible in some<br>
transaction patterns. (e.g. long payment chains=E2=81=B6) More users in les=
s<br>
blockchain space will lead to higher overall fees per block.<br>
<br>
Finally as we&#39;ll discuss below full RBF prevents a number of serious<br=
>
threats to the existing level playing field that miners operate in.<br>
<br>
<br>
Why can&#39;t we make accepting unconfirmed txs from untrusted people safe?=
<br>
-----------------------------------------------------------------------<br>
<br>
For a decentralized wallet, the situation is pretty bleak. These wallets<br=
>
only have a handful of connections to the network, with no way of<br>
knowing if those connections give an accurate view of what transactions<br>
miners actually know about.<br>
<br>
The only serious attempt to fix this problem for decentralized wallets<br>
that has been actually deployed is Andresen/Harding&#39;s double-spend<br>
relaying, implemented in Bitcoin XT. It relays up to one double-spend<br>
transaction per double-spent txout, with the intended effect to warn<br>
recipients. In practice however this functionality makes it easier to<br>
double-spend rather than harder, by giving an efficient and easy way to<br>
get double-spends to miners after the fact. Notably my RBF<br>
implementation even connects to Bitcoin XT nodes, reserving a % of all<br>
incoming and outgoing connection slots for them.<br>
<br>
Additionally Bitcoin XT&#39;s double-spend relaying is subject to attacks<b=
r>
include bandwidth exhaustion, sybil attacks, and Gervais&#39;s non-sybil<br=
>
interactive attacks=E2=81=B7 among many others.<br>
<br>
<br>
What about centralised wallets?<br>
-------------------------------<br>
<br>
Here the solutions being deployed, planned, and proposed are harmful,<br>
and even represent serious threats to Bitcoin&#39;s decentralization.<br>
<br>
<br>
Confidence factors<br>
------------------<br>
<br>
Many services such as BlockCypher=C2=B2 have attempted to predict the<br>
probability that unconfirmed transactions will be mined, often<br>
guaranteeing merchants payment=C2=B3 even in the event of a double-spend. T=
he<br>
key component of these predictions is to sybil attack the P2P network as<br=
>
a whole, connecting to as many nodes as possible to measure transaction<br>
propagation. Additionally these services connect to pools directly via<br>
the getblocktemplate protocol, repeatedly downloading via GBT the lists<br>
of transactions in the to-be-mined blocks to determine what transactions<br=
>
miners are attempting to mine.<br>
<br>
None of these measures scale, wasting significant network and miner<br>
resources; in one instance a sybil attack by Chainalysis even completely<br=
>
blocked the users of the SPV wallet Breadwallet=E2=81=B4 from accessing the=
<br>
network. These measures also don&#39;t work very well, giving double-spend<=
br>
attackers incentives to sybil attack miners themselves.<br>
<br>
<br>
Transaction processing contracts with miners<br>
--------------------------------------------<br>
<br>
The next step after measuring propagation fails is to contract with<br>
miners directly, signing contracts with as much of the hashing power as<br>
possible to get the transactions they want mined and double-spends<br>
rejected. The miners/pools would then provide an authenticated API<br>
endpoint for exclusive use of this service that would allow the service<br>
to add and remove specific transactions to the mempool on demand.<br>
<br>
There&#39;s a number of serious problems with this:<br>
<br>
1) Mining contracts can be used to double-spend<br>
<br>
...even when they&#39;re being used &quot;honestly&quot;.<br>
<br>
Suppose Alice is a merchant using CoinPayCypher, who has contracts with<br>
75% of the hashing power. Bob, another merchant, meanwhile uses a<br>
decentralized Bitcoin Core backend for payments to his website.<br>
<br>
Mallory wants to double-spend Bob&#39;s to buy his expensive products. He<b=
r>
can do this by creating a transaction, tx1, that pays Alice, followed by<br=
>
a second transaction, tx2, that pays Bob. In any circumstance when<br>
Mallory can convince Bob to accept tx2, but prevent Bob from seeing tx1,<br=
>
the chance of Malory&#39;s double-spend succeeding becomes ~75% because<br>
CoinPayCypher&#39;s contracts with mining ensure the transaction paying<br>
Alice will get mined.<br>
<br>
Of course, dishonest use and/or compromise makes double-spending<br>
trivial: Malory can use the API credentials to ask miners to reject<br>
Bob&#39;s payment at any time.<br>
<br>
<br>
2) They still don&#39;t work, without 51% attacking other miners<br>
<br>
Even if CoinPayCypher has 75% of the hashing power on contract, that&#39;s<=
br>
still a potentially 75% chance of being double-spent. The 25% of miners<br>
who haven&#39;t signed contracts have no _decentralized_ way of ensuring<br=
>
they don&#39;t create blocks with double-spends, let alone at low cost. If<=
br>
those miners won&#39;t or can&#39;t sign contracts with CoinPayCypher the o=
nly<br>
next step available is to reject their blocks entirely.<br>
<br>
<br>
3) Legal contracts give the advantage to non-anonymous miners in<br>
=C2=A0 =C2=A0Western jurisdictions<br>
<br>
Suppose CoinPayCypher is a US company, and you&#39;re a miner with 1%<br>
hashing power located in northern China. The barriers to you succesfully<br=
>
negotiating a contract with CoinPayCypher are significant. You don&#39;t<br=
>
speak the same langauge, you&#39;re in a completely different jurisdiction<=
br>
so enforcing the legal contract is difficult, and being just 1%,<br>
CoinPayCypher sees you as insignificant.<br>
<br>
Who&#39;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<br=
>
pressure towards centralization of mining.<br>
<br>
<br>
Why isn&#39;t this being announced on the bitcoin-security list first?<br>
------------------------------------------------------------------<br>
<br>
I&#39;ve had repeated discussions with services vulnerable to double-spends=
;<br>
they have been made well aware of the risk they&#39;re taking. If they&#39;=
ve<br>
followed my own and others&#39; advice they&#39;ll at minimum have constant=
<br>
monitoring of the rate of double-spends both on their own services and<br>
on the P2P network in general.<br>
<br>
If you choose to take a risk you should accept the consequences.<br>
<br>
<br>
How do I actually use full RBF?<br>
-------------------------------<br>
<br>
First get the full-RBF patch to v0.10.2:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/petertodd/bitcoin/tree/replace-=
by-fee-v0.10.2" rel=3D"noreferrer" target=3D"_blank">https://github.com/pet=
ertodd/bitcoin/tree/replace-by-fee-v0.10.2</a><br>
<br>
The above implementation of RBF includes additional code to find and<br>
preferentially connect to other RBF nodes, as well as Bitcoin XT nodes.<br>
Secondly, try out my replace-by-fee-tools at:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"https://github.com/petertodd/replace-by-fee-tools"=
 rel=3D"noreferrer" target=3D"_blank">https://github.com/petertodd/replace-=
by-fee-tools</a><br>
<br>
You can watch double-spends on the network here:<br>
<br>
=C2=A0 =C2=A0 <a href=3D"http://respends.thinlink.com/" rel=3D"noreferrer" =
target=3D"_blank">http://respends.thinlink.com/</a><br>
<br>
<br>
References<br>
----------<br>
<br>
1) &quot;Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel<br=
>
=C2=A0 =C2=A0 variants of existing attacks w/ Bitcoin XT and Android Bitcoi=
n Wallet&quot;,<br>
=C2=A0 =C2=A0Peter Todd, May 23rd 2015, Bitcoin-development mailing list,<b=
r>
=C2=A0 =C2=A0<a href=3D"http://www.mail-archive.com/bitcoin-development@lis=
ts.sourceforge.net/msg07795.html" rel=3D"noreferrer" target=3D"_blank">http=
://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.=
html</a><br>
<br>
2) &quot;From Zero to Hero: Bitcoin Transactions in 8 Seconds&quot;,<br>
=C2=A0 =C2=A0June 2nd, 2014, Erik Voorhees,<br>
=C2=A0 =C2=A0<a href=3D"https://medium.com/blockcypher-blog/from-zero-to-he=
ro-bitcoin-transactions-in-8-seconds-7c9edcb3b734" rel=3D"noreferrer" targe=
t=3D"_blank">https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-=
transactions-in-8-seconds-7c9edcb3b734</a><br>
<br>
3) Coinbase Merchant API, Accessed Jun 19th 2015,<br>
=C2=A0 =C2=A0<a href=3D"https://developers.coinbase.com/docs/merchants/call=
backs#confirmations" rel=3D"noreferrer" target=3D"_blank">https://developer=
s.coinbase.com/docs/merchants/callbacks#confirmations</a><br>
<br>
4) &quot;Chainalysis CEO Denies &#39;Sybil Attack&#39; on Bitcoin&#39;s Net=
work&quot;,<br>
=C2=A0 =C2=A0March 14th 2015, Grace Caffyn, Coindesk,<br>
=C2=A0 =C2=A0<a href=3D"http://www.coindesk.com/chainalysis-ceo-denies-laun=
ching-sybil-attack-on-bitcoin-network/" rel=3D"noreferrer" target=3D"_blank=
">http://www.coindesk.com/chainalysis-ceo-denies-launching-sybil-attack-on-=
bitcoin-network/</a><br>
<br>
5) &quot;First-Seen-Safe Replace-by-Fee&quot;,<br>
=C2=A0 =C2=A0May 25th 2015, Peter Todd, Bitcoin-development mailing list,<b=
r>
=C2=A0 =C2=A0<a href=3D"http://www.mail-archive.com/bitcoin-development%40l=
ists.sourceforge.net/msg07829.html" rel=3D"noreferrer" target=3D"_blank">ht=
tp://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg07=
829.html</a><br>
<br>
6) &quot;Cost savings by using replace-by-fee, 30-90%&quot;,<br>
=C2=A0 =C2=A0May 25th 2015, Peter Todd, Bitcoin-development mailing list,<b=
r>
=C2=A0 =C2=A0<a href=3D"http://www.mail-archive.com/bitcoin-development@lis=
ts.sourceforge.net/msg07813.html" rel=3D"noreferrer" target=3D"_blank">http=
://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.=
html</a><br>
<br>
7) &quot;Tampering with the Delivery of Blocks and Transactions in Bitcoin&=
quot;,<br>
=C2=A0 =C2=A0 Arthur Gervais and Hubert Ritzdorf and Ghassan O. Karame and =
Srdjan Capkun,<br>
=C2=A0 =C2=A0 Cryptology ePrint Archive: Report 2015/578, Jun 10th 2015,<br=
>
=C2=A0 =C2=A0 <a href=3D"http://eprint.iacr.org/2015/578" rel=3D"noreferrer=
" target=3D"_blank">http://eprint.iacr.org/2015/578</a><br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" rel=3D"noreferrer" ta=
rget=3D"_blank">petertodd.org</a><br>
0000000000000000070a2bb3b92c20d5c2c971e6e1a7abe55cdbbe6a2dd9a5ad<br>
</font></span><br>---------------------------------------------------------=
---------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla=
ss=3D"gmail_signature">Jeff Garzik<br>Bitcoin core developer and open sourc=
e evangelist<br>BitPay, Inc. =C2=A0 =C2=A0 =C2=A0<a href=3D"https://bitpay.=
com/" target=3D"_blank">https://bitpay.com/</a></div>
</div>

--089e014954c87b4ea50518e0bba3--