<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">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</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 &lt;<a href="mailto:kalle@rosenbaum.se">kalle@rosenbaum.se</a>&gt; wrote:<br>
&gt; I can&#39;t really see from your proposal if you had thought of this: A soft<br>
&gt; fork can make old nodes accept invalid message signatures as valid. For<br>
&gt; example, a &quot;signer&quot; can use a witness version unknown to the verifier to<br>
&gt; fool the verifier. Witness version is detectable (just reject unknown<br>
&gt; witness versions)  but there may be more subtle changes. Segwit was not<br>
&gt; &quot;detectable&quot; in that way, for example.<br>
&gt;<br>
&gt; This is the reason why I withdrew BIP120. If you have thought about the<br>
&gt; above, I&#39;d be very interested.<br>
<br>
</span>I&#39;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 &gt; 0 and a to<br>
me unknown pubkey and then fool you into thinking I own it, but I<br>
don&#39;t really see why you&#39;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&#39;m not sure it&#39;s a big issue. And it doesn&#39;t<br>
really require an old node. I just need to set witness version &gt;<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 &lt;<a href="mailto:luke@dashjr.org">luke@dashjr.org</a>&gt; wrote:<br>
&gt; I don&#39;t see a need for a new RPC interface, just a new signature format.<br>
<br>
</span>All right.<br>
<span class=""><br>
&gt; Ideally, it should support not only just &quot;proof I receive at this address&quot;,<br>
&gt; but also &quot;proof of funds&quot; (as a separate feature) since this is a popular<br>
&gt; misuse of the current message signing (which doesn&#39;t actually prove funds at<br>
&gt; 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&#39;d be enough?<br>
<span class=""><br>
&gt; Preferably, it should also avoid disclosing the public key for existing or<br>
&gt; future UTXOs. But I don&#39;t think it&#39;s possible to avoid this without something<br>
&gt; MAST-like first. Perhaps it can be a MAST upgrade later on, but the new<br>
&gt; signature scheme should probably be designed with it in mind.<br>
<br>
</span>I&#39;d love to not have to reveal the public key, but I&#39;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 &lt;<a href="mailto:aj@erisian.com.au">aj@erisian.com.au</a>&gt; wrote:<br>
&gt; Wouldn&#39;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>