<div dir="ltr">I like this proposal, it seems sufficiently general.<div><br></div><div>How are scripts with OP_CLTV and OP_CSV handled by verifiers? Do they always succeed? Or should an nLockTime and nSequence also be included in the proof in a way that can be parsed out and displayed to verifiers?</div><div><br></div><div>I assume any signatures in the scriptSig/witness data would have no sighash type?</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 14, 2018 at 8:01 PM, Karl Johan Alm via bitcoin-dev <span dir="ltr"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Mar 14, 2018 at 5:46 AM, Kalle Rosenbaum <<a href="mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>> wrote:<br>
> I can't really see from your proposal if you had thought of this: A soft<br>
> fork can make old nodes accept invalid message signatures as valid. For<br>
> example, a "signer" can use a witness version unknown to the verifier to<br>
> fool the verifier. Witness version is detectable (just reject unknown<br>
> witness versions) but there may be more subtle changes. Segwit was not<br>
> "detectable" in that way, for example.<br>
><br>
> This is the reason why I withdrew BIP120. If you have thought about the<br>
> above, I'd be very interested.<br>
<br>
</span>I'm not sure I see the problem. The scriptPubKey is derived directly<br>
from the address in all cases, which means the unknown witness version<br>
would have to be committed to in the address itself.<br>
<br>
So yeah, I can make a P2SH address with a witness version > 0 and a to<br>
me unknown pubkey and then fool you into thinking I own it, but I<br>
don't really see why you'd ultimately care. In other words, if I can<br>
SPEND funds sent to that address today, I can prove that I can spend<br>
today, which is the purpose of the tool, I think.<br>
<br>
For the case where the witness version HAS been upgraded, the above<br>
still applies, but I'm not sure it's a big issue. And it doesn't<br>
really require an old node. I just need to set witness version ><br>
current witness version and the problem applies to all nodes.<br>
<span class=""><br>
On Wed, Mar 14, 2018 at 8:36 AM, Luke Dashjr <<a href="mailto:luke@dashjr.org">luke@dashjr.org</a>> wrote:<br>
> I don't see a need for a new RPC interface, just a new signature format.<br>
<br>
</span>All right.<br>
<span class=""><br>
> Ideally, it should support not only just "proof I receive at this address",<br>
> but also "proof of funds" (as a separate feature) since this is a popular<br>
> misuse of the current message signing (which doesn't actually prove funds at<br>
> all). To do this, it needs to be capable of signing for multiple inputs.<br>
<br>
</span>I assume by inputs you mean addresses/keys. The address field could<br>
optionally be an array. That'd be enough?<br>
<span class=""><br>
> Preferably, it should also avoid disclosing the public key for existing or<br>
> future UTXOs. But I don't think it's possible to avoid this without something<br>
> MAST-like first. Perhaps it can be a MAST upgrade later on, but the new<br>
> signature scheme should probably be designed with it in mind.<br>
<br>
</span>I'd love to not have to reveal the public key, but I'm not sure how it<br>
would be done, even with MAST.<br>
<span class=""><br>
On Wed, Mar 14, 2018 at 12:12 PM, Anthony Towns <<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>> wrote:<br>
> Wouldn't it be sufficient for old nodes to check for standardness of the spending script and report non-standard scripts as either invalid outright, or at least highly questionable? That should prevent confusion as long as soft forks are only making nonstandard behaviours invalid.<br>
<br>
</span>That seems sensible to me. A warning would probably be useful, in case<br>
the verifier is running old software.<br>
<br>
-Kalle.<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>