[bitcoin-dev] Making OP_TRUE standard?

[bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Olaoluwa Osuntokun]

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

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
>

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj]

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

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:

> 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

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

Olaoluwa Osuntokun <laolu32@gmail.com> writes:
> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Johnson Lau]

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Peter Todd]

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

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Making OP_TRUE standard?

[Johnson Lau]

> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Peter Todd]

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

On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:
> 
> 
> > 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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Making OP_TRUE standard?

[Olaoluwa Osuntokun]

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

> 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.

> 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:

> 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
>

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

Johnson Lau <jl2012@xbt.hk> writes:
> 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 :(

> 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.

> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Luke Dashjr]

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:
> 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

Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj]

Good morning Luke and list,


> 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.

> 
>(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

Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj]

Good morning Luke,

> (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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

Luke Dashjr <luke@dashjr.org> writes:
> 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

Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj]

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.)

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Making OP_TRUE standard?

[Christian Decker]

ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:

> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jim Posen]

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

>
> 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?

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Peter Todd]

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

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.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

Peter Todd <pete@petertodd.org> writes:
> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Rusty Russell]

Rusty Russell <rusty@rustcorp.com.au> writes:
> 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.

Re: [bitcoin-dev] Making OP_TRUE standard?

[Russell O'Connor]

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

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:

> 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
>

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón]

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

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
>

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón]

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

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:

> 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
>>
>

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Luke Dashjr]

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:
> 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

Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj]

Good morning Luke and list,


> 
> (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