Jim Posen [ARCHIVE] on Nostr: ๐ Original date posted:2018-03-15 ๐ Original message:> > Good question.. Since ...
๐
Original date posted:2018-03-15
๐ Original message:>
> Good question.. Since you don't really have the input(s), I think it's
> fine to always assume sufficient time/height on CLTV/CSV checks.
>
In this general signing-a-script context, I think a verifier might want to
see the time conditions under which it may be spent. The proof container
could include an optional nLockTime which defaults to 0 and nSequence which
defaults to 0xFFFF...
> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> Is there a good reason to tweak it?
>
I took another look and there should definitely be a byte appended to the
end of the sig so that the encoding checks pass, but I think it might as
well be a 0x00 byte since it's not actually a sighash flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180315/6046c7a8/attachment.html>
๐ Original message:>
> Good question.. Since you don't really have the input(s), I think it's
> fine to always assume sufficient time/height on CLTV/CSV checks.
>
In this general signing-a-script context, I think a verifier might want to
see the time conditions under which it may be spent. The proof container
could include an optional nLockTime which defaults to 0 and nSequence which
defaults to 0xFFFF...
> I think it would just use the default (SIGHASH_ALL?) for simplicity.
> Is there a good reason to tweak it?
>
I took another look and there should definitely be a byte appended to the
end of the sig so that the encoding checks pass, but I think it might as
well be a 0x00 byte since it's not actually a sighash flag.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180315/6046c7a8/attachment.html>