All, Sorry for the rapid double message, but I forgot to mention here that Atlas can be used as a punishment mechanism for eltoo channels.
Thanks, Tyler On Sun, Jun 10, 2018 at 6:29 PM Tyler H <tyz...@gmail.com> wrote: > 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 <tyz...@gmail.com> 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 <zmnsc...@protonmail.com> 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 <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
