Newsletters: add #21 (2018-11-13) #85
Conversation
|
utACK fixed a small typo i haven't studied the technical details of much of the content to be able to provide critical feedback, but the explanations are well written and make sense to me. |
| - **Walletless channel opens:** pseudonymous contributor ZmnSCPxj | ||
| [notes][walletless opens] that if [BIP118][] | ||
| SIGHASH_NOINPUT_UNSAFE were adopted to allow implementing the | ||
| [Eltoo protocol][] in LN, then an LN implementation could set up a |
There was a problem hiding this comment.
I don't think the wording "implementing the Eltoo protocol in LN" is quite right. Eltoo is presented as a entirely new protocol, not something to implement in LN (see the wording in the eltoo paper: "This is in stark contrast with the channel commitment invalidation procedure used today in Lightning", "This is in stark contract to the Lightning Network, where the reaction to a previous state being published needs to tailored to that specific state.", "In Lightning the information stored is asymmetric [...] With eltoo the information stored by the participants is symmetric")
This is a bit confusing, since ZmnSCPxj talks about "Lightning implementations" using SIGHASH_NOINPUT. Perhaps eventually we're just going to call all Payment Channel Networks "Lightning Networks", but for now I think it's clearer to maintain the distinction. I like "Payment Channel Network" or PCN as used in the Multi-hop lock paper (https://eprint.iacr.org/2018/472.pdf) since it's agnostic to the construction of the channels and routing, although perhaps PCN is not widely recognised.
Perhaps: "if [BIP118][]SIGHASH_NOINPUT_UNSAFE were adopted, as originally proposed in the [Eltoo paper][], then a Payment Channel Network implementation could..."
There was a problem hiding this comment.
Christian Decker here (which was presumably written after the paper, since it's the announcement for the paper).
are we trying to replace Lightning with this proposal? Absolutely not! [...] The Lightning Network specification is no longer the specification of a single protocol, but rather a full stack of protocols, each fulfilling its own responsibilities. eltoo doesn’t aim to replace the entirety of the Lightning stack; rather it is a drop-in replacement for the original update mechanism that maintains backward compatibility with the other parts of the stack.
I also personally think of Eltoo as a module for LN/PCNs rather than a replacement for LN. I think we're going to see the protocol become increasingly modular as it gets built out and people find they have special needs.
I also think that we're stuck with the LN name, but I'm happy to rewrite this to use PCN if you think that'd be useful.
There was a problem hiding this comment.
I removed this summary. As I was proofreading my description of Zmn's idea the other day, I identified a possible flaw in it, which Zmn has now confirmed. This makes the idea less interesting, at least to me, and I think we have enough other news now that we don't need this item or a debate about where Eltoo fits in the PCN stack. :-)
There was a problem hiding this comment.
a debate about where Eltoo fits in the PCN stack
I was enjoying our debate! (but I'm sure we'll have an opportunity to revisit it at some point!)
| functions that don't require access to the internal state of the node | ||
| or wallet. During last week's developer IRC [meeting][core dev | ||
| meeting], members of the project reaffirmed their commitment to not | ||
| providing any new utility functions under normal circumstances in |
There was a problem hiding this comment.
I think this part "not providing any new utility functions" and below "the ability to gracefully deprecate those options" are putting it a bit strongly. See sipa and wumpus from the meeting:
19:16:18 i think that bitcoin core, for better or worse, implements certain featuresets - and it makes sense to implement those features completely, even if some are stateless
...
19:17:19 [...] signrawtransaction makes perfect sense, as we offer raw transaction functionality
19:15:12 I don't think the current ones should be removed, but i'm not sure about adding new ones
19:24:45 I'm not arguing to remove the current ones or so, just prevent an onslaught of new ones
sipa is saying for certain utilities it makes sense to offer them as an RPC even if they are stateless, and wumpus is saying that the goal isn't to deprecate existing RPCs, just to prevent feature creep.
There was a problem hiding this comment.
I'd recommend just removing the "giving the Bitcoin Core project the ability to gracefully deprecate those options and recommend the new tool to users needing those functions." part.
There was a problem hiding this comment.
To be fair, I wrote "not providing any new utility functions under normal circumstances" :-) sipa gave specific reasons in the meeting for when he thought they'd be ok to add (and provided a specific example). I also think there were comments in the meeting about wanting to be able to deprecate at least some of the utility functions, e.g.
i don't really care for decodescript being in our codebase really - it's trivial to do anywhere
That said, I think you're right about removing that final clause. I'll do that.
There was a problem hiding this comment.
I've edited this both per your suggestion and a bit extra too so I think the current text should be a quite conservative reading of the meeting discussion.
| {% include linkers/github-log.md | ||
| refname="lnd commits" | ||
| repo="lightningnetwork/lnd" | ||
| start="6b19df162a161079ab794162b45e8f4c7bb8beec" |
There was a problem hiding this comment.
Is this the wrong start commit? The link shows merge commits going all the way back to Oct 23rd.
There was a problem hiding this comment.
It is. Unfortunately, last week I forgot to update the info for LND so it has the same info as two weeks ago. I noticed the problem when I reviewed this week, but I don't have the data to reconstruct where I left off last week (bash history doesn't even help me here, as I git diff 1234abcd...upstream/master).
If you want, I can make a guess for where I left off and put that in.
There was a problem hiding this comment.
No, not a big issue. Let's leave it as is.
| - [LND #1944][] adds a `pub_key` field to the `sendtoroute` RPC so that | ||
| LND doesn't need to get the pubkey from an external source. This | ||
| allows routing payments through private channels that are not listed | ||
| on the public network. |
There was a problem hiding this comment.
I think the final sentence of the PR description is also very interesting and should be included: "It is also a step towards the unbundling of lnd. (maybe, in the future, we get a node that doesn't track the channel graph at all anymore and is just a payment executor. mobile maybe?)"
There was a problem hiding this comment.
I can't think of a reason why that'd be a useful feature. You can do remote authorization (e.g. channel on server, keys on mobile) without creating a separate channel requiring occasional on-chain txes between the server and mobile. What am I missing?
There was a problem hiding this comment.
My (mostly uninformed) understanding of lightning routing is that keeping an up-to-date graph of channels could be quite resource intensive, and therefore difficult to maintain on devices with limited compute or bandwidth. Allowing the route to be specified in sendtoroute would allow a node to run on those devices without maintaining that expensive channel graph.
There was a problem hiding this comment.
This is a secondary motivation for the PR, so I think it's fine to leave it out. If there are further PRs to allow graphless nodes then we can cover those in the newsletter.
jnewbery
force-pushed
the
2018-11-13-newsletter
branch
from
2fb1a49 to
765798a
Compare
|
Looks good. I've left a few comments inline. I don't think there would be anything wrong with mentioning bitcoin#14437 in this week's newsletter, but we'll have plenty of opportunities to cover node/wallet separation in future newsletters, so I'm fine leaving it out.
Finally, I've opened a PR against this branch for the Lightning residency talks: harding#1. |
Just saw your recommendation to wait until Dec 1st for this. Sounds good to me. |
|
@moneyball my web-merge of John's summaries seems to have silently removed your typo fix. I think your fix was s/change/changes/ in the opening paragraph, but I'm not absolutely sure. Can you either confirm that was indeed the fix or, if not, re-do the fix? (Sorry) |
harding
force-pushed
the
2018-11-13-newsletter
branch
from
65751fc to
dbe83b6
Compare
|
Pushed an edit update that I think addresses @jnewbery's points about Eltoo and utility functions (see comments I left in those threads). I have not made any changes regarding the wrong commit or the LND payment executor, as I think what we have now is slightly better than the presented alternatives---however, if either of you feel more strongly about changing those, please do! Also, regarding linking to the weekly dev meeting summaries, if those are available for last Thursday by merge time, please feel free to change the current link that goes directly to the log to the link for that section in the summary (which should itself have a link directly to the log). That's some promotion we can easily give now in advanced of the December recommendation. Please feel free to squash down to just two commits (yours and mine) at merge time. |
Sorry, this is my fault. I squashed and pushed @moneyball's change before opening my PR. I meant to note that in my update earlier. Steve's change is included in the most recent branch. |
jnewbery
force-pushed
the
2018-11-13-newsletter
branch
from
dbe83b6 to
94f6511
Compare
3 participants
This week's news is a bit short, but I'm hoping @jnewbery will be inserting a section about the LN Residency talk videos.
@jnewbery I decided against mentioning bitcoin#14437 (prep for separating node and wallet) in the code changes section as it's just preface to the real work---work I certainly do plan to mention when that gets merged (or earlier, if it otherwise becomes newsworthy). However, I know you're following the progress of the separation more closely than I am, so let me know if you think 14437 should go in this newsletter.