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

2018-11-24 Thread Russell O'Connor via bitcoin-dev
On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns wrote: > On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > Given that we want to move away from OP_CODESEPARATOR, because each call > to > > this operation effectively takes O(script-size) time, we need a > repla

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

2018-11-24 Thread Johnson Lau via bitcoin-dev
>Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires >recomputing a new #5. scriptCode from BIP 143, and hence computes a new >transaction digest. In the existing sighash (i.e. legacy and BIP143), there are 6 canonical SIGHASH types: 1, 2, 3, 0x81, 0x82, 0x83. In consensus, ho

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

2018-11-24 Thread Christian Decker via bitcoin-dev
Anthony Towns writes: > Commiting to just the sequence numbers seems really weird to me; it > only really prevents you from adding inputs, since you could still > replace any input that was meant to be there by almost any arbitrary > other transaction... It's a really roundabout way of committing

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

2018-11-24 Thread Anthony Towns via bitcoin-dev
On Wed, Nov 21, 2018 at 12:15:44PM +0100, Christian Decker via bitcoin-dev wrote: > One minor thing that I noticed a while ago and that I meant > to fix on BIP118 is that `hashSequence` does not need to be blanked for > eltoo to work (since where it is needed we also use `sighash_single`), > so I'