[Lightning-dev] New idea on decentralized identity and truth (Re: Numerifides)

ZmnSCPxj ZmnSCPxj at protonmail.com
Thu Jun 7 03:36:26 UTC 2018


Good morning again Tyler,

Building off the "server-client database" idea, here is an alternate idea.

We have a special node type, an "advertiser node".  Aside from normal LN protocol, advertiser nodes also have the below interface:

1.  A "write" interface that lets advertisers pay to set a mapping.
2.  A "read" interface that lets audiences pay to get a mapping.  The payment here should be much smaller than the "write" interface.
3.  A "proof" interface that lets anyone query how much the advertiser node owns in its channels.  It may be possible to set things up so that if the advertiser lies, it loses some of its funds (if not, this scheme is not workable).

If an advertiser node owns much funds, it probably earned that from many advertisers paying to set mappings, and audiences paying to get mappings.  So if the advertising node is inventing its audience, then it will have to lock some of its own funds and not spend it, sacrificing opportunity to invest it elsewhere.

Of course, this is strongly centralizing and thus not recommended.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On June 7, 2018 11:20 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:

> Good morning Tyler,
>
> It seems this can be a layer on top of LN.
>
> This is my understanding: the querier requests some mapping and sends also an invoice, the responder either fails, or returns the mapping and pays to the invoice.  So the responder pays to the querier.
>
> However it seems a little strange that I can get money by an action I initiate.
>
> For example, if I know that Google wants to claim some mapping, I could drain them of their allocated "advertising funds" by querying them repeatedly.
>
> In any case, non-distributed server-client protocols for storing database information I believe pay in reverse: the querier requests some query, the responder sends the encrypted data, an invoice with payment preimage, and a proof that the preimage is the (symmetric) encryption key to the encrypted data.  The querier pays the invoice and receives the preimage, which is the encryption key to the encrypted data.  The query may be a proof-of-storage so that a database client can have assurance that the server is indeed keeping its data alive.
>
> The mapping idea you have is the opposite of the above common consideration.  I suppose this is a pay-for-advertising, which I believe is not yet commonly researched yet.
>
> I believe a proposed pay-for-advertising should have the below considerations:
>
> 1.  As advertiser, I should get a proof that my advertisement did indeed reach some target audience, before I pay out.
> 2.  An attacker could trivially invent some target audience that it pretends exists, but might not actually exist.  How do we prove that the target audience exists?
>
> Regards,
> ZmnSCPxj
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On June 7, 2018 10:27 AM, Tyler H <tyzbit at gmail.com> wrote:
>
>> Greetings again, list.
>>
>> I have an idea that may be an excellent use-case for Lightning.  Where Numerifides was an attempt at decentralized identity rooted to the Blockchain, I thought of a new system that uses Lightning itself that seems superior, and perhaps gives Lightning even more utility than it currently has.
>>
>> The long and short of it is: I propose adding a feature (along with an RFC and a feature bit) to Lightning whereby any given node can be queried for a mapping (such as "Give me the IP address for Google.com" and the node can provide any answer one chooses _along with fulfilling a Lightning payment request the client provides_.
>>
>> The thinking here is nobody is willing to pay for mappings unless they're important, so mappings such as the pubkey associated with an unpopular username will only get paid by the person who has the username, or not paid at all, and thus the result can safely be disregarded.  Longer paths or more queries will cost the claimant more, plus it will cost for each query of the mapping.  Paying 1 satoshi (or less ;] ) per query for decentralized, trusted hosting of your data mappings seems fair.
>>
>> This is also aided by the fact that you cannot pay out on a channel without already having a channel _with outbound liquidity_.  So someone cannot, say, open a channel to a random node and spam queries as the directionality simply won't allow it.
>>
>> Lastly on the topic, the database could be shared among nodes for a price, where a Lightning node can offer to store data per hour and the person who wishes for redundancy can pay a Lightning invoice and provide the data.  This data wouldn't have to be encrypted or private, since the whole point is that it can be queried publicly.  You could even check if they're honest by querying them and seeing if they pay you Bitcoin back.
>>
>> I think if nothing else, this would be a good spare functionality used for rebalancing channels, if only to add some utility.
>>
>> Looking way far into the future, you could also submit queries like "What's the best place to get a burger in San Francisco" and only the real die-hard fans (and companies with some Bitcoin to burn for "advertising") would be willing to pay for their opinion to be heard.
>>
>> Feedback appreciated,
>> Tyler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180606/3e12e2db/attachment-0001.html>


More information about the Lightning-dev mailing list