Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-31 Thread Rusty Russell via bitcoin-dev
Rusty Russell  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 * (10 + 108) = 8609288 vbytes for a cost of
> 86 * 2 * 108 + 10 / 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-29 Thread Rusty Russell via bitcoin-dev
Peter Todd  writes:
> On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
>> Jim Posen  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 * (10 + 108) = 8609288 vbytes for a cost of
86 * 2 * 108 + 10 / 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-21 Thread Russell O'Connor via bitcoin-dev
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  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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-20 Thread Peter Todd via bitcoin-dev
On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
> Jim Posen  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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-20 Thread Rusty Russell via bitcoin-dev
Jim Posen  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


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-17 Thread Jim Posen via bitcoin-dev
>
> 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?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-17 Thread Christian Decker via bitcoin-dev
ZmnSCPxj via bitcoin-dev  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-17 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-14 Thread ZmnSCPxj via bitcoin-dev
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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-10 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-10 Thread Luke Dashjr via 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:
> 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-10 Thread Jorge Timón via 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,  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
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-10 Thread Jorge Timón via bitcoin-dev
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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread ZmnSCPxj via bitcoin-dev
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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Luke Dashjr via bitcoin-dev
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 0181 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 0181, 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Rusty Russell via bitcoin-dev
Johnson Lau  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Rusty Russell via bitcoin-dev
Olaoluwa Osuntokun  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Olaoluwa Osuntokun via bitcoin-dev
> 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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Peter Todd via bitcoin-dev
On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:
> 
> 
> > On 10 May 2018, at 3:27 AM, Peter Todd  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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Johnson Lau via bitcoin-dev


> On 10 May 2018, at 3:27 AM, Peter Todd  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Peter Todd via bitcoin-dev
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


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-09 Thread Johnson Lau via 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.



> On 9 May 2018, at 7:57 AM, 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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-08 Thread ZmnSCPxj via 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 
 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 
>  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


Re: [bitcoin-dev] Making OP_TRUE standard?

2018-05-08 Thread Olaoluwa Osuntokun via bitcoin-dev
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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev