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 cr

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

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

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 f

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 th