ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-05-02 📝 Original message: Good morning Christian, > ...
📅 Original date posted:2018-05-02
📝 Original message:
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
📝 Original message:
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