Good morning Christian,

> > > Hi Christian,
> > > 
> > > Let me know if I have summarized the paper accurately below:
> > > 
> > > 1.  SIGHASH_NOINPUT removes all inputs of the transaction copy before
> > >     
> > >     signing/verifying.
> > >     
> > 
> > It sets them to a known constant, in this case we just blank
> > 
> > them. Removing could entail more costly serialization depending on the
> > 
> > implementation. bitcoind serializes into a hash accumulator so it'd not
> > 
> > make a difference there, but others may do it differently.
> Does this then mean that if the transaction has two inputs, we are still 
> committing to the fact that there are two inputs? If so, it is probably 
> useable together with SIGHASH_ANYONECANPAY.
> In fact, it seems, if we are using this to provide additional fees to update 
> transactions, we should also use SIGHASH_ANYONECANPAY on the update UTXO path 
> so that we can add new inputs to the transaction that will pay for the fee.

Ha, no, looking at the detailed `SIGHASH_NOINPUT` spec, `hashPrevouts`, which 
normally commits to the other inputs, is blanked, so we do not commit to them 
either.  This means that `SIGHASH_NOINPUT` implicitly has a 

(the BIP `SIGHASH_NOINPUT` in the eltoo pdf does not mention `hashSequence`, 
but it seems you managed to add that to your github BIP repository)

Lightning-dev mailing list

Reply via email to