ZmnSCPxj, Regarding proof of payment, a receiving node must have some inbound Lightning capacity. Therefore, they must have spent funds on the LN already. Attackers can't drain more than they've spent on their channels. Node pubkeys can also be used such that rapid subsequent requests above a threshold from a given pubkey fail after the first success.
The read must be a payout, the point is that I get the mappings I care about and Google (with more Bitcoin, processing power, or Lightning nodes) can't come in and outbid me for them, or else I will just spam the fake mapping for a steady stream of satoshis ;) Also, no one knows which node has the original mapping, only which nodes are hosting them, and what mappings are available. The mappings themselves can be openly queried without payment. The payment is so a client knows that a specific mapping has "put its money where its mouth is" about it. Only mappings that actually pay out can be trusted. Compared to your alternate idea I believe this map of mappings, or the "Atlas bit" as it could be called is much more decentalized, honest and fair. Tyler On Wed, Jun 6, 2018, 23:36 ZmnSCPxj <zmnsc...@protonmail.com> wrote: > 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 <zmnsc...@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 <tyz...@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 > > > >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
