Sorry if I missed the rationale earlier, but why not just do a transaction, with a FORKID specifically for this? Then a node can have a mempool acceptance test that returns true even if the signature is not valid as per Bitcoin consensus, but only due to the FORKID?

This way basically any wallet can support this provided generic FORKID support.

On Thu, Mar 15, 2018 at 8:38 PM, Karl Johan Alm via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Thu, Mar 15, 2018 at 2:14 PM, Luke Dashjr <luke@dashjr.org> wrote:
> Not necessarily specific UTXOs (that would contradict fungibility, as well as
> be impossible for hot/cold wallet separation), but just to prove funds are
> available. The current sign message cannot be used to prove present possession
> of funds, only that you receive funds.

By saying "not necessarily specific UTXOs", are you saying it may be
spent outputs? I'm a little confused I think.

On Thu, Mar 15, 2018 at 8:53 PM, Jim Posen <jim.posen@gmail.com> wrote:
> 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...

Good point!

>> 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.

I think the sighash flag affects the outcome of the actual
verification, but I could be mistaken.

-Kalle.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev