MIME-Version: 1.0
In-Reply-To: <201803151414.06301.luke@dashjr.org>
References: <CALJw2w5=g-FL+MZ08DEoLxVzOKbSXeKu50drE1b4P0JZJpdTyA@mail.gmail.com>
	<201803141236.48869.luke@dashjr.org>
	<CALJw2w5NQ=WX1Cm4aUXMN=uxn8NLHAfYDLEtqUptce5DCWZXWA@mail.gmail.com>
	<201803151414.06301.luke@dashjr.org>
From: Karl Johan Alm <karljohan-alm@garage.co.jp>
Date: Fri, 16 Mar 2018 00:38:06 +0000
Message-ID: <CALJw2w49bsBNFBj3MvdzNL+Hu3zuq-dmrTv_6wgmO_ZaCXt1nA@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>
Content-Type: text/plain; charset="UTF-8"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] {sign|verify}message replacement
Precedence: list

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.