[bitcoin-dev] Making OP_TRUE standard?

2018-05-08 Thread Rusty Russell via bitcoin-dev
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?

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


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

2018-05-08 Thread Bram Cohen via bitcoin-dev
A technical point about SIGHASH_NOINPUT: It seems like a more general and
technically simpler to implement idea would be to have a boolean specifying
whether the inputs listed must be all of them (the way it works normally)
or a subset of everything. It feels like a similar boolean should be made
for outputs as well. Or maybe a single boolean should apply to both. In any
case, one could always use SIGHASH_SUBSET and not specify any inputs and
that would have the same effect as SIGHASH_NOINPUT.

On Mon, May 7, 2018 at 12:40 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Given the general enthusiasm, and lack of major criticism, for the
> `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent
> BIP editors) to be assigned a BIP number. I have hacked together a
> simple implementation of the hashing implementation in Bitcoin Core [1]
> though I think it's unlikely to sail through review, and given the lack
> of ground-work on witness V1 scripts, I can't really test it now, and
> only the second commit is part of the implementation itself.
>
> One issue that was raised off list was that some fork coins have used
> sighash 0x40 as FORKID. This does not conflict with this proposal since
> the proposal only applies to segwit transactions, which the fork coins
> have explicitly disabled :-)
>
> I'm looking forward to discussing how to we can move forward to
> implementing this proposal, and how we can combine multiple proposals
> into the next soft-fork.
>
> Cheers,
> Christian
>
> [1] https://github.com/cdecker/bitcoin/tree/noinput
> ___
> 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] BIP sighash_noinput

2018-05-08 Thread Anthony Towns via bitcoin-dev
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