Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Newsletters: add #22 (2018-11-20) #86

Merged
merged 1 commit into from Nov 20, 2018

Conversation

@harding
Copy link
Contributor

harding commented Nov 17, 2018

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.

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,

This comment has been minimized.

Copy link
@practicalswift

practicalswift Nov 18, 2018

Nit: Remove space after splicing :-)

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 18, 2018

@cdecker @renepickhardt - if you have time to review the LN sections, that'd be amazing. We publish Tuesday morning (US east coast time).

Copy link

renepickhardt left a comment

Very nice write up. Only have some minor points! Thanks for all the effort you put into creating this summary.

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,

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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 )

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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].

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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][].

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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)

This comment has been minimized.

Copy link
@harding

harding Nov 18, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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].

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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

This comment has been minimized.

Copy link
@harding

harding Nov 18, 2018

Author Contributor

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.)

This comment has been minimized.

Copy link
@renepickhardt

renepickhardt Nov 18, 2018

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

This comment has been minimized.

Copy link
@harding

harding Nov 18, 2018

Author Contributor

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.

This comment has been minimized.

Copy link
@cdecker

cdecker Nov 18, 2018

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].

This comment has been minimized.

Copy link
@cdecker

cdecker Nov 18, 2018

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 😉

This comment has been minimized.

Copy link
@cdecker

cdecker Nov 18, 2018

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 :-)

@moneyball

This comment has been minimized.

Copy link
Contributor

moneyball commented Nov 18, 2018

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.

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Nov 19, 2018

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.

Copy link
Contributor

jnewbery left a comment

This is great as always. I've left a bunch of nits. Feel free to take or ignore.

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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).

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

Actually, also remove 'many gossip improvements', since you've removed the section on that.

This comment has been minimized.

Copy link
@harding

harding Nov 19, 2018

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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)

This comment has been minimized.

Copy link
@harding

harding Nov 19, 2018

Author Contributor

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. :-)

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

"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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

"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.

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

Great commenting! 😗 👌

preparing any fee-reduction measures you're willing to use such as
payment batching.

- *Increased revenues for profit-maximizing miners:* each time

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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)

This comment has been minimized.

Copy link
@harding

harding Nov 19, 2018

Author Contributor

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!

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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].

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

Christian Decker, practicalswift, and René Pickhardt

This comment has been minimized.

Copy link
@harding

harding Nov 19, 2018

Author Contributor

D'oh. Thanks!

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 19, 2018

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).

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 19, 2018

oh, also added an "Bitcoin Optech News" section with a note that the second workshop was held.

@harding harding force-pushed the harding:2018-11-20-newsletter branch from 7229ea3 to da9dc36 Nov 19, 2018
@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Nov 19, 2018

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

sir when $1000?

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery Nov 19, 2018

Contributor

nit: is 'lost opportunity cost' right? Should it be 'onchain transaction fees and the opportunity cost'

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 19, 2018

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 harding force-pushed the harding:2018-11-20-newsletter branch from da9dc36 to d134887 Nov 20, 2018
@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Nov 20, 2018

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!

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented Nov 20, 2018

@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).

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 20, 2018

I just realized GitHub now provides a diff of force-pushed changes. Nice!

That is nice! I didn't know they'd added that.

tACK 79f75ca . Will squash & merge.

@jnewbery jnewbery force-pushed the harding:2018-11-20-newsletter branch from 79f75ca to 596d9e3 Nov 20, 2018
@jnewbery jnewbery merged commit d4251a0 into bitcoinops:master Nov 20, 2018
1 check passed
1 check passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented Nov 20, 2018

s all round! Great newsletter 🙂

@jnewbery jnewbery referenced this pull request Jul 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.