Nicolas Dorier [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-27 📝 Original message: > But B won't be able to ...
📅 Original date posted:2015-11-27
📝 Original message:
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
Did not thought about that, yes you are right.
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
Yes, I was worrying about B pro actively malleating everything.
But since A controls broadcast time, he can choose to delay the broadcast
when a vast malleability attack happens.
On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:
> > > A also passes the original unsigned commitment to B, who verifies that
> > > it's in the right format (ie, can be revoked), and hashes to the hash
> > > that he signed.
> > No, if A pass the unsigned commitment to B then B can malleate the
> anchor.
>
> Sorry, I meant the above needs to happen after the anchor's confirmed
> in the blockchain (and A's told B about the anchor).
>
> > > B can't reuse pubkeys between different channels with this protocol
> > > either, but that's good practice anyway.
> > Right, neither A should. If A reuse a key, then B can guess the redeem
> > hash, then would identify the transaction to malleate at broadcast time,
> > before A's announcement.
>
> B will be providing a signature for a tx that:
>
> - has the anchor as input
> - has a single refund output payable to
> (A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)
>
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
>
> > I'd prefer seggregated witness to fix the problem cleanly, but I think
> that
> > opening the channel as I said is a good enough workaround until it
> happen.
>
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/ea994660/attachment-0001.html>;
📝 Original message:
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
Did not thought about that, yes you are right.
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
Yes, I was worrying about B pro actively malleating everything.
But since A controls broadcast time, he can choose to delay the broadcast
when a vast malleability attack happens.
On Sat, Nov 28, 2015 at 5:11 AM, Anthony Towns <aj at erisian.com.au> wrote:
> On Sat, Nov 28, 2015 at 01:18:21AM +0900, Nicolas Dorier wrote:
> > > A also passes the original unsigned commitment to B, who verifies that
> > > it's in the right format (ie, can be revoked), and hashes to the hash
> > > that he signed.
> > No, if A pass the unsigned commitment to B then B can malleate the
> anchor.
>
> Sorry, I meant the above needs to happen after the anchor's confirmed
> in the blockchain (and A's told B about the anchor).
>
> > > B can't reuse pubkeys between different channels with this protocol
> > > either, but that's good practice anyway.
> > Right, neither A should. If A reuse a key, then B can guess the redeem
> > hash, then would identify the transaction to malleate at broadcast time,
> > before A's announcement.
>
> B will be providing a signature for a tx that:
>
> - has the anchor as input
> - has a single refund output payable to
> (A && OP_CSV) | (B && OP_HASH <revoke> OP_EQUALVERIFY)
>
> But B won't be able to guess what the <revoke> hash is, so won't be
> able to correlate with potential anchor transactions at all, afaics,
> even if pubkeys <A> and <B> are both known to B?
>
> > I'd prefer seggregated witness to fix the problem cleanly, but I think
> that
> > opening the channel as I said is a good enough workaround until it
> happen.
>
> Yeah, it's 99% of the way there; I just worry about random vandalism,
> personally.
>
> Cheers,
> aj
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151128/ea994660/attachment-0001.html>;