Re: [bitcoin-dev] Making OP_TRUE standard?

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

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

[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] BIP sighash_noinput

[Rusty Russell via bitcoin-dev]

Anthony Towns via bitcoin-dev  writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev 
> wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.

If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.

> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.

That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.

That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.

> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.

In a world where SIGHASH_NONE didn't exist, this might be an argument :)

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?

[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

[bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[Segue via bitcoin-dev]

On 3/17/18, someone posted on the Lightning-dev list, "Can I try 
Lightning without running a fully-fledged bitcoin block chain? (Yubin 
Ruan)."  The inquirer was asking because he didn't have much space to 
store the entire blockchain on his laptop.


I replied:

"Developers,

On THIS note and slightly off-topic but relevant, why can't chunks of 
blockchain peel off the backend periodically and be archived, say on 
minimum of 150 computers across 7 continents?


It seems crazy to continue adding on to an increasingly long chain to 
infinity if the old chapters (i.e. more than, say, 2 years old) could be 
stored in an evenly distributed manner across the planet. The same 150 
computers would not need to store every chapter either, just the index 
would need to be widely distributed in order to reconnect with a chapter 
if needed. Then maybe it is no longer a limitation in the future for 
people like Yubin. "


It was suggested by a couple of lightning developers that I post this 
idea on the bitcoin-dev list.  So, here I post :).


Segue




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

Re: [bitcoin-dev] BIP sighash_noinput

[Olaoluwa Osuntokun via bitcoin-dev]

> The current proposal kind-of limits the potential damage by still
committing
> to the prevout amount, but it still seems a big risk for all the people
that
> reuse addresses, which seems to be just about everyone.

The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.

IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.

-- Laolu


On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
> > Given the general enthusiasm, and lack of major criticism, for the
> > `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
>
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> ___
> 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?

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

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

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

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

[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