Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote: > 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. > 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 0ec0c3a90baa52289171046469fe4a21dc5a0dac4cb758a9 signature.asc Description: Digital signature -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
On 5/26/2015 4:11 PM, Gregory Maxwell wrote: > On Tue, May 26, 2015 at 11:00 PM, Tom Harding wrote: >> 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. >> 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. > >> 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. >> 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. > >> 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. > >> 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. > >> 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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
On Tue, May 26, 2015 at 11:00 PM, Tom Harding wrote: > 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. > 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. > 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. > 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. > 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. > 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? > 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? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
On 5/26/2015 12:10 PM, Gregory Maxwell wrote: > On Tue, May 26, 2015 at 5:54 PM, Tom Harding wrote: >> 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. > 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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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 On 26 May 2015 at 23:09, Danny Thorpe wrote: > 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 > > On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille > wrote: >> >> 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 > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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 On Tue, May 26, 2015 at 2:27 PM, Pieter Wuille wrote: > 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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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 Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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 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%
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
On Tue, May 26, 2015 at 5:54 PM, Tom Harding wrote: > 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. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee
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 transac
