Newsletters: add 63 (2019-09-11) #222
Conversation
| own change or in conjunction with other ongoing development such as | ||
| [Erlay][]. | ||
|
|
||
| - [Bitcoin Core #14540][] allows users to create new wallets for |
|
|
||
| ## Notable code and documentation changes | ||
|
|
||
| *Notable changes this week in [Bitcoin Core][bitcoin core repo], |
There was a problem hiding this comment.
Have you considered covering the miniscript repos? I think they deserve attention.
During the last two weeks there has been quite some activity in the C++ and Rust miniscript repos thanks to your call for review in a previous newsletter:
- Miniscript request for comments: the developers of this language have requested community feedback on their initial design.
Recent review activity in the miniscript C++ repo:
- Avoid termination due to unhandled exception when parsing invalid arguments to after(...), older(...), thresh(...) and thresh_m(...)
- Avoid assertion failure on after(k) or older(k) where k < 1 or k >= 0x80000000UL
- Avoid running out of stack space by limiting recursion depth in Parse(...)
- Policies with too high nesting depth are not rejected: It is possible to create small inputs that cause extreme memory usage (in practice: OOM kill or std::bad_alloc)
- "or(sha256(H),sha256(H))" not requivalent to "sha256(H)" in threshold construction?
- Avoid floating-point division by zero and assertion failure when handling large relative probabilities (N@)
Recent review activity in the rust-miniscript repo:
- Compiling invalid policy "or(pk())" causes "index out of bounds: the len is 1 but the index is 1
- Compiling heavily nested policy causes "fatal runtime error: stack overflow"
- Compiling thresh-policy with after(0) or older(0) (such as "thresh(2,after(0),pk(),pk())") causes panic
- Compiling invalid policy "thresh(1,thresh)" causes "index out of bounds: the len is 0 but the index is 0"
- Compiling invalid policy "and(pk())" causes assertion failure
- Compiling invalid policy "thresh(2,pk(),thresh(0))" causes "index out of bounds: the len is 0 but the index is 0"
- Compiling invalid policy "thresh(2,pk(),thresh(0,pk()))" causes "threshold subs, which we just compiled, typeck: TypeCheck("fragment «thresh(0,jtvc:pk_h())» has a threshold value of 0")"
Some coverage could perhaps attract additional reviewers? Together we can make the miniscript implementations super robust! :-)
There was a problem hiding this comment.
I'm trying to avoid significant increases in the amount of work that goes into the newsletter from now until the end of the year as I've committed to several non-newsletter Optech projects that I want to make progress on (e.g. the Scaling Book we've been working on for over a year now and only have two chapters and an intro done).
If someone else wants to monitor a particular project and write summaries, that's fine (although I'll warn you that I may be picky about what I consider notable).
There was a problem hiding this comment.
I empathize, and good luck with the Scaling Book 🥇
| --- | ||
| This week's newsletter describes a demo implementation of eltoo and | ||
| several discussions related to it, requests comments on limiting the | ||
| normal number of LN gossip updates to once per day, and provides our |
| Lightning-Dev mailing list, Richard Myers [posted][eltoo sample] a link | ||
| to a sample implementation of an eltoo payment flow between nodes on a | ||
| custom [signet][]. [Eltoo][] is a proposal to replace LN's current | ||
| enforcement layer, which depends upon the threat of a penalty for any |
| any earlier state within a certain period. With eltoo, there's no | ||
| penalty required, simplifying many aspects of the protocol and reducing | ||
| the complexity of many proposed protocol enhancements. Myers's sample | ||
| implementation works by using the Bitcoin Core integration test |
There was a problem hiding this comment.
possibly: s/works by using/uses/ and s/integration/functional/
| mechanism that gives the latest state the ability to spend funds from | ||
| any earlier state within a certain period. With eltoo, there's no | ||
| penalty required, simplifying many aspects of the protocol and reducing | ||
| the complexity of many proposed protocol enhancements. Myers's sample |
There was a problem hiding this comment.
perhaps s/Myers's/Richard's/
| implementation works by using the Bitcoin Core integration test | ||
| framework to simulate payments in an eltoo payment channel. | ||
|
|
||
| This lead to a discussion ([1][eltoo ms 1], [2][eltoo ms 2]) of |
| whether using [miniscript][] would help make LN "more future-proof | ||
| and extensible than directly using Bitcoin Script." | ||
|
|
||
| It also lead to eltoo co-author Christian Decker writing a |
| [summary][eltoo summary] of why he thinks eltoo is especially | ||
| valuable in providing a clean separation of protocol layers. For | ||
| example, by making state changes in eltoo similar to state changes | ||
| in Bitcoin, this allows tools and contract protocols built for |
There was a problem hiding this comment.
perhaps s/allows/would allow/ if not yet implemented
| regular Bitcoin transactions (state changes) to be easily reused | ||
| within payment channels. | ||
|
|
||
| - **Request for comments on limiting LN gossip updates to once per |
There was a problem hiding this comment.
Could possibly be in the Action items section?
There was a problem hiding this comment.
Although phrased as a RFC, I see this item as really a feature announcement for the ability to reduce gossip requirements. The people who should be responding are probably other LN implementation maintainers, and they should probably be reading the Lightning-dev mailing list directly. :-)
| ## News | ||
|
|
||
| - **Eltoo sample implementation and discussion:** on the | ||
| Lightning-Dev mailing list, Richard Myers [posted][eltoo sample] a link |
There was a problem hiding this comment.
fwiw interesting eltoo thread launched by Richard Myers an hour ago https://twitter.com/remyers_/status/1171026810005532673?s=20
There was a problem hiding this comment.
He just sent a longer description to the Lightning-dev mailing list, so I think we're good with just the existing link to that thread in the newsletter.
| default is adjustable). In theory, the channel can still be used | ||
| after this---which is why it isn't closed---although the node may not | ||
| have enough funds to initiate a spend, possibly making receiving its | ||
| only option unless onchain feerates drop. Because of a limitation of |
There was a problem hiding this comment.
perhaps s/onchain/on-chain/ and s/Because/Due to/
There was a problem hiding this comment.
|
Edits pushed for feedback so far. Thanks all! |
| - **Eltoo sample implementation and discussion:** on the | ||
| Lightning-Dev mailing list, Richard Myers [posted][eltoo sample] a link | ||
| to a sample implementation of an eltoo payment flow between nodes on a | ||
| custom [signet][]. [Eltoo][] is a proposal to replace LN's current |
There was a problem hiding this comment.
I find this sentence with subclause a bit difficult to parse (since it places the description of LN-penalty between the word Eltoo and the description of LN-eltoo). Consider re-ordering to something like:
"The current LN enforcement layer depends on the threat of a penalty for any party that attempts to use an old channel state. Eltoo replaces this with an enforcement mechanism that gives the latest state the ability to spend funds from any earlier state within a certain period." or similar
| - [Bitcoin Core #15759][] increases the number of outbound connections | ||
| the node will make from 8 to 10. The two new connections will only be | ||
| used to announce and relay new blocks; they won't announce or relay | ||
| unconfirmed transactions. Only announcing blocks minimizes the |
There was a problem hiding this comment.
Perhaps also mention that the block-relay connections will not gossip ADDRs?
| the node will make from 8 to 10. The two new connections will only be | ||
| used to announce and relay new blocks; they won't announce or relay | ||
| unconfirmed transactions. Only announcing blocks minimizes the | ||
| bandwidth overhead of the new connections and doesn't give spy nodes |
There was a problem hiding this comment.
s/bandwidth/bandwidth and memory/
| to partition the network and execute various attacks possible against | ||
| isolated nodes. If no problems are found with this change and the | ||
| bandwidth overhead remains small, it's possible the number of | ||
| blocks-only peers may be increased in later versions, either as its |
There was a problem hiding this comment.
Suhas renamed these connections to block-relay connections to avoid confusion with blocks-only mode bitcoin/bitcoin#15759 (review)
harding
force-pushed
the
2019-09-11-newsletter
branch
from
cead9d1 to
56822ff
Compare
|
Pushed edits for @jnewbery second-round feedback (thanks!). I actually read the PR comments for block-relay-connections, rather than just the merge commit summary, and substantially rewrote this item. John: given that we're on even more different than usual timezones and busy with Scaling Bitcoin stuff, please feel free to edit yourself or drop this item from this week's newsletter (we can cover it next week). |
|
tACK 56822ff |
|
Edit a48dfe5 LGTM. Thanks! |
bitschmidty
force-pushed
the
2019-09-11-newsletter
branch
from
a48dfe5 to
5b5189c
Compare
|
A demo of eltoo from Richard Myers Our longest list of notable changes to date @harding thanks for another educational newsletter! @jnewbery @jonatack @kanzure thanks for the review input. @practicalswift thanks for volunteering to write the miniscript section! :P |
No description provided.