From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z6P0b-0006KB-Vs for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 20:04:58 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z6P0Z-0006A7-Pt for bitcoin-development@lists.sourceforge.net; Sat, 20 Jun 2015 20:04:57 +0000 Received: from plantcutter.riseup.net (plantcutter-pn.riseup.net [10.0.1.121]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id B644F41121; Sat, 20 Jun 2015 20:04:49 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla) with ESMTPSA id 5EA5E1FBBD Message-ID: <5585C760.5010304@riseup.net> Date: Sat, 20 Jun 2015 13:04:48 -0700 From: odinn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Peter Todd , bitcoin-development@lists.sourceforge.net References: <20150619103959.GA32315@savin.petertodd.org> In-Reply-To: <20150619103959.GA32315@savin.petertodd.org> Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.9 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.1 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z6P0Z-0006A7-Pt Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2015 20:04:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter, Recently there was a brouhaha over Coinbase censoring the ability of firearms businesses to accept bitcoins via Coinbase https://www.reddit.com/r/Bitcoin/comments/3agbs7/coinbase_shuts_down_bit coin_biz_for_firearms/ The question and relevance here to this is that for people who are going for the alternate route (e.g., bailing on Coinbase / Bitpay / similar web wallets, in favor of setting up with something like Electrum and using Gear https://gear.mycelium.com/ as payment processor or Straight https://github.com/snitko/straight-server, what would be the answer to "What does this mean for me?" for this topic ? On 06/19/2015 03:39 AM, Peter Todd wrote: > Yesterday F2Pool, currently the largest pool with 21% of the > hashing power, enabled full replace-by-fee (RBF) support after > discussions with me. This means that transactions that F2Pool has > will be replaced if a conflicting transaction pays a higher fee. > There are no requirements for the replacement transaction to pay > addresses that were paid by the previous transaction. >=20 >=20 > I'm a user. What does this mean for me?=20 > --------------------------------------- >=20 > 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. >=20 > Additionally, SPV wallets based on bitcoinj can't even detect > invalid transactions reliably, instead trusting the full node(s) it > is connected too over the unauthenticated, unencrypted, P2P > protocol to do validation for them. For instance due to a unfixed > bug=C2=B9 Bitcoin XT nodes will 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. >=20 > 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. >=20 > 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. >=20 >=20 > I'm a business. What does this mean for me?=20 > ------------------------------------------- >=20 > 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. >=20 > 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. >=20 >=20 > I'm a miner. Why should I support replace-by-fee?=20 > ------------------------------------------------- >=20 > Whether full or first-seen-safe=E2=81=B5 RBF support (along with=20 > 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. >=20 > Full RBF also helps make use of the limited blockchain space more=20 > efficiently, with up to 90%+ transaction size savings possible in > some transaction patterns. (e.g. long payment chains=E2=81=B6) More use= rs > in less blockchain space will lead to higher overall fees per > block. >=20 > Finally as we'll discuss below full RBF prevents a number of > serious threats to the existing level playing field that miners > operate in. >=20 >=20 > Why can't we make accepting unconfirmed txs from untrusted people > safe?=20 > ---------------------------------------------------------------------- - - > > 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. >=20 > 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. >=20 > Additionally Bitcoin XT's double-spend relaying is subject to > attacks include bandwidth exhaustion, sybil attacks, and Gervais's > non-sybil interactive attacks=E2=81=B7 among many others. >=20 >=20 > What about centralised wallets? ------------------------------- >=20 > Here the solutions being deployed, planned, and proposed are > harmful, and even represent serious threats to Bitcoin's > decentralization. >=20 >=20 > Confidence factors ------------------ >=20 > Many services such as BlockCypher=C2=B2 have attempted to predict the=20 > probability that unconfirmed transactions will be mined, often=20 > guaranteeing merchants payment=C2=B3 even in the event of a > double-spend. The key component of these predictions is to sybil > attack the P2P network as a whole, connecting to as many nodes as > possible to measure transaction propagation. Additionally these > services connect to pools directly via the getblocktemplate > protocol, repeatedly downloading via GBT the lists of transactions > in the to-be-mined blocks to determine what transactions miners are > attempting to mine. >=20 > None of these measures scale, wasting significant network and > miner resources; in one instance a sybil attack by Chainalysis even > completely blocked the users of the SPV wallet Breadwallet=E2=81=B4 fro= m > accessing the network. These measures also don't work very well, > giving double-spend attackers incentives to sybil attack miners > themselves. >=20 >=20 > Transaction processing contracts with miners=20 > -------------------------------------------- >=20 > 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. >=20 > There's a number of serious problems with this: >=20 > 1) Mining contracts can be used to double-spend >=20 > ...even when they're being used "honestly". >=20 > 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. >=20 > 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. >=20 > Of course, dishonest use and/or compromise makes double-spending=20 > trivial: Malory can use the API credentials to ask miners to > reject Bob's payment at any time. >=20 >=20 > 2) They still don't work, without 51% attacking other miners >=20 > 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. >=20 >=20 > 3) Legal contracts give the advantage to non-anonymous miners in=20 > Western jurisdictions >=20 > Suppose CoinPayCypher is a US company, and you're a miner with 1%=20 > 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. >=20 > 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. >=20 >=20 > Why isn't this being announced on the bitcoin-security list first?=20 > ------------------------------------------------------------------ >=20 > 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. >=20 > If you choose to take a risk you should accept the consequences. >=20 >=20 > How do I actually use full RBF? ------------------------------- >=20 > First get the full-RBF patch to v0.10.2: >=20 > https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2 >=20 > 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: >=20 > https://github.com/petertodd/replace-by-fee-tools >=20 > You can watch double-spends on the network here: >=20 > http://respends.thinlink.com/ >=20 >=20 > References ---------- >=20 > 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,=20 > 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,=20 > https://medium.com/blockcypher-blog/from-zero-to-hero-bitcoin-transact ions-in-8-seconds-7c9edcb3b734 > > 3) Coinbase Merchant API, Accessed Jun 19th 2015,=20 > https://developers.coinbase.com/docs/merchants/callbacks#confirmations > > 4) "Chainalysis CEO Denies 'Sybil Attack' on Bitcoin's Network",=20 > March 14th 2015, Grace Caffyn, Coindesk,=20 > 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,=20 > http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.ne t/msg07829.html > > 6) "Cost savings by using replace-by-fee, 30-90%", May 25th 2015, > Peter Todd, Bitcoin-development mailing list,=20 > 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 >=20 >=20 >=20 > ---------------------------------------------------------------------- - -------- > >=20 >=20 >=20 > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists.sourceforge.net=20 > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >=20 - --=20 http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVhcdfAAoJEGxwq/inSG8CVxUH/1E7P/fuAaDaVMGexaW8MVRT wEPx/sI1IU7S7UC5wXdcm9EufSK4smPLyPuW97LAPRIGnSvTF8BEYW+EW1hLtt0V p9Vbj7+Ii5CJtarLebjeYKjiNSXF8h2p8oH+eeCjUygnzHt5Hsbc8R0aMRyPDJkT lNQmzWGxN1rBTjTQZ+FDA2E2AA1Dkv7UXL15MwudxLOCUONTMh3uwUKC5dz9HE+5 dz3iZWx879VLuaQscDz65FBf5axSKFjL+RGkIuPLF8B1ybsSl0ZYEctmPIv5Ld4V w0bw+oABCFvCKbINdUY+VOdXogDXJDVmCaY/Bbu6sPoZcr0FmHrvHd9KfngjkR4=3D =3D7W68 -----END PGP SIGNATURE-----