Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

[Danny Thorpe <danny.thorpe@gmail.com>]

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

Apologies if this has already been stated and I missed it, but:

Can transactions in a buried block be overridden/replaced by RBF?

Or is RBF strictly limited to transactions that have not yet been
incorporated into a block?

Thanks,
-Danny

On Mon, May 25, 2015 at 10:13 PM, Peter Todd <pete@petertodd.org> 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.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000c7ea0fcac58a9d7267fef8551b9d6a5206bf42b849618cb
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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