<div dir="ltr"><div>> But B won't be able to guess what the <revoke> hash is, so won't be</div><div>> able to correlate with potential anchor transactions at all, afaics,</div><div>> even if pubkeys <A> and <B> are both known to B?</div><div><br></div><div>Did not thought about that, yes you are right.</div><div><br></div><div><div>> Yeah, it's 99% of the way there; I just worry about random vandalism,</div><div>> personally.</div></div><div><br></div><div>Yes, I was worrying about B pro actively malleating everything.</div><div>But since A controls broadcast time, he can choose to delay the broadcast when a vast malleability attack happens.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns <span dir="ltr"><<a href="mailto:aj@erisian.com.au" target="_blank">aj@erisian.com.au</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 Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:<br>
> > A also passes the original unsigned commitment to B, who verifies that<br>
> > it's in the right format (ie, can be revoked), and hashes to the hash<br>
> > that he signed.<br>
> No, if A pass the unsigned commitment to B then B can malleate the anchor.<br>
<br>
</span>Sorry, I meant the above needs to happen after the anchor's confirmed<br>
in the blockchain (and A's told B about the anchor).<br>
<span class=""><br>
> > B can't reuse pubkeys between different channels with this protocol<br>
> > either, but that's good practice anyway.<br>
> Right, neither A should. If A reuse a key, then B can guess the redeem<br>
> hash, then would identify the transaction to malleate at broadcast time,<br>
> before A's announcement.<br>
<br>
</span>B will be providing a signature for a tx that:<br>
<br>
- has the anchor as input<br>
- has a single refund output payable to<br>
(A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)<br>
<br>
But B won't be able to guess what the <revoke> hash is, so won't be<br>
able to correlate with potential anchor transactions at all, afaics,<br>
even if pubkeys <A> and <B> are both known to B?<br>
<span class=""><br>
> I'd prefer seggregated witness to fix the problem cleanly, but I think that<br>
> opening the channel as I said is a good enough workaround until it happen.<br>
<br>
</span>Yeah, it's 99% of the way there; I just worry about random vandalism,<br>
personally.<br>
<br>
Cheers,<br>
aj<br>
<br>
</blockquote></div><br></div>