Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: >> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev >> wrote: >> >> Anthony Towns via bitcoin-dev writes: >>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev >>> wrote: And is it worthwhile doing the mask complexity, rather than just

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Rusty Russell via bitcoin-dev
Johnson Lau writes: > I don’t think this has been mentioned: without signing the script or masked > script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT. > > In the new sighash proposal, we will sign the hash of the full script (or > masked script), without any truncation. To make

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2018-12-19 Thread Johnson Lau via bitcoin-dev
> On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev > wrote: > > > >> On 17 Dec 2018, at 11:48 PM, Ruben Somsen > > wrote: >> >> Hi Johnson, >> >> The design considerations here seem similar to the ML discussion of >> whether Graftroot should be optional

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Johnson Lau via bitcoin-dev
> On 18 Dec 2018, at 12:58 PM, Anthony Towns wrote: > > On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote: >> On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau wrote: >>But I’m not sure if that would do more harm than good. For example, people >>might lose money by copying an

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Peter Todd via bitcoin-dev
On Tue, Dec 18, 2018 at 03:08:26AM +0800, Johnson Lau via bitcoin-dev wrote: > >> If it's not safer in practice, we've spent a little extra complexity > >> committing to a subset of the script in each signature to no gain. If > >> it is safer in practice, we've prevented people from losing funds.

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Anthony Towns via bitcoin-dev
On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote: > On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau wrote: > But I’m not sure if that would do more harm than good. For example, people > might lose money by copying an existing script template. But they might > also lose

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Russell O'Connor via bitcoin-dev
On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau wrote: > > I proposed the same in BIP114. I wish Satoshi had designed that way. > Thanks. I probably read that and internalized it and forgot you wrote it. > But I’m not sure if that would do more harm than good. For example, people > might lose

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Johnson Lau via bitcoin-dev
> On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev > wrote: > > On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev > > wrote: > 5. if there's exactly one, non-zero item on the stack; succeed > > Unless it is too

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2018-12-19 Thread Johnson Lau via bitcoin-dev
> On 17 Dec 2018, at 11:48 PM, Ruben Somsen wrote: > > Hi Johnson, > > The design considerations here seem similar to the ML discussion of > whether Graftroot should be optional [1]. Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Johnson Lau via bitcoin-dev
> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev > wrote: > > Anthony Towns via bitcoin-dev writes: >> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev >> wrote: >>> And is it worthwhile doing the mask complexity, rather than just >>> removing the

Re: [bitcoin-dev] Safer NOINPUT with output tagging

2018-12-19 Thread Ruben Somsen via bitcoin-dev
Hi Johnson, The design considerations here seem similar to the ML discussion of whether Graftroot should be optional [1]. >While this seems fully compatible with eltoo, is there any other proposals >require NOINPUT, and is adversely affected by either way of tagging? As far as I can tell it

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Rusty Russell via bitcoin-dev
Anthony Towns via bitcoin-dev writes: > On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote: >> And is it worthwhile doing the mask complexity, rather than just >> removing the commitment to script with NOINPUT? It *feels* safer to >> restrict what scripts we can sign,

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

2018-12-19 Thread Russell O'Connor via bitcoin-dev
On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 5. if there's exactly one, non-zero item on the stack; succeed > Unless it is too much bikeshedding, I'd like to propose that to succeed the stack must be exactly empty. Script

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-12-19 Thread Johnson Lau via bitcoin-dev
I don’t think this has been mentioned: without signing the script or masked script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT. In the new sighash proposal, we will sign the hash of the full script (or masked script), without any truncation. To make OP_CODESEPARATOR works like