Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-06-10 📝 Original message: All, I've opened ...
📅 Original date posted:2018-06-10
📝 Original message:
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 <tyzbit at 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 <ZmnSCPxj at 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 <ZmnSCPxj at 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 <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/20180610/b256d24e/attachment-0001.html>;
📝 Original message:
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 <tyzbit at 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 <ZmnSCPxj at 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 <ZmnSCPxj at 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 <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/20180610/b256d24e/attachment-0001.html>;