Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-09-03 Thread Christian Decker via bitcoin-dev
Johnson Lau writes: > Great, I’ll revise it. > > Follow-up questions: > > 1. Is there any useful case which one would like to use NOINPUT with > scriptCode and/or scriptPubKey committed? (Note that with > taproot/MAST, scriptCode and scriptPubKey are not > interchangeable. scriptPubKey commits to

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-08-31 Thread Johnson Lau via bitcoin-dev
Great, I’ll revise it. Follow-up questions: 1. Is there any useful case which one would like to use NOINPUT with scriptCode and/or scriptPubKey committed? (Note that with taproot/MAST, scriptCode and scriptPubKey are not interchangeable. scriptPubKey commits to all branches, and scriptCode is

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-08-30 Thread Christian Decker via bitcoin-dev
Thanks for the update Johnson, just wanted to give a really quick NACK on the SIGHASH_NOINPUT variant: the whole idea of BIP 118 is to have floating transactions that can be bound to predecessors, and still enforce some application logic. In eltoo's case this is the fact that the state number needs

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-08-30 Thread Johnson Lau via bitcoin-dev
After gathering some feedbacks I substantially revised the proposal. This version focus on improving security, and reduces the number of optional features. Formatted BIP and sample code at: https://github.com/jl2012/bips/blob/sighash2/bip-sighash2.mediawiki https://github.com/jl2012/bitcoin/comm

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-07-02 Thread Gregory Maxwell via bitcoin-dev
On Thu, May 31, 2018 at 6:35 PM, Johnson Lau via bitcoin-dev wrote: > The bit 0 to 3 of hashtype denotes a value between 0 and 15: > > • If the value is 1, the signature is invalid. > • If the value is 3 or below, hashPrevouts is the hash of all input, > same as defined in BIP143.

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Johnson Lau via bitcoin-dev
> On 2 Jun 2018, at 2:15 AM, Russell O'Connor wrote: > > > I prefer a different opcode for CHECKSIGFROMSTACK because I dislike opcodes > that pop a non-static number of elements off the stack. Popping a dynamic > number of stack elements makes it more difficult to validate that a Script >

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Russell O'Connor via bitcoin-dev
On Fri, Jun 1, 2018 at 1:03 PM, Johnson Lau wrote: > On 1 Jun 2018, at 11:03 PM, Russell O'Connor > wrote: > On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> Double SHA256 of the serialization of: >> > > Should we replace th

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Johnson Lau via bitcoin-dev
> On 1 Jun 2018, at 11:03 PM, Russell O'Connor wrote: > > > > On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev > > wrote: > > Double SHA256 of the serialization of: > > Should we replace the Double SHA256 with a Single SHA256? T

Re: [bitcoin-dev] SIGHASH2 for version 1 witness programme

2018-06-01 Thread Russell O'Connor via bitcoin-dev
On Thu, May 31, 2018 at 2:35 PM, Johnson Lau via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Double SHA256 of the serialization of: > Should we replace the Double SHA256 with a Single SHA256? There is no possible length extension attack here. Or are we speculating that the