Re: [bitcoin-dev] BIP sighash_noinput
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] Making OP_TRUE standard?
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?
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] BIP sighash_noinput
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] Making OP_TRUE standard?
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
