Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-16 📝 Original message: Hi ZmnSCPxj, > It seems ...
📅 Original date posted:2018-04-16
📝 Original message:
Hi ZmnSCPxj,
> It seems to me, that the only safe way to implement a trustless
WatchTower,
> is for the node to generate a fully-signed justice transaction,
IMMEDIATELY
> after every commitment transaction is revoked, and transmit it to the
> WatchTower.
No, one doesn't need to transmit the entire justice transaction. Instead,
the client simply sends out the latest items in the script template, and a
series of _signatures_ for the various breach outputs. The pre-generated
signature means that the server is *forced* to reproduce the justice
transaction that satisfies the latest template and signature. Upfront, free
parameters such as breach bonus (or w/e else) can be negotiated.
> The WatchTower would have to store each and every justice transaction it
> received, and would not be able to compress it or use various techniques
to
> store data efficiently.
In our current implementation, we've abandoned the "savings" from
compressing the shachain/elkrem tree. When one factors in the space
complexity due the *just* the commitment signatures, the savings from
compression become less attractive. Going a step father, once you factor in
the space complexity of the 2-stage HTLC claims, then the savings from
compressing the revocation tree become insignificant.
It's also worth pointing out that if the server is able to compress the
revocation tree, then their necessarily linking new breach payloads with a
particular channel. Another downside, is that if you go to revocation tree
compression, then all updates *must* be sent in order, and updates cannot be
*skipped*.
As a result of these downside, our current implementation goes back to the
ol' "encrypted blob" approach. One immediate benefit with this approach is
that the outsourcing protocol isn't so coupled with the current _commitment
protocol_. Instead, the internal payload can be typed, allowing the server
to dispatch the proper breach protocol based on the commitment type. The
blob approach can also support a "swap" protocol which is required for
commitment designs that allow for O(1) outsourcer state per-client, like the
scheme I presented at the last Scaling Bitcoin.
-- Laolu
On Sun, Apr 15, 2018 at 8:32 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Nicolas Dorier was requesting additional hooks in c-lightning for a simple
> WatchTower system:
> https://github.com/ElementsProject/lightning/issues/1353
>
> Unfortunately I was only able to provide an interface which requires a
> *trusted* WatchTower. Trust is of course a five-letter word and should not
> be used in polite company.
>
> My key problem is that I provide enough information to the WatchTower for
> the WatchTower to be able to create the justice transaction by itself. If
> so, the WatchTower could just make the justice transaction output to itself
> and the counterparty, so that the WatchTower and the counterparty can
> cooperate to steal the channel funds: the counterparty publishes a revoked
> transaction, the WatchTower writes a justice transaction on it that splits
> the earnings between itself and the counterparty.
>
> It seems to me, that the only safe way to implement a trustless
> WatchTower, is for the node to generate a fully-signed justice transaction,
> IMMEDIATELY after every commitment transaction is revoked, and transmit it
> to the WatchTower. The WatchTower would have to store each and every
> justice transaction it received, and would not be able to compress it or
> use various techniques to store data efficiently. The WatchTower would not
> have enough information to regenerate justice transactions (and in
> particular would not be able to create a travesty-of-justice transaction
> that pays out to itself rather than the protected party). In practice this
> would require that node software also keep around those transactions until
> some process has ensured that the WatchTower has received the justice
> transactions.
>
> Is there a good way to make trustless WatchTowers currently or did this
> simply not reach BOLT v1.0?
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180416/ed660fae/attachment-0001.html>;
📝 Original message:
Hi ZmnSCPxj,
> It seems to me, that the only safe way to implement a trustless
WatchTower,
> is for the node to generate a fully-signed justice transaction,
IMMEDIATELY
> after every commitment transaction is revoked, and transmit it to the
> WatchTower.
No, one doesn't need to transmit the entire justice transaction. Instead,
the client simply sends out the latest items in the script template, and a
series of _signatures_ for the various breach outputs. The pre-generated
signature means that the server is *forced* to reproduce the justice
transaction that satisfies the latest template and signature. Upfront, free
parameters such as breach bonus (or w/e else) can be negotiated.
> The WatchTower would have to store each and every justice transaction it
> received, and would not be able to compress it or use various techniques
to
> store data efficiently.
In our current implementation, we've abandoned the "savings" from
compressing the shachain/elkrem tree. When one factors in the space
complexity due the *just* the commitment signatures, the savings from
compression become less attractive. Going a step father, once you factor in
the space complexity of the 2-stage HTLC claims, then the savings from
compressing the revocation tree become insignificant.
It's also worth pointing out that if the server is able to compress the
revocation tree, then their necessarily linking new breach payloads with a
particular channel. Another downside, is that if you go to revocation tree
compression, then all updates *must* be sent in order, and updates cannot be
*skipped*.
As a result of these downside, our current implementation goes back to the
ol' "encrypted blob" approach. One immediate benefit with this approach is
that the outsourcing protocol isn't so coupled with the current _commitment
protocol_. Instead, the internal payload can be typed, allowing the server
to dispatch the proper breach protocol based on the commitment type. The
blob approach can also support a "swap" protocol which is required for
commitment designs that allow for O(1) outsourcer state per-client, like the
scheme I presented at the last Scaling Bitcoin.
-- Laolu
On Sun, Apr 15, 2018 at 8:32 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Hi all,
>
> Nicolas Dorier was requesting additional hooks in c-lightning for a simple
> WatchTower system:
> https://github.com/ElementsProject/lightning/issues/1353
>
> Unfortunately I was only able to provide an interface which requires a
> *trusted* WatchTower. Trust is of course a five-letter word and should not
> be used in polite company.
>
> My key problem is that I provide enough information to the WatchTower for
> the WatchTower to be able to create the justice transaction by itself. If
> so, the WatchTower could just make the justice transaction output to itself
> and the counterparty, so that the WatchTower and the counterparty can
> cooperate to steal the channel funds: the counterparty publishes a revoked
> transaction, the WatchTower writes a justice transaction on it that splits
> the earnings between itself and the counterparty.
>
> It seems to me, that the only safe way to implement a trustless
> WatchTower, is for the node to generate a fully-signed justice transaction,
> IMMEDIATELY after every commitment transaction is revoked, and transmit it
> to the WatchTower. The WatchTower would have to store each and every
> justice transaction it received, and would not be able to compress it or
> use various techniques to store data efficiently. The WatchTower would not
> have enough information to regenerate justice transactions (and in
> particular would not be able to create a travesty-of-justice transaction
> that pays out to itself rather than the protected party). In practice this
> would require that node software also keep around those transactions until
> some process has ensured that the WatchTower has received the justice
> transactions.
>
> Is there a good way to make trustless WatchTowers currently or did this
> simply not reach BOLT v1.0?
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180416/ed660fae/attachment-0001.html>;