public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Dario Sneidermanis <dariosn@gmail.com>
To: Peter Todd <pete@petertodd.org>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Date: Sat, 20 Jun 2015 23:23:27 -0300	[thread overview]
Message-ID: <CAHBM8Ui=Ahkw-x_B5UeemJduDbBMyzwSQPSzU-+RKekmsbqB=A@mail.gmail.com> (raw)
In-Reply-To: <CAHBM8UjC_qMvrpweEDuZxMqACu=xtvsDzd2BMB_B+PAS3Y8aaA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 12956 bytes --]

Sorry about that, ignore me
On Jun 20, 2015 11:11 PM, "Dario Sneidermanis" <dariosn@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 15483 bytes --]

      reply	other threads:[~2015-06-21  2:23 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 10:39 [Bitcoin-development] F2Pool has enabled full replace-by-fee Peter Todd
2015-06-19 13:33 ` Gavin Andresen
2015-06-19 13:52   ` Peter Todd
2015-06-19 14:00     ` Adrian Macneil
2015-06-19 14:08       ` Peter Todd
2015-06-19 14:30         ` Adrian Macneil
2015-06-19 14:59           ` Peter Todd
2015-06-19 15:20             ` Adrian Macneil
2015-06-19 15:40               ` Peter Todd
2015-06-19 16:18                 ` Adrian Macneil
2015-06-19 16:37                   ` Peter Todd
2015-06-19 20:39                   ` Matt Whitlock
2015-06-19 21:05                     ` Frank Flores
2015-06-19 21:15                       ` Jeff Garzik
2015-06-20  0:47                     ` Andreas Petersson
2015-06-20  1:09                       ` Mark Friedenbach
2015-06-20  1:23                         ` Aaron Voisine
2015-06-20  3:07                           ` Eric Lombrozo
2015-06-20  3:48                           ` Luke Dashjr
2015-06-20  4:02                             ` Eric Lombrozo
2015-06-20 16:43                               ` Ivan Brightly
2015-06-20 17:38                                 ` Cameron Hejazi
2015-06-19 14:40       ` Chun Wang
2015-06-19 15:22         ` Adrian Macneil
2015-06-19 13:33 ` Stephen Morse
2015-06-19 13:37   ` Chun Wang
2015-06-19 13:48     ` Peter Todd
2015-06-19 14:16     ` Lawrence Nahum
2015-06-19 13:40   ` Adrian Macneil
2015-06-19 13:44   ` Peter Todd
2015-06-19 13:52     ` Chun Wang
2015-06-19 15:43       ` Jeff Garzik
2015-06-19 19:49       ` Jeffrey Paul
2015-06-19 15:42     ` Jeff Garzik
2015-06-19 16:15     ` Peter Todd
2015-06-19 15:00 ` justusranvier
2015-06-19 15:11   ` Peter Todd
2015-06-19 15:37     ` Eric Lombrozo
2015-06-19 15:53       ` justusranvier
2015-06-19 16:36         ` Matt Whitlock
2015-06-19 16:42           ` Eric Lombrozo
2015-06-19 16:46             ` Matt Whitlock
2015-06-19 16:53             ` Peter Todd
2015-06-19 16:54             ` justusranvier
2015-06-19 17:00             ` Tier Nolan
2015-06-20 23:20             ` Jorge Timón
2015-06-20 23:37               ` justusranvier
2015-06-21  0:19                 ` Eric Lombrozo
2015-06-21  0:27                   ` justusranvier
2015-06-21  0:36                     ` Eric Lombrozo
2015-06-21  0:54                     ` Eric Lombrozo
2015-06-21  5:56                       ` Tom Harding
2015-06-21  6:45                       ` Jeff Garzik
2015-06-21  7:42                         ` Eric Lombrozo
2015-06-21  8:35                           ` Eric Lombrozo
2015-06-21  8:41                           ` Btc Drak
2015-06-21  8:51                             ` Eric Lombrozo
2015-06-21 19:49                           ` Jeff Garzik
2015-06-21 18:23                       ` Aaron Voisine
2015-06-19 16:44           ` justusranvier
2015-06-19 17:40             ` Jeff Garzik
2015-06-19 17:48               ` justusranvier
2015-06-19 17:50                 ` Jeff Garzik
2015-06-19 18:00                   ` justusranvier
2015-06-19 16:50           ` Milly Bitcoin
2015-06-19 16:41         ` [Bitcoin-development] Remove Us Please Gigas Gaming Inc.
2015-06-19 18:34           ` Jameson Lopp
2015-06-19 19:55             ` John Bodeen
2015-06-19 20:01               ` Brian Hoffman
2015-06-19 20:27                 ` Jameson Lopp
2015-06-20 23:16       ` [Bitcoin-development] F2Pool has enabled full replace-by-fee Jorge Timón
2015-06-20 23:47         ` Eric Lombrozo
2015-06-20 23:52           ` Eric Lombrozo
2015-06-20 23:56           ` Eric Lombrozo
2015-06-19 15:39     ` justusranvier
2015-06-19 15:39 ` Jeff Garzik
2015-06-20 20:04 ` odinn
2015-06-21  2:11 ` Dario Sneidermanis
2015-06-21  2:23   ` Dario Sneidermanis [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAHBM8Ui=Ahkw-x_B5UeemJduDbBMyzwSQPSzU-+RKekmsbqB=A@mail.gmail.com' \
    --to=dariosn@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=pete@petertodd.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox