From tyzbit at gmail.com Sun Jun 10 22:29:19 2018 From: tyzbit at gmail.com (Tyler H) Date: Sun, 10 Jun 2018 18:29:19 -0400 Subject: [Lightning-dev] New idea on decentralized identity and truth (Re: Numerifides) In-Reply-To: References: Message-ID: All, I've opened https://github.com/lightningnetwork/lightning-rfc/pull/441 to get started on hashing out the features and behavior of Atlas. Thanks, Tyler On Thu, Jun 7, 2018 at 4:45 AM Tyler H wrote: > >But in a trustless environment, "only mappings that actually pay out can > be trusted" is equivalent to "all reads require a payout"...? > > I'll rephrase to say "can be trusted to be human meaningful". As you may > recall, the goal of Numerifides was to create _human meaningful_ but still > _trusted_ name mappings. If you want to know the IP to Google.com, you (the > human) want _the right one_. If you get the wrong one, even if the node > paid you for it, you can ban that node as untrustworthy and over time, > you'll have a set of trustworthy nodes. > > New nodes will start out less trustworthy than old nodes that continue to > host mappings for the maximum number of people. Though I'm not clear on > the specifics of eltoo penalty transactions, I think that you can actually > use this as a trust meter for which nodes have the most accurate mappings > by combining proof of the routable channel, proof of a breach (either a > current-state Lightning breach where the revocation key is used OR an eltoo > breach where you can provide proof of the most recent state of a channel. > > >Presumably, in order to pay out, the mapping service needs to have *some* > outgoing channel *somewhere*. > > Yes, in a way this is a sort of way to know which Lightning nodes are > honest. Perhaps this could be combined with eltoo as a way for Lightning > to not even need Watchtowers. Every node could be a watchtower, by > announcing to the network at large when a channel is breached, thus nodes > will likely want to close their channels with the less trustworthy nodes. > > In a way, Lightning decentralizes payments to be usable. Atlas, as I've > come to call it, centralizes trust over the entire Lightning Network. > > I appreciate the feedback, this is very helpful in refining this idea. > > Thanks, > Tyler > > On Thu, Jun 7, 2018 at 4:07 AM ZmnSCPxj wrote: > >> Good morning Tyler, >> >> 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. >> >> >> But in a trustless environment, "only mappings that actually pay out can >> be trusted" is equivalent to "all reads require a payout"...? >> >> It would be easy for me to spin up a few hundred nodes, connect them into >> cyclic superhubs, somehow arrange an incoming channel per superhub (e.g. >> using an LN-to-chain bridge, or an exchange or similar service where I can >> send my Lightning money and then recover it in some other form), then make >> a few hundred queries of the mapping. The mapping service cannot >> differentiate between valid queries and invalid ones that I claim exist but >> are not. In short, you have no proof that the audience for the >> advertisement exists (i.e. there is no Sybil protection for readers of the >> mapping service). >> >> Presumably, in order to pay out, the mapping service needs to have *some* >> outgoing channel *somewhere*. I might not be able to directly convince the >> mapping service to make a direct channel to me, but I *could* convince >> *somebody* to make an incoming channel to me (which is something merchants >> would want to do, therefore such a service will arise (and likely already >> exists)). Using normal Lightning operations, there could be a viable path >> from the mapping service to a node on my cyclic superhub by which I could >> drain them (if such a path could not exist, then LN as a whole would have >> failed). And if at least one node on a cyclic superhub has an incoming >> channel, then the entire cyclic superhub is payable from that channel. >> >> Regards, >> ZmnSCPxj >> >> >> 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 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 Secure Email. >>> >>> ??????? Original Message ??????? >>> On June 7, 2018 11:20 AM, ZmnSCPxj 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 Secure Email. >>> >>> ??????? Original Message ??????? >>> On June 7, 2018 10:27 AM, Tyler H 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: