F2Pool has enabled full replace-by-fee

> 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¹ Bitcoin XT nodes will relay
> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ 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⁴ 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
>
> ...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/msg07795.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-transactions-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/msg07813.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
>
>

> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. Did they consider using FSS RBF instead?
>
> Best,
> Stephen
>
> On Fri, Jun 19, 2015 at 6: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¹ Bitcoin XT nodes will relay
>> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
>> probability that unconfirmed transactions will be mined, often
>> guaranteeing merchants payment³ 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⁴ 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
>>
>> ...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/msg07795.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-transactions-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/msg07813.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
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. Did they consider using FSS RBF instead?
>
> Best,
> Stephen
>
> On Fri, Jun 19, 2015 at 6: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¹ Bitcoin XT nodes will relay
>> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
>> probability that unconfirmed transactions will be mined, often
>> guaranteeing merchants payment³ 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⁴ 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
>>
>> ...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/msg07795.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-transactions-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/msg07813.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
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> It is disappointing that F2Pool would enable full RBF when the safe
> alternative, first-seen-safe RBF, is also available, especially since the
> fees they would gain by supporting full RBF over FSS RBF would likely be
> negligible. Did they consider using FSS RBF instead?

> We are
> interested in the replace-by-fee patch, but I am not following the
> development closely, more background info is needed, like what the
> difference between standard and zeroconf versions? Thanks.

> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
>> It is disappointing that F2Pool would enable full RBF when the safe
>> alternative, first-seen-safe RBF, is also available, especially since the
>> fees they would gain by supporting full RBF over FSS RBF would likely be
>> negligible. Did they consider using FSS RBF instead?
>
> Specifically the following is what I told them:
>
>> We are
>> interested in the replace-by-fee patch, but I am not following the
>> development closely, more background info is needed, like what the
>> difference between standard and zeroconf versions? Thanks.
>
> Great!
>
> Basically both let you replace one transaction with another that pays a
> higher fee. First-seen-safe replace-by-fee adds the additional criteria
> that all outputs of the old transaction still need to be paid by the new
> transaction, with >= as many Bitcoins. Basically, it makes sure that if
> someone was paid by tx1, then tx2 will still pay them.
>
> I've written about how wallets can use RBF and FSS-RBF to more
> efficiently use the blockchain on the bitcoin-development mailing list:
>
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
>
> Basically, for the purpose of increasing fees, RBF is something like %50
> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>
> In addition, for ease of implementation, my new FSS-RBF has a number of
> other restrictions. For instance, you can't replace multiple
> transactions with one, you can't replace a transaction whose outputs
> have already been spent, you can't replace a transaction with one that
> spends additional unconfirmed inputs, etc. These restrictions aren't
> "set in stone", but they do make the code simpler and less likely to
> have bugs.
>
> In comparison my previous standard RBF patch can replace multiple
> transactions with one, can replace long chains of transactions, etc.
> It's willing to do more computation before deciding if a transaction
> should be replaced, with more complex logic; it probably has a higher
> chance of having a bug or DoS attack.
>
> You've probably seen the huge controversy around zeroconf with regard to
> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
> it also doesn't make it any more dangerous, so politically with regard
> to zeroconf it makes no difference. You *can* still use it doublespend
> by taking advantage of how different transactions are accepted
> differently, but that's true of *every* change we've ever made to
> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
> zeroconf in the same way.
>
>
> Having said that... honestly, zeroconf is pretty broken already. Only
> with pretty heroic measures like connecting to a significant fraction of
> the Bitcoin network at once, as well as connecting to getblocktemplate
> supporting miners to figure out what transactions are being mined, are
> services having any hope of avoiding getting ripped off. For the average
> user their wallets do a terrible job of showing whether or not an
> unconfirmed transaction will go through. For example, Schildbach's
> Bitcoin wallet for Android has no code at all to detect double-spends
> until they get mined, and I've been able to trick it into showing
> completely invalid transactions. In fact, currently Bitcoin XT will
> relay invalid transactions that are doublepsends, and Schildbach's
> wallet displays them as valid, unconfirmed, payments. It's really no
> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
> unconfirmed transactions without some kind of protection that doesn't
> rely on first-seen-safe mempool behavior. For instance, many ATM's these
> days know who their customers are due to AML requirements, so while you
> can deposit Bitcoins and get your funds instantly, the protection for
> the ATM operator is that they can go to the police if you rip them off;
> I've spoken to ATM operators who didn't do this who've lost hundreds or
> even thousands of dollars before giving up on zeroconf.
>
> My big worry with zeroconf is a service like Coinbase or Shapeshift
> coming to rely on it, and then attempting to secure it by gaining
> control of a majority of hashing power. For instance, if Coinbase had
> contracts with 80% of the Bitcoin hashing power to guarantee their
> transactions would get mined, but 20% of the hashing power didn't sign
> up, then the only way to guarantee their transactions could be for the
> 80% to not build on blocks containing doublespends by the 20%. There's
> no way in a decentralized network to come to consensus about what
> transactions are or are not valid without mining itself, so you could
> end up in a situation where unless you're part of one of the big pools
> you can't reliably mine at all because your blocks may get rejected for
> containing doublespends.
>
> One of my goal with standard replace-by-fee is to prevent this scenario
> by forcing merchants and others to implement ways of accepting zeroconf
> transactions safely that work in a decentralized environment regardless
> of what miners do; we have a stronger and safer Bitcoin ecosystem if
> we're relying on math rather than trust to secure our zeroconf
> transactions. We're also being more honest to users, who right now often
> have the very wrong impression that unconfirmed transactions are safe to
> accept - this does get people ripped off all too often!
>
>
> Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
> waiting to get some feedback:
>
>     https://github.com/bitcoin/bitcoin/pull/6176
>
> Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
> working on porting it to v0.10.2, and once that's done I'm going to put
> up a bounty for anyone who can find a DoS attack in the patch. If no-one
> claims the bounty after a week or two I think I'll start feeling
> confident about using it in production.
>
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> I just sent the following email to F2Pool:
>
>
> I was disappointed to see Peter Todd claiming that you have (or will?) run
> his replace-by-fee patch.
>
> I strongly encourage you to wait until most wallet software supports
> replace-by-fee before doing that, because until that happens replace-by-fee
> just makes it easier to steal from bitcoin-accepting merchants.

>
> For instance, if Coinbase had
> contracts with 80% of the Bitcoin hashing power to guarantee their
> transactions would get mined, but 20% of the hashing power didn't sign
> up, then the only way to guarantee their transactions could be for the
> 80% to not build on blocks containing doublespends by the 20%.
>

> one of the merchant service providers trying to get hashing power
> contracts with mining pools for guaranteed transaction acceptance? IIRC
> you are still an advisor to them. This is a serious concern for the
> reasons I outlined in my post.
>

> >
> > For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transactions could be for the
> > 80% to not build on blocks containing doublespends by the 20%.
> >
>
> This seems to be more of a problem with centralized mining than zeroconf
> transactions.

> Speaking of, could we get a confirmation that Coinbase is, or is not,
> > one of the merchant service providers trying to get hashing power
> > contracts with mining pools for guaranteed transaction acceptance? IIRC
> > you are still an advisor to them. This is a serious concern for the
> > reasons I outlined in my post.
> >
>
> We have no contracts in place or plans to do this that I am aware of.
>
> However, we do rely pretty heavily on zeroconf transactions for merchant
> processing, so if any significant portion of the mining pools started
> running your unsafe RBF patch, then we would probably need to look into
> this as a way to prevent fraud.

> Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks.

>
> > We have no contracts in place or plans to do this that I am aware of.
> >
> > However, we do rely pretty heavily on zeroconf transactions for merchant
> > processing, so if any significant portion of the mining pools started
> > running your unsafe RBF patch, then we would probably need to look into
> > this as a way to prevent fraud.
>
> What happens if the mining pools who are mining double-spends aren't
> doing it delibrately? Sybil attacking pools appears to have been done
> before to get double-spends though, equally there are many other changes
> the reduce the reliability of transaction confirmations. For instance
> the higher demands on bandwidth of a higher blocksize will inevitably
> reduce the syncronicity of mempools, resulting in double-spend
> opportunities. Similarly many proposals to limit mempool size allow
> zeroconf double-spends.
>
> In that case would you enter into such contracts?
>

> However, we do rely pretty heavily on zeroconf transactions for merchant
> processing, so if any significant portion of the mining pools started
> running your unsafe RBF patch, then we would probably need to look into this
> as a way to prevent fraud.

> > In that case would you enter into such contracts?
> >
>
> We take it as it comes.
>
> Currently, it's perfectly possible to accept zeroconf transactions with
> only a very small chance of double spend. As long as it's only possible to
> double spend a small fraction of the time, it's an acceptable cost to us in
> exchange for being able to provide a fast checkout experience to customers
> and merchants.

> If the status quo changes, then we will need to investigate alternatives
> (which realistically would include mining contracts, or only accepting
> instant payments from other trusted hosted wallets, which would be a net
> loss for decentralization).

> On 2015-06-19 10:39, 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.
>
>
> Intentional fraud is a bad thing to add to a financial protocol.
>
> A user who creates conflicting transactions, one that pays someone else
> and another which does not pay them, and broadcasts both of them, has
> just self-incriminated themselves by producing prima facie evidence of
> fraud.

> It may be the case that since Bitcoin spans multiple legal jurisdictions
> and can be use anonymously that the victims of such fraud can not rely
> on legal recourse, and it may also be the case that proof of work is how
> Bitcoin deals with the aforementioned factors, but regardless
> un-prosecutable fraud is still fraud and anyone who encourages it should
> be recognied as a bad actors.
>
> Committing vandalism and encouraging fraud to prove a point may be
> something the network can't stop on a technical level, but there's no
> reason not to call it out for what it is.

>
> Unless you're sybil attacking the network and miners, consuming valuable
> resources and creating systemic risks of failure like we saw with
> Chainalysis, I don't see how you're getting "very small" double-spend
> probabilities.
>

> You know, you're creating an interesting bit of game theory here: if I'm
> a miner who doesn't already have a mining contract, why not implement
> full-RBF to force Coinbase to offer me one? One reason might be because
> other miners with such a contract - a majority - are going to be asked
> by Coinbase to reorg you out of the blockchain, but then we have a
> situation where a single entity has control of the blockchain.
>

> For the good of Bitcoin, and your own company, you'd do well to firmly
> state that under no condition will Coinbase ever enter into mining
> contracts.
>

> On Fri, Jun 19, 2015 at 10:00 PM, Adrian Macneil <adrian@coinbase•com>
> wrote:
> > However, we do rely pretty heavily on zeroconf transactions for merchant
> > processing, so if any significant portion of the mining pools started
> > running your unsafe RBF patch, then we would probably need to look into
> this
> > as a way to prevent fraud.
>
> This might be useful to you: https://www.f2pool.com/api/mempool
>
>

> On Jun 19, 2015, at 8:11 AM, Peter Todd <pete@petertodd•org> wrote:
>
> On Fri, Jun 19, 2015 at 03:00:57PM +0000, justusranvier@riseup•net wrote:
>> On 2015-06-19 10:39, 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.
>>
>>
>> Intentional fraud is a bad thing to add to a financial protocol.
>>
>> A user who creates conflicting transactions, one that pays someone else
>> and another which does not pay them, and broadcasts both of them, has
>> just self-incriminated themselves by producing prima facie evidence of
>> fraud.
>
> Depends.
>
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>
> Yet from the point of view of an external observer they have no idea why
> the transaction outputs reduced in size, nor any way of knowing if fraud
> did or did not occur.
>
> Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
> that debt", in which case I'm not breaking any contract at all by giving
> you less money than I first promised - the contract has changed.
>
> Again, none of this can or should be observable to anyone other than the
> parties directly involved.
>
>> It may be the case that since Bitcoin spans multiple legal jurisdictions
>> and can be use anonymously that the victims of such fraud can not rely
>> on legal recourse, and it may also be the case that proof of work is how
>> Bitcoin deals with the aforementioned factors, but regardless
>> un-prosecutable fraud is still fraud and anyone who encourages it should
>> be recognied as a bad actors.
>>
>> Committing vandalism and encouraging fraud to prove a point may be
>> something the network can't stop on a technical level, but there's no
>> reason not to call it out for what it is.
>
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
>
> Yet from the point of view of an external observer they have no idea
> why
> the transaction outputs reduced in size, nor any way of knowing if
> fraud
> did or did not occur.

> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?

> 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¹ Bitcoin XT nodes will relay
> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ 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⁴ 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
>
> ...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/msg07795.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-transactions-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/msg07813.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
>
>

> >
> > Unless you're sybil attacking the network and miners, consuming valuable
> > resources and creating systemic risks of failure like we saw with
> > Chainalysis, I don't see how you're getting "very small" double-spend
> > probabilities.
> >
>
> So connecting to many nodes just because we can and it's not technically
> prevented is bad for the network and creating systemic risks of failure,

> but relaying harmful double spend transactions just because you can and
> it's not technically prevented, is good for everyone?

> > You know, you're creating an interesting bit of game theory here: if I'm
> > a miner who doesn't already have a mining contract, why not implement
> > full-RBF to force Coinbase to offer me one? One reason might be because
> > other miners with such a contract - a majority - are going to be asked
> > by Coinbase to reorg you out of the blockchain, but then we have a
> > situation where a single entity has control of the blockchain.
> >
>
> If someone did enter into contracts with miners to mine certain
> transactions, and had a guarantee that the miners would not build on
> previous blocks which included double spends, then they would only need
> contracts with 51% of the network anyway. So it wouldn't really matter if
> you were a small time miner and wanted to run full-RBF.

> > For the good of Bitcoin, and your own company, you'd do well to firmly
> > state that under no condition will Coinbase ever enter into mining
> > contracts.
> >
>
> I don't personally see what good this does for bitcoin. Now you are
> suggesting that we should prevent a 51% attack by using policy and
> promises, rather than a technical solution. How is this any better than us
> relying on existing double spend rules which are based on policy and
> promises?

> Having said that... honestly, zeroconf is pretty broken already. Only
> with pretty heroic measures like connecting to a significant fraction of
> the Bitcoin network at once, as well as connecting to getblocktemplate
> supporting miners to figure out what transactions are being mined, are
> services having any hope of avoiding getting ripped off. For the average
> user their wallets do a terrible job of showing whether or not an
>

> Before F2Pool's launch, I performed probably the only successful
> bitcoin double spend in the March 2013 fork without any mining power.
> [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <pete@petertodd•org> wrote:
> > On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> >> It is disappointing that F2Pool would enable full RBF when the safe
> >> alternative, first-seen-safe RBF, is also available, especially since
> the
> >> fees they would gain by supporting full RBF over FSS RBF would likely be
> >> negligible. Did they consider using FSS RBF instead?
> >
> > Specifically the following is what I told them:
> >
> >> We are
> >> interested in the replace-by-fee patch, but I am not following the
> >> development closely, more background info is needed, like what the
> >> difference between standard and zeroconf versions? Thanks.
> >
> > Great!
> >
> > Basically both let you replace one transaction with another that pays a
> > higher fee. First-seen-safe replace-by-fee adds the additional criteria
> > that all outputs of the old transaction still need to be paid by the new
> > transaction, with >= as many Bitcoins. Basically, it makes sure that if
> > someone was paid by tx1, then tx2 will still pay them.
> >
> > I've written about how wallets can use RBF and FSS-RBF to more
> > efficiently use the blockchain on the bitcoin-development mailing list:
> >
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
> >
> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
> >
> > Basically, for the purpose of increasing fees, RBF is something like %50
> > cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
> >
> > In addition, for ease of implementation, my new FSS-RBF has a number of
> > other restrictions. For instance, you can't replace multiple
> > transactions with one, you can't replace a transaction whose outputs
> > have already been spent, you can't replace a transaction with one that
> > spends additional unconfirmed inputs, etc. These restrictions aren't
> > "set in stone", but they do make the code simpler and less likely to
> > have bugs.
> >
> > In comparison my previous standard RBF patch can replace multiple
> > transactions with one, can replace long chains of transactions, etc.
> > It's willing to do more computation before deciding if a transaction
> > should be replaced, with more complex logic; it probably has a higher
> > chance of having a bug or DoS attack.
> >
> > You've probably seen the huge controversy around zeroconf with regard to
> > standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
> > it also doesn't make it any more dangerous, so politically with regard
> > to zeroconf it makes no difference. You *can* still use it doublespend
> > by taking advantage of how different transactions are accepted
> > differently, but that's true of *every* change we've ever made to
> > Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
> > zeroconf in the same way.
> >
> >
> > Having said that... honestly, zeroconf is pretty broken already. Only
> > with pretty heroic measures like connecting to a significant fraction of
> > the Bitcoin network at once, as well as connecting to getblocktemplate
> > supporting miners to figure out what transactions are being mined, are
> > services having any hope of avoiding getting ripped off. For the average
> > user their wallets do a terrible job of showing whether or not an
> > unconfirmed transaction will go through. For example, Schildbach's
> > Bitcoin wallet for Android has no code at all to detect double-spends
> > until they get mined, and I've been able to trick it into showing
> > completely invalid transactions. In fact, currently Bitcoin XT will
> > relay invalid transactions that are doublepsends, and Schildbach's
> > wallet displays them as valid, unconfirmed, payments. It's really no
> > surprise to me that nearly no-one in the Bitcoin ecosystem accepts
> > unconfirmed transactions without some kind of protection that doesn't
> > rely on first-seen-safe mempool behavior. For instance, many ATM's these
> > days know who their customers are due to AML requirements, so while you
> > can deposit Bitcoins and get your funds instantly, the protection for
> > the ATM operator is that they can go to the police if you rip them off;
> > I've spoken to ATM operators who didn't do this who've lost hundreds or
> > even thousands of dollars before giving up on zeroconf.
> >
> > My big worry with zeroconf is a service like Coinbase or Shapeshift
> > coming to rely on it, and then attempting to secure it by gaining
> > control of a majority of hashing power. For instance, if Coinbase had
> > contracts with 80% of the Bitcoin hashing power to guarantee their
> > transactions would get mined, but 20% of the hashing power didn't sign
> > up, then the only way to guarantee their transactions could be for the
> > 80% to not build on blocks containing doublespends by the 20%. There's
> > no way in a decentralized network to come to consensus about what
> > transactions are or are not valid without mining itself, so you could
> > end up in a situation where unless you're part of one of the big pools
> > you can't reliably mine at all because your blocks may get rejected for
> > containing doublespends.
> >
> > One of my goal with standard replace-by-fee is to prevent this scenario
> > by forcing merchants and others to implement ways of accepting zeroconf
> > transactions safely that work in a decentralized environment regardless
> > of what miners do; we have a stronger and safer Bitcoin ecosystem if
> > we're relying on math rather than trust to secure our zeroconf
> > transactions. We're also being more honest to users, who right now often
> > have the very wrong impression that unconfirmed transactions are safe to
> > accept - this does get people ripped off all too often!
> >
> >
> > Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
> > waiting to get some feedback:
> >
> >     https://github.com/bitcoin/bitcoin/pull/6176
> >
> > Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
> > working on porting it to v0.10.2, and once that's done I'm going to put
> > up a bounty for anyone who can find a DoS attack in the patch. If no-one
> > claims the bounty after a week or two I think I'll start feeling
> > confident about using it in production.
> >
> >
> > --
> > 'peter'[:-1]@petertodd.org
> > 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
> >
> >
> ------------------------------------------------------------------------------
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge•net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> OK, a few things here:
>
> The Bitcoin network was designed (or should be designed) with the
> requirement that it can withstand deliberate double-spend attacks that
> can come from anywhere at any time…and relaxing this assumption
> without adequately assessing the risk (i.e. I’ve never been hacked
> before so I can assume it’s safe) is extremely dangerous at best and
> just horrid security practice at worst. Your users might not thank you
> for not getting hacked - but they surely will not like it when you DO
> get hacked…and lack a proper recovery plan.
>
> Furthermore, the protocol itself makes no assumptions regarding the
> intentions behind someone signing two conflicting transactions. There
> are many potential use cases where doing so could make a lot of sense.
> Had the protocol been designed along the lines of, say,
> tendermint…where signing multiple conflicting blocks results in loss
> of one’s funds…then the protocol itself disincentivizes the behavior
> without requiring any sort of altruistic, moralistic assumptions. That
> would also mean we’d need a different mechanism for the use cases that
> things like RBF address.
>
> Thirdly, taken to the extreme, the viewpoint of “signing a conflicting
> transaction is fraud and vandalism” means that if for whatever reason
> you attempt to propagate a transaction and nobody mines it for a very
> long time, you’re not entitled to immediately reclaim those funds…they
> must remain in limbo forever.

> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
> > It is disappointing that F2Pool would enable full RBF when the safe
> > alternative, first-seen-safe RBF, is also available, especially since the
> > fees they would gain by supporting full RBF over FSS RBF would likely be
> > negligible. Did they consider using FSS RBF instead?
>
> Specifically the following is what I told them:

>
> > So connecting to many nodes just because we can and it's not technically
> > prevented is bad for the network and creating systemic risks of failure,
>
> Well it is actually; that's why myself, Wladimir van der Laan, and
> Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
> attack.
>
> The Bitcoin P2P network is resilliant to failure when the chance of any
> one node going down is uncorrelated with others. For instance if you
> accidentally introduced a bug in your nodes that failed to relay
> transactions/blocks properly, you'd simultaneously be disrupting a large
> portion of the network all at once.
>

> How many nodes is Coinbase connecting too? What software are they
> running? What subnets are they using? In particular, are they all on one
> subnet or multiple?
>

> > You know, you're creating an interesting bit of game theory here: if I'm
> > > a miner who doesn't already have a mining contract, why not implement
> > > full-RBF to force Coinbase to offer me one? One reason might be because
> > > other miners with such a contract - a majority - are going to be asked
> > > by Coinbase to reorg you out of the blockchain, but then we have a
> > > situation where a single entity has control of the blockchain.
> > >
> >
> > If someone did enter into contracts with miners to mine certain
> > transactions, and had a guarantee that the miners would not build on
> > previous blocks which included double spends, then they would only need
> > contracts with 51% of the network anyway. So it wouldn't really matter if
> > you were a small time miner and wanted to run full-RBF.
>
> But of course, you'd never 51% the network right? After all it's not
> possible to guarantee that your miner won't mine double-spends, as there
> is no single consensus definition of which transaction came first, nor
> can there be.
>
> Or do you see things differently? If I'm a small miner should I be
> worried my blocks might be rejected by the majority with hashing power
> contracts because I'm unable to predict which transactions Coinbase
> believes should go in the blockchain?
>

> I'd also like to note that "prima facie" doesn't mean "always", it means
> that "the default assumption, unless proven otherwise."

> >
> > > So connecting to many nodes just because we can and it's not technically
> > > prevented is bad for the network and creating systemic risks of failure,
> >
> > Well it is actually; that's why myself, Wladimir van der Laan, and
> > Gregory Maxwell all specifically¹ called Chainalysis's actions a sybil
> > attack.
> >
> > The Bitcoin P2P network is resilliant to failure when the chance of any
> > one node going down is uncorrelated with others. For instance if you
> > accidentally introduced a bug in your nodes that failed to relay
> > transactions/blocks properly, you'd simultaneously be disrupting a large
> > portion of the network all at once.
> >
>
> This is exactly what your RBF patch is doing. By your own logic, nodes on
> the network should be allowed to relay (or not relay) whatever they wish.

> > How many nodes is Coinbase connecting too? What software are they
> > running? What subnets are they using? In particular, are they all on one
> > subnet or multiple?
> >
>
> We're running about a dozen nodes running regular Bitcoin Core in various
> subnets. We aren't doing anything particularly out of the ordinary here.
> Nothing that would fall under your definition of a sybil attack or harmful
> to the network.

> > But of course, you'd never 51% the network right? After all it's not
> > possible to guarantee that your miner won't mine double-spends, as there
> > is no single consensus definition of which transaction came first, nor
> > can there be.
> >
> > Or do you see things differently? If I'm a small miner should I be
> > worried my blocks might be rejected by the majority with hashing power
> > contracts because I'm unable to predict which transactions Coinbase
> > believes should go in the blockchain?
> >
>
> You seem so concerned that we are actively trying to harm or control the
> network. We're simply trying to drive bitcoin adoption by making it easy
> for people to spend their bitcoin with merchants online. The problems we
> face are no different from other merchant processors, or small independent
> merchants accepting online or point-of-sale payments.
>
> We've historically had relatively little interest in what miners were doing
> (until RBF came out) - for the most part it didn't affect our business.
> However, most large merchants would be simply uninterested in accepting
> bitcoin if we forced their customers to wait 10-60 minutes for their
> payments to confirm. Many have inventory management systems which can not
> even place items on hold that long.

> On Jun 19, 2015, at 9:36 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:
>
> On Friday, 19 June 2015, at 3:53 pm, justusranvier@riseup•net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it means
>> that "the default assumption, unless proven otherwise."
>
> Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.

> On Friday, 19 June 2015, at 3:53 pm, justusranvier@riseup•net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it
>> means
>> that "the default assumption, unless proven otherwise."
>
> Why would you automatically assume fraud by default? Shouldn't the
> null hypothesis be the default? Without any information one way or
> another, you ought to make *no assumption* about the fraudulence or
> non-fraudulence of any given double-spend.

> If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…
>
>
> > On Jun 19, 2015, at 9:36 AM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> >
> > On Friday, 19 June 2015, at 3:53 pm, justusranvier@riseup•net wrote:
> >> I'd also like to note that "prima facie" doesn't mean "always", it means
> >> that "the default assumption, unless proven otherwise."
> >
> > Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
>

> On Friday, 19 June 2015, at 3:53 pm, justusranvier@riseup•net wrote:
>> I'd also like to note that "prima facie" doesn't mean "always", it means
>> that "the default assumption, unless proven otherwise."
> Why would you automatically assume fraud by default? Shouldn't the null hypothesis be the default? Without any information one way or another, you ought to make *no assumption* about the fraudulence or non-fraudulence of any given double-spend.
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…

> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie”
> assumptions. Otherwise, I would recommend not relying on the existence
> of a signed transaction as proof of intent to pay…

> If we want a non-repudiation mechanism in the protocol, we should
> explicitly define one rather than relying on “prima facie” assumptions.
> Otherwise, I would recommend not relying on the existence of a signed
> transaction as proof of intent to pay…
>

> If we have ECDSA proof that an entity intentionally made and publicly
> announced incompatible promises regarding the disposition of particular
> Bitcoins under their control, then why shouldn't that be assumed to be a
> fraud attempt unless shown otherwise?
>

> Making multiple incompatible versions of a spend is a -requirement- of
> various refund contract protocols.

> On 2015-06-19 17:40, Jeff Garzik wrote:
>
>> Making multiple incompatible versions of a spend is a -requirement- of
>> various refund contract protocols.
>>
>
> Is there not a dedicated field in a transaction (nSequence) for express
> purpose of indicating when a protocol like this is in use?
>

> No.  You cannot know which is the 'right' or wrong transaction.  One tx
> has
> obvious nSequence adjustments, the other - the refund transaction - may
> not.

> This is no longer a mailing list, this is a chatroom.
> Please remove this email from your list, you are now interfering with
> official company business.
>
> Thanks
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> *October 14, 2014 *In latest Hiatus new, the company has taken on yet
> another crazy project but this one is going to benefit the world in which
> it entered not long ago.  The company had done a lot of research on crypto
> currencies, built one for itself, for testing purposes (GigasCorpCoin) and
> found the underlaying problem of Bitcoin and was poised to solve it.
> Company execs decided it would be a good investment to launch its own coin
> and back it itself.
> The company is currently in motion and will hire an expert to do some of
> the coding by October 14, 2015.  Company President refused to be
> interviewed due to too much work that needs done for this secret and
> upcoming project.

> You are free to remove yourself; the URL is at the bottom of every email:
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <
> corporate@gigasgaming•com> wrote:
>
>> This is no longer a mailing list, this is a chatroom.
>> Please remove this email from your list, you are now interfering with
>> official company business.
>>
>> Thanks
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> On Jun 19, 2015, at 3:55 PM, John Bodeen <john-bodeen@uiowa•edu> wrote:
>
> from their website, humorous bits highlighted
>
> October 14, 2014
> In latest Hiatus new, the company has taken on yet another crazy project but this one is going to benefit the world in which it entered not long ago.  The company had done a lot of research on crypto currencies, built one for itself, for testing purposes (GigasCorpCoin) and found the underlaying problem of Bitcoin and was poised to solve it.  Company execs decided it would be a good investment to launch its own coin and back it itself.
> The company is currently in motion and will hire an expert to do some of the coding by October 14, 2015.  Company President refused to be interviewed due to too much work that needs done for this secret and upcoming project.
>
> On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp <jameson.lopp@gmail•com <mailto:jameson.lopp@gmail.com>> wrote:
> You are free to remove yourself; the URL is at the bottom of every email: https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <corporate@gigasgaming•com <mailto:corporate@gigasgaming.com>> wrote:
> This is no longer a mailing list, this is a chatroom.
> Please remove this email from your list, you are now interfering with
> official company business.
>
> Thanks
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> damn he was just on the verge of solving the underlaying problem with
> Bitcoin and you interrupted his focus.
>
> On Jun 19, 2015, at 3:55 PM, John Bodeen <john-bodeen@uiowa•edu> wrote:
>
> from their website, humorous bits highlighted
>
>
>> *October 14, 2014 *In latest Hiatus new, the company has taken on yet
>> another crazy project but this one is going to benefit the world in which
>> it entered not long ago.  The company had done a lot of research on crypto
>> currencies, built one for itself, for testing purposes (GigasCorpCoin) and
>> found the underlaying problem of Bitcoin and was poised to solve it.
>> Company execs decided it would be a good investment to launch its own coin
>> and back it itself.
>> The company is currently in motion and will hire an expert to do some of
>> the coding by October 14, 2015.  Company President refused to be
>> interviewed due to too much work that needs done for this secret and
>> upcoming project.
>
>
> On Fri, Jun 19, 2015 at 10:34 AM, Jameson Lopp <jameson.lopp@gmail•com>
> wrote:
>
>> You are free to remove yourself; the URL is at the bottom of every email:
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>> On Fri, Jun 19, 2015 at 12:41 PM, Gigas Gaming Inc. <
>> corporate@gigasgaming•com> wrote:
>>
>>> This is no longer a mailing list, this is a chatroom.
>>> Please remove this email from your list, you are now interfering with
>>> official company business.
>>>
>>> Thanks
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists•sourceforge•net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> If full-RBF sees any significant adoption by miners, then it will actively
> harm bitcoin adoption by reducing or removing the ability for online or POS
> merchants to accept bitcoin payments at all.

> On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
> > If full-RBF sees any significant adoption by miners, then it will
> actively
> > harm bitcoin adoption by reducing or removing the ability for online or
> POS
> > merchants to accept bitcoin payments at all.
>
> Retail POS merchants probably should not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several blocks
> deep in the chain. Retail merchants should be requiring a co-signature from
> a mutually trusted co-signer that vows never to sign a double-spend. The
> reason we don't yet see such technology permeating the ecosystem is
> because, to date, zero-conf transactions have been irreversible "enough,"
> but this has only been a happy accident; it was never promised, and it
> should not be relied upon.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> Has anyone from Mycelium weighed in on this? Is their doublespend attack
> detection broken with this kind of irresponsible behavior?
>
> On Fri, Jun 19, 2015 at 3:39 PM, Matt Whitlock <bip@mattwhitlock•name>
> wrote:
>
>> On Friday, 19 June 2015, at 9:18 am, Adrian Macneil wrote:
>> > If full-RBF sees any significant adoption by miners, then it will
>> actively
>> > harm bitcoin adoption by reducing or removing the ability for online or
>> POS
>> > merchants to accept bitcoin payments at all.
>>
>> Retail POS merchants probably should not be accepting vanilla Bitcoin
>> payments, as Bitcoin alone does not (and cannot) guarantee the
>> irreversibility of a transaction until it has been buried several blocks
>> deep in the chain. Retail merchants should be requiring a co-signature from
>> a mutually trusted co-signer that vows never to sign a double-spend. The
>> reason we don't yet see such technology permeating the ecosystem is
>> because, to date, zero-conf transactions have been irreversible "enough,"
>> but this has only been a happy accident; it was never promised, and it
>> should not be relied upon.
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> --
> *MONEY IS OVER!*
>                                 IF YOU WANT IT
> <http://www.zeitgeistmovie.com/>
> =====================================================
> The causes of my servitude can be traced to the tyranny of money.
> -Serj Tankian
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Retail POS merchants probably should not be accepting vanilla Bitcoin
> payments, as Bitcoin alone does not (and cannot) guarantee the
> irreversibility of a transaction until it has been buried several
> blocks deep in the chain. Retail merchants should be requiring a
> co-signature from a mutually trusted co-signer that vows never to sign
> a double-spend.

> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> What retail needs is escrowed microchannel hubs (what lightning provides,

> What retail needs is escrowed microchannel hubs (what lightning provides,
> for example), which enable untrusted instant payments. Not reliance on
> single-signer zeroconf transactions that can never be made safe.
>
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas@petersson•at>
> wrote:
>
>> I have some experience here. If you are seriously suggesting these
>> measures, you might as well kill retail transactions altogether.
>>
>> In practice, if a retail place starts to accept bitcoin they have a
>> similar situation as with cash, only that the fraud potential is much
>> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
>> and the fraud frequency is also much lower.
>>
>> 0-conf concerns were never a problem in practice. except for 2-way atms
>> i have never heard of a problem that was caused by double spends.
>> while adding these measures is generally positive, requiring them means
>> excluding 99.9% of the potential users. so you might as well not do it.
>>
>> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
>> value. So it's a bad thing.
>>
>> for any online or automated system, waiting for a handful of
>> confirmations was always recommended practice.
>>
>> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
>> > Retail POS merchants probably should not be accepting vanilla Bitcoin
>> > payments, as Bitcoin alone does not (and cannot) guarantee the
>> > irreversibility of a transaction until it has been buried several
>> > blocks deep in the chain. Retail merchants should be requiring a
>> > co-signature from a mutually trusted co-signer that vows never to sign
>> > a double-spend.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge•net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> On Jun 19, 2015, at 6:23 PM, Aaron Voisine <voisine@gmail•com> wrote:
>
> > What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.
>
> They don't need to be made cryptographically safe, they just have to be safer than, for instance, credit card payments that can be charged back. As long as it's reasonably good in practice, that's fine.
>
>
> Aaron Voisine
> co-founder and CEO
> breadwallet.com <http://breadwallet.com/>
> On Fri, Jun 19, 2015 at 6:09 PM, Mark Friedenbach <mark@friedenbach•org <mailto:mark@friedenbach.org>> wrote:
> What retail needs is escrowed microchannel hubs (what lightning provides, for example), which enable untrusted instant payments. Not reliance on single-signer zeroconf transactions that can never be made safe.
>
> On Fri, Jun 19, 2015 at 5:47 PM, Andreas Petersson <andreas@petersson•at <mailto:andreas@petersson.at>> wrote:
> I have some experience here. If you are seriously suggesting these
> measures, you might as well kill retail transactions altogether.
>
> In practice, if a retail place starts to accept bitcoin they have a
> similar situation as with cash, only that the fraud potential is much
> lower. (e.g. 100-dollar bill for a sandwich might turn out fake later)
> and the fraud frequency is also much lower.
>
> 0-conf concerns were never a problem in practice. except for 2-way atms
> i have never heard of a problem that was caused by double spends.
> while adding these measures is generally positive, requiring them means
> excluding 99.9% of the potential users. so you might as well not do it.
>
> RBF as implemented by F2Pool just flat out lowers Bitcoins utility
> value. So it's a bad thing.
>
> for any online or automated system, waiting for a handful of
> confirmations was always recommended practice.
>
> Am 19.06.2015 um 22:39 schrieb Matt Whitlock:
> > Retail POS merchants probably should not be accepting vanilla Bitcoin
> > payments, as Bitcoin alone does not (and cannot) guarantee the
> > irreversibility of a transaction until it has been buried several
> > blocks deep in the chain. Retail merchants should be requiring a
> > co-signature from a mutually trusted co-signer that vows never to sign
> > a double-spend.
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net <mailto:Bitcoin-development@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

> They don't need to be made cryptographically safe, they just have to be
> safer than, for instance, credit card payments that can be charged back. As
> long as it's reasonably good in practice, that's fine.

> On Jun 19, 2015, at 8:48 PM, Luke Dashjr <luke@dashjr•org> wrote:
>
> On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
>> They don't need to be made cryptographically safe, they just have to be
>> safer than, for instance, credit card payments that can be charged back. As
>> long as it's reasonably good in practice, that's fine.
>
> They never will be. You can get a decent rate of success merely by making one
> transaction propagate fast (eg, 1 input, 1 output) and the other slow (eg,
> 1000 inputs, 1000 outputs) and choosing your peers carefully. The only reason
> unconfirmed transactions aren't double spent today is because nobody is
> seriously *trying*.
>
> Luke
>

> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

>
> > On Jun 19, 2015, at 8:48 PM, Luke Dashjr <luke@dashjr•org> wrote:
> >
> > On Saturday, June 20, 2015 1:23:03 AM Aaron Voisine wrote:
> >> They don't need to be made cryptographically safe, they just have to be
> >> safer than, for instance, credit card payments that can be charged
> back. As
> >> long as it's reasonably good in practice, that's fine.
> >
> > They never will be. You can get a decent rate of success merely by
> making one
> > transaction propagate fast (eg, 1 input, 1 output) and the other slow
> (eg,
> > 1000 inputs, 1000 outputs) and choosing your peers carefully. The only
> reason
> > unconfirmed transactions aren't double spent today is because nobody is
> > seriously *trying*.
> >
> > Luke
> >
>
>
> Newspapers are often sold in vending machines that make it possible for
> anyone to just pay the price of one and take them all…and most of the time
> they are not that carefully monitored. Why? Because most people have better
> things to do than try to steal a few newspapers. They probably were much
> more closely monitored earlier in their history…but once it became clear
> that despite the obvious attack vector very few people actually try to game
> it, vendors figured it wasn’t really that big a risk. Same thing applies to
> people trying to steal a piece of bubble gum at the cash register at a
> convenience store by double-spending.
>
> - Eric Lombrozo
>
> >
> ------------------------------------------------------------------------------
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge•net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Yep - similarly: you live in a neighborhood with a local coffee store.
> Sure you could use a stolen credit card or a fake $5 bill, but it's not
> worth the risk of being caught for a $3 coffee. And on the other side, the
> store can deal with 1% of transactions getting reversed or having a fake
> bill so they don't change their procedures.
>

> Perfection is not necessary in all situations.
>

> 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¹ Bitcoin XT nodes will relay 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ 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⁴ 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
>
> ...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/

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

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

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

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

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

>
>
>
>
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…

> If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof of intent to pay…

> On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail•com>
> wrote:
>> If we want a non-repudiation mechanism in the protocol, we should
>> explicitly define one rather than relying on “prima facie”
>> assumptions. Otherwise, I would recommend not relying on the existence
>> of a signed transaction as proof of intent to pay…
>
> Non-repudiation can be built on top of the payment protocol layer.

> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>
> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>
> I disagree with this premise. Please, don't take this as an argument
> from authority fallacy, but I will cite Satoshi to express what I
> think the assumptions while using the system should be:
>
> "As long as a majority of CPU power is controlled by nodes that are
> not cooperating to attack the network, they'll generate the longest
> chain and outpace attackers."
>
> I can't say for sure what was meant by "attacking the network" in this
> context but I personally mean trying to rewrite valid and
> proof-of-work-timestamped history.
> Unconfirmed transactions are simply not part of history yet. Ordering
> unconfirmed transactions in a consensus compatible way without a
> universal clock is impossible, that's why we're using proof of work in
> the first place.
>
> Alternative policies are NOT attacks on the network.

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>>
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>>
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>>
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>>
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>>
>> Alternative policies are NOT attacks on the network.
>
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
>
> - Eric Lombrozo

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
>>
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>>> The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…
>>
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>>
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>>
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>>
>> Alternative policies are NOT attacks on the network.
>
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
>
> - Eric Lombrozo

> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup•net wrote:
>
> Signed PGP part
> On 2015-06-20 18:20, Jorge Timón wrote:
> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail•com>
> > wrote:
> >> If we want a non-repudiation mechanism in the protocol, we should
> >> explicitly define one rather than relying on “prima facie”
> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> of a signed transaction as proof of intent to pay…
> >
> > Non-repudiation can be built on top of the payment protocol layer.
>
>
> Non-repudiation is an intrinsic property of the ECDSA signatures which
> Bitcoin uses - it's not a feature that needs to be built.
>
> There's no way to accidentally sign a transaction and accidentally
> announce it publicly. There is no form of third-party error that can
> result in a payee receiving an erroneous contract.
>
>

>> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup•net wrote:
>>
>> Signed PGP part
>> On 2015-06-20 18:20, Jorge Timón wrote:
>> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail•com>
>> > wrote:
>> >> If we want a non-repudiation mechanism in the protocol, we should
>> >> explicitly define one rather than relying on “prima facie”
>> >> assumptions. Otherwise, I would recommend not relying on the existence
>> >> of a signed transaction as proof of intent to pay…
>> >
>> > Non-repudiation can be built on top of the payment protocol layer.
>>
>>
>> Non-repudiation is an intrinsic property of the ECDSA signatures which
>> Bitcoin uses - it's not a feature that needs to be built.
>>
>> There's no way to accidentally sign a transaction and accidentally
>> announce it publicly. There is no form of third-party error that can
>> result in a payee receiving an erroneous contract.
>>
>>
>
> Justus,
>
> We don’t even have a concept of identity in the Bitcoin protocol, let
> alone non-repudiation. What good is non-repudiation if there’s no way
> to even associate a signature with a legal entity?
>
> Sure, we could use the ECDSA signatures in transactions as part of a
> non-repudiation scheme - but the recipient would have to also have a
> means to establish the identity of the sender and associate it with
> the the transaction.
>
>
> Furthermore, in light of the fact that there *are* fully legitimate
> use cases for sending conflicting transactions…and the fact that
> determination of intent isn’t always entirely clear…we should refrain
> from attaching any further significance transaction signatures other
> than that “the sender was willing to have it included in the
> blockchain if a miner were to have seen it and accepted it…but perhaps
> the sender would have changed their mind before it actually did get
> accepted.”

> On Jun 20, 2015, at 5:27 PM, justusranvier@riseup•net wrote:
>
> Signed PGP part
> On 2015-06-20 19:19, Eric Lombrozo wrote:
> >> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup•net wrote:
> >>
> >> Signed PGP part
> >> On 2015-06-20 18:20, Jorge Timón wrote:
> >> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail•com>
> >> > wrote:
> >> >> If we want a non-repudiation mechanism in the protocol, we should
> >> >> explicitly define one rather than relying on “prima facie”
> >> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> >> of a signed transaction as proof of intent to pay…
> >> >
> >> > Non-repudiation can be built on top of the payment protocol layer.
> >>
> >>
> >> Non-repudiation is an intrinsic property of the ECDSA signatures which
> >> Bitcoin uses - it's not a feature that needs to be built.
> >>
> >> There's no way to accidentally sign a transaction and accidentally
> >> announce it publicly. There is no form of third-party error that can
> >> result in a payee receiving an erroneous contract.
> >>
> >>
> >
> > Justus,
> >
> > We don’t even have a concept of identity in the Bitcoin protocol, let
> > alone non-repudiation. What good is non-repudiation if there’s no way
> > to even associate a signature with a legal entity?
> >
> > Sure, we could use the ECDSA signatures in transactions as part of a
> > non-repudiation scheme - but the recipient would have to also have a
> > means to establish the identity of the sender and associate it with
> > the the transaction.
> >
> >
> > Furthermore, in light of the fact that there *are* fully legitimate
> > use cases for sending conflicting transactions…and the fact that
> > determination of intent isn’t always entirely clear…we should refrain
> > from attaching any further significance transaction signatures other
> > than that “the sender was willing to have it included in the
> > blockchain if a miner were to have seen it and accepted it…but perhaps
> > the sender would have changed their mind before it actually did get
> > accepted.”
>
> Bitcoin has no concept of identity, but in any type of commercial
> transaction the parties involved must know some minimal amount of
> identity information in order to transact at all.
>
> Except for some identifiable special cases, I think a payee is perfectly
> justified in treating a double spend of a payment sent to them as part
> of a commercial transaction as a fraud attempt and employing whatever
> non-Bitcoin recourse mechanisms, if any, they have access to.
>
> From the perspective of the network, the obviously correct action for
> any node or miner is to relay the first version of any transaction they
> see. The primary purpose of mining is to resolve this
> otherwise-unresolvable problem of determining which transaction among a
> set of conflicting transactions happened first.
>
> If a node or miner wants to deviate from the obviously correct
> behaviour, and if they want to avoid harming the value of the network,
> they should be particularly careful to make sure their deviation from
> "first seen" doesn't introduce harmful unintended side effects, like
> making fraud easier.
>

> 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¹ Bitcoin XT nodes will relay
> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
> probability that unconfirmed transactions will be mined, often
> guaranteeing merchants payment³ 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⁴ 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
>
> ...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/msg07795.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-transactions-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/msg07813.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
>
>

> se, lo re putearon a Peter Todd en reddit por esto
> On Jun 19, 2015 7:42 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¹ Bitcoin XT nodes will relay
>> 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⁵ 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⁶) 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⁷ 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² have attempted to predict the
>> probability that unconfirmed transactions will be mined, often
>> guaranteeing merchants payment³ 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⁴ 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
>>
>> ...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/msg07795.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-transactions-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/msg07813.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
>>
>>

> Perhaps it isn’t prudent to push out changes to the relay policy that make these exploits even easier right now - but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient so that we have more room for changes on things like relay policy without significant disruption to the network.
>

>  but we NEED to be applying some kind of pressure on the merchant end to
> upgrade their stuff to be more resilient
>

> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail.com>> wrote:
>  but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
>
> Can you be specific?  What precise technical steps would you have BitPay and Coinbase do?  We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/ <https://bitpay.com/>

> On Jun 21, 2015, at 12:42 AM, Eric Lombrozo <elombrozo@gmail•com> wrote:
>
>
>> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik@bitpay•com <mailto:jgarzik@bitpay.com>> wrote:
>>
>> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail•com <mailto:elombrozo@gmail.com>> wrote:
>>  but we NEED to be applying some kind of pressure on the merchant end to upgrade their stuff to be more resilient
>>
>> Can you be specific?  What precise technical steps would you have BitPay and Coinbase do?  We upgrade our stuff to... what exactly?
>>
>> --
>> Jeff Garzik
>> Bitcoin core developer and open source evangelist
>> BitPay, Inc.      https://bitpay.com/ <https://bitpay.com/>
> Thanks for asking *the* question, Jeff. We often get caught up in these philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the security policy.
>
> If you must accept zero confirmation transactions, there are a few concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do not accept them for very high priced goods…especially if they require physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…) the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e. someone trying to purchase a bunch of stuff that totally doesn’t fit into their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is probably pretty hard to obtain since statistics are generally of little use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to see an attack you can immediately disable all zero confirmation transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that offline :)
>
>
> - Eric Lombrozo
>
>
>
>

>
> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik@bitpay•com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo@gmail•com>
> wrote:
>
>>  but we NEED to be applying some kind of pressure on the merchant end to
>> upgrade their stuff to be more resilient
>>
>
> Can you be specific?  What precise technical steps would you have BitPay
> and Coinbase do?  We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.      https://bitpay.com/
>
>
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that
> offline :)
>
>
> - Eric Lombrozo
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> On Jun 21, 2015, at 1:41 AM, Btc Drak <btcdrak@gmail•com> wrote:
>
> Eric,
>
> BitPay clearly do understand the risks of 0-conf. In case you were not aware BitPay does not particularly "accept zero confirm transactions". When a payment is seen on the network the payment screen reports the invoice has been paid, but that's front-end user facing. On the back end it's marked as paid but the API exposes the the confirmation status allowing the merchant to make business decisions about when to progress to fulfilment. A good example of this is Neteller (a sort of paypal variant) which allows one to fund the account with fiat using Bitcoin, via Bitpay. When you pay the bitpay invoice, your account is marked as payment pending until there are some confirmations.
>

> Coinbase does not expose the confirmation status and from what I understand (not checked myself) they guarantee payment to merchants for 0-confirm, regardless of whether they confirm or not.

> One more thing I would like to add to this thread: I want to make it
> unequivocally clear that I believe what is making double-spends easier has
> relatively little to do with the protocol and almost everything to do with
> poor software and poor security policy on the merchant end. Perhaps it
> isn’t prudent to push out changes to the relay policy that make these
> exploits even easier right now - but we NEED to be applying some kind of
> pressure on the merchant end to upgrade their stuff to be more resilient so
> that we have more room for changes on things like relay policy without
> significant disruption to the network.
>
> - Eric Lombrozo
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
>

> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
>

> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>