Making OP_TRUE standard?
26 messages, 8 to 31 May 2018. Started by Rusty Russell.
Rusty Russell (7), ZmnSCPxj (5), Peter Todd (3), Olaoluwa Osuntokun (2), Johnson Lau (2), Luke Dashjr (2), Jorge Timón (2), Christian Decker, +2 more
Hi all,
The largest problem we are having today with the lightning protocol is trying to predict future fees. Eltoo solves this elegantly, but meanwhile we would like to include a 546 satoshi OP_TRUE output in commitment transactions so that we use minimal fees and then use CPFP (which can't be done at the moment due to CSV delays on outputs).
Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is non-standard. Are there any reasons not to suggest such a policy change?
Thanks! Rusty.
What are the downsides of just using p2wsh? This route can be rolled out immediately, while policy changes are pretty "fuzzy" and would require a near uniform rollout in order to ensure wide propagation of the commitment transactions.
On Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> Hi all, > > The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Good morning Olauluwa,
I believe P2WSH is larger due to the script hash commitment in the `scriptPubKey` as well as the actual script revelation in the `witnessScript`, whereas, a flat OP_TRUE in the `scriptPubKey` is much smaller and can be spent with an empty `scriptSig`. It seems this is the entirety of the reason to desire an isStandard OP_TRUE.
Regards, ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On May 9, 2018 8:24 AM, Olaoluwa Osuntokun via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (22 lines)
> What are the downsides of just using p2wsh? This route can be rolled out immediately, while policy changes are pretty "fuzzy" and would require a near uniform rollout in order to ensure wide propagation of the commitment transactions. > > On Tue, May 8, 2018, 4:58 PM Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > >> Hi all, >> >> The largest problem we are having today with the lightning >> protocol is trying to predict future fees. Eltoo solves this elegantly, >> but meanwhile we would like to include a 546 satoshi OP_TRUE output in >> commitment transactions so that we use minimal fees and then use CPFP >> (which can't be done at the moment due to CSV delays on outputs). >> >> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is >> non-standard. Are there any reasons not to suggest such a policy >> change? >> >> Thanks! >> Rusty. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change.
In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
Quoted text (20 lines)
> On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote: > > Hi all, > > The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:
Quoted text (5 lines)
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set > > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change. > > In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
I don't think that will work, as a zero-fee tx won't get relayed even with CPFP, due to the fact that we haven't yet implemented package-based tx relaying.
Quoted text (15 lines)
> On 10 May 2018, at 3:27 AM, Peter Todd <pete@petertodd•org> wrote: > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set >> >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change. >> >> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily. > > I don't think that will work, as a zero-fee tx won't get relayed even with > CPFP, due to the fact that we haven't yet implemented package-based tx > relaying. > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org
My only concern is UTXO pollution. There could be a “CPFP anchor” softfork that outputs with empty scriptPubKey and 0 value are spendable only in the same block. If not spent immediately, they become invalid and are removed from UTXO. But I still think the best solution is a more flexible SIGHASH system, which doesn’t need CPFP at all.
On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:
Quoted text (19 lines)
> > > > On 10 May 2018, at 3:27 AM, Peter Todd <pete@petertodd•org> wrote: > > > > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote: > >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set > >> > >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change. > >> > >> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily. > > > > I don't think that will work, as a zero-fee tx won't get relayed even with > > CPFP, due to the fact that we haven't yet implemented package-based tx > > relaying. > > > > -- > > https://petertodd.org 'peter'[:-1]@petertodd.org > > My only concern is UTXO pollution. There could be a “CPFP anchor” softfork that outputs with empty scriptPubKey and 0 value are spendable only in the same block. If not spent immediately, they become invalid and are removed from UTXO. But I still think the best solution is a more flexible SIGHASH system, which doesn’t need CPFP at all.
I don't see any reason why UTXO pollution would be a special concern so long as those outputs are subject to the same dust rules as any other output is.
Quoted text (3 lines)
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don’t need to ask for any protocol change.
If one has a "root" commitment with other nested descendent multi-transaction contracts, then changing the txid of the root commitment will invalidated all the nested multi tx contracts. In our specific case, we have pre-signed 2-stage HTLC transaction which rely on a stable txid. As a result, we can't use the ANYONECANPAY approach atm.
Quoted text (2 lines)
> In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily.
Agreed, see the recent proposal to introduce SIGHASH_NOINPUT as a new sighash type. IMO it presents an opportunity to introduce more flexible fine grained sighash inclusion control.
-- Laolu
On Wed, May 9, 2018 at 11:12 AM Johnson Lau via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (41 lines)
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but > nothing else. This makes sure CPFP will always be needed, so the OP_TRUE > output won’t pollute the UTXO set > > Instead, would you consider to use ANYONECANPAY to sign the tx, so it is > possible add more inputs for fees? The total tx size is bigger than the > OP_TRUE approach, but you don’t need to ask for any protocol change. > > In long-term, I think the right way is to have a more flexible SIGHASH > system to allow people to add more inputs and outputs easily. > > > > > On 9 May 2018, at 7:57 AM, Rusty Russell via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > > > > Hi all, > > > > The largest problem we are having today with the lightning > > protocol is trying to predict future fees. Eltoo solves this elegantly, > > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > > commitment transactions so that we use minimal fees and then use CPFP > > (which can't be done at the moment due to CSV delays on outputs). > > > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > > non-standard. Are there any reasons not to suggest such a policy > > change? > > > > Thanks! > > Rusty. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Johnson Lau <jl2012@xbt•hk> writes:
Quoted text (1 line)
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
That won't propagate :(
Quoted text (4 lines)
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it > is possible add more inputs for fees? The total tx size is bigger than > the OP_TRUE approach, but you don’t need to ask for any protocol > change.
No, that would change the TXID, which we rely on for HTLC transactions.
Quoted text (1 line)
> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
Agreed: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015862.html
But in the long term we'll have Eltoo and SIGHASH_NOINPUT which both allow different solutions.
Cheers, Rusty.
Olaoluwa Osuntokun <laolu32@gmail•com> writes:
Quoted text (4 lines)
> What are the downsides of just using p2wsh? This route can be rolled out > immediately, while policy changes are pretty "fuzzy" and would require a > near uniform rollout in order to ensure wide propagation of the commitment > transactions.
I expect we will, but thougth I'd ask :)
I get annoyed when people say "We found this issue, but we worked around it and so never bothered you with it!" for my projects :)
Cheers, Rusty.
An OP_TRUE-only script with a low value seems like a good example of where the weight doesn't reflect the true cost: it uses a UTXO forever, while only costing a weight of 4.
I like Johnson's idea to have some template (perhaps OP_2-only, to preserve expected behaviour of OP_TRUE-only) that when combined with a 0-value is always valid only if spent in the same block.
I wonder if it would make sense to actually tie it to a transaction version bit, such that when the bit is set, the transaction is serialised with +1 on the output count and 00000000000000000181 is simply injected into the transaction hashing... But for now, simply having a consensus rule that a bit MUST be set for the expected behaviour, and the bit may ONLY be set when the last output is exactly 00000000000000000181, would allow us to code the transaction serialisation up later. (Maybe it should be the first output instead of the last... Is there any legitimate reason one would have multiple such dummy outputs?)
Luke
On Tuesday 08 May 2018 23:57:11 Rusty Russell via bitcoin-dev wrote:
Quoted text (18 lines)
> Hi all, > > The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Good morning Luke and list,
Quoted text (11 lines)
> An OP_TRUE-only script with a low value seems like a good example of where the > > weight doesn't reflect the true cost: it uses a UTXO forever, while only > > costing a weight of 4. > > I like Johnson's idea to have some template (perhaps OP_2-only, to preserve > > expected behaviour of OP_TRUE-only) that when combined with a 0-value is > > always valid only if spent in the same block.
I understand the issue. On Lightning side, if this rule is used, we would have the two options below:
1. Commitment transactions always use the minimum feerate, but always have the above OP_TRUE output. Then to confirm the commitment transaction we would have to always spend the OP_TRUE output in CPFP transaction that pays for actual fee at unilateral close. This consumes more blockchain space for unilateral closes, as the second transaction is always mandatory. 2. We store two commitment transactions and associated paraphernalia (further transactions to claim the HTLCs). One version has a negotiated feerate without the OP_TRUE output. The other version has a slightly increased feerate and an OP_TRUE output as above. At unilateral close, we see if the negotiated feerate is enough and use that version if possible, but if not we RBF it with other version and in addition also CPFP on top. As mentioned before, we do not have transaction packages, so we need to RBF with higher feerate the commitment transaction, then submit the CPFP transaction which makes the first transaction valid to include in a block as per the rule. This requires that the fallback always have both an RBF bump and a CPFP bump.
Quoted text (6 lines)
> >(Maybe it should be the first output > > instead of the last... Is there any legitimate reason one would have multiple > > such dummy outputs?)
It seems there are indeed none.
Regards, ZmnSCPxj
I fail to see what's the practical difference between sending to op_true and giving the coins are fees directly. Perhaps it is ao obvious to you that you forget to mention it? If you did I honestlt missed it.
On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (19 lines)
> Hi all, > > The largest problem we are having today with the lightning > protocol is trying to predict future fees. Eltoo solves this elegantly, > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > commitment transactions so that we use minimal fees and then use CPFP > (which can't be done at the moment due to CSV delays on outputs). > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > non-standard. Are there any reasons not to suggest such a policy > change? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
But in prnciple I don't oppose to making it stardard, just want to understand what's the point.
On Thu, 10 May 2018, 02:16 Jorge Timón, <jtimon@jtimon•cc> wrote:
Quoted text (28 lines)
> I fail to see what's the practical difference between sending to op_true > and giving the coins are fees directly. Perhaps it is ao obvious to you > that you forget to mention it? > If you did I honestlt missed it. > > On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >> Hi all, >> >> The largest problem we are having today with the lightning >> protocol is trying to predict future fees. Eltoo solves this elegantly, >> but meanwhile we would like to include a 546 satoshi OP_TRUE output in >> commitment transactions so that we use minimal fees and then use CPFP >> (which can't be done at the moment due to CSV delays on outputs). >> >> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is >> non-standard. Are there any reasons not to suggest such a policy >> change? >> >> Thanks! >> Rusty. >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists•linuxfoundation•org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> >
You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value UTXO in another transaction with a normal fee. The idea is that to get the latter fee, the miner needs to confirm the original tranaction with the 0-value OP_TRUE.
(Aside, in case it wasn't clear on my previous email, the template-script idea would not make it *mandatory* to spend in the same block, but that the UTXO would merely cease to be valid *after* that block. So the 0-value output does not take up a UTXO db entry when left unused.)
On Thursday 10 May 2018 09:33:29 Jorge Timón via bitcoin-dev wrote:
Quoted text (26 lines)
> I fail to see what's the practical difference between sending to op_true > and giving the coins are fees directly. Perhaps it is ao obvious to you > that you forget to mention it? > If you did I honestlt missed it. > > On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, < > > bitcoin-dev@lists•linuxfoundation•org> wrote: > > Hi all, > > > > The largest problem we are having today with the lightning > > protocol is trying to predict future fees. Eltoo solves this elegantly, > > but meanwhile we would like to include a 546 satoshi OP_TRUE output in > > commitment transactions so that we use minimal fees and then use CPFP > > (which can't be done at the moment due to CSV delays on outputs). > > > > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is > > non-standard. Are there any reasons not to suggest such a policy > > change? > > > > Thanks! > > Rusty. > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists•linuxfoundation•org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Good morning Luke and list,
Quoted text (8 lines)
> > (Aside, in case it wasn't clear on my previous email, the template-script idea > > would not make it mandatory to spend in the same block, but that the UTXO > > would merely cease to be valid after that block. So the 0-value output does > > not take up a UTXO db entry when left unused.)
Thank you for clearing this up. It seems, I misunderstood. So my earlier rumination, about having two options for Lightning, is incorrect.
For Lightning, we just need to add this 0-value OP_TRUE output always to transactions that require both side signatures (commitment, HTLC-timeout, HTLC-success), and it will always serve as a "hook" for adding more fees if needed.
Regards, ZmnSCPxj
Good morning Luke,
Quoted text (5 lines)
> (Maybe it should be the first output > > instead of the last... Is there any legitimate reason one would have multiple > > such dummy outputs?)
None, but how about use of `SIGHASH_SINGLE` flag? If a dummy output is added as the first, would it not require adjustment of the inputs of the transaction?
In context you are discussing the transaction serialization, though, so perhaps `SIGHASH_SINGLE`, is unaffected?
Regards, ZmnSCPxj
Luke Dashjr <luke@dashjr•org> writes:
Quoted text (17 lines)
> An OP_TRUE-only script with a low value seems like a good example of where the > weight doesn't reflect the true cost: it uses a UTXO forever, while only > costing a weight of 4. > > I like Johnson's idea to have some template (perhaps OP_2-only, to preserve > expected behaviour of OP_TRUE-only) that when combined with a 0-value is > always valid only if spent in the same block. > > I wonder if it would make sense to actually tie it to a transaction version > bit, such that when the bit is set, the transaction is serialised with +1 on > the output count and 00000000000000000181 is simply injected into the > transaction hashing... But for now, simply having a consensus rule that a bit > MUST be set for the expected behaviour, and the bit may ONLY be set when the > last output is exactly 00000000000000000181, would allow us to code the > transaction serialisation up later. (Maybe it should be the first output > instead of the last... Is there any legitimate reason one would have multiple > such dummy outputs?)
Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting, but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this at all (though others still might). It's nicer than the previous discussions on after-the-fact feebumping[1] though.
Meanwhile, our best mitigation against UTXO bloat is: 1. Make the fees as low as possible[2] 2. Put a CSV delay on the to-remote output (currently there's asymmetry) 3. Attach more value to the OP_TRUE output, say 1000 satoshi.
But turns out we probably don't want an OP_TRUE output nor P2SH, because then the spending tx would be malleable. So P2WSH is is.
This brings us another theoretical problem: someone could spend our OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to CPFP the tx. It'd be hard to do, but possible. I think the network benefits from using OP_TRUE (anyone can clean, and size, vs some only-known-to-me pubkey) outweighs the risk, but it'd be nice if OP_TRUE P2WSH spends were always considered RBF.
Thanks, Rusty. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-April/015864.html [2] Because bitcoin core use legacy measurements, this is actually 253 satoshi per kilosipa for us, see https://github.com/ElementsProject/lightning/commit/2e687b9b352c9092b5e8bd4a688916ac50b44af0
Good morning Rusty and list,
Quoted text (5 lines)
> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is interesting, > > but if we want a SF just give us SIGHASH_NOINPUT and we'll not need this > > at all (though others still might).
We might still want this in general in Lightning; for instance we could make every funding transaction include such an output. If it turns out, our initial feerate estimate for the funding transaction is low, we can use the `OP_TRUE` for fee-bumping. This is a win for Lightning since the funding transaction ID remains the same (even in Decker-Russell-Osuntokun, the trigger transaction is signed with `SIGHASH_ALL`, and refers to a fixed funding transaction ID).
Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a new different channel and RBF the old funding transaction with a new higher-feerate funding transaction, then keep track of which one gets confirmed deeply (there is a race where a miner discovers a block using the older funding transaction before our broadcast of the new funding transaction reaches it).
(we could also feebump using the change output of the funding transaction, but such a change output might not exist for all funding transactions.)
Regards, ZmnSCPxj
ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> writes:
Quoted text (28 lines)
> Good morning Rusty and list, > >> Your zero-val-OP_TRUE-can't-be-spent-after-same-block SF is >> interesting, >> >> but if we want a SF just give us SIGHASH_NOINPUT and we'll not need >> this >> >> at all (though others still might). > > We might still want this in general in Lightning; for instance we > could make every funding transaction include such an output. If it > turns out, our initial feerate estimate for the funding transaction is > low, we can use the `OP_TRUE` for fee-bumping. This is a win for > Lightning since the funding transaction ID remains the same (even in > Decker-Russell-Osuntokun, the trigger transaction is signed with > `SIGHASH_ALL`, and refers to a fixed funding transaction ID). > > Without the `OP_TRUE`-for-fee-bump, we would have to pretend to open a > new different channel and RBF the old funding transaction with a new > higher-feerate funding transaction, then keep track of which one gets > confirmed deeply (there is a race where a miner discovers a block > using the older funding transaction before our broadcast of the new > funding transaction reaches it). > > (we could also feebump using the change output of the funding > transaction, but such a change output might not exist for all funding > transactions.)
This would only really help in the case of the funding tx not having a change output, which I believe will be very rare. In the case of a change output we can simply do a CPFP which includes the change output.
Quoted text (8 lines)
> > This brings us another theoretical problem: someone could spend our > OP_TRUE with a low-fee non-RBF tx, and we'd not be able to use it to > CPFP the tx. It'd be hard to do, but possible. I think the network > benefits from using OP_TRUE (anyone can clean, and size, vs some > only-known-to-me pubkey) outweighs the risk, but it'd be nice if OP_TRUE > P2WSH spends were always considered RBF. >
I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF on the spending tx?
Jim Posen <jim.posen@gmail•com> writes:
Quoted text (2 lines)
> I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > on the spending tx?
Marco points out that if the parent is RBF, this child inherits it, so we're actually good here.
However, Matt Corallo points out that you can block RBF will a large-but-lowball tx, as BIP 125 points out:
will be replaced by a new transaction...:
3. The replacement transaction pays an absolute fee of at least the sum
paid by the original transactions.
I understand implementing a single mempool requires these kind of up-front decisions on which tx is "better", but I wonder about the consequences of dropping this heuristic? Peter?
Thanks! Rusty.
On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
Quoted text (18 lines)
> Jim Posen <jim.posen@gmail•com> writes: > > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF > > on the spending tx? > > Marco points out that if the parent is RBF, this child inherits it, so > we're actually good here. > > However, Matt Corallo points out that you can block RBF will a > large-but-lowball tx, as BIP 125 points out: > > will be replaced by a new transaction...: > > 3. The replacement transaction pays an absolute fee of at least the sum > paid by the original transactions. > > I understand implementing a single mempool requires these kind of > up-front decisions on which tx is "better", but I wonder about the > consequences of dropping this heuristic? Peter?
We've discussed this before: that rule prevents bandwidth usage DoS attacks on the mempool; it's not a "heuristic". If you drop it, an attacker can repeatedly broadcast and replace a series of transactions to use up tx relay bandwidth for significantly lower cost than otherwise.
Though these days with relatively high minimum fees that may not matter.
In the thread "Revisting BIP 125 RBF policy" @ https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015717.html and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-March/015797.html I propose replacing rule 3 with a rule that instead demands that the replacement package fee rate exceeds the package fee rate of the original transactions, and that there is an absolute fee bump of the particular transaction being replaced that covers the min-fee rate times the size of the mempool churn's data size.
Perhaps this would address your issue too Rusty.
On Sun, May 20, 2018 at 11:44 PM, Rusty Russell via bitcoin-dev < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (27 lines)
> Jim Posen <jim.posen@gmail•com> writes: > > I believe OP_CSV with a relative locktime of 0 could be used to enforce > RBF > > on the spending tx? > > Marco points out that if the parent is RBF, this child inherits it, so > we're actually good here. > > However, Matt Corallo points out that you can block RBF will a > large-but-lowball tx, as BIP 125 points out: > > will be replaced by a new transaction...: > > 3. The replacement transaction pays an absolute fee of at least the sum > paid by the original transactions. > > I understand implementing a single mempool requires these kind of > up-front decisions on which tx is "better", but I wonder about the > consequences of dropping this heuristic? Peter? > > Thanks! > Rusty. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
Peter Todd <pete@petertodd•org> writes:
Quoted text (26 lines)
> On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote: >> Jim Posen <jim.posen@gmail•com> writes: >> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF >> > on the spending tx? >> >> Marco points out that if the parent is RBF, this child inherits it, so >> we're actually good here. >> >> However, Matt Corallo points out that you can block RBF will a >> large-but-lowball tx, as BIP 125 points out: >> >> will be replaced by a new transaction...: >> >> 3. The replacement transaction pays an absolute fee of at least the sum >> paid by the original transactions. >> >> I understand implementing a single mempool requires these kind of >> up-front decisions on which tx is "better", but I wonder about the >> consequences of dropping this heuristic? Peter? > > We've discussed this before: that rule prevents bandwidth usage DoS attacks on > the mempool; it's not a "heuristic". If you drop it, an attacker can repeatedly > broadcast and replace a series of transactions to use up tx relay bandwidth for > significantly lower cost than otherwise. > > Though these days with relatively high minimum fees that may not matter.
AFAICT the optimal DoS is where:
1. Attacker sends a 100,000 vbyte tx @1sat/vbyte.
2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of
those inputs.
3. Replaces that spent input in the 100k tx and does it again.
It takes 3.5 seconds to propagate to 50% of network[1] (probably much worse given 100k txs), so they can only do this about 86 times per block.
That means they send 86 * (100000 + 108) = 8609288 vbytes for a cost of 86 * 2 * 108 + 100000 / 2 = 68576 satoshi (assuming 50% chance 100k tx gets mined).
That's a 125x cost over just sending 1sat/vbyte txs under optimal conditions[2], but it doesn't really reach most low-bandwidth nodes anyway.
Given that this rule is against miner incentives (assuming mempool is full), and makes things more complex than they need to be, I think there's a strong argument for its removal.
Cheers, Rusty. [1] http://bitcoinstats.com/network/propagation/ [2] Bandwidth overhead for just sending a 108-vbyte tx is about 160 bytes, so our actual bandwidth per satoshi is closer to 60x even under optimal conditions.
Rusty Russell <rusty@rustcorp•com•au> writes:
Quoted text (13 lines)
> AFAICT the optimal DoS is where: > > 1. Attacker sends a 100,000 vbyte tx @1sat/vbyte. > 2. Replaces it with a 108 vbyte tx @2sat/vbyte which spends one of > those inputs. > 3. Replaces that spent input in the 100k tx and does it again. > > It takes 3.5 seconds to propagate to 50% of network[1] (probably much worse > given 100k txs), so they can only do this about 86 times per block. > > That means they send 86 * (100000 + 108) = 8609288 vbytes for a cost of > 86 * 2 * 108 + 100000 / 2 = 68576 satoshi (assuming 50% chance 100k tx > gets mined).
This 50% chance assumption is wrong; it's almost 0% for a low enough fee. Thus the cost is only 18576, making the cost for the transactions 463x lower than just sending 1sat/vbyte txs under optimal conditions. That's a bit ouch.[1]
I think a better solution is to address the DoS potential directly: if a replacement doesn't meet #3 or #4, but *does* increase the feerate by at least minrelayfee, processing should be delayed by 30-60 seconds.
That means that eventually you will RBF a larger tx, but it'll take much longer. Should be easy to implement, too, since similar timers will be needed for dandelion.
Cheers,
Rusty.
[1] Christian grabbed some more detailed propagation stats for me: larger
txs do propagate slower, but only by a factor of 2.5 or so.