Newsletters: add #22 (2018-11-20) #86
Conversation
| necessarily defined or agreed upon yet---but the basic outline of the | ||
| new features is available. In linking to the [working outline][ln1.1 | ||
| outline], Rusty Russell noted the following highlights: "multi-path | ||
| payments, dual-funded channels, splicing , wumbo, hidden destinations, |
There was a problem hiding this comment.
Nit: Remove space after splicing :-)
|
@cdecker @renepickhardt - if you have time to review the LN sections, that'd be amazing. We publish Tuesday morning (US east coast time). |
| necessarily defined or agreed upon yet---but the basic outline of the | ||
| new features is available. In linking to the [working outline][ln1.1 | ||
| outline], Rusty Russell noted the following highlights: "multi-path | ||
| payments, dual-funded channels, splicing , wumbo, hidden destinations, |
There was a problem hiding this comment.
I understand it is a quote but maybe we can add [arbitrary channel capacity] after wumbo. also context could be given (c.f.: https://www.youtube.com/watch?v=--hsVknT1c0 )
There was a problem hiding this comment.
never mind! I see that you are explaining the meaning of wumbo below
| For more information, see the following Lightning-Dev threads | ||
| which often call this feature Atomic | ||
| Multi-path Payments (AMP): [1][roasbeef amp], [2][zmn base amp], | ||
| [3][pickhardt local amp]. |
There was a problem hiding this comment.
we should add that it was agreed that we would go for base amp (which is much easier to implement)
We could even add a short paragraph describing that all paths commit to the same payment hash but the recipient only releases the preimage if enough partial incoming partical htlcs are detected.
also I should mention that my proposal with local amp is probably to optimistic
| incentive mechanism that can reward capital providers like Bob is | ||
| still being discussed. For more information, see the following | ||
| threads: [1][neigut liquidity], [2][zmn liquidity], [3][zmn dual | ||
| rbf]. See also [Newsletter #21][]. |
There was a problem hiding this comment.
I suggest that we add somewhere (probably in the first paragraph) that the initiator of the channel currently also pays the fees for closing the channel. There was an entire discussion about the game theory of fees in the meeting as far as I see you have not mentioned symmetric CSV which would actually lock the funds in a unilateral close for both sides. Also here is not discussed who will pay the fees now and why. (Maybe that would be too technical and you linked to the discussions)
There was a problem hiding this comment.
I'm adding a note for "the initiator of the channel currently also pays the fees for closing the channel" as you suggest, but I don't see any other easy changes---it seems to me, as is said in the post, that finding the best incentive mechanism for dual-funded is still being discussed. (One of the nice things about having a weekly newsletter, is that we often get the opportunity to write follow-up stories---so there's usually no need to go too deep on things that are still being worked on. For example, this particular week's newsletter adds detail to items mentioned in three previous weeks.)
Is the symmetric CSV comment directly regarding dual-funded or is it a suggestion for a separate item? I see https://github.com/lightningnetwork/lightning-rfc/wiki/Brainstorming#symmetric-csv-delay which does sound interesting and I see that it's one of the accepted proposals in the 1.1 spec draft. I didn't mention CSV here since it wasn't in Rusty's highlights I used as a filter, but I'm happy to write it up if you think it's noteworthy (I just need to know whether it should go with dual-funded or be a separate item).
| receives the payment, he can simply return the success preimage to | ||
| Dan, who returns it to Charlene, and so forth back to Alice. | ||
|
|
||
| However, Tor also has a hidden service mode where the both the |
There was a problem hiding this comment.
remove the first "the" --> Tor also has a hidden service mode where the both the
|
|
||
| For more information, see the following threads where this feature | ||
| is also called rendez-vous routing: [1][cjp rz], [2][zmn rz], [3][zmn | ||
| rz packetswitch]. |
There was a problem hiding this comment.
I think there is an important remark by @cdecker which you should also link to: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001574.html though it is in the threads that you mentioned
There was a problem hiding this comment.
Oh, that is very important. Thank you! I didn't read past the first post in that thread before linking to it (sorry, you people put in a crazy amount of work last week and I'm still trying to catch up!). I just did my homework and I think even more important is Decker's extended remark on Zmn's base AMP proposal at https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001573.html, Fromknecht's reply, and the rest of that sub-thread.
Since all of those are encompassed by the linked threads, what I'm going to do is keep those links the same but provide a prominent link to https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx as suggested by Decker subsequent to your comment above. Of course, please let me know if you disagree or see a better option.
| nodes to tell their peers and potential peers which block chains | ||
| they're interested in to avoid the wasted effort of sharing data about | ||
| uninteresting chains. (We didn't find any recent threads about these | ||
| particular proposals, so there are no reference links.) |
There was a problem hiding this comment.
I am also a little bit confused with this passage. I think I remembered that we explicitly agreed to leave everything out that would require a base layer update at this point (in particular noinput & schnorr) so maybe omit this paragraph or ask on the lightning dev list / check with other devs?
What I remember is that we discussed having a random but stable backbone set of nodes that should be known to mobile nodes so that they don't have to store the entire network graph in order to be able to route payments
There was a problem hiding this comment.
Each of the items was listed here: https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States#gossip-changes
However, that's not much information and I wouldn't be surprised if I extrapolated too much. It was also vague, so I'm just removing it from this already-too-long newsletter.
| the same parties. Closing one channel and opening another requires | ||
| completely stopping all payments between the two parties until an | ||
| appropriate number of onchain confirmations have been received for the | ||
| close-and-reopen transaction. |
There was a problem hiding this comment.
Even more importantly splice-outs allow you to perform on-chain payments directly out of an off-chain contract. This means that there is no need to differentiate between off-chain and on-chain funds anymore. This goes a long way towards a much simpler UX where users don't have to differentiate, and in combination with AMP it allows us to hide the channel management completely from the user.
|
|
||
| For more information, see the following threads where this feature | ||
| is also called rendez-vous routing: [1][cjp rz], [2][zmn rz], [3][zmn | ||
| rz packetswitch]. |
There was a problem hiding this comment.
For a detailed writeup you can point to https://github.com/lightningnetwork/lightning-rfc/wiki/Rendez-vous-mechanism-on-top-of-Sphinx. We're trying to aggregate the discussions in the Wiki so it should get easier to get a complete view of the proposal instead of having to read through the evolution in the form of mails 😉
There was a problem hiding this comment.
Also if anybody has an idea on how to write that up in a more concise and precise way I'd be happy to hear :-)
|
I reviewed the non-LN parts. The section on fees and hash rate looks good to me. I'll try to review the LN section from a lay person perspective after any changes based on LN experts review. |
|
I pushed a bunch of commits (eventually to be squashed) with one commit per comment or suggestion, labeling each commit with the name of the person who made the suggestion. I also also left replies on a couple of the comments. I think that should address all feedback. I also added a Special Thanks section thanking y'all for your feedback, as I'm very grateful to have it. |
| Specification 1.1. Thirty proposals were accepted at a | ||
| high-level---meaning full specifications for each proposal are not | ||
| necessarily defined or agreed upon yet---but the basic outline of the | ||
| new features is available. Below, Optech has attempted to briefly |
There was a problem hiding this comment.
Could tighten up this sentence a little:
- "an email" - which email? (it's the one you linked to earlier in this paragraph, but that's not clear)
- "by Rusty Russell" - is the email by Rusty or the working outline. I think you mean the email, but that's not clear.
Suggest something like:
"Rusty Russell's [summary email to the mailing list][rusty wrapup] links to the [working outline][ln1.1 outline] and highlights multi-path payments, dual-funded channels, splicing, wumbo, hidden destinations, and 'many gossip improvements' as being of particularly interest. Below, Optech summarizes those highlights." (and remove the [met in Adelaide] link above).
There was a problem hiding this comment.
Actually, also remove 'many gossip improvements', since you've removed the section on that.
There was a problem hiding this comment.
Dropping the whole quote and moving the link earlier in the paragraph. I was trying to be clever by letting Russell choose the topics, but it was quite wasteful to try to demonstrate my cleverness---especially after we removed the gossip point and added the not-spec'd paragraph.
| - **Multi-path payments:** the current normal way to make a payment over | ||
| LN is using a single path. Alice pays Charlie through her channel to | ||
| Bob and Bob's channel to Charlie. This works well for small payments | ||
| where each participant has enough balance or capacity in their channel |
There was a problem hiding this comment.
s/balance or capacity/balance and capacity/
| receives multiple payments within a reasonable time period that | ||
| equal or exceed the expected amount, he can reveal their shared | ||
| preimage to claim them simultaneously---providing the same security | ||
| currently used for single-path payments. This also works if some |
There was a problem hiding this comment.
I'd be even more explicit about atomicity here. Something like "By revealing the shared secret, Charlie guarantees that he receives both partial payments. There is no way for one of the payments to succeed and the other to fail."
| receives multiple payments within a reasonable time period that | ||
| equal or exceed the expected amount, he can reveal their shared | ||
| preimage to claim them simultaneously---providing the same security | ||
| currently used for single-path payments. This also works if some |
There was a problem hiding this comment.
Consider pulling the last sentence out into a new paragraph. Being able to branch further along the path solves a big problem with unroutable payments and seems sufficiently important to have its own paragraph.
(in fact, I think being able to have multiple branches further along the path is more useful than the first version you've used with multiple small channels from Alice, but I think introducing that way is probably more intuitive and so makes sense)
There was a problem hiding this comment.
A new paragraph! And ruin my precious parallelism between each of these points! Are you crazy! :-)
Seriously, I'm confused by your remark. Splitting further along the path was something I deliberately didn't describe because the base AMP proposal indicated it might be unsafe so I don't want to promise it. What's described here is merging along the path---to make that clearer, I'm revising the phrasing slightly.
I don't think a single sentence about path merging is enough to warrant a new paragraph, so I'm leaving the sentence where it is (feel free to overrule), but if you want an upgrade to an additional sentence about non-spender path splitting, I'll throw in the extra paragraph for free. :-)
There was a problem hiding this comment.
I think it looks great as it is in your latest commit.
I hadn't read the Base AMP emails before my comment and was going off my (limited) knowledge of OG AMP where I thought arbitrary splits were allowed and payment was guaranteed to be atomic.
I don't understand the point in zmn's email about the safety of arbitrary splits. Hopefully at some point there'll be an explanation on the mailing list of why that is.
| funds to it. For example, Alice opens a channel to Bob with 0.1 BTC | ||
| of her money and none of Bob's money. This makes it very easy for | ||
| users to accept new incoming channels as they don't cost the receiving | ||
| user anything---not even any opportunity costs (except for operating |
There was a problem hiding this comment.
"not even any opportunity costs". What do you mean here? Are you alluding to tying up liquidity in a channel? I think that might not be obvious for readers with less background knowledge.
Consider either expanding this or removing.
There was a problem hiding this comment.
Ah, I see you've made it more explicit below. Consider moving that explanation up to here.
| routing path including Bob until Alice has sent Bob some money. This | ||
| creates a bootstrapping problem: if Alice wants to receive payments | ||
| via LN, she has to get people to open new channels to her node---which | ||
| requires them paying possibly-high onchain fees and waiting for onchain |
There was a problem hiding this comment.
"requires them paying .. and waiting" or "requires them to pay ... and wait"
|
|
||
| The reason long interblock periods become more common at a faster rate | ||
| than average interblock times increase is because the variance for | ||
| independent events is the square of the average. |
| preparing any fee-reduction measures you're willing to use such as | ||
| payment batching. | ||
|
|
||
| - *Increased revenues for profit-maximizing miners:* each time |
There was a problem hiding this comment.
Note that mining becomes more profitable even before a difficulty adjustment because fees become a more significant proportion of coinbase reward (eg https://blockstream.info/tx/09ed9d39d5dab626b8d55dd0b36e63eaf15d7e19b34fa8effaae2cba8381d43c had almost 0.9BTC of fees)
There was a problem hiding this comment.
I think your comment is just saying that higher fees (described in the text's previous bullet point) mean more miner profit, ceteris paribus. That's an obvious insight I missed, so I'm adding it. However, the way you've phrased it makes me wonder whether I'm missing some subtler point---if so, please let me know!
There was a problem hiding this comment.
no, that's it exactly. Miners get higher fees until the downwards difficulty adjustment, and then they get more frequent blocks. Christmas has come early!
| 10% of the list's traffic in the past 365 days. Many of the threads | ||
| continue conversations started at the protocol developers summit. If | ||
| you're interested in Lightning protocol development, we suggest | ||
| reading each of this month's [threads][ln list]. |
There was a problem hiding this comment.
Was this supposed to link to a thread view of the LN mailing list? It links to the list info page.
|
|
||
| ## Special thanks | ||
|
|
||
| We thank Chris Decker, PracticalSwift, and Rene Pickhardt for providing |
There was a problem hiding this comment.
Christian Decker, practicalswift, and René Pickhardt
|
I've reviewed e9bb477 and confirmed that all fixup commits do what they say. I'm happy for them to be squashed (not sure if Dave wants to wait until the other reviewers have had a chance to review the individual fixup commits). |
|
oh, also added an "Bitcoin Optech News" section with a note that the second workshop was held. |
harding
force-pushed
the
2018-11-20-newsletter
branch
from
7229ea3
to
da9dc36
Compare
|
I believed I've addressed @jnewbery's excellent suggestions (with some notes left in individual comments), done a new proofread with a few minor edits, and squashed down to one commit. The original branch and the commit addressing John's points is here: https://github.com/harding/bitcoinops.github.io/commits/2018-11-20-newsletter-orig |
|
|
||
| - **Wumbo:** by agreement among early LN implementations, currently each | ||
| channel's capacity is limited by default to about 0.168 BTC (about $40 | ||
| USD when defined; currently about $850). This was [chosen][russell |
| A proposed solution to this problem is to allow dual-funded | ||
| channels. Alice agrees to put 0.1 BTC into a channel with Bob if | ||
| Bob agrees to open the channel with 0.1 BTC of his own funds. This | ||
| can cost Bob money---namely onchain transaction fees and lost |
There was a problem hiding this comment.
nit: is 'lost opportunity cost' right? Should it be 'onchain transaction fees and the opportunity cost'
|
One additional small nit. Otherwise tACK da9dc36. The newsletter is always great, but I think this may be the best yet. There's so much great information in here! Thanks Dave, and thanks to @cdecker @renepickhardt and @practicalswift for contributing. |
harding
force-pushed
the
2018-11-20-newsletter
branch
from
da9dc36
to
d134887
Compare
|
Nit addressed and price-dependent note updated. Thanks again everyone! Edit: removed pasted-in diff. I just realized GitHub now provides a diff of force-pushed changes. Nice! |
|
@jnewbery oh, I just realized that the bullet about mining was sounding pretty odd with the recent price drop, so I added a sentence providing an alternative perspective. Feel free to remove or edit that addition freely (or anything else, as always). |
That is nice! I didn't know they'd added that. tACK 79f75ca . Will squash & merge. |
jnewbery
force-pushed
the
2018-11-20-newsletter
branch
from
79f75ca
to
596d9e3
Compare
|
✋s all round! Great newsletter 🙂 |
Our longest newsletter yet. Hopefully that doesn't scare readers away.
If we can get a LN expert to review the feature news section, I'd love that. In case we can, hopefully I've described things at high enough level that I didn't get too much wrong.