Benjamin Mord [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-11-16 to 2018-05-08
💬 Posted a total of 28 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub16ycdmhx5sct3h37cwvjff8le7qlp9k0ngst5ry5n262j6gkesrssskjvwy

Profile Code

nprofile1qqsdzvxamn2gv9cmclv8xfy5nlulq0sjm8e5g96pj2f4d9fdytvcpcgpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dsj4umv0

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub16ycdmhx5sct3h37cwvjff8le7qlp9k0ngst5ry5n262j6gkesrssskjvwy

Show more details

Last Notes

2023-06-09 14:50:42

- reply

📅 Original date posted:2018-05-08
📝 Original message:
Good evening Jim,
> I don't agree that quantum resistance should be a blocker to deployment of
> scriptless scripts on lightning
>
I don't mean to speak narrowly about quantum cryptanalysis, but more
generally about the need for backups to every primitive we use. DL is no
exception, but for DL signatures, we do have lattices.
> because 1) it is a layer-2 solution
>
If this becomes global financial infrastructure, then layer 2 security will
matter enough to merit some cryptographic conservatism. What if lightning
succeeds fabulously? I think, it might.
> and 2) it already critically depends on the security of DL.
>
Does it? In specific form, sure - but in a pinch, could lattice-based
algorithms not be swapped on relatively short notice, without changing the
conceptual architecture? Perhaps I'm overlooking something, but I think
probably, yes.
> There are arguments against making certain protocol changes to the base
> Bitcoin blockchain for the reason that they may not be quantum resistant.
> The most notable is Confidential Transactions. There reason is that the
> worst case attack is much worse: an attacker could print money freely and
> without detection.
>
Yes, that risk is entirely unacceptable, I agree - even at a mere $150
billion market cap, and much more so if this one day surpasses USD M3. Of
course, if one knew the attack, it would be tempting to advocate for the
weakness. I'm not making such an accusation here of course, I'm just saying
that cryptographic conservatism helps demonstrate and maintain alignment of
interests, and to demonstrate such alignment also to skeptical observers.
> In Bitcoin today, a DL break would compromise funds in any addresses for
> which the pubkey has been revealed and it's not even clear what to do about
> the remaining funds on chain. Compromising the fundamental security of the
> blockchain is a valid cause for concern.
>
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.
> 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.
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.
Thanks,
Benjamin Mord
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/efb40998/attachment-0001.html>

2023-06-09 14:50:41

- reply

📅 Original date posted:2018-05-08
📝 Original message:
Sorry, I do not wish to spam the list, but I need to correct a rather
serious error in my last email. We must never call something
"post-quantum", absent mathematical proof. (And good luck with that.) I
apologise for my mistake in doing so myself.
I should not even refer to lattice based cryptography as a post-quantum
algorithm, I should at best call it a Shor's algorithm-resistant scheme. At
least, it is not (yet) known how Shor's algorithm could be used to break
it. Not in public circles, anyhow.
A cursory glance at the history of cryptanalysis shows that primitives
generally have finite life, which makes it odd that systems seldom use
redundant primitives, and seldom provide for their rapid and safe swap. A
system whose entire security rests on nothing but cryptography, ought to
take particular care! The spectre of quantum computers may render the
finite life of certain primitives more salient than others, but we must not
suppose that, absent Shor's algorithm, there would be no need to plan for
cryptographic failures. The question is not if, but when, Bitcoin and
lightning will contend with broken primitives, whether due to classical or
quantum cryptanalysis. Likely, both will come into play at various times,
and one must plan accordingly.
On Tue, May 8, 2018, 9:09 AM Benjamin Mord <ben at mord.io> wrote:
>
> That would be awesome. Do you have a reference?
>
> As pertains to the whole of asymmetric cryptography, I believe there are
> not a variety of post quantum schemes, there is only one*: lattice-based
> cryptography. (Which scares me, because it is not all that different from
> the others.)
>
> (* Actually, in contexts where time can be used for asymmetry, as in
> TESLA, we can then use hash functions to create something like asymmetric
> signatures as well. But the functional context has to be compatible with
> delayed verification.)
>
> (But I do not mean to focus exclusively on Schor's algorithm, the history
> of even pre-quantum cryptanalysis shows that primitives tend to have finite
> lifespan. Redundancy of any sort of good, even when not focused
> specifically on quantum risks.)
>
> On Tue, May 8, 2018, 8:58 AM Greg Sanders <gsanders87 at gmail.com> wrote:
>
>> From what I understand talking to folks, the linear properties of these
>> signature tricks are maintained under a number of post-quantum schemes.
>>
>> On Tue, May 8, 2018 at 8:44 AM, Benjamin Mord <ben at mord.family> wrote:
>>
>>>
>>> If I'm not mistaken, the scriptless scripts concept (as currently
>>> formulated) falls to Schor's algorithm, and at present there is no
>>> alternative implementation of the concept to fall back on. Correct? Lest we
>>> build a house of cards, I'd strongly urge everyone to not depend on
>>> functional concepts whose underlying cryptographic primitives cannot be
>>> swapped in an emergency.
>>>
>>> Sure, we use ecdsa for example (which is also vulnerable to Schor's
>>> algorithm), but in contrast to scriptless scripts we have a variety of
>>> backup primitives at our disposal that fulfill the same functional
>>> objective.
>>>
>>> If scriptless scripts are found possible under lattice-based
>>> cryptography for example, that would be something I suppose. The functional
>>> concept of scriptless scripts is indeed very awesome - we just need to add
>>> some cryptographic conservatism before we build on it.
>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/664c63d0/attachment-0001.html>

2023-06-09 14:50:40

- reply

📅 Original date posted:2018-05-08
📝 Original message:
If I'm not mistaken, the scriptless scripts concept (as currently
formulated) falls to Schor's algorithm, and at present there is no
alternative implementation of the concept to fall back on. Correct? Lest we
build a house of cards, I'd strongly urge everyone to not depend on
functional concepts whose underlying cryptographic primitives cannot be
swapped in an emergency.
Sure, we use ecdsa for example (which is also vulnerable to Schor's
algorithm), but in contrast to scriptless scripts we have a variety of
backup primitives at our disposal that fulfill the same functional
objective.
If scriptless scripts are found possible under lattice-based cryptography
for example, that would be something I suppose. The functional concept of
scriptless scripts is indeed very awesome - we just need to add some
cryptographic conservatism before we build on it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/e565d776/attachment.html>

2023-06-09 14:50:40

- reply

📅 Original date posted:2018-05-08
📝 Original message:
That would be awesome. Do you have a reference?
As pertains to the whole of asymmetric cryptography, I believe there are
not a variety of post quantum schemes, there is only one*: lattice-based
cryptography. (Which scares me, because it is not all that different from
the others.)
(* Actually, in contexts where time can be used for asymmetry, as in TESLA,
we can then use hash functions to create something like asymmetric
signatures as well. But the functional context has to be compatible with
delayed verification.)
(But I do not mean to focus exclusively on Schor's algorithm, the history
of even pre-quantum cryptanalysis shows that primitives tend to have finite
lifespan. Redundancy of any sort of good, even when not focused
specifically on quantum risks.)
On Tue, May 8, 2018, 8:58 AM Greg Sanders <gsanders87 at gmail.com> wrote:
> From what I understand talking to folks, the linear properties of these
> signature tricks are maintained under a number of post-quantum schemes.
>
> On Tue, May 8, 2018 at 8:44 AM, Benjamin Mord <ben at mord.family> wrote:
>
>>
>> If I'm not mistaken, the scriptless scripts concept (as currently
>> formulated) falls to Schor's algorithm, and at present there is no
>> alternative implementation of the concept to fall back on. Correct? Lest we
>> build a house of cards, I'd strongly urge everyone to not depend on
>> functional concepts whose underlying cryptographic primitives cannot be
>> swapped in an emergency.
>>
>> Sure, we use ecdsa for example (which is also vulnerable to Schor's
>> algorithm), but in contrast to scriptless scripts we have a variety of
>> backup primitives at our disposal that fulfill the same functional
>> objective.
>>
>> If scriptless scripts are found possible under lattice-based cryptography
>> for example, that would be something I suppose. The functional concept of
>> scriptless scripts is indeed very awesome - we just need to add some
>> cryptographic conservatism before we build on it.
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180508/45b1c742/attachment.html>

2023-06-09 14:50:15

- reply

📅 Original date posted:2018-04-20
📝 Original message:
Good afternoon ZmnSCPxj,
"I do not see a bloom filter?"
Well, if you look at it kinda sideways, you are using a bloom filter in
your March 23rd proposal. As originally defined, I think the "false
positives" in bloom filtering were the unfortunate cost of performance. In
BIP 37, the false positives become desirable, although still are 'false' in
that their only function is to serve as red herrings. But (omitting i for
clarity), your proposal takes BIP 37's spin on bloom filters one step
further to actually take the 'false positives' as the very definition of
our desired set, since what you are "searching for" is just your own public
key, which ends up being the least interesting result within that set.
" Regarding 24 vs 23, the condition for 23 allows a 3 members of a 5-member
neighborhood to think they form a single 3-member neighborhood, while the
remaining 2 members think they are in a 5-member neighborhood that includes
the other 3 members who have formed a 3-member neighborhood."
Oh, I see. But the reason that occurs is because different nodes are
considering different numbers of high-order bits. If everyone used the same
number of high-order bits, then it would become an equivalence
relationship, with which we can partition the network. This is because
then, a=b, would imply b=a, and also a=b and b=c, would imply a=c.
https://en.wikipedia.org/wiki/Equivalence_relation#Partition
I think algorithm from March 24 is broken actually, on second look, but I
understand now what you are trying to achieve. You want to allow local
judgement over best local cell size, and yet somehow end up with precise
uniform agreement on who is in which cells, because cycles require such
precision. But if you throw in that the network is dynamic, knowledge is
imperfect, and malicious behavior may occur, then I think strict
equivalence relationships and cycles become brittle. Perhaps we should
generalize the equivalence relationship into a distance function, so that
we can start thinking of this as a metric space which we want to fill with
some sort of structure. Perhaps then we can design efficient yet robustly
"fuzzy" structures. Perhaps we want a fuzzy fractal of some sort. Hmm...
"Intermediate nodes already know two hops? The incoming and outgoing hop?
Or do you need more information?"
Yes, nodes would need to know one hope more, since the idea would be to
attract competition to the high-usage yet high-fee links.
Thanks,
Ben
On Thu, Apr 19, 2018 at 11:24 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
>
> I think there are two distinct concepts here. The first is the
> identification of a 'neighborhood', and the second is the establishment of
> an order within that neighborhood for purpose of cycle formation.
>
> Your use of bloom filters to define a neighborhood, is I think the most
> valuable contribution. Formation of neighborhoods with high connectivity,
> with sparse but redundant connections among these neighborhoods, does seem
> like an economically efficient approach to maintaining useful competition
> and redundancy. If there are any graph theorists or category theorists on
> the list, perhaps they could offer some formal validation or optimization.
> For this, I prefer your March 23 proposal over March 24, I'm curious what
> improvement is intended in March 24 vs 23?
>
>
> I do not see a bloom filter? But then I am not a mathematician so it is
> possible I fail to see how the Bloom filter arises from the algorithm I
> described.
>
> Regarding 24 vs 23, the condition for 23 allows a 3 members of a 5-member
> neighborhood to think they form a single 3-member neighborhood, while the
> remaining 2 members think they are in a 5-member neighborhood that includes
> the other 3 members who have formed a 3-member neighborhood.
>
>
> The emergent definition and maintenance of a unique ordering for cycle
> establishment within a neighborhood is, I think, a much more ambitious
> undertaking. I'm not sure how we efficiently make that robust in a dynamic
> context, except perhaps with interactive coordination among the members
> operating off something other than just static global data. Otherwise
> different members would have different ideas about cycle order, depending
> on when they first joined. I also don't see how cycles recover when someone
> leaves.
>
> As people come and go, cycles will break. As the lightning network grows
> overall, neighborhoods identified by one setting of the bloom filter will
> become undesirably large. Perhaps a less ambitious but more robust
> heuristic would be one where probability of establishing a channel is
> proportional to the number of bits in common in the pubkey hash, normalized
> by the number of nodes currently observed?
>
>
> I believe that is what the algorithm already does? It dynamically sizes
> neighborhoods to be small, with high probability of neighborhoods to be
> 3->5 members.
>
> This heuristic would automatically adjust granularity over time as
> lightning membership grows and shrinks. Nodes could periodically reevaluate
> their channel allocations as the overall network grows or shrinks.
>
>
> The algorithm does not consider what happens when we have a cycle already
> existing, and a new member joins or an existing one wishes to leave. There
> is no way to inform this. My expectation is that people will just close
> channels that they no longer find useful; this makes funds available
> onchain. Then a process notices there are onchain funds, and calls this
> algorithm to get a proposed channel; this adapts to whatever the topology
> is right now.
>
> It is not clear when we should close channels. For one, gossip requires
> that a node first open a channel to somebody, before its existence is
> acknowledged and gossiped across the network: this is intended to prevent
> spammers from spinning up nodes without actually intending to join the
> network. Similarly, to leave the network, we assume that nodes will at
> least get all their channels closed: channel closure is an onchain event
> visible to everyone monitoring the the blockchain (which is what all LN
> nodes SHOULD do), and once all channels of a node have closed, we MAY drop
> them from the network view (c-lightning implements this, but I do not know
> if other implementations do).
>
> So at least for *leaving* LN permanently, the leaving node SHOULD close
> all its channels (or at least their peers SHOULD close it for them in
> unilateral closes if the peer just does not respond at all anymore). This
> updates the network view of everybody (assuming they follow the
> recommendation that they MAY drop nodes from the network view, if that node
> has all its channels closed). The closing will also put the channel funds
> onchain, and presumably the autopilots of its neighbors will notice the
> onchain funds, calls the algorithm to get a peer to channel to, which
> computes (hopefully) using the updated network view that has the leaving
> node removed already (this may not be true: the leaving node might not be
> able to close all channels simultaneously, and may misbehave and expect its
> neighbors to close the channels for it), and adapts correctly to the node
> leaving the network.
>
> However for a new node entering the network, there is problem. This
> requires existing nodes to close existing channels and open new ones to the
> new node: as this costs onchain fees, there is no real incentive for them
> to do so. I can only fall back on the informal argument: that people will
> at first experiment with the Lightning Network and commit a tiny amount of
> funds, then later they will put in more funds and thus open new channels,
> hopefully using this algorithm so that other people who come in later will
> also get new channels to them: the first channels people make will
> (eventually) not be in the neighborhood later on, but since they will open
> new channels later those will adapt to new neighborhoods of the larger
> network graph.
>
> I believe the main benefit of the algorithm I describe is that it flattens
> the number of channels a node will have and reduces centralization
> (although I believe roasbeef argues that centralization at the LN layer is
> relatively unimportant?). If each node opens two channels to two different
> nodes, pure random selection will by chance award a few lucky nodes with 3
> or 4 or 5 or more incoming channels while about 1/4 of nodes will have no
> channels incoming, but this algorithm will force all nodes to have exactly
> two incoming and two outgoing channels, while having similar reachability
> as random selection. Of course, that assumes everyone already knows the
> entire network beforehand, and the issue of new nodes coming in is absent.
>
>
> Were it not for the privacy goals, dynamic optimization based on actual
> usage would be possible. Nodes could track the routes of payments that flow
> through their channels and could spot fees that seem both large and
> popular, and could use this information to identify under-served nodes to
> which a direct channel might be in order. If we allowed nodes to see two
> hops of the route instead of just the one, then such optimization would
> become possible, although this compromise would require longer minimum
> routes for a given level of privacy.
>
>
> Intermediate nodes already know two hops? The incoming and outgoing hop?
> Or do you need more information?
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180420/ab47485a/attachment-0001.html>

2023-06-09 14:50:14

- reply

📅 Original date posted:2018-04-19
📝 Original message:
Hello ZmnSCPxj,
I think there are two distinct concepts here. The first is the
identification of a 'neighborhood', and the second is the establishment of
an order within that neighborhood for purpose of cycle formation.
Your use of bloom filters to define a neighborhood, is I think the most
valuable contribution. Formation of neighborhoods with high connectivity,
with sparse but redundant connections among these neighborhoods, does seem
like an economically efficient approach to maintaining useful competition
and redundancy. If there are any graph theorists or category theorists on
the list, perhaps they could offer some formal validation or optimization.
For this, I prefer your March 23 proposal over March 24, I'm curious what
improvement is intended in March 24 vs 23?
The emergent definition and maintenance of a unique ordering for cycle
establishment within a neighborhood is, I think, a much more ambitious
undertaking. I'm not sure how we efficiently make that robust in a dynamic
context, except perhaps with interactive coordination among the members
operating off something other than just static global data. Otherwise
different members would have different ideas about cycle order, depending
on when they first joined. I also don't see how cycles recover when someone
leaves.
As people come and go, cycles will break. As the lightning network grows
overall, neighborhoods identified by one setting of the bloom filter will
become undesirably large. Perhaps a less ambitious but more robust
heuristic would be one where probability of establishing a channel is
proportional to the number of bits in common in the pubkey hash, normalized
by the number of nodes currently observed? This heuristic would
automatically adjust granularity over time as lightning membership grows
and shrinks. Nodes could periodically reevaluate their channel allocations
as the overall network grows or shrinks.
Were it not for the privacy goals, dynamic optimization based on actual
usage would be possible. Nodes could track the routes of payments that flow
through their channels and could spot fees that seem both large and
popular, and could use this information to identify under-served nodes to
which a direct channel might be in order. If we allowed nodes to see two
hops of the route instead of just the one, then such optimization would
become possible, although this compromise would require longer minimum
routes for a given level of privacy.
Thanks,
Ben
On Wed, Apr 18, 2018 at 10:04 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
> Rusty simulated an older version of my idea here; C code near the end of
> the message: https://lists.ozlabs.org/pipermail/c-lightning/2018-
> April/000029.html
>
> However this has a bug: I specify that:
>
> >If the candidate already has a channel with us, or has no address info and
> >cannot be found by DNS seed or so on, or cannot be contacted, or refuses
> >incoming channels or some other error, then increment i and try finding again.
>
> The code there does not implement the check "if the candidate has a
> channel with us", leading to smaller reachability since nodes who could
> afford to create multiple channels will create multiple channels to the
> same peer in the simulation.
>
> A naive analysis suggests that if only one node in the entire network uses
> the algorithm I described, it should be indistinguishable from a random
> connection policy, so a naive analysis suggests that something has gone
> wrong if the reachability of this algorithm is significantly less than the
> reachability of a random connection algorithm. The simulation also does
> not consider that existing nodes may break old channels or make new
> channels themselves; it is not certain how often that happens on the real
> network.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 19, 2018 7:56 AM, Benjamin Mord <ben at mord.family> wrote:
>
>
> Elegant idea.
>
> Is there a simulation platform yet for experimenting with ideas such as
> this? I imagine it may sometimes be useful to empirically test aggregate
> effects of different routing heuristics, however naive or artificial the
> underlying assumptions may need to be.
>
> Is there an API, perhaps implementation agnostic, to separate such
> strategies from the protocol itself?
>
> Is there a place yet to specify such heuristics where tight coordination
> on details are of mutual benefit, such as a bolt?
>
> On Sat, Mar 24, 2018, 8:08 AM ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
>> Good morning list,
>>
>> I have decided on a better termination condition for searching for a
>> cyclic superhub. I re-describe below the algorithm:
>>
>> Start with `i` = 0 and a set of known nodes, including our own node.
>>
>> Iterate over `i`:
>>
>> - Compute hash = H(i || pubkey) for each node. H = RIPEMD160 . SHA256,
>> serialize `i` as a big-endian 32-bit number. Also compute our_hash = H(i
>> || our_pubkey) for our self. Put this in a working set.
>>
>> - Iterate over bits (start with the 7th bit (128) of the first byte):
>>
>> - - Split the working set into two sets, the matching set and the
>> non-matching set, where the bit in the hash matches the bit in our_hash.
>>
>> - - If the non-matching set is empty, skip to the next bit.
>>
>> - - If the matching set is 1 or 2 members, or the non-matching set is 1
>> or 2 members, merge the two sets together into the working set and exit
>> this loop: we have found a cyclic superhub.
>>
>> - - else set the working set to the matching set.
>>
>> - Sort the set according to the hash (treat the hash as a 160-bit
>> big-endian number).
>>
>> - We should open a channel to the node after us in the sorted list; if we
>> are the last, wrap around to the first node in the list.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On March 23, 2018 11:29 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>> Good morning list,
>>
>> Igor Cota has started implementing my idea: https://github.com/icota/
>> presto/commit/3311785e660d840f0ac8f2e333d0f0097aec980e
>>
>> This forced me to actually start thinking more deeply about the algorithm
>> I gave.
>>
>> 1. We should use a well-used hash algorithm, such as RIPEMD160(SHA256(x))
>> 2. We should specify the size of `i` - 32-bits, 4 bytes - and indicate
>> its endianness. Let us use big-endian, as is typical for the rest of
>> Lightning and for network order.
>> 3. My original algorithm had a significant probability of diverging. So
>> I respecify the termination condition later.
>> 4. Our own node should be part of the original working set.
>> 5. In the decimation loop, start with the highest bit. This is the
>> 7-index bit (1 << 7) of the first byte in the 20-byte hash (we treat the
>> hash as a big-endian 160-bit number).
>>
>> The modified termination condition for the decimation loop is below:
>>
>> * If the working set is 7 nodes or more, decimate (i.e. match the next
>> bit in the hashes and remove those that do not match our own hash in that
>> bit.).
>> * If the working set is 3 to 6 nodes, stop, that is now the members of
>> the superhub and we then sort them by hash and decide our position in the
>> superhub (who will channel to us and who we will channel to).
>> * If the working set is 1 or 2 nodes, fail to form a superhub. Increment
>> `i` and restart.
>>
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail <https://protonmail.com> Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On March 20, 2018 11:19 AM, ZmnSCPxj via Lightning-dev <
>> lightning-dev at lists.linuxfoundation.org> wrote:
>>
>> Good morning list,
>>
>> As my award-winning and supremely notable and talked-about-by-the-man-on-the-street
>> article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network
>> Topography" points out, cycles are a good way to organize the LN in order
>> to allow easier accessibility to the network for all participants of all
>> kinds.
>>
>> An issue here is the need for coordination in order to set up cyclic
>> superhubs. A node acting by itself cannot form cyclic superhubs.
>>
>> However, one can consider that coordination is needed only to identify
>> peers with which one forms superhubs. But we already have a system that
>> identifies peers: the node gossip.
>>
>> So let us assume: All nodes have similar-enough views of the
>> publicly-visible peers on the node graph, as built by node gossip.
>>
>> I now present an algorithm, which given a set of nodes extracted from
>> node gossip, returns a peer to try connecting and funding a channel to.
>>
>> --
>>
>> First, start with a 32-bit number i = 0.
>>
>> For each node, get hash = H(i || pubkey), where H is some standard hash
>> algorithm, and pubkey is the public key of the node. Also get our_hash =
>> H(i || our_pubkey)
>>
>> Perform successive filtering. While the set is larger than 2 nodes,
>> successively compare high bits. If the highest bit of hash does not match
>> the highest bit of our_hash, remove it from the set. If the resulting set
>> is still larger than 2, match the next bit. When the set is now 2 or 1
>> node, back off by one bit and add back the most recently removed nodes.
>> This yields a set that is at least 3 or more nodes.
>>
>> Sort the nodes according to hash.
>>
>> Identify where our node is in the sorted list. Then our candidate is the
>> next node in the list, or if we are the last node, then the first node in
>> the list.
>>
>> If the candidate already has a channel with us, or has no address info
>> and cannot be found by DNS seed or so on, or cannot be contacted, or
>> refuses incoming channels or some other error, then increment i and try
>> finding again.
>>
>> ---
>>
>> Even if nodes have some divergence in their own local maps of the
>> network, there is the chance that the difference will be filtered away and
>> the nodes that are "destined" to form a superhub can still find each other
>> in the same superhub.
>>
>> Assuming all nodes have the same routemap, then all nodes will form their
>> own, non-overlapping superhubs for each i. However if some nodes get to
>> increment i, hopefully because it already has a channel with its destined
>> candidate peer at one value of i, it can then potentially form superhubs
>> with other nodes that have also reached higher i.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180419/a12578c3/attachment-0001.html>

2023-06-09 14:50:12

- reply

📅 Original date posted:2018-04-18
📝 Original message:
Elegant idea.
Is there a simulation platform yet for experimenting with ideas such as
this? I imagine it may sometimes be useful to empirically test aggregate
effects of different routing heuristics, however naive or artificial the
underlying assumptions may need to be.
Is there an API, perhaps implementation agnostic, to separate such
strategies from the protocol itself?
Is there a place yet to specify such heuristics where tight coordination on
details are of mutual benefit, such as a bolt?
On Sat, Mar 24, 2018, 8:08 AM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> I have decided on a better termination condition for searching for a
> cyclic superhub. I re-describe below the algorithm:
>
> Start with `i` = 0 and a set of known nodes, including our own node.
>
> Iterate over `i`:
>
> - Compute hash = H(i || pubkey) for each node. H = RIPEMD160 . SHA256,
> serialize `i` as a big-endian 32-bit number. Also compute our_hash = H(i
> || our_pubkey) for our self. Put this in a working set.
>
> - Iterate over bits (start with the 7th bit (128) of the first byte):
>
> - - Split the working set into two sets, the matching set and the
> non-matching set, where the bit in the hash matches the bit in our_hash.
>
> - - If the non-matching set is empty, skip to the next bit.
>
> - - If the matching set is 1 or 2 members, or the non-matching set is 1 or
> 2 members, merge the two sets together into the working set and exit this
> loop: we have found a cyclic superhub.
>
> - - else set the working set to the matching set.
>
> - Sort the set according to the hash (treat the hash as a 160-bit
> big-endian number).
>
> - We should open a channel to the node after us in the sorted list; if we
> are the last, wrap around to the first node in the list.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On March 23, 2018 11:29 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> Good morning list,
>
> Igor Cota has started implementing my idea:
> https://github.com/icota/presto/commit/3311785e660d840f0ac8f2e333d0f0097aec980e
>
> This forced me to actually start thinking more deeply about the algorithm
> I gave.
>
> 1. We should use a well-used hash algorithm, such as RIPEMD160(SHA256(x))
> 2. We should specify the size of `i` - 32-bits, 4 bytes - and indicate
> its endianness. Let us use big-endian, as is typical for the rest of
> Lightning and for network order.
> 3. My original algorithm had a significant probability of diverging. So
> I respecify the termination condition later.
> 4. Our own node should be part of the original working set.
> 5. In the decimation loop, start with the highest bit. This is the
> 7-index bit (1 << 7) of the first byte in the 20-byte hash (we treat the
> hash as a big-endian 160-bit number).
>
> The modified termination condition for the decimation loop is below:
>
> * If the working set is 7 nodes or more, decimate (i.e. match the next bit
> in the hashes and remove those that do not match our own hash in that bit.).
> * If the working set is 3 to 6 nodes, stop, that is now the members of the
> superhub and we then sort them by hash and decide our position in the
> superhub (who will channel to us and who we will channel to).
> * If the working set is 1 or 2 nodes, fail to form a superhub. Increment
> `i` and restart.
>
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On March 20, 2018 11:19 AM, ZmnSCPxj via Lightning-dev <
> lightning-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> As my award-winning and supremely notable and
> talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution
> Towards Reasonable Lightning Network Topography" points out, cycles are a
> good way to organize the LN in order to allow easier accessibility to the
> network for all participants of all kinds.
>
> An issue here is the need for coordination in order to set up cyclic
> superhubs. A node acting by itself cannot form cyclic superhubs.
>
> However, one can consider that coordination is needed only to identify
> peers with which one forms superhubs. But we already have a system that
> identifies peers: the node gossip.
>
> So let us assume: All nodes have similar-enough views of the
> publicly-visible peers on the node graph, as built by node gossip.
>
> I now present an algorithm, which given a set of nodes extracted from node
> gossip, returns a peer to try connecting and funding a channel to.
>
> --
>
> First, start with a 32-bit number i = 0.
>
> For each node, get hash = H(i || pubkey), where H is some standard hash
> algorithm, and pubkey is the public key of the node. Also get our_hash =
> H(i || our_pubkey)
>
> Perform successive filtering. While the set is larger than 2 nodes,
> successively compare high bits. If the highest bit of hash does not match
> the highest bit of our_hash, remove it from the set. If the resulting set
> is still larger than 2, match the next bit. When the set is now 2 or 1
> node, back off by one bit and add back the most recently removed nodes.
> This yields a set that is at least 3 or more nodes.
>
> Sort the nodes according to hash.
>
> Identify where our node is in the sorted list. Then our candidate is the
> next node in the list, or if we are the last node, then the first node in
> the list.
>
> If the candidate already has a channel with us, or has no address info and
> cannot be found by DNS seed or so on, or cannot be contacted, or refuses
> incoming channels or some other error, then increment i and try finding
> again.
>
> ---
>
> Even if nodes have some divergence in their own local maps of the network,
> there is the chance that the difference will be filtered away and the nodes
> that are "destined" to form a superhub can still find each other in the
> same superhub.
>
> Assuming all nodes have the same routemap, then all nodes will form their
> own, non-overlapping superhubs for each i. However if some nodes get to
> increment i, hopefully because it already has a channel with its destined
> candidate peer at one value of i, it can then potentially form superhubs
> with other nodes that have also reached higher i.
>
> Regards,
> ZmnSCPxj
>
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180418/067b809c/attachment-0001.html>

2023-06-09 14:50:01

- reply

📅 Original date posted:2018-04-13
📝 Original message:
Good morning ZmnSCPxj,
As a skeptic of discrete logarithm's long-term security, I view scriptless
scripts as dangerously seductive. (But wow, are they cool! Almost cool
enough to wish we could uninvent quantum computing. I wonder if R-LWE can
be used instead as foundation? Not that I expect R-LWE to hold long-term
either...) But I digress.
As I listen to all the work starting up in the legacy financial markets to
mitigate the likely future failure of LIBOR, given how little thought went
into that possibility in the writing of currently-traded derivative
contracts, I'm reminded of how important and also how possible it is to
think about short and long-term goals simultaneously as we build systems.
It is far easier now than it will soon be to add expressiveness into the
core protocol, such as negative fees and optional exponential component.
Just because we pragmatically ignore negative fees and exponents in routing
decisions today, does not mean we will not feel enormous need for them in
the future - and having the ability to express such fee structures now will
enable efficiency improvements in the future, as simple implementation
(rather than protocol) upgrades.
I recognize AMP (at least as you proposed) is a long way out, but it seems
like something we'll inevitably want and will surely add. It is therefore
worth assuming now, as we think strategically about how fee dynamics will
improve efficiency over time. Who knows, my skepticism of discrete
logarithm hardness may prove misplaced, or else we'll find other ways to
achieve AMP. (I have not read roasbeef's proposal, but I shall.) The
protocol does not presently allow an exponential component, but it would be
trivial to add (even if, at first, defaulted to 1).
Thanks,
Ben
On Fri, Apr 13, 2018 at 9:26 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
>
>
>
> Sent with ProtonMail <https://protonmail.com> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On April 13, 2018 4:37 AM, Benjamin Mord <ben at mord.io> wrote:
>
> Thank you, ZmnSCPxj.
>
> "... by adjusting the on-Lightning `fee_base_msat` and
> `fee_proportional_millionths` of channels."
>
> Yes, I agree these prices are a critical signaling mechanism that can have
> substantial impact on expected channel lifetime and thus economic
> efficiency of lightning operation overall. (As you may recall, I believe we
> should allow negative prices - even if present day routing algorithms
> choose to treat negative fees as zero for temporary simplicity.) You make
> a good point it can also improve routing efficiency by hinting at capacity,
> but for now they are unfortunately linear.
>
> The following paper did not account for the improved efficiency that price
> adjustment in response to channel state will likely enable, but one thing
> which may be relevant here is the underlying power law assumption of
> transaction size distribution (which is apparently drawn from actual data),
> and the more general approach to estimating channel lifespan. In lieu of
> advertising max capacity, perhaps we should instead permit a price exponent
> which may optionally be set to something larger than 1. The cost to channel
> operator of processing a transaction is largely the impact to expected
> channel lifespan, which in turn is nonlinear with respect to transaction
> size - and dramatically so as transaction size approaches (or exceeds)
> remaining capacity.
> https://arxiv.org/pdf/1712.10222.pdf
>
>
> Larger payments also have a much lower chance of successfully propagating
> through the network, as every channel in its route needs to have the
> requisite capacity, so I think it somewhat balances out (maybe).
>
> Adding a nonlinear component would be difficult to add on to the protocol
> currently, as I think there is no provision for it in the protocol. But
> maybe I am incorrect..?
>
> If we combine nonlinear pricing with your March 19 AMP proposal, I expect
> economic efficiency could be greatly improved.
>
>
> My AMP proposal cannot work soon. It requires at minimum for
> Bellare-Neven/MuSig/Schnorr (I get confused, which is the proper name for
> this) signatures to be added to Bitcoin to get HD+SS. Then we need to
> switch over all implementations to using scriptless script contingent
> payments rather than hashlocked contingent payments (and convince all
> network node operators to upgrade); we will be unable to use an
> intermediate node that does not understand SS contingent payments for my
> style of AMP.
>
> The earlier AMP proposal by roasbeef is back-compatible (uses the same
> hashlocked contingent payments we already use now), but does not support a
> proof-of-payment compatible with ZKCP protocols (although possibly I am
> wrong, I think roasbeef has mentioned before that it is ZKCP compatible).
>
> Regards,
> ZmnSCPxj
>
> Thanks again,
> Benjamin Mord
>
>
> On Thu, Apr 12, 2018 at 12:49 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
> wrote:
>
>> Good morning Benjamin,
>>
>> Do (should) channels have the option of publicizing their balances, so as
>> to improve routing performance / scalability in a large network, and for
>> competitive differentiation among competing routes? This would allow
>> channel owners to balance privacy with efficiency, and where the incentive
>> to publish would go up in proportion to network scalability requirements.
>> Brute force trial & error seems expensive at scale, and also reduces
>> privacy of the sender - so it seems a useful hedge to leave this decision
>> to the market (if technically practical).
>>
>>
>> I think brute-force scales well enough, but perhaps we should see the
>> network in action more.
>>
>> To an extent, it is possible to hint the suitability of a channel for
>> routing in a particular direction, without completely leaking your balance
>> in detail, by adjusting the on-Lightning `fee_base_msat` and
>> `fee_proportional_millionths` of channels. If you have a high balance on a
>> channel, you reduce your side of the fee for that channel (i.e. the
>> direction where you are the source for payments on that channel) to
>> encourage others to use it and hopefully pay you on a depleted channel. If
>> you have a low balance, you increase your fee. These fees are already
>> propagated using `channel_update`. No current node software implements
>> this yet, however.
>>
>> Regards,
>> ZmnSCPxj
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180413/c35af87b/attachment.html>

2023-06-09 14:50:00

- reply

📅 Original date posted:2018-04-12
📝 Original message:
Thank you, ZmnSCPxj.
"... by adjusting the on-Lightning `fee_base_msat` and
`fee_proportional_millionths` of channels."
Yes, I agree these prices are a critical signaling mechanism that can have
substantial impact on expected channel lifetime and thus economic
efficiency of lightning operation overall. (As you may recall, I believe we
should allow negative prices - even if present day routing algorithms
choose to treat negative fees as zero for temporary simplicity.) You make a
good point it can also improve routing efficiency by hinting at capacity,
but for now they are unfortunately linear.
The following paper did not account for the improved efficiency that price
adjustment in response to channel state will likely enable, but one thing
which may be relevant here is the underlying power law assumption of
transaction size distribution (which is apparently drawn from actual data),
and the more general approach to estimating channel lifespan. In lieu of
advertising max capacity, perhaps we should instead permit a price exponent
which may optionally be set to something larger than 1. The cost to channel
operator of processing a transaction is largely the impact to expected
channel lifespan, which in turn is nonlinear with respect to transaction
size - and dramatically so as transaction size approaches (or exceeds)
remaining capacity.
https://arxiv.org/pdf/1712.10222.pdf
If we combine nonlinear pricing with your March 19 AMP proposal, I expect
economic efficiency could be greatly improved.
Thanks again,
Benjamin Mord
On Thu, Apr 12, 2018 at 12:49 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Benjamin,
>
> Do (should) channels have the option of publicizing their balances, so as
> to improve routing performance / scalability in a large network, and for
> competitive differentiation among competing routes? This would allow
> channel owners to balance privacy with efficiency, and where the incentive
> to publish would go up in proportion to network scalability requirements.
> Brute force trial & error seems expensive at scale, and also reduces
> privacy of the sender - so it seems a useful hedge to leave this decision
> to the market (if technically practical).
>
>
> I think brute-force scales well enough, but perhaps we should see the
> network in action more.
>
> To an extent, it is possible to hint the suitability of a channel for
> routing in a particular direction, without completely leaking your balance
> in detail, by adjusting the on-Lightning `fee_base_msat` and
> `fee_proportional_millionths` of channels. If you have a high balance on a
> channel, you reduce your side of the fee for that channel (i.e. the
> direction where you are the source for payments on that channel) to
> encourage others to use it and hopefully pay you on a depleted channel. If
> you have a low balance, you increase your fee. These fees are already
> propagated using `channel_update`. No current node software implements
> this yet, however.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180412/d4d4baee/attachment-0001.html>

2023-06-09 14:49:59

- reply

📅 Original date posted:2018-04-11
📝 Original message:
Do (should) channels have the option of publicizing their balances, so as
to improve routing performance / scalability in a large network, and for
competitive differentiation among competing routes? This would allow
channel owners to balance privacy with efficiency, and where the incentive
to publish would go up in proportion to network scalability requirements.
Brute force trial & error seems expensive at scale, and also reduces
privacy of the sender - so it seems a useful hedge to leave this decision
to the market (if technically practical).
On Wed, Apr 11, 2018 at 5:17 AM, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Alejandro,
>
>
> No, channel balance of each peer on the channel is not revealed on node
> gossip.
>
> Logically, invert the question: do you want to report how much you
> spend/receive on each of your channels to the network? Do you want to
> report how much you own on Lightning to be reported to everyone on
> Lightning?
>
> Since the balance on each peer is effectively the amount of money each
> peer owns on that channel, and each change to that balance represents a
> send/receive on that channel, you will not want to report your balance, and
> any changes in that balance, to the entire network.
>
> Logically you can then expect not to receive such updates from anybody
> else, either.
>
> How do real-life implementations like c-lightning get your payment routes
> then? By brute-force trial-and-error
>
>
> If payment routes are discovered by brute-force trial-and-error, and
> actually the sender can interrupt any payment by simply not revealing the
> secret, isn't it possible for any sender to simply start probing
> to discover the capacities in each path?
>
>
> Yes. Although now the sender risks its funds: if a node along the route
> it selects stalls, then the sender risks having its money locked for some
> blocks.
>
> Also, the sender only gets one bit of information to the question: Is the
> channel balance in this direction greater than X?
>
> Finally, the exact failure TEMPORARY_CHANNEL_FAILURE can mean that the
> other node is currently down rather than the channel not having enough
> capacity in that direction, or if there are too many HTLCs in-flight on
> that channel, or so on (the most likely currently seems to be the node is
> currently down rather than the channel balance being insufficient, since it
> seems many people do not leave their nodes running 24/7).
>
> So it is always less desirable than getting the exact channel balances at
> each balance update. You get degraded privacy, but not a full loss of
> privacy compared to broadcasting all balance updates.
>
> (in particular, if the channel balance changes, you would have to re-query
> the channel again to learn this)
>
> (your technique is flawed in the detail that the sender simply selects a
> destination randomly and a random payment hash, which has negligible
> probability of the randomly-selected destination knowing its preimage, but
> is otherwise sound in its broad strokes)
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180411/5d786b71/attachment-0001.html>

2023-06-09 14:48:44

- reply

📅 Original date posted:2018-01-31
📝 Original message:
Thanks - the installation instructions you linked to say otherwise (the
reason I asked), but perhaps they just need to be updated.
*"Installing btcd*
*lnd currently requires btcd with segwit support, which is not yet merged
into the master branch. Instead, roasbeef maintains a fork with his segwit
implementation applied. To install, run the following commands:"*
On Wed, Jan 31, 2018 at 3:43 PM, Olaoluwa Osuntokun <laolu32 at gmail.com>
wrote:
> Segwit has been merged into btcd for for sometime now. It's also possible
> to
> run with bitcoind. I encourage you to check out the documentation:
> https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md
>
> In lnd, the chain backend has already been abstracted[1]. This is what
> allows
> it to run with any of the three supported chain backends (btcd, bitcoind,
> neutrino). I invite you to continue this conversation on #lnd on Freenode.
>
> [1]: https://github.com/lightningnetwork/lnd/blob/
> master/lnwallet/interface.go
>
> On Wed, Jan 31, 2018 at 12:23 PM Benjamin Mord <ben at mord.io> wrote:
>
>> Hi,
>>
>> I'm not finding evidence of segwit in btcd, yet choice of golang is
>> appealing to me. Can one run lnd on bitcoind?
>>
>> More generally speaking, is there a plan for the layer 2 / layer 1
>> protocol binding to be abstracted away from the implementation on either
>> side, via SPI or such?
>>
>> Thanks,
>> Ben
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180131/ffd52b92/attachment.html>

2023-06-09 14:48:44

- reply

📅 Original date posted:2018-01-31
📝 Original message:
Hi,
I'm not finding evidence of segwit in btcd, yet choice of golang is
appealing to me. Can one run lnd on bitcoind?
More generally speaking, is there a plan for the layer 2 / layer 1 protocol
binding to be abstracted away from the implementation on either side, via
SPI or such?
Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180131/a4570a8b/attachment.html>

2023-06-09 14:48:42

- reply

📅 Original date posted:2018-01-30
📝 Original message:
Oh wait - I think we're covered. Any node "B" which follows the "wrong"
fork (according to judgement of node "A"), will at worst be
indistinguishable from a fraudulent node that attempts to mimic the
lightning protocol while failing to transmit the expected blockchain
transactions during channel funding or closure. But the protocol is already
designed to be robust against nodes failing to broadcast expected
blockchain transactions, so we get fork protection as byproduct. Correct?
If so, this point might be worth advertising in either BOLT 2 or 5. In some
ways, this might even strengthen consensus of the underlying blockchain.
Perhaps the only caveat is we must not get carried away with excessive
penalties against nodes who fail to broadcast blockchain transactions, if
those penalties are given to others. In aggregate, such penalties could
turn needless forking into a profit opportunity for
disingenuous-yet-sophisticated nodes at expense of sincere nodes, which in
turn might motivate forking.
On Tue, Jan 30, 2018 at 11:55 AM, Greg Sanders <gsanders87 at gmail.com> wrote:
> Not sure there is much to be done in simple consensus failures. Agreed
> it's a bit floaty unless there's an actual proposal.
>
> On Tue, Jan 30, 2018 at 11:42 AM, Benjamin Mord <ben at mord.io> wrote:
>
>>
>> Ugh, correction - BOLTs are presently written explicitly require segwit
>> (not segwit2x! need more coffee...). Sorry for the 'typo'
>>
>> On Tue, Jan 30, 2018 at 11:41 AM, Benjamin Mord <ben at mord.io> wrote:
>>
>>>
>>> Greg, I think you are confusing two different topics: adversarial forks,
>>> versus segwit as fix to transaction malleability.
>>>
>>> If you remove segwit, i.e. if you reintroduce the txid malleability bug,
>>> then lightning becomes unsafe - any nodes which attempt to follow such a
>>> fork would suffer. Incentives strongly motivate maintenance of consensus,
>>> so that scenario (I think?) is automatically covered and of no concern. (So
>>> actually, BCH is presently of no concern.) BOLTs as presently written
>>> explicitly require segwit2x anyhow, and for this reason.
>>>
>>> I understand an "adversarial fork" is one which lacks replay protection,
>>> . This is very much something worth addressing, as that is the case by
>>> default with a BIP 50-style accidental fork, and also appeared likely with
>>> the failed (and poorly named) "segwit2x". But I'm thinking out loud, will
>>> stop spamming people on the list unless / until I have a usefully concrete
>>> solution to offer. (Or until someone else comes up with something.)
>>>
>>>
>>> On Tue, Jan 30, 2018 at 11:31 AM, Greg Sanders <gsanders87 at gmail.com>
>>> wrote:
>>>
>>>> "Adversarial" forks that rip out segwit, or maliciously do not change
>>>> their signature algorithm, are basically impossible to defend against. May
>>>> be best to focus energies on forks that use strong replay protection in the
>>>> form of FORKID.
>>>>
>>>> On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord <ben at mord.io> wrote:
>>>>
>>>>>
>>>>> Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I
>>>>> believe they don't even support segwit (!) so lightning would be unsafe due
>>>>> to their txid mutability bug. I agree altcoin support should be lower
>>>>> priority, whenever it is obvious which is the altcoin (as indeed, is
>>>>> abundantly clear wrt BTC vs BCH). But it might one day become unclear.
>>>>>
>>>>> I remain concerned about safety despite BIP 50 scenarios, forks with
>>>>> more legitimate contention than so far seen, and also system stability in
>>>>> face of increasingly unsophisticated / gullible user base. As a
>>>>> cryptocurrency is little more than a trustless consensus mechanism, it
>>>>> seems circular to assume consensus in its design, especially if there are
>>>>> entities financially motivated to fracture that consensus. Resilience
>>>>> against forks would seem core to safety. If I think of a concrete solution,
>>>>> I'll send it first to this list for discussion - as I believe that is the
>>>>> preferred process?
>>>>>
>>>>> Thanks,
>>>>> Ben
>>>>>
>>>>>
>>>>> On Tue, Jan 30, 2018 at 1:16 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>>>> wrote:
>>>>>
>>>>>> Good morning Ben,
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> One topic I can't seem to find in the BOLTs is how lightning nodes
>>>>>> maintain consensus during or after a fork of the underlying blockchain(s).
>>>>>> For example, channel_announcement messages use a chain_hash, defined as
>>>>>> hash of underlying block chain's genesis block, to identify the currency in
>>>>>> use. Today, one might ask which hash identifies BTC as opposed to BCH?
>>>>>>
>>>>>>
>>>>>> I believe the rough consensus among most Lightning developers is that
>>>>>> BTC is "the real BTC" and gets the Satoshi genesis hash, while BCH is an
>>>>>> altcoin that was forked off BTC and gets as hash the branching-off point.
>>>>>> You could try to convince people developing and using Lightning software to
>>>>>> do the reverse, but I think it is unlikely that many people would agree to
>>>>>> that.
>>>>>>
>>>>>>
>>>>>> A more difficult question arises in how existing channels handle
>>>>>> intentional forks which arise after funding of a payment channel.
>>>>>>
>>>>>> An even more difficult question arises in the handling of
>>>>>> unintentional forks, as documented for example in BIP 50.
>>>>>>
>>>>>> Have these scenarios been analyzed / designed yet, or does that work
>>>>>> remain?
>>>>>>
>>>>>>
>>>>>> The work remains. For the most part, the priority is to get
>>>>>> implementations to a state, where we can safely deploy on Bitcoin Mainnet.
>>>>>> Then optimize further by adding RBF and multi-channel funding, then
>>>>>> integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so
>>>>>> on. Greater support for altcoins can be done later.
>>>>>>
>>>>>> For forked altcoins, short channel IDs contain the block height at
>>>>>> which the funding transaction confirmed. This might be used to judge if a
>>>>>> channel contains forked coins or not.
>>>>>>
>>>>>> Regards,
>>>>>> ZmnSCPxj
>>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>> Ben
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Lightning-dev mailing list
>>>>> Lightning-dev at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/cd1d60d9/attachment-0001.html>

2023-06-09 14:48:41

- reply

📅 Original date posted:2018-01-30
📝 Original message:
Ugh, correction - BOLTs are presently written explicitly require segwit
(not segwit2x! need more coffee...). Sorry for the 'typo'
On Tue, Jan 30, 2018 at 11:41 AM, Benjamin Mord <ben at mord.io> wrote:
>
> Greg, I think you are confusing two different topics: adversarial forks,
> versus segwit as fix to transaction malleability.
>
> If you remove segwit, i.e. if you reintroduce the txid malleability bug,
> then lightning becomes unsafe - any nodes which attempt to follow such a
> fork would suffer. Incentives strongly motivate maintenance of consensus,
> so that scenario (I think?) is automatically covered and of no concern. (So
> actually, BCH is presently of no concern.) BOLTs as presently written
> explicitly require segwit2x anyhow, and for this reason.
>
> I understand an "adversarial fork" is one which lacks replay protection, .
> This is very much something worth addressing, as that is the case by
> default with a BIP 50-style accidental fork, and also appeared likely with
> the failed (and poorly named) "segwit2x". But I'm thinking out loud, will
> stop spamming people on the list unless / until I have a usefully concrete
> solution to offer. (Or until someone else comes up with something.)
>
>
> On Tue, Jan 30, 2018 at 11:31 AM, Greg Sanders <gsanders87 at gmail.com>
> wrote:
>
>> "Adversarial" forks that rip out segwit, or maliciously do not change
>> their signature algorithm, are basically impossible to defend against. May
>> be best to focus energies on forks that use strong replay protection in the
>> form of FORKID.
>>
>> On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord <ben at mord.io> wrote:
>>
>>>
>>> Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I
>>> believe they don't even support segwit (!) so lightning would be unsafe due
>>> to their txid mutability bug. I agree altcoin support should be lower
>>> priority, whenever it is obvious which is the altcoin (as indeed, is
>>> abundantly clear wrt BTC vs BCH). But it might one day become unclear.
>>>
>>> I remain concerned about safety despite BIP 50 scenarios, forks with
>>> more legitimate contention than so far seen, and also system stability in
>>> face of increasingly unsophisticated / gullible user base. As a
>>> cryptocurrency is little more than a trustless consensus mechanism, it
>>> seems circular to assume consensus in its design, especially if there are
>>> entities financially motivated to fracture that consensus. Resilience
>>> against forks would seem core to safety. If I think of a concrete solution,
>>> I'll send it first to this list for discussion - as I believe that is the
>>> preferred process?
>>>
>>> Thanks,
>>> Ben
>>>
>>>
>>> On Tue, Jan 30, 2018 at 1:16 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>>> wrote:
>>>
>>>> Good morning Ben,
>>>>
>>>> Hi,
>>>>
>>>> One topic I can't seem to find in the BOLTs is how lightning nodes
>>>> maintain consensus during or after a fork of the underlying blockchain(s).
>>>> For example, channel_announcement messages use a chain_hash, defined as
>>>> hash of underlying block chain's genesis block, to identify the currency in
>>>> use. Today, one might ask which hash identifies BTC as opposed to BCH?
>>>>
>>>>
>>>> I believe the rough consensus among most Lightning developers is that
>>>> BTC is "the real BTC" and gets the Satoshi genesis hash, while BCH is an
>>>> altcoin that was forked off BTC and gets as hash the branching-off point.
>>>> You could try to convince people developing and using Lightning software to
>>>> do the reverse, but I think it is unlikely that many people would agree to
>>>> that.
>>>>
>>>>
>>>> A more difficult question arises in how existing channels handle
>>>> intentional forks which arise after funding of a payment channel.
>>>>
>>>> An even more difficult question arises in the handling of unintentional
>>>> forks, as documented for example in BIP 50.
>>>>
>>>> Have these scenarios been analyzed / designed yet, or does that work
>>>> remain?
>>>>
>>>>
>>>> The work remains. For the most part, the priority is to get
>>>> implementations to a state, where we can safely deploy on Bitcoin Mainnet.
>>>> Then optimize further by adding RBF and multi-channel funding, then
>>>> integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so
>>>> on. Greater support for altcoins can be done later.
>>>>
>>>> For forked altcoins, short channel IDs contain the block height at
>>>> which the funding transaction confirmed. This might be used to judge if a
>>>> channel contains forked coins or not.
>>>>
>>>> Regards,
>>>> ZmnSCPxj
>>>>
>>>>
>>>> Thanks!
>>>> Ben
>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/f330ebd6/attachment-0001.html>

2023-06-09 14:48:40

- reply

📅 Original date posted:2018-01-30
📝 Original message:
Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I
believe they don't even support segwit (!) so lightning would be unsafe due
to their txid mutability bug. I agree altcoin support should be lower
priority, whenever it is obvious which is the altcoin (as indeed, is
abundantly clear wrt BTC vs BCH). But it might one day become unclear.
I remain concerned about safety despite BIP 50 scenarios, forks with more
legitimate contention than so far seen, and also system stability in face
of increasingly unsophisticated / gullible user base. As a cryptocurrency
is little more than a trustless consensus mechanism, it seems circular to
assume consensus in its design, especially if there are entities
financially motivated to fracture that consensus. Resilience against forks
would seem core to safety. If I think of a concrete solution, I'll send it
first to this list for discussion - as I believe that is the preferred
process?
Thanks,
Ben
On Tue, Jan 30, 2018 at 1:16 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Ben,
>
> Hi,
>
> One topic I can't seem to find in the BOLTs is how lightning nodes
> maintain consensus during or after a fork of the underlying blockchain(s).
> For example, channel_announcement messages use a chain_hash, defined as
> hash of underlying block chain's genesis block, to identify the currency in
> use. Today, one might ask which hash identifies BTC as opposed to BCH?
>
>
> I believe the rough consensus among most Lightning developers is that BTC
> is "the real BTC" and gets the Satoshi genesis hash, while BCH is an
> altcoin that was forked off BTC and gets as hash the branching-off point.
> You could try to convince people developing and using Lightning software to
> do the reverse, but I think it is unlikely that many people would agree to
> that.
>
>
> A more difficult question arises in how existing channels handle
> intentional forks which arise after funding of a payment channel.
>
> An even more difficult question arises in the handling of unintentional
> forks, as documented for example in BIP 50.
>
> Have these scenarios been analyzed / designed yet, or does that work
> remain?
>
>
> The work remains. For the most part, the priority is to get
> implementations to a state, where we can safely deploy on Bitcoin Mainnet.
> Then optimize further by adding RBF and multi-channel funding, then
> integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so
> on. Greater support for altcoins can be done later.
>
> For forked altcoins, short channel IDs contain the block height at which
> the funding transaction confirmed. This might be used to judge if a
> channel contains forked coins or not.
>
> Regards,
> ZmnSCPxj
>
>
> Thanks!
> Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/12f8f93b/attachment.html>

2023-06-09 14:48:40

- reply

📅 Original date posted:2018-01-30
📝 Original message:
Greg, I think you are confusing two different topics: adversarial forks,
versus segwit as fix to transaction malleability.
If you remove segwit, i.e. if you reintroduce the txid malleability bug,
then lightning becomes unsafe - any nodes which attempt to follow such a
fork would suffer. Incentives strongly motivate maintenance of consensus,
so that scenario (I think?) is automatically covered and of no concern. (So
actually, BCH is presently of no concern.) BOLTs as presently written
explicitly require segwit2x anyhow, and for this reason.
I understand an "adversarial fork" is one which lacks replay protection, .
This is very much something worth addressing, as that is the case by
default with a BIP 50-style accidental fork, and also appeared likely with
the failed (and poorly named) "segwit2x". But I'm thinking out loud, will
stop spamming people on the list unless / until I have a usefully concrete
solution to offer. (Or until someone else comes up with something.)
On Tue, Jan 30, 2018 at 11:31 AM, Greg Sanders <gsanders87 at gmail.com> wrote:
> "Adversarial" forks that rip out segwit, or maliciously do not change
> their signature algorithm, are basically impossible to defend against. May
> be best to focus energies on forks that use strong replay protection in the
> form of FORKID.
>
> On Tue, Jan 30, 2018 at 11:26 AM, Benjamin Mord <ben at mord.io> wrote:
>
>>
>> Thank you, ZmnSCPxj. BCH is a warmup question for several reasons, I
>> believe they don't even support segwit (!) so lightning would be unsafe due
>> to their txid mutability bug. I agree altcoin support should be lower
>> priority, whenever it is obvious which is the altcoin (as indeed, is
>> abundantly clear wrt BTC vs BCH). But it might one day become unclear.
>>
>> I remain concerned about safety despite BIP 50 scenarios, forks with more
>> legitimate contention than so far seen, and also system stability in face
>> of increasingly unsophisticated / gullible user base. As a cryptocurrency
>> is little more than a trustless consensus mechanism, it seems circular to
>> assume consensus in its design, especially if there are entities
>> financially motivated to fracture that consensus. Resilience against forks
>> would seem core to safety. If I think of a concrete solution, I'll send it
>> first to this list for discussion - as I believe that is the preferred
>> process?
>>
>> Thanks,
>> Ben
>>
>>
>> On Tue, Jan 30, 2018 at 1:16 AM, ZmnSCPxj <ZmnSCPxj at protonmail.com>
>> wrote:
>>
>>> Good morning Ben,
>>>
>>> Hi,
>>>
>>> One topic I can't seem to find in the BOLTs is how lightning nodes
>>> maintain consensus during or after a fork of the underlying blockchain(s).
>>> For example, channel_announcement messages use a chain_hash, defined as
>>> hash of underlying block chain's genesis block, to identify the currency in
>>> use. Today, one might ask which hash identifies BTC as opposed to BCH?
>>>
>>>
>>> I believe the rough consensus among most Lightning developers is that
>>> BTC is "the real BTC" and gets the Satoshi genesis hash, while BCH is an
>>> altcoin that was forked off BTC and gets as hash the branching-off point.
>>> You could try to convince people developing and using Lightning software to
>>> do the reverse, but I think it is unlikely that many people would agree to
>>> that.
>>>
>>>
>>> A more difficult question arises in how existing channels handle
>>> intentional forks which arise after funding of a payment channel.
>>>
>>> An even more difficult question arises in the handling of unintentional
>>> forks, as documented for example in BIP 50.
>>>
>>> Have these scenarios been analyzed / designed yet, or does that work
>>> remain?
>>>
>>>
>>> The work remains. For the most part, the priority is to get
>>> implementations to a state, where we can safely deploy on Bitcoin Mainnet.
>>> Then optimize further by adding RBF and multi-channel funding, then
>>> integrate Burchert-Decker-Wattenhofer channel factories, splicing, and so
>>> on. Greater support for altcoins can be done later.
>>>
>>> For forked altcoins, short channel IDs contain the block height at which
>>> the funding transaction confirmed. This might be used to judge if a
>>> channel contains forked coins or not.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>>
>>> Thanks!
>>> Ben
>>>
>>>
>>>
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180130/0da17217/attachment.html>

2023-06-09 14:48:39

- reply

📅 Original date posted:2018-01-29
📝 Original message:
Hi,
One topic I can't seem to find in the BOLTs is how lightning nodes maintain
consensus during or after a fork of the underlying blockchain(s). For
example, channel_announcement messages use a chain_hash, defined as hash of
underlying block chain's genesis block, to identify the currency in use.
Today, one might ask which hash identifies BTC as opposed to BCH?
A more difficult question arises in how existing channels handle
intentional forks which arise after funding of a payment channel.
An even more difficult question arises in the handling of unintentional
forks, as documented for example in BIP 50.
Have these scenarios been analyzed / designed yet, or does that work remain?
Thanks!
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180129/7b478ccf/attachment.html>

2023-06-09 14:48:38

- reply

📅 Original date posted:2018-01-25
📝 Original message:
Related, I am also interested in the differences between the three major
lightning implementations: lnd, eclair, and c-lightning. I understand they
are implemented in Go, Scala, and C, respectively. Are there other
important differences for early adopters to consider, when selecting an
implementation?
(Christian, I believe of these three implementations, you happen to work on
c-lightning. Correct? Are there contributors from lnd and eclair on this
list as well?)
On Jan 25, 2018 3:48 PM, "v e" <veligeti999 at gmail.com> wrote:
Thanks Christian,
I do know that i should not expose lighteningd to multiple tenants however,
I am still trying to understand:
1) How merchant wallet is tied up to an invoice?
2) How consumer wallet can send satoshi to that invoice id?
If you have any code examples that would be great.
On Sat, Jan 20, 2018 at 5:41 AM, Christian Decker <
decker.christian at gmail.com> wrote:
> v e <veligeti999 at gmail.com> writes:
> > Will do as you suggested. one another question, when you say customers do
> > you mean end clients who are buying goods and services?
>
> Yes, they'll need to have clients that understand the Lightning protocol
> just like anyone else in the network.
>
> > Also i am building an server-client model where i am trying to host
> > multiple merchants who can accepts payments from end customers.
> > Does that mean i need to have (bitcoins node, c-lightning + charge) node
> > per merchant?
>
> Neither c-lightning nor Lightning Charge (or any other implementation
> for that matter) is multi-tenant, which is what you're
> describing. Someone with access to the RPC has full control over all
> channels and all funds in the daemon. Just like you wouldn't expose a
> raw bitcoind RPC interface to multiple users, you shouldn't directly
> expose lightningd to multiple tenants. You can build a layer inbetween
> that differentiates the tenants and controls access to individual
> resources though, but we don't currently support it directly.
>
> Notive also that we'd like to encourage every users, be it customer or
> shop, to run their own nodes, not rely on large managed infrastructure.
>
> Cheers,
> Christian
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180125/71b22b08/attachment-0001.html>

2023-06-09 14:48:37

- reply

📅 Original date posted:2018-01-18
📝 Original message:
Although lightning and cryptocurrency is new, the idea of a distribution
network created from links with negotiated fees and with limited
unidirectional capacity that can be corrected via rebalancing, is not new.
In fact there are several very large and mature markets around the world
that we can study which illustrate what people have found to work well in
such contexts, and one class of such markets is wholesale electricity
distribution, such as PJM:
http://www.pjm.com/about-pjm/who-we-are.aspx
When Will Yager mentioned FTRs, he was referring to a specific financial
instrument traded on the PJM, for the purpose of managing load on
transmission lines. Much as with lightning payment channels, power flows in
one direction on a line can be canceled with power flows in the opposite
direction, and so FTR prices are therefore allowed to go negative on the
PJM exchanges for the same reasons as discussed in this thread. If this has
worked for them for some decades, I'm not sure why it wouldn't work for us
also.
In full disclosure, I should point out that this is not the same thing as
electricity transmission. Although they do have counterflow cancellation in
common, payment channel balance is still more analogous to energy than
power, whereas transmission capacity limits are in power and not energy.
Time scales are long enough for manual intervention in PJM negotiations,
whereas timescales necessitate a high degree of automation in lightning
negotiation, as another difference. And there are other differences, and
some might matter.
At at a technical level, I see no complexity at all in allowing fees to go
negative. What is hard about allowing signed versus unsigned integers in
the protocol, and even passing them along? Perhaps there is complexity in a
routing algorithm which attempts to take full advantage of negative fees,
and so perhaps implementations will prefer in the near term to pretend
negative fees are actually zero - but such implementations can easily pass
along info about negative fees even when they themselves choose not to
fully avail themselves of the resulting opportunities. (At worst, some
recipients might receive an unexpected tip! There are worse fates in life.)
As relates to lightning's design goals, I applaud simplifying assumptions
in the early implementations, as a matter of triage - but I would still
discourage premature neutering of underlying protocol expressiveness, since
the resulting limitations can then linger or even come to motivate harmful
or risky forks down the road. Passingly along signed instead of unsigned
ints is easy enough, and we can just cast to unsigned internally, wherever
that may be our local preference.
Incidentally, if anyone is interested in exploring specific application of
lightning to the electricity markets, please contact me offline at
ben at mord.io, as it happens I am attempting to organize such an effort.
While I see opportunity here for collaborative and complimentary work that
could in turn boost lightning adoption, I want to be careful also not to
distract the lightning project from its already ambitious and laudable
mission. Lightning must beware scope creep of a harmful sort, and I'll try
to be disciplined in not encouraging it. We should still walk before we run.
On Thu, Jan 18, 2018 at 12:17 PM, Christian Decker <
decker.christian at gmail.com> wrote:
> Mark Friedenbach <mark at friedenbach.org> writes:
>
> > It is not the case that all instances where you might have negative
> > fees would have loops.
>
> If we don't have a cycle we can hardly talk about rebalancing
> channels. At that point you're paying for someone else's payment to go
> through your channel, and I'm unclear what the motivation for that might
> be. Anyway, this is still possible by communicating this out of band
> with the payment creator, and should not be baked into the gossip
> protocol itself, in my opinion. It's obscure enough to not be worth the
> extra effort.
>
> > One instance where you want this feature is when the network becomes
> > too weighted in one side of the graph.
>
> There is little you can do to prevent this: if we have a network with a
> small cut, with a source and sink on opposite sides of that cut, no
> amount of voluntary sacrifice from the nodes along the cut will have a
> lasting effect. The better solution would be to change the topology of
> the network to remove the cut, or balance traffic over it, e.g., moving
> a sink to the other side of the cut.
>
> > Another is when the other side is a non-routable endpoint. In both
> > cases would be useful to signal to others that you were willing to pay
> > to rebalance, and this hand wavy argument about loops doesn’t seem to
> > apply.
>
> I'm not sure I understand what you mean with non-routable endpoint, so
> correct me if I'm wrong. I'm assuming that non-routable endpoint is a
> non-publicly announced node in the network? In that case no fee tricks
> will ever get people to route over it, since they can't even construct
> the onion to talk to it. Notice that the payment requests allow for
> recipients of payments to get paid by explicitly including the necessary
> information to construct the onion to talk to that node.
>
> Not trying to be dismissive here, and I might be getting this wrong, so
> let me know if I did and what use-cases you had in mind :-)
>
> Cheers,
> Christian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180118/e66006d8/attachment.html>

2023-06-09 14:48:35

- reply

📅 Original date posted:2018-01-16
📝 Original message:
It isn't obvious to me from the BOLTs if fees can be negative, and I'm
finding uint in the go source code - which suggests not. In scenarios where
the funding of a payment channel has been fully committed in one direction,
why not allow negative fees to incent unwinding, in scenarios where nodes
consider that cheaper than on-chain rebalancing?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/e91b10db/attachment.html>

2023-06-09 14:48:35

- reply

📅 Original date posted:2018-01-16
📝 Original message:
Thanks. It sounds like it was dropped due to difficulty in the routing
protocol. Is that difficulty documented somewhere I can review? If so, I
might take a crack at a solution to it. But regardless I suggest the
protocol should support negative fees, even if an individual routing
implementation prefers to treat as 0 for simplicity. That should be up to
the implementation I think, and not a protocol constraint.
On Tue, Jan 16, 2018 at 2:58 PM, William Casarin <jb55 at jb55.com> wrote:
> Benjamin Mord <ben at mord.io> writes:
> > [..]
> > why not allow negative fees to incent unwinding, in scenarios where nodes
> > consider that cheaper than on-chain rebalancing?
>
> This was brought up before here [1]:
>
> Rusty Russell <rusty at rustcorp.com.au> writes:
> >> Edward Marynarz <edziumarynarz at gmail.com> writes:
> >> Another trivial question: can the fee be negative? It might help with
> some
> >> channel rebalancing.
>
> >In my original implementation, they could be. However, that turns out
> >to be a very strange idea, and complicates routing.
>
> [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/
> 2017-December/000827.html
>
> Cheers,
>
> --
> https://jb55.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/79b12b13/attachment.html>

2023-06-09 14:48:31

- reply

📅 Original date posted:2018-01-16
📝 Original message:
With all due respect to Bradner, RFC 2119 (written in 1997) is harmful to
lightning and to cryptocurrency protocols more broadly. As was the
prevailing mindset at the time, RFC 2119 is for a world of good guys and
(if we're feeling diligent) bad guys, where good guys try to communicate
despite presence of bad guys who would spoil the fun. The intended endpoint
of your communication would never itself be a bad guy - why would you
knowingly communicate with a bad guy?
But Satoshi was less naive, and considered every node as pursuing self
interest alone. Rather than good guys and bad guys, we have lots of selfish
guys playing the game (and also selfish guys trying to destroy the game).
The lightning concept itself embraces this idea also at the very abstract
level, so the navel-gazing we MUST take on now is simply the task of
carrying that philosophy through into the byte-level details and how we
sell those details to programmers. RFC 2119 is harmful both for what it
says and what it does not say. The harm in what it says is illustrated by
this example - one of several (emphasis mine):
"In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior *which has*
* potential for causing harm* (e.g., limiting retransmisssions)"
(Another example is where it limits what sort of behavior implementers
ought to prepare for in their peers.)
When someone violates a MUST, what shall we do? Throw them in jail? Say
nasty things behind their backs? No, cryptocurrency protocol specifications
are 100% advisory - a cleverly devised system where we can sincerely sell
the implementer that it will be in their individual best interest to do
highly specific things which have been arranged to also accrue to the
collective benefit. Use of MUST (in RFC 2119 sense) invites lazy thought in
the protocol design itself, where details need not be sold as beneficial to
individuals. We should say, there is no RFC 2119 MUST - there is only self
interest.
Another way to view it: a protocol spec attempts to program the
programmers. But unlike computers, people don't always do what you ask
simply because you asked. Every detail must therefore be sold, as there is
no other source of authority at our disposal. RFC 2119 assumes an intrinsic
authority that simply does not exist here. We must arrange for that to be
OK - not only at an abstract level, but at a detailed one also.
On Mon, Jan 15, 2018 at 7:01 PM, Rusty Russell <rusty at rustcorp.com.au>
wrote:
> Benjamin Mord <ben at mord.io> writes:
> > One thing I find useful in RFCs is a brief discussion about the meaning
> of
> > terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
> > definition.
>
> Hi Benjamin!
>
> Weird, I always find them kinda useless. RFC2119 pretty much
> covers it.
>
> > When a BOLT says that a lightning node MUST do some X, what does that
> mean
> > exactly? I'm thinking it means we should stigmatize it as "non-compliant"
> > with protocol consensus as documented in BOLTs, whenever we discuss the
> > implementation. I think violation of a MUST should be considered
> hostile. I
> > think a MUST encourages nodes to fail a channel or connection upon
> > observing a violation of that MUST, and even to take
> > implementation-specific defensive measures as deemed appropriate by
> > implementers (so long as they have cryptographic evidence that the
> > violation is not forged). But in no way does a MUST assure implementers
> > that they may assume this MUST will be respected by remote nodes, as it
> is
> > not the purpose of MUST to convey that cryptographic safeguards or such
> > elsewhere in the protocol design have arranged to force adherence..
>
> This is why we attempt to divide requirements into sender and receiver.
> For example, this is an absolute unchangable protocol requirement:
>
> Sender MUST set X.
> Receiver MUST close channel if X is not set.
>
> or:
> Sender MUST set X.
> If X is set, Receiver MUST ...
>
> The latter implies that future versions of the spec may have senders not
> setting X.
>
> I thought about writing a BOLT on how to write BOLTs, but it would
> doubtless come across as inane navel-gazing.
>
> Note also that the spec does not live up to this property in all places,
> but we bugfix where we find that.
>
> Cheers,
> Rusty.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180116/9a13eedb/attachment.html>

2023-06-09 14:48:30

- reply

📅 Original date posted:2018-01-11
📝 Original message:
One thing I find useful in RFCs is a brief discussion about the meaning of
terms like MUST, SHOULD, MAY, etc.. as used in the subsequent protocol
definition. But in the traditional approach to protocol design we first
assume cooperative nodes, and then later attempt to retrofit security when
we are surprised (yet again) to find not all nodes are operating in good
faith. Initial definition of "MUST" in RFCs thus implicitly presumes good
faith, inadvertently inviting implementers to lower their guard. But of
course, integrity despite presence of adversarial nodes is an explicit
design goal of the lightning network.
When a BOLT says that a lightning node MUST do some X, what does that mean
exactly? I'm thinking it means we should stigmatize it as "non-compliant"
with protocol consensus as documented in BOLTs, whenever we discuss the
implementation. I think violation of a MUST should be considered hostile. I
think a MUST encourages nodes to fail a channel or connection upon
observing a violation of that MUST, and even to take
implementation-specific defensive measures as deemed appropriate by
implementers (so long as they have cryptographic evidence that the
violation is not forged). But in no way does a MUST assure implementers
that they may assume this MUST will be respected by remote nodes, as it is
not the purpose of MUST to convey that cryptographic safeguards or such
elsewhere in the protocol design have arranged to force adherence..
Does that sound right? Is it worth stating explicitly somewhere, along with
definitions of SHOULD, MAY etc? Sorry if these definitions are already
stated someplace that I overlooked.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/36714035/attachment.html>

2023-06-09 14:48:22

- reply

📅 Original date posted:2018-01-11
📝 Original message:
Thanks Christian. I'm reading the BOLTs and reviewing source code now, so
perhaps my question / request will be more usefully specific once I've
finished that review. Sorry for being vague as to use case for now, let me
just point out that the concept of source routing opens up a lot of
potential use cases that involve collaborations with intermediaries of
various sorts, but for which flexible communication capability would be
desirable or required (unless you do that out-of-band, which would be so
messy as to largely defeat the point.)
I'm impressed so far by how cleanly and explicitly the BOLTs address
extensibility. I find that reassuring, many thanks to whoever applied their
technical creativity to this aspect.
Was there a BOLT #6?
On Thu, Jan 4, 2018 at 12:13 PM, Christian Decker <
decker.christian at gmail.com> wrote:
> Hi Benjamin,
>
> currently the only piece of information that is kept contstant along the
> entire route is the payment hash, and we will be removing that as well
> in order to further decorrelate hops of a payment and make it harder for
> forwarding nodes to collate hops into a route.
>
> As ZmnSCPxj has pointed out we do have the possibility of adding some
> information in the onion packet. You can even give every single hop its
> very specific information in the onion. Say for example you have a node
> that does currency conversion, you may specify the desired exchange rate
> in the onion.
>
> May I ask what use-case you are looking to implement using this feature?
>
> Cheers,
> Christian
>
> Benjamin Mord <ben at mord.io> writes:
> > Are there, or will there be, annotations one can add to a lightning
> > transaction that can be read by all intermediate nodes along a given
> route?
> > Conversely, can one add annotations readable only by certain specific
> known
> > (to sender) intermediate nodes?
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180111/011a25a2/attachment.html>

2023-06-09 14:48:22

- reply

📅 Original date posted:2018-01-02
📝 Original message:
Are there, or will there be, annotations one can add to a lightning
transaction that can be read by all intermediate nodes along a given route?
Conversely, can one add annotations readable only by certain specific known
(to sender) intermediate nodes?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180102/72057803/attachment.html>

2023-06-09 14:47:43

- reply

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

2023-06-09 14:47:42

- reply

📅 Original date posted:2017-11-16
📝 Original message:
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. 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. 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. 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.)
I'll post more about this on http://ben.mord.io
Thanks,
Ben
On Thu, Nov 16, 2017 at 9:26 AM, Ivan Raszl <iraszl at gmail.com> wrote:
> I came across a thread discussing lightning network on reddit. A comment
> was stating there is an unresolvable issue with the concept of lightning
> network, related to routing. Quoting the comment:
>
> "The problem is, actually scaling and preventing decentralization requires
> far more than a nice UX that lets you shoot tx from alpha-tester-A to
> alpha-tester-B, and Lightning currently utterly fails at both of them. It
> can't scale to 100,000 users due to routing difficulties; nor does it has
> any plan of bootstrapping to "everyone using it" without the hubs
> hypercentralizing to a few "liquidity providers" (read:banks); nor does it
> have any plans to have actual security on a congested blockchain with high
> fees. As a scaling solution, Lightning is a lot worse than the blockchain
> itself right now."
>
> Can somebody comment on this? Thanks!
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20171116/d24b925d/attachment.html>

2023-06-09 14:47:42

- reply

📅 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>