Pedro Moreno Sanchez [ARCHIVE] / is on Nostr

Last Notes

2023-06-09 12:50:42

- reply

📅 Original date posted:2018-05-24
📝 Original message:
Hello,
I know it is kind of a late reply, but my co-authors and I have been
working hard to get ready an extended version of the paper for this
work. The paper is now available at https://eprint.iacr.org/2018/472
In this paper, we describe in detail the scriptless script (SS) ECDSA
construction and formally prove its security and privacy guarantees.
Additionally, we describe several other constructions of interest for
the LN:
- The SS Schnorr, initially proposed by A. Poelstra. We formally
describe the protocol and prove its security and privacy guarantees
- Interestingly, we show that it is possible to combine SS ECDSA and SS
Schnorr without losing security or privacy. This allows interoperability
between different implementations.
- A framework to combine script-based cryptographic locks using
partially homomorphic one-way functions.
- Possible applications. For instance, SS ECDSA could be used today in
Bitcoin to perform atomic swaps where the resulting transaction no
longer reveals the cryptographic condition. Instead, it is embedded in a
regular ECDSA signature. This provides several advantages such as
reduced transaction size and better privacy/fungibility among others.
Please, let us know any comment/feedback that you might have.
Thanks,
Pedro.
On 5/8/18 11:59 PM, ZmnSCPxj via Lightning-dev wrote:
> Good morning Benjamin,
>
> Your caution is laudable, I think.
>
>
>> Yes, bitcoin is wise to at least hash the pub key until use. Granted,
>> lightning (necessarily?) risks public key exposure, but in a pinch
>> there are other signature algorithms for lightning to move to.
>>
>
> Lightning cannot *quickly* move to a new signature algorithm. At the
> minimum you need to wait for the signature algorithm to get widely
> deployed in the base-layer blockchain, then LN implementations will need
> to scramble to implement the new signature algorithm. Then all LN users
> need to update, close existing channels, and reopen new ones.
>
> Another issue is that the message transport is encrypted using a shared
> key derived from the node-identity public keys. If a break lets
> attackers derive private keys from public keys, then it is possible for
> any LN node to have its communications spoofed, meaning any mitigation
> may very well be obviated: channels need to be re-anchored
> cooperatively, but how do you know you are cooperating with the other
> node in the channel rather than the attacker, if the attacker can derive
> the private key from the other node public key?
>
> The sudden influx of close followed by open transactions will probably
> massively load the blockchain layer, too.
>
> In that case, perhaps a concrete proposal would be to prepare a new
> message protocol for reanchoring transactions:
>
> 1. A new "signing algo" concept, which is effectively an enumeration
> that will be extended later, e.g. 0 => ECDSA on secp256k1, 1->255 =>
> reserved.
> 2. `open_channel` would need to provide a `signing_algo` that underlies
> the commitment structure at a lower level.
> 3. A new `reopen_channel` to move a channel from one signing algorithm
> to another, plus a reply to accept the switch and provide new commitment
> transactions for both sides. This is effectively a `shutdown` followed
> by the `closing_signed` negotiation followed by a new `open_channel`,
> but with the resulting transaction cutting through a close and a funding
> transaction (in order to reduce blockspace competition).
> 4. A new `reopen_channel_rbf`, possibly including a proof that an
> existing reopen channel has replaced (e.g. sending the actual
> transaction that spends the funding outpoint and bids a higher feerate
> than the last re-open transaction), to RBF the re-open transaction that
> moves from one signing algorithm to another; better to lose the channel
> to miners as fees then to let a thief succeed (i.e. scorched earth).
> This is complicated by the fact that the re-open has to be signed
> cooperatively by two parties whereas a thief can be singular and thus
> faster in replacing transactions. But at least better to make an effort
> than to just give up!
>
>>
>>
>>
>>
>> In the case of Lightning, the attack scenario on scriptless
>> scripts is that a peer is going to use a quantum computer to steal
>> all live payments routed through them from their senders before
>> they get to the recipient. This would be bad, but not
>> catastrophic, and once it is recognized that the attack is
>> possible, insecure channels could be closed.
>>
>>
>> All channels would become insecure, the very premise of lightning
>> would thus break, which is only a problem if the world came to depend
>> on it. But then why try a thing, unless you plan to maybe succeed?
>> Also, we don't know that a quantum computer is necessary. SHA-1 was
>> secure, until it wasn't, no quantum computer was needed to break it.
>>
>>
>> But furthermore, an attacker with a quantum computer could just
>> steal the multisig funding output directly instead of attacking
>> scriptless scripts.
>>
>>
>> Absolutely, and today there is no redundant signature of different
>> algorithm, in the code. (That would be better.) But even so, how hard
>> would it be to swap one signature algorithm for another? Then users
>> "just" move their funds to multisig addresses under the new algorithm.
>>
>>
>> So additional protocol changes relying on the DL assumption don't
>> bother me in the least.
>>
>>
>> I don't follow the logic. If today we would have a frantic scramble in
>> event of sudden DL weakness, as indeed seems probable, it does not
>> then follow that we might as well design DL weakness to become a
>> fundamentally unsurvivable problem. DL signatures bother me less
>> because lattice cryptography can serve as backup. Scriptless scripts
>> worry me because I just don't know what the backup is, when (not if)
>> DL falls. Perhaps scriptless scripts can be done with lattices(?), in
>> which case I am simply unaware - but some such backup should be
>> identified, at least at a conceptual level, prior to use.
>
> At least on Lightning, Scriptless Script can only be used for payment
> forwarding. Thus the vulnerability is time-bounded. Further, while
> Scriptless Script enables new applications such as within-path
> decorrelation (privacy boost) and multi-path payments with
> proof-of-payment (functionality boost), we *can* fall back to the simple
> hashlocking we use now, which degrades functionality and privacy (but
> only to the level that we have today!). Hashlocking can have the exact
> hash function changed reasonably easily, modulo blockchain-layer
> infrastructure change (i.e. the base layer needs to implement the
> replacement before upper layers can use them), plus the need to update
> invoice formats to use a different hash function.
>
>> If this is just a toy, then never mind. If we don't expect the world
>> to ever depend on this for anything important, then there is no need
>> to fret over the finite lifespan of primitives. Or maybe we can just
>> hope, that this time will be unlike all the others in the history of
>> cryptography.
>>
>> Otherwise, consider for example the history of DES, or SHA-1. Those
>> are scenarios where we saw the problems coming far enough in advance
>> to transition. Sure, it would be better if we had redundant primitives
>> for every function in the actual code itself - just in case of either
>> a sudden, or else a secret, break. In fact, we should aim to one day
>> get there. But for now, let's at least have functionally equivalent
>> backups for every function, even if only on paper. When exciting new
>> functionality is invented but based on a mathematically unproven
>> assumption, then let's wait to build on it until after at least one or
>> two mathematically dissimilar assumptions have been found as
>> alternative backup foundation. The global economy deserves such
>> careful hands, I think, or else we do not deserve it.
>
> Naively, it seems to me that there are already multiple ways to do
> Scriptless.
>
> (I am not a mathematician and not a cryptographer; I am merely a
> dilettante, and probably massively misunderstand this)
>
> 1. The classic one which takes advantage of Bellare-Neven signature
> linearity, where you provide an adaptor signature that can have magical
> mathematic operations with the actual signature to reveal the private key.
> 2. Nonce reuse, where you provide a different message signed using the
> private key and a specific nonce, and commit that the actual transaction
> gets signed with the same private key and the same nonce used in the
> first message, which in combination with magical mathematic operations
> will reveal the private key.
> 3. The Paillier cryptosystem thing that the ECDSA Scriptless Script
> uses, where you encrypt the private key in the Paillier cryptosystem,
> provide it, and you can have magical mathematic operations reveal the
> private key when you sign with it.
>
> All of the above still depend on the Discrete Log Problem being Hard. I
> am uncertain if they can be adapted in a Lattice-based signing
> algorithm; the first one almost certainly cannot, I am unsure for the
> second and third.
>
> Regards,
> ZmnSCPxj
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180524/01971226/attachment.sig>

2023-06-09 12:50:16

- reply

📅 Original date posted:2018-04-26
📝 Original message:
Hello guys,
as some of you already know, I am working on some cryptographic
constructions that might be of interest and useful for the Lightning
Network.
Recently, I have come up with a scriptless version of the adaptor
signatures and the contract required in the Lighting Network using only
2-party ECDSA signatures. The main advantage is that, instead of waiting
for Schnorr signatures to be deployed in Bitcoin so that Poelstra's
scriptless scripts can be used, I believe that this ECDSA-version of the
scriptless scripts can be directly applied today.
Details are in the attached PDF. I am looking forward to hearing your
comments and suggestions.
Cheers,
Pedro.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: scriptless-ecdsa.pdf
Type: application/pdf
Size: 161444 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180426/fe978423/attachment-0001.sig>

2023-06-09 12:47:50

- reply

📅 Original date posted:2017-11-25
📝 Original message:
Hello Christian,
Thanks for your prompt reply. Please, see my minor comments and
questions below.
On 11/23/17 7:50 AM, Christian Decker wrote:
> Thanks Pedro for the paper, I'll read through it as soon as possible and
> add more feedback :-) I just have some minor points to add regarding
> your last mail.
>
>> The onion-like packets used for *payments* in the current LN
>> implementations inevitably assume that the sender knows the complete
>> path from the sender to the intended receiver. The question/challenge
>> that we are solving in this work is: how does the sender gets to know
>> such path in the first place?
>
> The current implementation requires the node to compute the entire
> route, yes. However we have mechanisms in place for the two endpoints of a
> route to collaboratively find such a route. This includes telling the
> recipient ginving the sender hints as how best to reach the recipient,
> e.g., adding channel information in the invoice. In the long-term we
> also plan to add landmarks.
When you say "we have mechanisms in place", you refer to the
descriptions available in
https://github.com/lightningnetwork/lightning-rfc?
Interesting to know that you have landmark-based routing in your plans.
Given the time, I would be obviously interested to talk to you more
about it and possibly collaborate on that if you find it suitable.
>
> Personally I'd like to separate the base routing layer and the onion
> routing layer eventually. The base layer would provide end-to-end
> connectivity between any two nodes and the onion layer would then simply
> chose some random nodes in the network and not be bound to the networks
> topology. The same way IP and TOR are not mixed.
Yes, I totally agree. I also think that this separation would help us to
better understand what are the necessary and/or sufficient guarantees
required in both layers for the LN to work.
>
>> One approach is that each user in the LN locally stores the complete set
>> of opened channels either by looking at open channel transactions in the
>> blockchain or by a gossip protocol. However, this approach has trivial
>> privacy issues and it is not scalable for a growing number of users and
>> channels between them. Moreover, this approach is no longer possible if
>> open channel transactions can be modified such that they are
>> indistinguishable from other Bitcoin transactions.
>
> The funding transactions are currently indistinguishable from any other
> P2SH transaction. We currently only rely on being able to reveal the
> script behind the P2SH hash in order to prove that indeed the two
> endpoints have setup a channel. The gossip protocol does not require the
> information to be identifiable on-chain, only that we can verify some
> commitment to what we are claiming.
Could you please point me to where this mechanism is described? I have
been thinking about this, but the solution is not completely clear in my
mind yet.
>
> Cheers,
> Christian
Thanks again,
Pedro.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171125/578defda/attachment.sig>

2023-06-09 12:47:49

- reply

📅 Original date posted:2017-11-22
📝 Original message:
Hello Giovanni,
thanks for you interest in our work.
The onion-like packets used for *payments* in the current LN
implementations inevitably assume that the sender knows the complete
path from the sender to the intended receiver. The question/challenge
that we are solving in this work is: how does the sender gets to know
such path in the first place?
One approach is that each user in the LN locally stores the complete set
of opened channels either by looking at open channel transactions in the
blockchain or by a gossip protocol. However, this approach has trivial
privacy issues and it is not scalable for a growing number of users and
channels between them. Moreover, this approach is no longer possible if
open channel transactions can be modified such that they are
indistinguishable from other Bitcoin transactions.
Instead, we assume a decentralized setting where each user only needs to
know her own open channels and a small set of well connected users (that
we called landmarks). In this decentralized setting, our approach still
allows a user to route a payment to the intended receiver while
preserving scalability and privacy.
Cheers,
Pedro.
On 11/22/17 9:11 AM, Giovanni Di Stasi wrote:
> Hello,
>
> I am in the process of studying your routing approach and a doubt arised
> related to the privacy of payments.
> The current LN accomplishes payments thorugh onion-like packets which do
> not reveil the path, but just previous and next hops.
> Your approach also aims at obfuscating the path. What is that your
> approach provides more that is not currently provided in the current LN
> implementations?
>
> Thanks,
> Giovanni
>
> On Tue, Nov 21, 2017 at 4:37 PM, Pedro Moreno Sanchez
> <pmorenos at purdue.edu <mailto:pmorenos at purdue.edu>> wrote:
>
> Hello,
>
> my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
> science department at Purdue. I would like to bring to your attention a
> novel routing algorithm suitable for the Lightning Network (LN) that I
> have been working on with my supervisor Prof. Aniket Kate (Purdue
> University) and my co-workers Stefanie Roos and Prof. Ian Goldberg
> (University of Waterloo).
>
> Our approach is called SpeedyMurmurs, a routing algorithm for
> decentralized payment networks such as the LN. SpeedyMurmurs uses an
> embedding-based approach, meaning that the algorithm assigns meaningful
> coordinates to nodes that enable efficient and effective discovery of
> payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by
> means of a Breadth-First Search and then associates a coordinate to each
> node depending on its position in the tree. A path from the sender to
> the receiver is then calculated in a flexible manner, with each
> intermediate node choosing the next node in the path as a function of
> its neighbors' coordinates, available funds and closeness to the
> receiver. To account for topology changes (e.g., a new channel is
> created), the routing information is locally updated by only those
> affected nodes in the network.
>
> We have simulated several configurations of SpeedyMurmurs using real
> data from the Ripple network and compared it with other routing
> algorithms available in the literature. Our simulation results show that
> SpeedyMurmurs is able to find paths at about twice faster, reduces the
> communication overhead by at least a factor of 2 and maintains a similar
> or higher payment success ratio. Our simulation framework is open source
> and we believe that it might be of independent interest for this
> community to test this and any other alternative protocols that you
> might have in mind. If you are interested, we are happy to extend on
> this.
>
> Finally, we also show that SpeedyMurmurs achieves the privacy notions of
> interest in the LN. In particular, SpeedyMurmurs achieves value privacy,
> i.e., the total value of a transaction remains hidden, as well as sender
> and receiver privacy, i.e., the identities of the two transacting nodes
> remain hidden from the adversary.
>
>
> You can find all the details in the draft of our paper [1]. The final
> version of this work will appear at NDSS 2018 conference [2]. We would
> be glad to hear any question and feedback from you and are open to carry
> out further collaborations if this line of work is of interest for you.
>
> Best regards,
> Pedro, Stef, Aniket and Ian.
>
> [1] https://arxiv.org/abs/1709.05748
> <https://secure-web.cisco.com/1hKUYOfcuq4S8a9TIKcLHGL9DClggwCNIawUq93hdeDE96Iwqy58ZYdtuXM7Gdlsa7Jrf2OSRaN8bCSA5A74crC3YMfDDYBFzdPzGLddtPHiwfricnMNkNn1ckmgnLM9PZgTRN8pb6zsMwR4nOpoDV7iA0ADp6e_ai5Xvb5KYV7eIT7uRjN97oObGzTHtgOqrvq4QOxNfIJPm0qFFlSaDjnYrwhzLI8ztEKvLkjYqtUiDUN87Uk-vfS3Fr4z-UfP3TXAQAXxMnjFgU0RGtbUP6EPL3Aq8e1hDo-EH4puHV5s7yrTp3FqszUcVLENKMB41mcbQ7FiMVGyLKjdBj3zl9_mpOKPT0Btoda9HkUkOQvegEfkEU5Egi-i1PU64R8Hwl8h0Kw2PQvNp_pivjXHyyg/https%3A%2F%2Farxiv.org%2Fabs%2F1709.05748>
> [2] https://www.ndss-symposium.org/
> <https://secure-web.cisco.com/1nggVVGPi7xPxGDgQEilIAwDXM7YLFtoex67MSrW44z8RuhhcveLKqA2oIqsnabgrBe15G6j0f9vgW1bEbCRP2OCVp_VxnY7NxW8_KegfsFJ-UIL56M33Y3G-FLqnj8MPI-5Ik2yef5hW3NJyplwQLjdR-9qJ6HhVv-gtcwxr_pTaymYQ7Z3ghG6eMS8Yn4-uMik8eXkyuRp3EtJF3r-9xJbJrA97MdUSXtrLA0oWCqQ442ADPSP1ksXQmw9Bk-sk26Un4PNoiWNyQcst0VO2BgMS0QSHB0d25C0X8G0cToaTF0-NBoeN9cJiRktO3rXgOPwSUVb-GmdkK4iYmOpDoRbUj4UEyU72u2DrUYIvNH1PtWMMTmpDGA0GR3L3hriruRpB3GcieDB-BJ1SFC31gA/https%3A%2F%2Fwww.ndss-symposium.org%2F>
>
> On 11/17/17 8:09 PM, Saravanan Vijayakumaran wrote:
> > Hi Christian,
> >
> > Are there any open source simulators available for trying different
> > routing strategies? Or even a simulator for the Lightning network as a
> > whole?
> >
> > Regards
> > sarva
> >
> >
> > On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker
> > <decker.christian at gmail.com <mailto:decker.christian at gmail.com>
> <mailto:decker.christian at gmail.com
> <mailto: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
> <https://secure-web.cisco.com/1QCSVb9BsMDqtEKFYVGufBky5ZVyP5f-3BY6BU8hx8o5B_AQk9o3bMUIXLEwycuzAbZY9slXFGwMN1G6RxiejW-WZ0cZbKqEvug8fwvQsatOiuQ0okPQ-hLPmLR_AoupYFwgQBAKrMGJ0ShV7lcmrC2Iks3wVwfZIUphx3-6pWfrawTevAfoHjvhJ10t231HSKgWOAqorvonX-SSNdHq7hCkrTrsKJ_ktylzczPRI_VYVNuhX6pWUcRbizufYj8zvrcIMxbRpPBHxE4pMZDtnaYWUnZ0RvekRAOF41AXozQT1P3O332N4b5x65xgxg2HUmmyJGTGlsqQxXdfC2xcxyEop3UL6RxpLRrce7hMBrzM9L9N4VMdSLKvx5gfaQMfyh8MHUT7w7PVJPcwIq_eoTg/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md>
> >
> <https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md
> <https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md>>
> > [2]
> >
> https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad
> <https://secure-web.cisco.com/1QlQABw_J2zOgEv2OwHqW_kAUUOtsbAeDZOTrd5Poo978Dahqri_ejNF_Llc8OqZa8NUUUnVcF6XvNoQl5wDYCzCMe74Loa3XitswCBI7Q3jtwlZ4amZqFA3cxnHs5uRckoeKTv9UF0_kGySCJM1mxEZTH5mCbaHagy0rIrvfQ1W12-zkt6L2Id1qWHkG8lcdkiwcpscqHZbwnVXGYPBH7dGq1RT7_8S7zRJ74L9AAFHjCW_67HUAJ1xKuaboo2teXFAOH2lCtlgfMv6HBo8IRKmcp6SdM9n2niHbGu3xDQWDETzO1tjuuD9lDCWn26YQnZMp1QmFJR1Q9d01pvg0WSrcHqT8uM0UnOyDhGTd1MjCxD0MU_vbrdmmbJGNVFVJhiRMMinvo1Rb0DaQ8ffxHl9wVLc7mzVbwOGc9kKv6t4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad>
> >
> <https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad
> <https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad>>
> > [3]
> >
> https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
> <https://secure-web.cisco.com/1c8JC4qI_MTxxHa-DGbFUNMw7VCvn-g4WzxWywl1i76GVih6Yk55MJMteiwwVEYeSf-S8cU5PQph7ztH1w5wGyqdWj8CH0ZboAbqRSs6Pwk_N1TwpagW0kT9naYq-KR_Cd5n1FP8H-EhCg-fSuXXoqYQZe0yolQboLx1zFK_CGOrSUKxjPhtE-Bk7paKRi2NbVtN9LB61UUIgnUR0Vt_dR8WtRulNvRDX1XOs7z6x8EybbgKEN6hxjSwDI2tplvFZnExAn_qDKTAZ8GM2SzfpGMSSh15VDlXYjZNP1hxwAyx3k4I3tpR23X9jx_VJUh2hFUZC8gjFo3FcM9VLEhMOSKzvxS8GzmyN0PforQgtO6U0X3fBHbY-FpipsYXSfZK9-v1IPKtORDWxTPrJCN1PHg/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.pdf>
> >
> <https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igotNGGbWhACevBJfU1Hxqk90_g-DgQtS9_e_UX_FsY-yAjw/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.pdf
> <https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igotNGGbWhACevBJfU1Hxqk90_g-DgQtS9_e_UX_FsY-yAjw/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.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
> <https://secure-web.cisco.com/1VcbQX_unqZTCQECFjDEGAiKvOG66QPSZlFe-mWT7utsCj88ZllcLwEhj6IDZ4Sa2xTt3w9awwz4kO0XcaEIBvF0pwUr0f-vqdNjHyEFYJjbAwFk0sszCLpq9OR8jL7RkFRButNBcRcFBWHG3PWf0NxWFldrO9SOY_DnhrktT7H7_1RjPUn-tBBJ_Ewy5K_J8bZyWgWqTclnXJ-EnqVx_2YRC-oXQLXP0uplqQb0grFs5H_FD7s9GKfyF0IkF59o_Q-RvIDuxSkxjcIsdwkMEYpl7avwm3xCTfiIe-l1pCPBsusQE8hlhADYbHHu-oLMoJeKbMK21GjoXe2xAFNwlE4EMFGrmJmOuyP373kNiUwNfPugYAnLlTeGHtVGNbROgxMnJRejdAVxRLMYmbUVzrw/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming>
> >
> <https://secure-web.cisco.com/1XqVZXht8sW8tdbLxwEMjoU-hxxV6OJwpKqc2OudZy26Le21yvOIBPwqizepwLi9TBeEV2BMDc-nCiKpj3eryi59jqvoZcBRrSQSVt9Qrq8pIxNSvhIMlG4cRd3lnj17JT9mDRRt0lS51C_9gpryV6qFqdiROdyJeTKfqUGmnvPo3isfeUbC_TOOfWLDV16jYA38ytCfTOryyDvJgJdYw7ArAUEMg10jNv8lV9aTARBOcOmgLjqJt0ktecsUpUCfIVAQlJEvtAAbWAUKwMoXg6MpIQEA4NE1ATntmwjLGl4IqQEqRAGxkGxWI8yQDL74yPPTIQmGTxs_JXE6YYMrhuD93GR1kyUJkOAH3Z_5nL1bsr3ifW31PJtUckQNnwY8e/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming
> <https://secure-web.cisco.com/1XqVZXht8sW8tdbLxwEMjoU-hxxV6OJwpKqc2OudZy26Le21yvOIBPwqizepwLi9TBeEV2BMDc-nCiKpj3eryi59jqvoZcBRrSQSVt9Qrq8pIxNSvhIMlG4cRd3lnj17JT9mDRRt0lS51C_9gpryV6qFqdiROdyJeTKfqUGmnvPo3isfeUbC_TOOfWLDV16jYA38ytCfTOryyDvJgJdYw7ArAUEMg10jNv8lV9aTARBOcOmgLjqJt0ktecsUpUCfIVAQlJEvtAAbWAUKwMoXg6MpIQEA4NE1ATntmwjLGl4IqQEqRAGxkGxWI8yQDL74yPPTIQmGTxs_JXE6YYMrhuD93GR1kyUJkOAH3Z_5nL1bsr3ifW31PJtUckQNnwY8e/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming>>
> >
> >
> > On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io <mailto:ben at mord.io>
> > <mailto:ben at mord.io <mailto: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
> <http://secure-web.cisco.com/1iHjjTtGT6OdOsOVAVj_MWbK7ZgkVPaS5cpYQ9uRNiujQk2TIf9vY4NAwhVQFwPLGsl0H9FaZYFlyOCo16Ivd9gIGVUo5XIrrwOuHEUKBSj3yFKfKKefRHtCQPZ2HEZi-1MO86cmNRtwnQYDm_i9Go6BJDpctCrNWnxv189sncNPgGLmZcKcl2830X-tmJy0zBPyglQyd2B24vG46VuOIobRt3iHz7oPLoWDn17Oj4U1GyDo6PhG-vkYn9j3pkSoU5QtEkJSpjzFEF1XJpIG_oxr1p3MEtIQZ1Cce7Rp4oe3qTkENaHR4K-8yQQOicT-wRruCad-xALJddFq__z75v4ufN86TW19Tg3epmhdQrD9R_Uuw04aLihzPbi5twLfUfZJ54MRptQ1e80d5OiXVLA/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html>
> >
> <http://secure-web.cisco.com/1ewGQFfIxw1QZwneD3sDbhSSWP-YTmBwOYe529E7_zeYZZADnASbspvBAftPFXX6ZxJI2l2-8-xEqdpkmFg3fEIfkfRBYN8oZ8Z0HpeHh73MnT3Zi3M8GUs8SGMww38ZPnzsc7xlt7H5KFlLMcCsTWIgEtq4roZHDkYasanNeViP_UA3DIod7A281fNvWnQ1mnLs6d8WN_uFx1diU_xr-EoMab3wyANozirDj1gZ2_yPBn6S8tePYMkTkhIZlLz_BlvIfk9_KCOOiUcWxDTtCq9KdvoqEzStC04Z6q8xS5rtSnmK9GZZxv30yrgT8eWA4eOzce6AA3m0WEClNzbzANgi11GXBVde9pNiUIRcLDNw/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html
> <http://secure-web.cisco.com/1ewGQFfIxw1QZwneD3sDbhSSWP-YTmBwOYe529E7_zeYZZADnASbspvBAftPFXX6ZxJI2l2-8-xEqdpkmFg3fEIfkfRBYN8oZ8Z0HpeHh73MnT3Zi3M8GUs8SGMww38ZPnzsc7xlt7H5KFlLMcCsTWIgEtq4roZHDkYasanNeViP_UA3DIod7A281fNvWnQ1mnLs6d8WN_uFx1diU_xr-EoMab3wyANozirDj1gZ2_yPBn6S8tePYMkTkhIZlLz_BlvIfk9_KCOOiUcWxDTtCq9KdvoqEzStC04Z6q8xS5rtSnmK9GZZxv30yrgT8eWA4eOzce6AA3m0WEClNzbzANgi11GXBVde9pNiUIRcLDNw/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html>>
> >
> > Thanks,
> > Ben
> >
> >
> > On Nov 17, 2017 8:04 AM, "Christian Decker"
> > <decker.christian at gmail.com
> <mailto:decker.christian at gmail.com>
> <mailto:decker.christian at gmail.com <mailto:decker.christian at gmail.com>>>
> > wrote:
> >
> > On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io <mailto:ben at mord.io>
> > <mailto:ben at mord.io <mailto:ben at mord.io>>> wrote:
> >
> > Ivan,
> >
> > That is mostly false, but with bits of truth sprinkled
> > in. Contact me at ben at mord.io <mailto:ben at mord.io>
> <mailto:ben at mord.io <mailto: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
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> > <mailto:Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>>
> >
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> <https://secure-web.cisco.com/1Z80ybEZtSxMFvIVLI91NzX8bnd-dcAxFAcjmztkHu2A5AIto_cmfcpa6XKnhGzOC25Isf717_ZKWYqMl4P9PhE2nUCOq8pAwcM6y6d7M2RtxKz0m67F-yoYBLiCGtIV7x9jSuQOjZOHP3HVOUWY6znvyVPmV0pSLklLGd82v4EpKikFAOEsPGht5jZ0Iy3JkMe457t3HRMJHlFPyhb_bxDbNXlgZEZyWZxI_HGxBqwI8dS1Ul4LoM2HR-AdrJtFYQQmzD3UZe32pxFpQ4auJCX_2w8bVJL0q4k6mHAI5aU73F-Ln1ah_LspgtJpxOBs1YW3iF6fAbxiRmmevGoa7tg_m1Gh12ek82m8K_-VWKV5zSMd2NHmi54tAFaYh3DAmxuo7pk_1usffGiTSb84-Z4Fis4U22PvkbHyAUgC6XLs/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev>
> >
> <https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev
> <https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev>>
> >
> >
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> >
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev
> <https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev>
> >
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> <https://secure-web.cisco.com/1Z80ybEZtSxMFvIVLI91NzX8bnd-dcAxFAcjmztkHu2A5AIto_cmfcpa6XKnhGzOC25Isf717_ZKWYqMl4P9PhE2nUCOq8pAwcM6y6d7M2RtxKz0m67F-yoYBLiCGtIV7x9jSuQOjZOHP3HVOUWY6znvyVPmV0pSLklLGd82v4EpKikFAOEsPGht5jZ0Iy3JkMe457t3HRMJHlFPyhb_bxDbNXlgZEZyWZxI_HGxBqwI8dS1Ul4LoM2HR-AdrJtFYQQmzD3UZe32pxFpQ4auJCX_2w8bVJL0q4k6mHAI5aU73F-Ln1ah_LspgtJpxOBs1YW3iF6fAbxiRmmevGoa7tg_m1Gh12ek82m8K_-VWKV5zSMd2NHmi54tAFaYh3DAmxuo7pk_1usffGiTSb84-Z4Fis4U22PvkbHyAUgC6XLs/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171122/18196616/attachment-0001.sig>

2023-06-09 12:47:48

- reply

📅 Original date posted:2017-11-30
📝 Original message:
Hi Laolu,
Thanks for your detailed and interesting reply. Please see below some
points I would like to make in some of your comments and the answers to
your questions in the last email. And of course, I would be happy to
further discuss with you.
On 11/25/17 2:16 PM, Olaoluwa Osuntokun wrote:
> (final try as the prior mail hit the size limit, sorry for the spam!)
>
> Hi Pedro,
>
> I came across this paper a few weeks ago, skimmed it lightly, and noted a
> few interesting aspects I wanted to dig into later. Your email reminded me
> to re-read the paper, so thanks for that! Before reading the paper, I
> wasn't aware of the concept of coordinate embedding, nor how that could be
> leveraged in order to provide sender+receiver privacy in a payment network
> using a distance-vector-like routing system. Very cool technique!
>
>
> After reading the paper again, my current conclusion is that while the
> protocol presents some novel traits in the design a routing system for
> payment channel based networks, it lends much better to a
> closed-membership, credit network, such as Ripple (which is the focus of
> the paper).
>
I personally do not agree with this conclusion. The Ripple network uses
a global ledger that contains all the nodes, all the credit links among
them and the weight of each credit link at all points in time.
Therefore, as such, every user can simply check such public information
and decide a route with enough credit on its own. There is no need for a
decentralized routing algorithm on Ripple as all the information is
being continuously updated in the ledger.
In the work we present in this paper, we focus instead on a
decentralized payment network, where the links’ states (e.g., bitcoin
balances in the payment channels within LN) are not continuously logged
in the blockchain but instead, every link is locally maintained by the
corresponding pair of users. With such setting in mind, we have designed
our routing algorithm (SpeedyMurmurs) and we believe it has potential to
be used in the Lightning network as well.
>
> In Ripple, there are only a handful of gateways, and clients that seek to
> interact with the network must chose their gateways *very* carefully,
> otherwise consensus faults can occur, violating safety properties of the
> network. It would appear that this gateway model nicely translates well to
> the concept of landmarks that the protocol is strongly dependant on.
> Ideally, each gateway would be a landmark, and as there are a very small
> number of gateways within Ripple (as you must be admitted to be a verified
> gateway in the network), then parameter L (the total number of landmarks)
> is kept small which minimizes routing overhead, the average path-length,
> etc.
>
I think this description confuses the terms: gateway, validator and
landmark. A gateway is an online exchange service that is trusted to
correctly create a credit link with a new user in the Ripple network. If
Alice has a Ripple wallet but no credit link yet in the Ripple network,
she can get her first issued credits on a link with a gateway.
Similarly, Alice can use such online exchange service to get her first
bitcoins by paying fiat currency, for instance. Importantly, a gateway
does not take part in the Ripple Consensus Algorithm, and therefore a
gateway cannot provoke consensus failures and violate safety properties.
The Ripple consensus algorithm is run among a set of validators. A
validator is the one that can provoke consensus failures. Note that a
validator is a participant in the consensus protocol that might not even
have a wallet in the Ripple network and therefore might not even be a
gateway. For example, MIT and Microsoft have run a validator and are not
gateways in the Ripple network.
Finally, a landmark as used in SpeedyMurmurs, the routing algorithm we
propose in this paper, is simply a node in the network that it is
*only* used to bootstrap the routing algorithm, and any node in the
network can do so. In the very specific case of a decentralized version
of the Ripple network such as SilentWhispers
(https://eprint.iacr.org/2016/1054), gateways become good candidates to
be such landmarks. However, the routing algorithm that we propose in
SpeedyMurmurs is by no means tied to gateways and in particular,
landmarks can be simply nodes chosen at random from the complete set of
nodes in the network, as we show in the paper. Therefore, we believe
that SpeedyMurmurs might be suitable for different payment networks, and
in particular for the LN.
>
> When we compare Ripple to LN, we find that the two networks are nearly
> polar opposites of each other. LN is an open-membership network that
> requires zero initial configuration by central administrators(s). It more
> closely resembles *debit* network (a series of tubes of money), as the
> funds within channels must be pre-committed in order to establish a link
> between two nodes, and cannot be increased without an additional on-chain
> control transaction (to add or remove funds). Additionally, AFAIK (I'm no
> expert on Ripple of course), there's no concept of fees within the
> network. While within LN, the fee structure is a critical component of the
> inventive for node operators to lift their coins onto this new layer to
> provider payment routing services. Finally, in LN we rely on time-locks
> in order to ensure that all transactions are atomic which adds another set
> of constraints. Ripple has no such constraint as transfers are based on
> bi-lateral trust.
>
I agree that comparing Ripple and LN is like comparing apples and
oranges. For starters, Ripple is a “blockchain-focussed” payment network
as *all* the operations in the network are registered in the blockchain
while the LN only uses the blockchain for opening and closing a payment
channel. Ripple is a credit network while the LN is a debit network. And
many other differences.
There are some similarities though. In Ripple *there is* also the
concept of fee being charged for forwarding a payment and for currency
exchange. This fee structure has a similar motivation as in the LN:
create an incentive for users to be used as intermediate hops in
payments. Both networks face/will have to face similar challenges:
bootstrapping, i.e., how to create the first credit link/payment channel
for a new user in the network and with whom so that one can transact
with the rest of the network; liquidity: i.e., what should be the
network topology and how much credit/debit there should be in the
links/channels so that every user can transact to any other user in the
network; and many others.
But again, in SpeedyMurmurs we are not presenting a routing algorithm
for a “blockchain-centered” payment network like Ripple but rather a
routing algorithm for a decentralized payment network such as
SilentWhispers, LN, Raiden Network or Interledger.
>
> With that said, the primary difference between this protocol is that
> currently we utilize a source-routed system which requires the sender to
> know "most" of the path to the destination. I say "most" as currently,
> it's possible for the receiver of a payment to use a poor man's rendezvous
> system to provide the sender with a set of suffix paths form what one can
> consider ad-hoc landmarks. The sender can then concatenate these with
> their own paths, and construct the Sphinx routing package which encodes
> the full route. This itself only gives sender privacy, and the receiver
> doesn't know the identity of the sender, but the sender learns the
> identity of the receiver.
>
> We have plans to achieve proper sender/receiver privacy by extending our
> Sphinx usage to leverage HORNET, such that the payment descriptor (payment
> request containing details of the payment) also includes several paths
> from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
> itself will be nested as a further Anonymous Header (AHDR) which includes
> the information necessary to complete the onion circuit from Rodrigo to
> the receiver. As onion routing is used, only Rodrigo can decrypt the
> payload and finalize the route. With such a structure, the only nodes that
> need to advertise their channels are nodes which seek to actively serve as
> channel routers. All other nodes (phones, laptops, etc), don't need to
> advertise their channels to the greater network, reducing the size of the
> visible network, and also the storage and validation overhead. This serves
> to extend the "scale ceiling" a bit.
>
Two comments here:
* As Christian Decker indicated in a previous email, this routing
technique assumes that the routing layer and the onion layer are
together by default. This is obviously an interesting alternative worth
exploring and investigating what advantages/disadvantages it has and
what are the inherent tradeoffs.
* Nevertheless, it is obviously not the only alternative. We could
separate the routing layer from the onion layer and study what
advantages/disadvantages we can get from there. For instance, in
SpeedyMurmurs, nodes only need to announce their channels to their
neighbors and yet they are able to reconstruct a path from sender to the
receiver. Our current experiments show that this simplicity has
enormous benefits in terms of performance.
In my opinion, it is interesting to look at tradeoffs and the
necessary/sufficient guarantees for the routing algorithm in a
decentralized payment network such as the LN before we stick to a solution.
>
> My first question is: is it possible to adapt the protocol to allow each
> intermediate node to communicate their time lock and fee references to the
> sender? Currently, as the full path isn't known ahead of time, the sender
> is unable to properly craft the timelocks to ensure safety+atomicity of
> the payment. This would mean they don't know what the total timelock
> should be on the first outgoing link. Additionally, as they don't know the
> total path and the fee schedule of each intermediate node, then once
> again, they don't know how much to send on the first out going link. It
> would seem that one could extend the probing phase to allow backwards
> communication by each intermediate node back to the sender, such that they
> can properly craft a valid HTLC. This would increase the set up costs of
> the protocol however, and may also increase routing failures as it's
> possible incompatibilities arise at run-time between the preferences of
> intermediate nodes. Additionally, routes may fail as an intermediate node
> consumes too many funds as their fee, causing the funds to be insufficient
> when it reaches the destination. One countermeasure would maybe: the
> sender always sends waaay more than necessary, and gives the receiver a
> one-time payment identifier, requiring that they route the remainder of
> the funds *back* to them.
>
>
> To solve this issue presently, we extend the header in Sphinx to include a
> per-hop payload which allows the sender to precisely dictate the
> structure of the route, allows the intermediate nodes to authenticate the
> information given to it, and also allow the intermediate node to verify
> that their policies have properly been respected. These payloads can also
> be utilized by applications to communicate a small-ish amount of data to
> construct higher-level protocols on top of the system. Examples include:
> cross-chain swaps, chance payment games, higher-level B2B protocols,
> flavors of ZKCP's, media streaming, internet access proxying, etc.
>
For what I understand, what you are asking/proposing is a mixture of the
routing layer (route from sender to receiver) + onion layer (using
“adapted”/”optimized” sphinx)+ payment layer (HTLCs). Even in this mixed
alternative, we might want to investigate what are the guarantees and
tradeoffs provided. For instance, in another recent work from us
(https://eprint.iacr.org/2017/820), we proposed multi-hop HTLC: A
modification of the HTLC contract so that the condition of the
conditional payment does not lead to privacy issues.
However, I rather prefer the approach of looking at one layer/component
at a time and see what optimizations we can perform there and what are
the inherent impossibilities. Therefore, we have not thoroughly studied
yet how to integrate the routing algorithm we propose in SpeedyMurmurs
with a possible payment operation. Having said that, some variation of
what you sketched might work. Another proposal might consist on a
payment operation that does not assume source-routing to start with.
There are many possibilities to investigate and think about.
>
> From my point-of-view, when extended to LN, the core component of the
> protocol (landmarks), becomes the weakest component. From my reading,
> *all* nodes need to be ware of an *identical* set of landmarks (more or
> less similar to the desired homogeneity of Gateways), otherwise the
> coordinate embedding scheme breaks down. Currently, there's no requirement
> that all nodes have a globally consistent view of the network. So then an
> important questions arises: who choose the landmarks? A desirable property
> of a routing system for LN (IMO) is that is has close to zero required
> initial set up by a central administrator. With this protocol, it would
> seem that all nodes much ship with a hard coded set of global landmarks
> for the path finding to succeed. This itself pins a hard coordination
> requirement amongst implementers to have something like this deployed.
I think your description here might not be accurate for what I
understand. What you describe here is indeed a problem inherent to the
original landmark routing mechanism. However, it is no longer an issue
in SpeedyMurmurs. In particular, any node could be a landmark or two
users could have a different view of what set of nodes constitute the
set of landmarks. As soon as sender and receiver have a non-empty
intersection of their set of landmark-nodes, SpeedyMurmurs provides a
route among them.
In the approach we present in SpeedyMurmurs, the landmark is just a node
that declares himself a landmark by triggering to his neighbors the
chain of messages required to construct the embeddings in the whole
network. Any node in the network can do this. Moreover, in
SpeedyMurmurs, this is a one-time thing. Once a set of embedding are
created, the landmark is not used again. Changes in the network topology
are locally handled by the neighbors of the newly connected/disconnected
node.
> Even ignoring this requirement for a minute, I see several other
> downsides:
>
> * As *all* payments must flow through landmarks (since nodes break up
> their payment into L sub-flows), the landmarks must be very, very
> well capitalized. This would cause strong consolidation of the
> selection of landmarks, as they need extremely large channels in
> order to facilitate transfer within the network.
This is true in the original landmark routing. However, this is no
longer the case in SpeedyMurmurs. Paths no longer require to have the
landmark as intermediate user. Even further, a path from a sender to the
receiver might use links that are not even part of the spanning tree. We
call them “shortcuts” in the paper. We designed it like this having the
capitalization problem you mentioned in mind.
>
> * As landmarks must be globally known, this it seems this would
> introduce fragility in the network. If most of the landmarks go down
> (fails stop crashes) due to hardware issues, DoS, exploited bugs,
> etc, then the network's throughput instantly becomes crippled.
Again, this is true in the original landmark routing, not the case in
SpeedyMurmurs. We use the landmarks as a one-time setup and any node
could be a landmark. In particular, every node in the network could be
the landmark if it is really DoS-sensitive. We just require that a
sender and a receiver have a non-empty intersection of the landmarks
that they have seen so far.
>
> * If all payment flow *must* go through landmarks, and the transfers
> within the network are relatively uni-directional (all payment going
> to Candy Crush Ultra: Lighting Strikes Twice), then their
> channels would become unbalanced very quickly.
Again, this is true in the original landmark routing, not the case in
SpeedyMurmurs. Payments *must not* go through landmarks any longer with
our approach. Moreover, unbalanced payment channels are an issue to
consider independently of the routing algorithm that is in use.
All in all, it seems that there might be some misconceptions and/or
aspects in the current draft of the paper that might need clarifications
so that the approach is well understood. We are more than happy to
further talk about it and answer questions, doubts or concerns that
might arise.
>
>
> The last point there invokes another component of the network: passive
> channel rebalancing. With source routing, it's possible for nodes to
> passive rebalance their channels, in order to keep the in equilibrium,
> such that on average they'll be able to handle a payment flow coming from
> any direction. This is possible as with source routing, it's easy for a
> node to simply send a payment to himself incoming/outgoing from the pair
> of channels they wish to adjust the available flow of. With
> distance-vector-like protocols, this doesn't seem possible, as the node
> doesn't have any control of the incoming channel that the payment will
> arrive on.
>
I think this is another case of mixing functionalities at different
layers. I do agree that unbalanced channels is an interesting problem to
deal with. I, however, do not agree that we should choose one routing
approach or another based on how unbalanced channels are handled.
In my understanding, what you propose requires several assumptions: (i)
the node should be aware of “enough” network topology so that it is
aware of those “special topology shapes”. However, if opening channel
operations are indistinguishable from other payments in the Bitcoin
blockchain, this is not trivial. However, company X might not want to
reveal its channel with company Y to its competitors; (ii) such
circular/suitable paths actually exist. However, this might just not be
the case. (iii) The chosen path(s) has enough liquidity for the
“equilibrium”. As the node is not aware of the current capacity of each
of the channels, it might be the case that several payments are required
for the equilibrium to happen.
In any case, my point is not to discuss whether the problem of
unbalanced channels is interesting. My point is that I think we should
not stick to one routing algorithm depending on how another
algorithm/functionality at another layer is handled, at least not before
we explore and fully understand the tradeoffs, benefits and
impossibilities that we will have to face here.
>
> Finally, the notion of value privacy within the scheme seems a bit weak.
> From this definition, any protocol that didn't broadcast intents to send
> payments to the world would achieve this trait. The base Bitcoin
> blockchain doesn't mask the values of transfers (yet), but even if it did
> unconditionally maintaining value privacy of channel doesn't seem
> compatible with multi-hop payment networks (nodes can simply perform
> probing/tagging attacks to ascertain a range of the size of a channel). A
> possible mitigation would be for nodes to probabilistically drop incoming
> payments, with all nodes sampling from the same distribution. However,
> this would dramatically increase routing failures by senders, removing the
> "low-latency" trait of payment networks that many find desirable.
>
I totally agree with you here. I believe that having stronger notions of
value privacy is conceptually hard. Imagine that the payment value must
be routed through the path from sender to the receiver. In particular,
any intermediate node must know what value is receiving from its
predecessor to forward the corresponding value to the successor node in
the path.
>
> Personally, I've very excited to see additional research on the front of
> routing within the network! Excellent work by all authors.
Thanks. Really looking forward for further conversations and discussions.
>
>
> In the end, I don't think it'll be a one-size fits all solution, as each
> routing protocol delivers with it a set of tradeoffs that should be
> weighed depending on target characteristics, and use-cases. There's no
> strong requirement that the network as a whole uses a *single* routing
> protocol. Instead several distinct protocols can be deployed based on
> use-case requirements, as we only need to share a single end-to-end
> construct: the HTLC. I could see a future in a few years where we have
> several deployed protocols, similar to the wide array of existing routing
> protocols deployed on the Internet. What we have currently gets us from
> Zero to One. We'll definitely need to experiment with additional
> approaches as the size of the network grows, and the true economic flow
> patterns emerge after we all deploy to mainnet.
>
I also agree with you here. I also think that there might be several
routing approaches at the routing layer, the same way we have BGP, OSPF,
RIP protocols for routing in IP today. I also believe that we might have
more than just HTLC-based payments in the LN, but this is the topic for
another long email :)
Many thanks again for the feedback and looking forward for more
conversations,
Pedro.
>
> -- Laolu
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171130/9fc27a52/attachment-0001.sig>

2023-06-09 12:47:45

- reply

📅 Original date posted:2017-11-21
📝 Original message:
Hello,
my name is Pedro Moreno-Sanchez and I am a PhD student at the computer
science department at Purdue. I would like to bring to your attention a
novel routing algorithm suitable for the Lightning Network (LN) that I
have been working on with my supervisor Prof. Aniket Kate (Purdue
University) and my co-workers Stefanie Roos and Prof. Ian Goldberg
(University of Waterloo).
Our approach is called SpeedyMurmurs, a routing algorithm for
decentralized payment networks such as the LN. SpeedyMurmurs uses an
embedding-based approach, meaning that the algorithm assigns meaningful
coordinates to nodes that enable efficient and effective discovery of
payment paths. In a nutshell, SpeedyMurmurs creates a spanning tree by
means of a Breadth-First Search and then associates a coordinate to each
node depending on its position in the tree. A path from the sender to
the receiver is then calculated in a flexible manner, with each
intermediate node choosing the next node in the path as a function of
its neighbors' coordinates, available funds and closeness to the
receiver. To account for topology changes (e.g., a new channel is
created), the routing information is locally updated by only those
affected nodes in the network.
We have simulated several configurations of SpeedyMurmurs using real
data from the Ripple network and compared it with other routing
algorithms available in the literature. Our simulation results show that
SpeedyMurmurs is able to find paths at about twice faster, reduces the
communication overhead by at least a factor of 2 and maintains a similar
or higher payment success ratio. Our simulation framework is open source
and we believe that it might be of independent interest for this
community to test this and any other alternative protocols that you
might have in mind. If you are interested, we are happy to extend on this.
Finally, we also show that SpeedyMurmurs achieves the privacy notions of
interest in the LN. In particular, SpeedyMurmurs achieves value privacy,
i.e., the total value of a transaction remains hidden, as well as sender
and receiver privacy, i.e., the identities of the two transacting nodes
remain hidden from the adversary.
You can find all the details in the draft of our paper [1]. The final
version of this work will appear at NDSS 2018 conference [2]. We would
be glad to hear any question and feedback from you and are open to carry
out further collaborations if this line of work is of interest for you.
Best regards,
Pedro, Stef, Aniket and Ian.
[1] https://arxiv.org/abs/1709.05748
[2] https://www.ndss-symposium.org/
On 11/17/17 8:09 PM, Saravanan Vijayakumaran wrote:
> Hi Christian,
>
> Are there any open source simulators available for trying different
> routing strategies? Or even a simulator for the Lightning network as a
> whole?
>
> Regards
> sarva
>
>
> On Fri, Nov 17, 2017 at 8:00 PM, Christian Decker
> <decker.christian at gmail.com <mailto: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
> <https://secure-web.cisco.com/1wkWGu7k6qIvsw8KxbTL8XXIpbTYjcgzOohVSUjpLJpNW0_r00YaFlguhX0pSCEAg2qU5kztXF4bxEpLbMz-RLAz9KTBvE0lh3kFGUjL5qke6yx8EcYvhHQQSttWjRX5HOt69vu8suXd7AhjEweVxeBFhvptINqjBarDx7woqCa14ZgWZdMk0dAt45Lnu_w1wjgn3j5sD7tBo187MGXR94eapimiMFjXySj70GeP1yiEA8rP0NUQ5CSXme2wQy-spVW_SLQpvkAQ01NlXUjK-ufQw_APez6C73Qx0bFh_9F-CPhKhhvM3tSs6IGNEM63aXMVeti2Ci0R5Xc15tvcT9gxpC32bNetja5ber6wbIHLbI9FWviQ63cWaNwhedQRN/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fblob%2Fmaster%2F07-routing-gossip.md>
> [2]
> https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad
> <https://secure-web.cisco.com/1UG1OaEI1KFpQ4prjxrhN1Wsxs0P1Tco0MXQz0xltJZQjwI-sNi98eXMz-gW4qOQd2jJ4i0uktvL8CH-9RrmEg3GkxHfcxjnjxY_hlLP-ctXOYMSk4BFbySy7vD5xWivimHIfMHtr13ffgEoFLItUgoajxUe7tnkchPN_P5OZ_FOzYdpqW_UDdgWW0_VOsccR5yt1vh0MRyVxO2B2ua8k4NmbFgTmht6hxUlXDsXOsOSGDHm1WO5VNrRbUcGeTPpdBMx0xeyZ9FTMTBCIAMOZ6UEb_eAX3X1iVIFkP_MPtuJcp0q8t9Tk_UBs-dHVRjyYcCsnetXYNI_mEsdtyg63aLXuJE1pMLb8-eamWaFfklVo-w9N9F0XTbmbkgGfcWU4/https%3A%2F%2Fmedium.com%2F%40rusty_lightning%2Flightning-routing-rough-background-dbac930abbad>
> [3]
> https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf
> <https://secure-web.cisco.com/1XOlJdRo0gtzmPhNfVlEpMsrVBAI6BSjdDawPogEDIwYDdva2BSx4H8F9B3E6bkVIqA7ByFEF85qVjJ775leFwE54p5G6-wHH4Cio0p9sYLJ14-NHwcwvYQ--zdI8hdAyjGQbcLltVFAmorMaTlHq4FGI1CmxlwiUYgH1tjZn3UAHOu5xm5pLVi6KTb9WsJvuJsOBJhLfRLWGcAhVbjRXuV8b3x_G4ybOg1CQYC9ZVq3RJCPnNgQ3BN3a5ZuzW4veOE_dgi80FEy1x7a8spH-TV-cb_fey6ud-S25AWQ1PbctVS5zgQ4Ki4XYkR5igotNGGbWhACevBJfU1Hxqk90_g-DgQtS9_e_UX_FsY-yAjw/https%3A%2F%2Fwww.tik.ee.ethz.ch%2Ffile%2Fa20a865ce40d40c8f942cf206a7cba96%2FScalable_Funding_Of_Blockchain_Micropayment_Networks%2520%281%29.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
> <https://secure-web.cisco.com/1XqVZXht8sW8tdbLxwEMjoU-hxxV6OJwpKqc2OudZy26Le21yvOIBPwqizepwLi9TBeEV2BMDc-nCiKpj3eryi59jqvoZcBRrSQSVt9Qrq8pIxNSvhIMlG4cRd3lnj17JT9mDRRt0lS51C_9gpryV6qFqdiROdyJeTKfqUGmnvPo3isfeUbC_TOOfWLDV16jYA38ytCfTOryyDvJgJdYw7ArAUEMg10jNv8lV9aTARBOcOmgLjqJt0ktecsUpUCfIVAQlJEvtAAbWAUKwMoXg6MpIQEA4NE1ATntmwjLGl4IqQEqRAGxkGxWI8yQDL74yPPTIQmGTxs_JXE6YYMrhuD93GR1kyUJkOAH3Z_5nL1bsr3ifW31PJtUckQNnwY8e/https%3A%2F%2Fgithub.com%2Flightningnetwork%2Flightning-rfc%2Fwiki%2FBrainstorming>
>
>
> On Fri, Nov 17, 2017 at 3:10 PM Benjamin Mord <ben at mord.io
> <mailto: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
> <http://secure-web.cisco.com/1ewGQFfIxw1QZwneD3sDbhSSWP-YTmBwOYe529E7_zeYZZADnASbspvBAftPFXX6ZxJI2l2-8-xEqdpkmFg3fEIfkfRBYN8oZ8Z0HpeHh73MnT3Zi3M8GUs8SGMww38ZPnzsc7xlt7H5KFlLMcCsTWIgEtq4roZHDkYasanNeViP_UA3DIod7A281fNvWnQ1mnLs6d8WN_uFx1diU_xr-EoMab3wyANozirDj1gZ2_yPBn6S8tePYMkTkhIZlLz_BlvIfk9_KCOOiUcWxDTtCq9KdvoqEzStC04Z6q8xS5rtSnmK9GZZxv30yrgT8eWA4eOzce6AA3m0WEClNzbzANgi11GXBVde9pNiUIRcLDNw/http%3A%2F%2Fben.mord.io%2Fp%2Fdelayed-chained-key-revelation-dckr.html>
>
> Thanks,
> Ben
>
>
> On Nov 17, 2017 8:04 AM, "Christian Decker"
> <decker.christian at gmail.com <mailto:decker.christian at gmail.com>>
> wrote:
>
> On Thu, Nov 16, 2017 at 5:01 PM Benjamin Mord <ben at mord.io
> <mailto:ben at mord.io>> wrote:
>
> Ivan,
>
> That is mostly false, but with bits of truth sprinkled
> in. Contact me at ben at mord.io <mailto: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
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> <mailto:Lightning-dev at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> <https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev>
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://secure-web.cisco.com/1rKvOL6YDFMOjqgsWHIPJzPSwJMPOfbibptuquR_1TsVdIQrLf1NxCVE-s5WE1ZYrdP24xdimGxHK9mO5lyt539Tkw2lzYa9rwS9--thSiY_hjklJDMsHrV19nNF8fOU35MvLMeISx2brsJSH0K4MNQpctvdWWImDsvS4rwweaXJRgtUfd1uSxbqCGdjJ7KTTOlWCdUehIfdcJtlBoiUGIy2yKJMqn7uLJT4tXQQWbGZAou9uWgwGJmHnUk4oW05-otW_6u-nrcT1jhnhPGcP6x6_k8EMv1PaCs5w0baDgHhZ09GvGpSFr9Wmk8cd69ob8sEcl6xXHuFHTt1GHMh6KfMOc11pAXgM6FsY6B35bjHVVOw0DiIz7n_a8w-RLxc-/https%3A%2F%2Flists.linuxfoundation.org%2Fmailman%2Flistinfo%2Flightning-dev
>