Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-16 🗒️ Summary of this message: The author ...
📅 Original date posted:2023-08-16
🗒️ Summary of this message: The author disagrees with the necessity and potential dangers of fraud proofs in Lightning Network, suggesting a different approach and highlighting a potential use case for a "latest state backup" oracle scheme. They also discuss the benefits and drawbacks of Phoenix's approach.
📝 Original message:
On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote:
> Hi Thomas,
>
> I don't think those fraud proofs are necessary at all. They're also
> dangerous, because they impose a hard penalty on LSPs for something
> that should be best effort (and could get desynchronized by connection
> issues, especially with flaky mobile connections).
Note that a hard pentalty might be more appropriate for a paid service, where
there's a clear expectation that the service works.
Also I'll point out to Thomas, that he's actually come up with a generic
"latest state backup" oracle scheme that might be useful for applications
outside of Lightning. It might be wortwhile to forward it to bitcoin-dev,
pointing that out, so it sees a wider audience. I can't recall anyone else
coming up with that precise mechanism before.
> I agree with Peter Todd that since the mobile wallet can check the state
> of the returned backup at every connection request, this makes it highly
> unlikely that the LSP can cheat: that's the approach we've taken for
> Phoenix.
Does Phoenix tell the user this has happened? Phoenix being a centralized
entity, a useful outcome would be people finding out something is wrong and
saying so on, eg, social media.
Similarly, the most likely reason why that would be triggered is Phoenix making
a mistake, not malice. Having clients loudly shutdown probably protects Phoenix
overall from their own mistakes in that scenario, by quickly getting people to
stop using Phoenix wallet temporarily until the situation is fixed. Bad for
reputation in the short term. But IMO better in the long term.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230816/e27888fd/attachment.sig>;
🗒️ Summary of this message: The author disagrees with the necessity and potential dangers of fraud proofs in Lightning Network, suggesting a different approach and highlighting a potential use case for a "latest state backup" oracle scheme. They also discuss the benefits and drawbacks of Phoenix's approach.
📝 Original message:
On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote:
> Hi Thomas,
>
> I don't think those fraud proofs are necessary at all. They're also
> dangerous, because they impose a hard penalty on LSPs for something
> that should be best effort (and could get desynchronized by connection
> issues, especially with flaky mobile connections).
Note that a hard pentalty might be more appropriate for a paid service, where
there's a clear expectation that the service works.
Also I'll point out to Thomas, that he's actually come up with a generic
"latest state backup" oracle scheme that might be useful for applications
outside of Lightning. It might be wortwhile to forward it to bitcoin-dev,
pointing that out, so it sees a wider audience. I can't recall anyone else
coming up with that precise mechanism before.
> I agree with Peter Todd that since the mobile wallet can check the state
> of the returned backup at every connection request, this makes it highly
> unlikely that the LSP can cheat: that's the approach we've taken for
> Phoenix.
Does Phoenix tell the user this has happened? Phoenix being a centralized
entity, a useful outcome would be people finding out something is wrong and
saying so on, eg, social media.
Similarly, the most likely reason why that would be triggered is Phoenix making
a mistake, not malice. Having clients loudly shutdown probably protects Phoenix
overall from their own mistakes in that scenario, by quickly getting people to
stop using Phoenix wallet temporarily until the situation is fixed. Bad for
reputation in the short term. But IMO better in the long term.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230816/e27888fd/attachment.sig>;