Re: [bitcoin-dev] BIP sighash_noinput

Oh, I missed that that's still the case with NOINPUT - thanks for pointing it out. In that case there's no reason to sign the other inputs' sequence and that's even better because the current NOINPUT proposal already enables taprootifiability of eltoo unilateral closings. On 9/26/18 7:45 PM,

Re: [bitcoin-dev] BIP sighash_noinput

In BIP143, the nSequence of the same input is always signed, with any hashtype. Why do you need to sign the sequence of other inputs? > On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev > wrote: > >> At the risk of bikeshedding, shouldn't NOINPUT also zero out the >> hashSequence so that

Re: [bitcoin-dev] BIP sighash_noinput

> At the risk of bikeshedding, shouldn't NOINPUT also zero out the > hashSequence so that its behaviour is consistent with ANYONECANPAY? There is a good reason for not doing that. If NOINPUT would sign the hashSequence then it would be possible to get rid of OP_CSV in eltoo update scripts. As a

Re: [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote: > On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote: > > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing > > about what the flag actually does. > > I believe that making the signature replayable is 1:1

Re: [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd wrote: > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing > about what the flag actually does. I believe that making the signature replayable is 1:1 with omitting the identification of the specific coin being spent from it.

Re: [bitcoin-dev] BIP sighash_noinput

Gregory Maxwell writes: > I know it seems kind of silly, but I think it's somewhat important > that the formal name of this flag is something like > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least > "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially > insecure for traditional

Re: [bitcoin-dev] BIP sighash_noinput

On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote: > Gregory Maxwell via bitcoin-dev > writes: > > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > > wrote: > >> Hi all, > >> > >> I'd like to pick up the discussion from a few months ago, and

Re: [bitcoin-dev] BIP sighash_noinput

Gregory Maxwell via bitcoin-dev writes: > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev > wrote: >> Hi all, >> >> I'd like to pick up the discussion from a few months ago, and propose a new >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous > > I

Re: [bitcoin-dev] BIP sighash_noinput

On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev wrote: > Hi all, > > I'd like to pick up the discussion from a few months ago, and propose a new > sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous I know it seems kind of silly, but I think it's

Re: [bitcoin-dev] BIP sighash_noinput

Olaoluwa Osuntokun writes: > Super stoked to see that no_input has been resurrected!!! I actually > implemented a variant back in 2015 when Tadge first described the > approach to me for both btcd [1], and bitcoind [2]. The version being > proposed is _slightly_ differ though,

Re: [bitcoin-dev] BIP sighash_noinput

Anthony Towns via bitcoin-dev writes: > 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

Re: [bitcoin-dev] BIP sighash_noinput

> 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. The typical address re-use doesn't apply here as this is a sighash flag that

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

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

Re: [bitcoin-dev] BIP sighash_noinput

Super stoked to see that no_input has been resurrected!!! I actually implemented a variant back in 2015 when Tadge first described the approach to me for both btcd [1], and bitcoind [2]. The version being proposed is _slightly_ differ though, as the initial version I implemented still committed to

Re: [bitcoin-dev] BIP sighash_noinput

Good morning Christian, > ZmnSCPxj zmnsc...@protonmail.com writes: > > > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol > > > > integrate better with existing wallets. > > Depends on which end of a transaction the existing wallet is: existing > > wallets will refuse to

Re: [bitcoin-dev] BIP sighash_noinput

ZmnSCPxj writes: > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol > integrate better with existing wallets. Depends on which end of a transaction the existing wallet is: existing wallets will refuse to sign a transaction with an unknown sighash flag,

Re: [bitcoin-dev] BIP sighash_noinput

Russell O'Connor writes: > At the risk of bikeshedding, shouldn't NOINPUT also zero out the > hashSequence so that its behaviour is consistent with ANYONECANPAY? Good catch, must've missed that somehow. I'll amend the BIP accordingly.

Re: [bitcoin-dev] BIP sighash_noinput

At the risk of bikeshedding, shouldn't NOINPUT also zero out the hashSequence so that its behaviour is consistent with ANYONECANPAY? On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi all, > > I'd like to pick up the discussion

Re: [bitcoin-dev] BIP sighash_noinput

Something like this might also be useful for several use cases related to RBF. For example: Alice sends Bob an RBF-activated transaction T1 with the intention of bumping its fee if necessary. Bob wants to send these funds to Carol, but cannot wait until T1 confirms, so he crafts a transaction T2