Benjamin Mord [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-17 📝 Original message: "I think this is exactly ...
📅 Original date posted:2017-11-17
📝 Original message:
"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/e5c6d7af/attachment-0001.html>;
📝 Original message:
"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/e5c6d7af/attachment-0001.html>;