Bastien TEINTURIER [ARCHIVE] on Nostr: 📅 Original date posted:2023-08-17 🗒️ Summary of this message: A hard penalty ...
📅 Original date posted:2023-08-17
🗒️ Summary of this message: A hard penalty may be appropriate for a paid service, but designing payment for it is not easy and users may not be willing to pay. Phoenix should inform users if something goes wrong.
📝 Original message:
Hi Peter,
> Note that a hard penalty might be more appropriate for a paid service,
where
there's a clear expectation that the service works.
Agreed, and in that case we'd have to design payment for this service,
which isn't completely trivial and I'm not sure users are ready to pay
for it (the free version that mostly works is likely a better fit for
the majority of users).
> 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.
We made sure that the code clearly distinguishes that case: we currently
handle it by simply ignoring the stale server backup, but it should be
easy to surface this to the user (which would also help us figure out
some edge cases where disconnections lead to a desynchronization between
the wallet and the wallet provider). The non-trivial part is to design
the proof that the user could share publicly, without revealing its
private data or leaking its backup encryption keys.
Thanks,
Bastien
Le mer. 16 août 2023 à 15:16, Peter Todd <pete at petertodd.org> a écrit :
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/ac792817/attachment.html>;
🗒️ Summary of this message: A hard penalty may be appropriate for a paid service, but designing payment for it is not easy and users may not be willing to pay. Phoenix should inform users if something goes wrong.
📝 Original message:
Hi Peter,
> Note that a hard penalty might be more appropriate for a paid service,
where
there's a clear expectation that the service works.
Agreed, and in that case we'd have to design payment for this service,
which isn't completely trivial and I'm not sure users are ready to pay
for it (the free version that mostly works is likely a better fit for
the majority of users).
> 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.
We made sure that the code clearly distinguishes that case: we currently
handle it by simply ignoring the stale server backup, but it should be
easy to surface this to the user (which would also help us figure out
some edge cases where disconnections lead to a desynchronization between
the wallet and the wallet provider). The non-trivial part is to design
the proof that the user could share publicly, without revealing its
private data or leaking its backup encryption keys.
Thanks,
Bastien
Le mer. 16 août 2023 à 15:16, Peter Todd <pete at petertodd.org> a écrit :
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230817/ac792817/attachment.html>;