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 `SIGHASH_ANYONECANPAY`. (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) Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
