ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-26 📝 Original message: Good morning Stepan, > ...
📅 Original date posted:2019-06-26
📝 Original message:
Good morning Stepan,
> But it depends on the application and communication channel, so I would leave these details to the app developers.
I would mildly disagree, as I worry about proliferation of incompatible applications, or applications that can only work with specific wallets.
Still, it can be argued that this is early times for such applications, and the extra creativity may be more important for exploring the space than a premature optimization of working on a single standard.
>
> P.S. It would be nice to have this proposal and other interesting ideas from the mailing list in some kind of guidelines for different lightning use-cases, but I feel like BOLTs repo is the wrong place to put it. Could we organize some kind of lightning-guidelines repo for lapp developers? I think it would be very useful.
This seems a good idea.
Perhaps we can add Lightning Application Protocol Proposals (LAPP) repository somewhere.
This would be dependent on BOLT, but BOLT would not depend on LAPP.
Probably the existing protocols like WebLN and Thor would be in scope for this.
---
On the original topic:
A concern I raised is the issue that data providers must be trusted to actually provide the data.
Unfortunately, I cannot derive a good way for a data consumer to prove that the data given by a data provider is bogus.
It becomes an assertion and counter-assertion (the problem with reputation systems).
An escrow system might be useful, but requires us to have some way of integrating escrow with proof-of-payment.
(and it seems we need to *really* switch to payment points / scalars to combine proof-of-payment with a lot of features... this is delayed by Bitcoin getting Schnorr, unless we want to step up now and use 2p-ECDSA today, then reimplement under Schnorr when Bitcoin gets it (my understanding is that Schnorr Scriptless Script has more security than 2p-ECDSA Scriptless Script, though I am not a mathist and cannot show this))
Regards,
ZmnSCPxj
📝 Original message:
Good morning Stepan,
> But it depends on the application and communication channel, so I would leave these details to the app developers.
I would mildly disagree, as I worry about proliferation of incompatible applications, or applications that can only work with specific wallets.
Still, it can be argued that this is early times for such applications, and the extra creativity may be more important for exploring the space than a premature optimization of working on a single standard.
>
> P.S. It would be nice to have this proposal and other interesting ideas from the mailing list in some kind of guidelines for different lightning use-cases, but I feel like BOLTs repo is the wrong place to put it. Could we organize some kind of lightning-guidelines repo for lapp developers? I think it would be very useful.
This seems a good idea.
Perhaps we can add Lightning Application Protocol Proposals (LAPP) repository somewhere.
This would be dependent on BOLT, but BOLT would not depend on LAPP.
Probably the existing protocols like WebLN and Thor would be in scope for this.
---
On the original topic:
A concern I raised is the issue that data providers must be trusted to actually provide the data.
Unfortunately, I cannot derive a good way for a data consumer to prove that the data given by a data provider is bogus.
It becomes an assertion and counter-assertion (the problem with reputation systems).
An escrow system might be useful, but requires us to have some way of integrating escrow with proof-of-payment.
(and it seems we need to *really* switch to payment points / scalars to combine proof-of-payment with a lot of features... this is delayed by Bitcoin getting Schnorr, unless we want to step up now and use 2p-ECDSA today, then reimplement under Schnorr when Bitcoin gets it (my understanding is that Schnorr Scriptless Script has more security than 2p-ECDSA Scriptless Script, though I am not a mathist and cannot show this))
Regards,
ZmnSCPxj