Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-17 📝 Original message: Thanks for the links! And ...
📅 Original date posted:2017-11-17
📝 Original message:
Thanks for the links!
And just to clarify, my other comments relate to cryptographic conservatism
in general, and not specifically to routing. I switched topics, sorry for
the confusion.
On Nov 17, 2017 9:30 AM, "Christian Decker" <decker.christian at gmail.com>
wrote:
> Oh yeah, my mail tool destroyed that mail quite expertly :-)
>
> The footnotes were
> [1] https://github.com/lightningnetwork/lightning-
> rfc/blob/master/07-routing-gossip.md
> [2] https://medium.com/@rusty_lightning/lightning-routing-
> rough-background-dbac930abbad
> [3] https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba
> 96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
>
> We will eventually move away from the hash function based approach in
> favor of something that allows us to decorrelate hops in a route. We have
> indeed started writing down some of the ideas at least for Lightning in the
> project's wiki [4], but they're definitely not fleshed out.
>
> [4] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
>
>
> On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io> wrote:
>
>> "I think this is exactly the right venue to discuss these kinds of
>> issue..." - you are probably right! My bad.
>>
>> Christian, thank you for your knowledgable reply. The footnotes did not
>> come through on my end, I am especially interested in [3]. Do you have a
>> link? I am thrilled to hear of a Bitcoin-compatible revive alternative! :)
>>
>> Are we keeping an inventory somewhere of the cryptographic primitives
>> being used in lightning and the specific assumptions being made about them
>> (e.g. preimage resistance vs collision resistance and such)? One project I
>> have not yet found but believe we need across the entire cryptocurrency
>> community, is a (wiki-style?) inventory of unproven mathematical
>> assumptions (e.g. hardness of discrete logarithm) and/or cryptographic
>> primitives, cataloged in terms of the cryptocurrency technologies which
>> require them. Such a resource could help the community respond more
>> quickly, comprehensively, and transparently to the inevitable cryptanalytic
>> surprises that will pop up over time (especially from the quantum
>> cryptanalytic area, but even the classical cryptanalytic community as well).
>>
>> Related, I believe the ideal end state would be to only assume existence
>> of a preimage-resistant hash function, and to code such that one function
>> could be quickly swapped with another and thus update entire system. I'm
>> not sure if that is a realistic goal, but here is my first attempt to move
>> in that direction in case it is of interest to lightning. It is hard to
>> imagine it would be a new idea, although I have not yet found the precedent:
>> http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html
>>
>> Thanks,
>> Ben
>>
>>
>> On Nov 17, 2017 8:04 AM, "Christian Decker" <decker.christian at gmail.com>
>> wrote:
>>
>> On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io> wrote:
>>
>>> Ivan,
>>>
>>> That is mostly false, but with bits of truth sprinkled in. Contact me at
>>> ben at mord.io for further discussion so we tread lightly on the lists'
>>> email inboxes.
>>>
>>
>> I think this is exactly the right venue to discuss these kinds of issue,
>> so please don't move the conversation somewhere else :-)
>>
>> Routing is still very much in flux, we have a minimally viable routing
>> protocol in the spec [1]. It is minimal in the sense that we just push
>> the entire network's topology to the edges, which can then locally
>> compute routes. This is effectively a source-routed network, which
>> matches the requirements of the onion routing protocol we use for
>> privact as well. But this does not mean that this is protocol is set in
>> stone. We are actively working on finding better solutions to the
>> problem of finding routes across a vast network of millions if not
>> billions of nodes. Distance vector routing such as BGP uses may be one
>> option like Ben suggested.
>>
>> For now the network can easily scale to about 1 million channels [2]
>> even on very limited devices, Upgrading to another protocol at a later
>> point in time is trivial, since none of the routing information is
>> consensus critical. We have all the extension points built in to allow
>> future extensibility.
>>
>>
>>> But briefly: scale-capable routing protocols are possible as
>>> demonstrated by IP and thus by the internet itself. As for centralizing
>>> flow through small number of liquidity providers, yes that does seem
>>> economically probable, at least unless / until off-chain channel
>>> rebalancing mechanism (like the recently proposed "revive" protocol) come
>>> about. Bitcoin script is not currently revive-capable but Ethereum is, so
>>> either Bitcoin revive could be enabled via two-way pegged sidechain
>>> protocol with Ethereum, or even better, by a purpose-built (yet still not
>>> Turing-complete) extension to Bitcoin script itself in the future.
>>>
>>
>> As a matter of fact, Conrad and I just published a similar technique for
>> off-chain channel rebalancing and fund re-allocation based solely on
>> Bitcoin [3] (major props to Conrad for the excellent writeup!). The
>> flexibility in Bitcoin exists.
>>
>> As for the hubs everybody is assuming will form, I don't think they're
>> as likely to form. Creating such a hub is extremely costly since it'll
>> have to allocate sufficient funds to cover the maximum imbalance of all
>> of its channels ahead of time. Then the fees must cover the opportunity
>> cost of allocating all of those funds to channels instead of investing
>> them somewhere else. On top of that the funds will not be moved alot
>> since they serve only a small number of endpoints connected through
>> those channels, this compounds the problem of having high fees. The high
>> fees make the hub channels a really bad choice for your payments, after
>> all you were looking for small fees for your payments, right? It opens
>> up an opportunity for nodes to open bypasses that grab some of the
>> traffic and associated fees from the expensive hub.
>>
>> All of that being said, we should be careful about our predictions on
>> how the topology will look, I added some counter arguments to a
>> hub-and-spoke network forming, but nobody can really be sure about
>> what'll happen.
>>
>>
>>> In either case the lightning network seems a key first step, and even
>>> were off-chain payment rebalancing not possible for some odd reason, the
>>> lightning network seems extremely valuable and scaleable - regardless
>>> because the centralization you speak is not one that affects safety of the
>>> money supply itself, and these centralized hubs would be more dispensable /
>>> swappable versus the mining centralization risk that people more often talk
>>> about in Bitcoin. Lightning network centralization, even if it persisted
>>> somehow despite revive and future concepts, would not be an existential
>>> risk.
>>>
>>
>> Rebalancing is definitely possible, even without [3], you can
>> disincentivize the use of a channel until they have been rebalanced. For
>> long term imbalance, opening another channel may be the best option
>>
>>
>>> As for transaction fees, the idea is only channel setup / tear down are
>>> required greatly reducing fees. Yes if txin fees were millions of dollars
>>> then people could not practically penalize fraud, but that is unlikely.
>>> Even if txin fees made fraud claims marginally unprofitable (yet practical)
>>> that would still be ok - the judicial systems of most countries prove that
>>> people go beyond self-interest when sufficiently ticked, a fact of human
>>> psychology which in turn creates the incentives that support honest
>>> business. (Also please be aware I'm not a lightning code contributor, so
>>> that team might also be doing more to address already than I thought to
>>> mention above.)
>>>
>>
>> This is open to speculation as well. We hope to reduce the load on the
>> on-chain network sufficiently to allow timely on-chain settlements. By
>> aggregating payments off-chain we can also aggregate the fees and then
>> use them to pay on-chain fees. So don't consider the on-chain fees for
>> your channels as your sole loss, they are paid for by payments you
>> forward. Ultimately this should encourage participants to open channels
>> that support the network as a whole, not just themselves. We are
>> building automations that should take care of this, the user won't have
>> to do anything to improve the network topology.
>>
>> Cheers,
>> Christian
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171117/68bb665c/attachment-0001.html>;
📝 Original message:
Thanks for the links!
And just to clarify, my other comments relate to cryptographic conservatism
in general, and not specifically to routing. I switched topics, sorry for
the confusion.
On Nov 17, 2017 9:30 AM, "Christian Decker" <decker.christian at gmail.com>
wrote:
> Oh yeah, my mail tool destroyed that mail quite expertly :-)
>
> The footnotes were
> [1] https://github.com/lightningnetwork/lightning-
> rfc/blob/master/07-routing-gossip.md
> [2] https://medium.com/@rusty_lightning/lightning-routing-
> rough-background-dbac930abbad
> [3] https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba
> 96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
>
> We will eventually move away from the hash function based approach in
> favor of something that allows us to decorrelate hops in a route. We have
> indeed started writing down some of the ideas at least for Lightning in the
> project's wiki [4], but they're definitely not fleshed out.
>
> [4] https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming
>
>
> On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io> wrote:
>
>> "I think this is exactly the right venue to discuss these kinds of
>> issue..." - you are probably right! My bad.
>>
>> Christian, thank you for your knowledgable reply. The footnotes did not
>> come through on my end, I am especially interested in [3]. Do you have a
>> link? I am thrilled to hear of a Bitcoin-compatible revive alternative! :)
>>
>> Are we keeping an inventory somewhere of the cryptographic primitives
>> being used in lightning and the specific assumptions being made about them
>> (e.g. preimage resistance vs collision resistance and such)? One project I
>> have not yet found but believe we need across the entire cryptocurrency
>> community, is a (wiki-style?) inventory of unproven mathematical
>> assumptions (e.g. hardness of discrete logarithm) and/or cryptographic
>> primitives, cataloged in terms of the cryptocurrency technologies which
>> require them. Such a resource could help the community respond more
>> quickly, comprehensively, and transparently to the inevitable cryptanalytic
>> surprises that will pop up over time (especially from the quantum
>> cryptanalytic area, but even the classical cryptanalytic community as well).
>>
>> Related, I believe the ideal end state would be to only assume existence
>> of a preimage-resistant hash function, and to code such that one function
>> could be quickly swapped with another and thus update entire system. I'm
>> not sure if that is a realistic goal, but here is my first attempt to move
>> in that direction in case it is of interest to lightning. It is hard to
>> imagine it would be a new idea, although I have not yet found the precedent:
>> http://ben.mord.io/p/delayed-chained-key-revelation-dckr.html
>>
>> Thanks,
>> Ben
>>
>>
>> On Nov 17, 2017 8:04 AM, "Christian Decker" <decker.christian at gmail.com>
>> wrote:
>>
>> On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io> wrote:
>>
>>> Ivan,
>>>
>>> That is mostly false, but with bits of truth sprinkled in. Contact me at
>>> ben at mord.io for further discussion so we tread lightly on the lists'
>>> email inboxes.
>>>
>>
>> I think this is exactly the right venue to discuss these kinds of issue,
>> so please don't move the conversation somewhere else :-)
>>
>> Routing is still very much in flux, we have a minimally viable routing
>> protocol in the spec [1]. It is minimal in the sense that we just push
>> the entire network's topology to the edges, which can then locally
>> compute routes. This is effectively a source-routed network, which
>> matches the requirements of the onion routing protocol we use for
>> privact as well. But this does not mean that this is protocol is set in
>> stone. We are actively working on finding better solutions to the
>> problem of finding routes across a vast network of millions if not
>> billions of nodes. Distance vector routing such as BGP uses may be one
>> option like Ben suggested.
>>
>> For now the network can easily scale to about 1 million channels [2]
>> even on very limited devices, Upgrading to another protocol at a later
>> point in time is trivial, since none of the routing information is
>> consensus critical. We have all the extension points built in to allow
>> future extensibility.
>>
>>
>>> But briefly: scale-capable routing protocols are possible as
>>> demonstrated by IP and thus by the internet itself. As for centralizing
>>> flow through small number of liquidity providers, yes that does seem
>>> economically probable, at least unless / until off-chain channel
>>> rebalancing mechanism (like the recently proposed "revive" protocol) come
>>> about. Bitcoin script is not currently revive-capable but Ethereum is, so
>>> either Bitcoin revive could be enabled via two-way pegged sidechain
>>> protocol with Ethereum, or even better, by a purpose-built (yet still not
>>> Turing-complete) extension to Bitcoin script itself in the future.
>>>
>>
>> As a matter of fact, Conrad and I just published a similar technique for
>> off-chain channel rebalancing and fund re-allocation based solely on
>> Bitcoin [3] (major props to Conrad for the excellent writeup!). The
>> flexibility in Bitcoin exists.
>>
>> As for the hubs everybody is assuming will form, I don't think they're
>> as likely to form. Creating such a hub is extremely costly since it'll
>> have to allocate sufficient funds to cover the maximum imbalance of all
>> of its channels ahead of time. Then the fees must cover the opportunity
>> cost of allocating all of those funds to channels instead of investing
>> them somewhere else. On top of that the funds will not be moved alot
>> since they serve only a small number of endpoints connected through
>> those channels, this compounds the problem of having high fees. The high
>> fees make the hub channels a really bad choice for your payments, after
>> all you were looking for small fees for your payments, right? It opens
>> up an opportunity for nodes to open bypasses that grab some of the
>> traffic and associated fees from the expensive hub.
>>
>> All of that being said, we should be careful about our predictions on
>> how the topology will look, I added some counter arguments to a
>> hub-and-spoke network forming, but nobody can really be sure about
>> what'll happen.
>>
>>
>>> In either case the lightning network seems a key first step, and even
>>> were off-chain payment rebalancing not possible for some odd reason, the
>>> lightning network seems extremely valuable and scaleable - regardless
>>> because the centralization you speak is not one that affects safety of the
>>> money supply itself, and these centralized hubs would be more dispensable /
>>> swappable versus the mining centralization risk that people more often talk
>>> about in Bitcoin. Lightning network centralization, even if it persisted
>>> somehow despite revive and future concepts, would not be an existential
>>> risk.
>>>
>>
>> Rebalancing is definitely possible, even without [3], you can
>> disincentivize the use of a channel until they have been rebalanced. For
>> long term imbalance, opening another channel may be the best option
>>
>>
>>> As for transaction fees, the idea is only channel setup / tear down are
>>> required greatly reducing fees. Yes if txin fees were millions of dollars
>>> then people could not practically penalize fraud, but that is unlikely.
>>> Even if txin fees made fraud claims marginally unprofitable (yet practical)
>>> that would still be ok - the judicial systems of most countries prove that
>>> people go beyond self-interest when sufficiently ticked, a fact of human
>>> psychology which in turn creates the incentives that support honest
>>> business. (Also please be aware I'm not a lightning code contributor, so
>>> that team might also be doing more to address already than I thought to
>>> mention above.)
>>>
>>
>> This is open to speculation as well. We hope to reduce the load on the
>> on-chain network sufficiently to allow timely on-chain settlements. By
>> aggregating payments off-chain we can also aggregate the fees and then
>> use them to pay on-chain fees. So don't consider the on-chain fees for
>> your channels as your sole loss, they are paid for by payments you
>> forward. Ultimately this should encourage participants to open channels
>> that support the network as a whole, not just themselves. We are
>> building automations that should take care of this, the user won't have
>> to do anything to improve the network topology.
>>
>> Cheers,
>> Christian
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171117/68bb665c/attachment-0001.html>;