Discussion:
[Bitcoin-development] First-Seen-Safe Replace-by-Fee
(too old to reply)
Peter Todd
2015-05-26 05:13:05 UTC
Permalink
Raw Message
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
Tom Harding
2015-05-26 17:54:05 UTC
Permalink
Raw Message
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.
Post by Peter Todd
Summary
-------
1) Give users effective ways of getting "stuck" transactions unstuck.
2) Use blockchain space efficiently.
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
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.
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.
Gregory Maxwell
2015-05-26 19:10:25 UTC
Permalink
Raw Message
Post by Tom Harding
It's not difficult to
imagine real-world consequences to not having contributed to the
transaction.
I'm having a hard time. Can you help me understand a specific case
where this makes a difference.

It appears to be a gratuitous requirement; if I have another unused
input that happens to be larger by the required fee-- why not just use
it?

The inherent malleability of signatures makes it unreliable to depend
on the signature content of a transaction until its good and buried,
regardless. And an inability to replace an input means you could not
RBF for additional fees without taking change in more cases; there
ought to be a benefit to that.

------------------------------------------------------------------------------
Tom Harding
2015-05-26 23:00:01 UTC
Permalink
Raw Message
Post by Gregory Maxwell
Post by Tom Harding
It's not difficult to
imagine real-world consequences to not having contributed to the
transaction.
I'm having a hard time. Can you help me understand a specific case
where this makes a difference.
The bitcoin transaction is part of a real-world "deal" with unknown
connections to the other parts. New inputs combined with new or
increased outputs can be thought of as a second deal sharing the same
envelope. That's not the case if paying parties are kicked out of the
deal, and possibly don't learn about it right away.

A subset of parties to an Armory simulfunding transaction (an actual
multi-input use case) could replace one signer's input after they
broadcast it. Whether that's a problem depends on real-world
connections. Maybe the receiver cares where he is paid from or is
basing a subsequent decision on it. Maybe a new output is being added,
whose presence makes the transaction less likely to be confirmed
quickly, with that speed affecting the business.

With Kalle's Proof of Payment proposed standard, one payer in a
two-input transaction could decide to boot the other, and claim the
concert tickets all for himself. The fact that he pays is not the only
consideration in the real world -- what if these are the last 2 tickets?

Mempool policy shouldn't help one payer make a unilateral decision to
become the sole party to a deal after various parties have seen it
broadcast.
Post by Gregory Maxwell
The inherent malleability of signatures makes it unreliable to depend
on the signature content of a transaction until its good and buried,
regardless.
I'd argue that changing how an input is signed doesn't change the deal.
For example if a different 2 of 3 multisig participants sign, those 3
people gave up that level of control when they created the multisig.

Replacement is new - we have a choice what kind of warnings we need to
give to signers of multi-input transactions. IMHO we should avoid
needing a stronger warning than is already needed for 0-conf.



------------------------------------------------------------------------------
Gregory Maxwell
2015-05-26 23:11:17 UTC
Permalink
Raw Message
Post by Tom Harding
The bitcoin transaction is part of a real-world "deal" with unknown
connections to the other parts
I'm having a hard time parsing this. You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it.
Post by Tom Harding
not the case if paying parties are kicked out of the deal, and possibly
don't learn about it right away.
The signatures of a transaction can always be changed any any time,
including by the miner, as they're not signed.
Post by Tom Harding
A subset of parties to an Armory simulfunding transaction (an actual
multi-input use case) could replace one signer's input after they broadcast
it.
They can already do this.
Post by Tom Harding
Maybe the
receiver cares where he is paid from or is basing a subsequent decision on
it. Maybe a new output is being added, whose presence makes the transaction
less likely to be confirmed quickly, with that speed affecting the business.
The RBF behavior always moves in the direction of more prefered or
otherwise the node would not switch to the replacement. Petertodd
should perhaps make that more clear.

But your "maybe"s are what I was asking you to clarify. You said it
wasn't hard to imagine; so I was asking for specific clarification.
Post by Tom Harding
With Kalle's Proof of Payment proposed standard, one payer in a two-input
transaction could decide to boot the other, and claim the concert tickets
all for himself. The fact that he pays is not the only consideration in the
real world -- what if these are the last 2 tickets?
They can already do that.
Post by Tom Harding
I'd argue that changing how an input is signed doesn't change the deal. For
example if a different 2 of 3 multisig participants sign, those 3 people
gave up that level of control when they created the multisig.
Then why do you not argue that changing the input set does not change
the weeblix?

Why is one case of writing out a participant different that the other
case of writing out a participant?
Post by Tom Harding
Replacement is new - we have a choice what kind of warnings we need to give
to signers of multi-input transactions. IMHO we should avoid needing a
stronger warning than is already needed for 0-conf.
How could a _stronger_ warning be required?

------------------------------------------------------------------------------
Tom Harding
2015-05-26 23:42:23 UTC
Permalink
Raw Message
Post by Gregory Maxwell
Post by Tom Harding
The bitcoin transaction is part of a real-world "deal" with unknown
connections to the other parts
I'm having a hard time parsing this. You might as well say that its
part of a weeblix for how informative it is, since you've not defined
it.
For example, you are paying for concert tickets. The deal is concert
tickets for bitcoin. Or you're buying a company with 3 other investors.
Post by Gregory Maxwell
Post by Tom Harding
not the case if paying parties are kicked out of the deal, and possibly
don't learn about it right away.
The signatures of a transaction can always be changed any any time,
including by the miner, as they're not signed.
Miners can't update the signature on input #0 after removing input #1.
Post by Gregory Maxwell
Post by Tom Harding
A subset of parties to an Armory simulfunding transaction (an actual
multi-input use case) could replace one signer's input after they broadcast
it.
They can already do this.
Replacement is about how difficult it is to change the tx after it is
broadcast and seen by observers.
Post by Gregory Maxwell
Post by Tom Harding
Maybe the
receiver cares where he is paid from or is basing a subsequent decision on
it. Maybe a new output is being added, whose presence makes the transaction
less likely to be confirmed quickly, with that speed affecting the business.
The RBF behavior always moves in the direction of more prefered or
otherwise the node would not switch to the replacement. Petertodd
should perhaps make that more clear.
But your "maybe"s are what I was asking you to clarify. You said it
wasn't hard to imagine; so I was asking for specific clarification.
Pick any one "maybe". They're only maybes because it's not realistic
for them all to happen at once.
Post by Gregory Maxwell
Post by Tom Harding
With Kalle's Proof of Payment proposed standard, one payer in a two-input
transaction could decide to boot the other, and claim the concert tickets
all for himself. The fact that he pays is not the only consideration in the
real world -- what if these are the last 2 tickets?
They can already do that.
Not without replacement, after broadcast, unless they successfully pay
twice.
Post by Gregory Maxwell
Post by Tom Harding
I'd argue that changing how an input is signed doesn't change the deal. For
example if a different 2 of 3 multisig participants sign, those 3 people
gave up that level of control when they created the multisig.
Then why do you not argue that changing the input set does not change
the weeblix?
Why is one case of writing out a participant different that the other
case of writing out a participant?
In the multisig input case, each signer already accepted the possibility
of being written out. Peter Todd's proposal is in the spirit of not
willfully making unconfirmed txes less reliable. I'm suggesting that
multi-input signers should be included in the set of people for whom
they don't get less reliable.
Post by Gregory Maxwell
Post by Tom Harding
Replacement is new - we have a choice what kind of warnings we need to give
to signers of multi-input transactions. IMHO we should avoid needing a
stronger warning than is already needed for 0-conf.
How could a _stronger_ warning be required?
We'd have to warn signers to multi-input txes instead of just warning
receivers.


------------------------------------------------------------------------------
Danny Thorpe
2015-05-26 21:20:35 UTC
Permalink
Raw Message
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
Post by Peter Todd
Summary
-------
1) Give users effective ways of getting "stuck" transactions unstuck.
2) Use blockchain space efficiently.
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
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.
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.
--
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
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Pieter Wuille
2015-05-26 21:27:04 UTC
Permalink
Raw Message
It's just a mempool policy rule.

Allowing the contents of blocks to change (other than by mining a competing
chain) would be pretty much the largest possible change to Bitcoin's
design....
Danny Thorpe
2015-05-26 22:09:35 UTC
Permalink
Raw Message
Thanks for the clarification.

So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender
is constructing and publishing a replacement for that pending tx.

The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction
to accomplish what they hoped to do with an RBF replacement.

So an implementation that wishes to take advantage of RBF will still need
to have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.

Is this correct?

I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.

Thanks,
-Danny
Post by Pieter Wuille
It's just a mempool policy rule.
Allowing the contents of blocks to change (other than by mining a
competing chain) would be pretty much the largest possible change to
Bitcoin's design....
Adam Back
2015-05-26 22:18:42 UTC
Permalink
Raw Message
I think the point is the replacement tx spends the same inputs (plus
additional inputs), so if the original tx is accepted, and your
replacement rejected, thats good news - you dont have to pay the
higher fee, the extra input remains unspent (and can be used later for
other purpose) and the extra change address is unused.

(If you had bundled extra transactions into the replacement, spending
from the additional inputs, then you'll need to resubmit those as a
separate transaction).

(You have to keep in mind re-orgs so for example the original tx could
be put into a block, and then that block could get reorged by another
block that grows into a longer chain with the replacement tx in it (or
vice versa)).

Adam
Post by Danny Thorpe
Thanks for the clarification.
So, since RBF applies only to pending transactions in the mempool awaiting
incorporation into a block, there is a window of opportunity in which the
pending tx is incorporated into a block at the same time that the spender is
constructing and publishing a replacement for that pending tx.
The replacement transaction would be rejected by the peer network as a
double spend because it conflicts with the now confirmed original tx, and
the spender will have to go back and create a new stand-alone transaction to
accomplish what they hoped to do with an RBF replacement.
So an implementation that wishes to take advantage of RBF will still need to
have a "plan B" implementation path to handle the corner case of a
replacement tx being rejected as a double spend.
Is this correct?
I'm just trying to get my head around the implementation cost vs benefit of
RBF in the context of my applications.
Thanks,
-Danny
Post by Pieter Wuille
It's just a mempool policy rule.
Allowing the contents of blocks to change (other than by mining a
competing chain) would be pretty much the largest possible change to
Bitcoin's design....
------------------------------------------------------------------------------
_______________________________________________
Bitcoin-development mailing list
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
Peter Todd
2015-05-27 07:30:32 UTC
Permalink
Raw Message
Post by Peter Todd
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.
To clarify a point raised(1) on the pull-req itself:

The replacement transaction is allowed to not only add new txin's, but
also replace txins. Suppose t1 is a 2-in-2-out P2PKH using transaction,
374 bytes in size. With CPFP accomplished by a 1-in-1-out tx, 192 bytes,
you have 566 bytes total. With FSS RBF if you have an unspent output
greater in value than one of the outputs spent by t1, you can replace
that output in t1's vin txin set and rebroadcast the transaction, still
374 bytes in size. This gives you a 34% cost savings vs. CPFP.
Post by Peter Todd
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%
Similarly in the multiple recipients case, if sufficiently large
outputs are available the additional funds can be obtained by swapping
one input for another.

For instance if Alice has three outputs, 1.0, 0.5, and 0.2 BTC, and
needs to pay Bob 1.1 BTC, she can create t1:

1.0 -> Bob 1.1
0.2 -> Alice 0.1

If she then needs to pay Charlie 0.2 BTC she can doublespend that with:

1.0 -> Bob 1.1
0.5 -> Charlie 0.2
-> Alice 0.2

Note that care does need to be taken to ensure that multiple rounds of
this always leave at least one input unchanged.


1) https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-105630255
--
'peter'[:-1]@petertodd.org
00000000000000000ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9
Peter Todd
2015-06-10 09:10:13 UTC
Permalink
Raw Message
First-seen-safe Replace-by-Fee is now available as a patch against
v0.10.2:

https://github.com/petertodd/bitcoin/tree/first-seen-safe-rbf-v0.10.2

I've also had a pull-req against git HEAD open for a few weeks now:

https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829

I've got some hashing power interested in running this patch in the near
future, so I'm offering a bounty of up to 1 BTC to anyone who can find a
way to attack miners running this patch. Specifically, I'm concerned
about things that would lead to significant losses for those miners. A
total crash would be considered very serious - 1 BTC - while excess
bandwidth usage would be considered minor - more like 0.1 BTC. (remember
that this would have to be bandwidth significantly in excess of existing
attacks)

For reference, here's an example of a crash exploit found by Suhas
Daftuar: https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829

If two people report the same or overlapping issues, first person will
get priority. Adding a new test that demos your exploit to the unit
tests will be looked upon favorably. That said, in general I'm not going
to make any hard promises with regards to payouts and will be using my
best judgement. I've got a bit over 2BTC budgetted for this, which is
coming out of my own pockets - I'm not rich! All applicants are however
welcome to troll me on reddit if you think I'm being unfair.


Suhas: speaking of, feel free to email me a Bitcoin address! :)
--
'peter'[:-1]@petertodd.org
000000000000000006dd456cf5ff8bbb56cf88e9314711d55b75c8d23cccddd5
Loading...