<div dir="ltr"><div>Cool, I had not seen that, I&#39;ll take a look.  I&#39;m all for anything that allows reliable spends from unconfirmed txs.  If SW can get in easier, sounds good.<br><br></div>-Tadge<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Nov 19, 2015 at 11:38 AM, Matt Corallo <span dir="ltr">&lt;<a href="mailto:lf-lists@mattcorallo.com" target="_blank">lf-lists@mattcorallo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nope, Luke came up with a way to do it in a soft-fork.<span class=""><br>
<br>
On 11/19/15 19:12, Tadge Dryja wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
I&#39;ve joked that BIP62 is the &quot;whack-a-mole&quot; BIP in that it addresses<br>
many vectors for txid malleability, but maybe there are more.  And more<br>
importantly, it addresses 3rd party malleability.  It&#39;s not helpful in<br>
the context of lightning channel creation because ECDSA sigs are<br>
inherently malleable.  You can always re-sign the same message with a<br>
different k-value and get a different signature.<br>
<br>
The functionality that&#39;s needed is to be able to reliably spend from<br>
unconfirmed transactions.  Segregated witness can accomplish that, but<br>
it quite a large hard-fork change.  sighash_noinput can also accomplish<br>
that: as input txids are not signed, if they change, the spending<br>
transaction can be modified while leaving counterparty signatures intact.<br>
<br>
I&#39;m hoping to start a new &quot;testnet-L&quot; similar to testnet3, with this<br>
sighash type so that we can test malleability mitigation out.<br>
<br>
(Oh also, hi mailing list, sorry I have not posted till now!  But I will<br>
start posting!)<br>
<br>
-Tadge<br>
<br>
On Thu, Nov 19, 2015 at 9:56 AM, Mark Friedenbach &lt;<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a><br></span><span class="">
&lt;mailto:<a href="mailto:mark@friedenbach.org" target="_blank">mark@friedenbach.org</a>&gt;&gt; wrote:<br>
<br>
    The basic idea of the soft-fork plan is very simple --- have the<br>
    scriptPubKey be just the 20-byte hash of the redeem script. The<br>
    scriptSig of the spending input is empty. The actual scriptSig, with<br>
    the redeem script and signatures, is contained in a separate Merkle<br>
    tree committed to elsewhere in the block (e.g. in the last output of<br>
    the coinbase, or the last output of the last transaction).<br>
<br>
    On Thu, Nov 19, 2015 at 7:31 AM, Greg Sanders &lt;<a href="mailto:gsanders87@gmail.com" target="_blank">gsanders87@gmail.com</a><br></span><span class="">
    &lt;mailto:<a href="mailto:gsanders87@gmail.com" target="_blank">gsanders87@gmail.com</a>&gt;&gt; wrote:<br>
<br>
        The hardfork variant is quite simple, if I understood it<br>
        correctly. You just stick the signatures in another parallel<br>
        merkle tree. So if you don&#39;t want to validate signatures, just<br>
        don&#39;t download them, and validate everything else. TXIDs don&#39;t<br>
        use the signature at all. Nothing to malleate, AFAIK. Not sure<br>
        what the softfork plan is, but it will be a talk at Scaling<br>
        Bitcoin HK.<br>
<br>
        On Thu, Nov 19, 2015 at 10:28 AM, Glenn Tarbox, PhD<br></span><span class="">
        &lt;<a href="mailto:glenn@tarbox.org" target="_blank">glenn@tarbox.org</a> &lt;mailto:<a href="mailto:glenn@tarbox.org" target="_blank">glenn@tarbox.org</a>&gt;&gt; wrote:<br>
<br>
<br>
            On Thu, Nov 19, 2015 at 4:33 AM, <a href="mailto:sickpig@gmail.com" target="_blank">sickpig@gmail.com</a><br></span>
            &lt;mailto:<a href="mailto:sickpig@gmail.com" target="_blank">sickpig@gmail.com</a>&gt; &lt;<a href="mailto:sickpig@gmail.com" target="_blank">sickpig@gmail.com</a><span class=""><br>
            &lt;mailto:<a href="mailto:sickpig@gmail.com" target="_blank">sickpig@gmail.com</a>&gt;&gt; wrote:<br>
<br>
                Hi Pierre<br>
<br>
                you could start here<br>
<br>
                <a href="https://github.com/ElementsProject/elementsproject.github.io#segregated-witness" rel="noreferrer" target="_blank">https://github.com/ElementsProject/elementsproject.github.io#segregated-witness</a><br>
                <a href="https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf" rel="noreferrer" target="_blank">https://people.xiph.org/~greg/blockstream.gmaxwell.elements.talk.060815.pdf</a><br>
                <a href="https://github.com/ElementsProject/elements" rel="noreferrer" target="_blank">https://github.com/ElementsProject/elements</a><br>
<br>
<br>
            There was a brief blip on Reddit:<br>
<br>
            <a href="https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh" rel="noreferrer" target="_blank">https://www.reddit.com/r/Bitcoin/comments/3ngtx5/could_the_segregated_witness_part_of_the/cwnthlh</a><br>
<br>
            Its weird how little information there is on Segregated<br>
            Witness.  I&#39;m guessing its a simple concept and those<br>
            working on it (sipa / gmaxwell) haven&#39;t felt the need to<br>
            write it up.<br>
<br>
            That it &quot;apparently&quot; can be done with a soft fork similar to<br>
            P2SH is good news... I guess...<br>
<br>
<br>
            --<br>
            Glenn H. Tarbox, PhD<br>
              =]|[=<br>
<br>
            _______________________________________________<br>
            Lightning-dev mailing list<br>
            <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br></span>
            &lt;mailto:<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a>&gt;<span class=""><br>
            <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
<br>
        _______________________________________________<br>
        Lightning-dev mailing list<br>
        <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br></span>
        &lt;mailto:<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a>&gt;<span class=""><br>
        <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
<br>
    _______________________________________________<br>
    Lightning-dev mailing list<br>
    <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br></span>
    &lt;mailto:<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a>&gt;<span class=""><br>
    <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>