diff options
| author | Tom Harding <tomh@thinlink.com> | 2015-05-26 10:54:05 -0700 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-05-26 18:22:30 +0000 |
| commit | 40094998d1923f704feedf195725b721c99360d9 (patch) | |
| tree | 284740c1bbf42cf63e0da1e2dadfdc50349be663 | |
| parent | b02196f56389cbad6caa0e5c712b22d8ebc3b0e9 (diff) | |
| download | pi-bitcoindev-40094998d1923f704feedf195725b721c99360d9.tar.gz pi-bitcoindev-40094998d1923f704feedf195725b721c99360d9.zip | |
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
| -rw-r--r-- | f0/893fc94c5496bd18cd9638c49f0da071359caf | 264 |
1 files changed, 264 insertions, 0 deletions
diff --git a/f0/893fc94c5496bd18cd9638c49f0da071359caf b/f0/893fc94c5496bd18cd9638c49f0da071359caf new file mode 100644 index 000000000..3cabf82ce --- /dev/null +++ b/f0/893fc94c5496bd18cd9638c49f0da071359caf @@ -0,0 +1,264 @@ +Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] + helo=mx.sourceforge.net) + by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <tomh@thinlink.com>) id 1YxJUk-00065w-Bw + for bitcoin-development@lists.sourceforge.net; + Tue, 26 May 2015 18:22:30 +0000 +X-ACL-Warn: +Received: from mail-pa0-f54.google.com ([209.85.220.54]) + by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1YxJUi-0002Cd-LB + for bitcoin-development@lists.sourceforge.net; + Tue, 26 May 2015 18:22:30 +0000 +Received: by pacwv17 with SMTP id wv17so98606076pac.2 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 26 May 2015 11:22:22 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to + :subject:references:in-reply-to:content-type + :content-transfer-encoding; + bh=AX1Mb3hmF3dPqJpSzRoHAoy1u9TIsOvMf1dnU8JjDek=; + b=Lbm2v10wMcPMJHsej8Dv4175q7yu9UCm5MHGt80s4vKKRs02lfSHsJ0nJ/c4na29Pl + A/Z2QGzpQYIlEuX7M2qRXMGHvNTmLL4/L+1gK4nOzr8GE9CFwa+DkrU2qwnD3GKq3tUB + QypA2a/MeGqi55ZBs5GzQWKiNFRw3hwh7Nnh3TSh+3Xarkq/wv/T7FHyrbu8Q/64TlMa + MDYpvCNOTu37nypk5ZIjj98o+7eIJF63/xafwJn8nCMLw70ta3PDRDwpvOpVNPDyk3sk + cO7LsZnNbK+ieboW3Q0XD0KoSPU7o9fVb3gTmi6ras/FqXbmtG/FgpN/y8FfXCG/Qc1F + jXvA== +X-Gm-Message-State: ALoCoQkPHbHnvEqVxlJf9dkIbl/UYO5g+x2eVziYIoR3RttbsYU0tz/YK7jhBqbWI5JwRb0TVoJf +X-Received: by 10.70.56.98 with SMTP id z2mr50325320pdp.120.1432662871220; + Tue, 26 May 2015 10:54:31 -0700 (PDT) +Received: from [10.100.1.239] ([204.58.254.99]) + by mx.google.com with ESMTPSA id + ux4sm13673148pbc.61.2015.05.26.10.54.29 + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Tue, 26 May 2015 10:54:30 -0700 (PDT) +Message-ID: <5564B33D.3070107@thinlink.com> +Date: Tue, 26 May 2015 10:54:05 -0700 +From: Tom Harding <tomh@thinlink.com> +User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; + rv:31.0) Gecko/20100101 Thunderbird/31.7.0 +MIME-Version: 1.0 +To: Peter Todd <pete@petertodd.org>, + Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +References: <20150526051305.GA23502@savin.petertodd.org> +In-Reply-To: <20150526051305.GA23502@savin.petertodd.org> +Content-Type: text/plain; charset=windows-1252; format=flowed +Content-Transfer-Encoding: 7bit +X-Spam-Score: 0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + 0.6 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server + [204.58.254.99 listed in dnsbl.sorbs.net] +X-Headers-End: 1YxJUi-0002Cd-LB +Subject: Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 26 May 2015 18:22:30 -0000 + + +I think this is a significant step forward. + +I suggest you also need to ensure that no inputs can be removed or +changed (other than scriptsigs) -- only added. Otherwise, the semantics +change too much for the original signers. Imagine a tx with two inputs +from different parties. Should it be easy for party 1 to be able to +eliminate party 2 as a contributor of funds? It's not difficult to +imagine real-world consequences to not having contributed to the +transaction. And unless you can think of a reason, tx-level attributes +like nLocktime should not change either. + +The result would be something very like CPFP, but with the new inputs +and outputs merged into the original tx, keeping most of the overhead +savings you describe. + +It should be submitted to bitcoin/bitcoin because like most inconsistent +relay policies, inconsistently deployed FSS RBF invites attacks (see +https://gist.github.com/aalness/a78e3e35b90f52140f0d). + +Generally, to be kind to zeroconf: + + - Align relay and validation rules + - Keep first-seen + - Relay double-spends as alerts + - Allow nLocktime transactions into the mempool a bit before they +become final + - ... + +It's not unlike making a best-effort to reduce sources of malleability. +FSS RBF should be compatible with this if deployed consistently. + + + +On 5/25/2015 10:13 PM, Peter Todd wrote: +> Summary +> ------- +> +> First-seen-safe replace-by-fee (FSS RBF) does the following: +> +> 1) Give users effective ways of getting "stuck" transactions unstuck. +> 2) Use blockchain space efficiently. +> +> without: +> +> 3) Changing the status quo with regard to zeroconf. +> +> The current Bitcoin Core implementation has "first-seen" mempool +> behavior. Once transaction t1 has been accepted, the transaction is +> never removed from the mempool until mined, or double-spent by a +> transaction in a block. The author's previously proposed replace-by-fee +> replaced this behavior with simply accepting the transaction paying the +> highest fee. +> +> FSS RBF is a compromise between these two behaviors. Transactions may be +> replaced by higher-fee paying transactions, provided that all outputs in +> the previous transaction are still paid by the replacement. While not as +> general as standard RBF, and with higher costs than standard RBF, this +> still allows fees on transaction to be increased after the fact with +> less cost and higher efficiency than child-pays-for-parent in many +> common situations; in some situations CPFP is unusable, leaving RBF as +> the only option. +> +> +> Semantics +> --------- +> +> For reference, standard replace-by-fee has the following criteria for +> determining whether to replace a transaction. +> +> 1) t2 pays > fees than t1 +> +> 2) The delta fees pay by t2, t2.fee - t1.fee, are >= the minimum fee +> required to relay t2. (t2.size * min_fee_per_kb) +> +> 3) t2 pays more fees/kb than t1 +> +> FSS RBF adds the following additional criteria to replace-by-fee before +> allowing a transaction t1 to be replaced with t2: +> +> 1) All outputs of t1 exist in t2 and pay >= the value in t1. +> +> 2) All outputs of t1 are unspent. +> +> 3) The order of outputs in t2 is the same as in t1 with additional new +> outputs at the end of the output list. +> +> 4) t2 only conflicts with a single transaction, t1 +> +> 5) t2 does not spend any outputs of t1 (which would make it an invalid +> transaction, impossible to mine) +> +> These additional criteria respect the existing "first-seen" behavior of +> the Bitcoin Core mempool implementation, such that once an address is +> payed some amount of BTC, all subsequent replacement transactions will +> pay an equal or greater amount. In short, FSS-RBF is "zeroconf safe" and +> has no affect on the ability of attackers to doublespend. (beyond of +> course the fact that any changes what-so-ever to mempool behavior are +> potential zeroconf doublespend vulnerabilities) +> +> +> Implementation +> -------------- +> +> Pull-req for git HEAD: https://github.com/bitcoin/bitcoin/pull/6176 +> +> A backport to v0.10.2 is pending. +> +> An implementation of fee bumping respecting FSS rules is available at: +> +> https://github.com/petertodd/replace-by-fee-tools/blob/master/bump-fee.py +> +> +> Usage Scenarios +> --------------- +> +> Case 1: Increasing the fee on a single tx +> ----------------------------------------- +> +> We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size +> with the minimal relay fee, 2.26uBTC. Increasing the fee while +> respecting FSS-RBF rules requires the addition of one more txin, with +> the change output value increased appropriately, resulting in +> transaction t2, size 374 bytes. If the change txout is sufficient for +> the fee increase, increasing the fee via CPFP requires a second +> 1-in-1-out transaction, 192 bytes, for a total of 418 bytes; if another +> input is required, CPFP requires a 2-in-1-out tx, 340 bytes, for a total +> of 566 bytes. +> +> Benefits: 11% to 34%+ cost savings, and RBF can increase fees even in +> cases where the original transaction didn't have a change +> output. +> +> +> Case 2: Paying multiple recipients in succession +> ------------------------------------------------ +> +> We have a 1-in-2-out P2PKH transaction t1, 226 bytes, that pays Alice. +> We now need to pay Bob. With plain RBF we'd just add a new outptu and +> reduce the value of the change address, a 90% savings. However with FSS +> RBF, decreasing the value is not allowed, so we have to add an input. +> +> If the change of t1 is sufficient to pay Bob, a second 1-in-2-out tx can +> be created, 2*226=452 bytes in total. With FSS RBF we can replace t1 +> with a 2-in-3-out tx paying both, increasing the value of the change +> output appropriately, resulting in 408 bytes transaction saving 10% +> +> Similar to the above example in the case where the change address of t1 +> is insufficient to pay Bob the end result is one less transaction output +> in the wallet, defragmenting it. Spending these outputs later on would +> require two 148 byte inputs compared to one with RBF, resulting in an +> overall savings of 25% +> +> +> Case 3: Paying the same recipient multiple times +> ------------------------------------------------ +> +> For example, consider the situation of an exchange, Acme Bitcoin Sales, +> that keeps the majority of coins in cold storage. Acme wants to move +> funds to cold storage at the lowest possible cost, taking advantage of +> periods of higher capacity. (inevitable due to the poisson nature of +> block creation) At the same time they would like to defragment their +> incoming outputs to keep redemption costs low, particularly since +> spending their high-security 3-of-7 P2SH multisigs is expensive. Acme +> creates a low fee transaction with a single output to cold storage, +> periodically adding new inputs as funds need to be moved to storage. +> Estimating the cost savings here is complex, and depends greatly on +> details of Acme's business, but regardless the approach works from a +> technical point of view. For instance if Acme's business is such that +> the total hotwallet size needed heavily depends on external factors like +> volatility, as hotwallet demand decreases throughout a day they can add +> inputs to the pending transaction. (simply asking customers to deposit +> funds directly to the cold storage is also a useful strategy) +> +> However this is another case where standard RBF is significantly more +> useful. For instance, as withdrawal requests come in the exchange can +> quickly replace their pending transactions sending funds to cold storage +> with transactions sending those funds to customers instead, each time +> avoiding multiple costly transactions. In particular, by reducing the +> need to access cold storage at all, the security of the cold-stored +> funds is increased. +> +> +> Wallet Compatibility +> -------------------- +> +> All wallets should treat conflicting incoming transactions as equivalent +> so long as the transaction outputs owned by them do not change. In +> addition to compatibility with RBF-related practices, this prevents +> unnecessary user concern if transactions are mutated. Wallets must not +> assume TXIDs are fixed until confirmed in the blockchain; a fixed TXID +> is not guaranteed by the Bitcoin protocol. +> +> + + + |