Newsletters: add 179 (2021-12-15) #700
Conversation
lightning-developer
left a comment
lightning-developer
left a comment
There was a problem hiding this comment.
As always a very interesting newsletter I suggested another BOLTs PR and suggest to focus on anchor outputs instead of eltoo in the discussion about fee bumping.
| --- | ||
| This week's newsletter describes a proposal to allow relay of | ||
| transactions with zero-value outputs in some cases and summarizes a | ||
| discussion about preparing LN for the adoption of PTLCs. FIXME:harding |
There was a problem hiding this comment.
This seems very high level. As far as I understood the posts on the mailing list the discussion was mainly about preparing the communication protocol for setting up and settling PTLCs with as little roundtrips as possible. Maybe we could write something like:
... summarizes a discussion about preparing LN for a stepwise upgrade to PTLCs.
There was a problem hiding this comment.
I think this point is covered in the extended description. I prefer to keep the lede as short as possible.
| However, there may be a use for zero-value outputs in [CPFP][topic | ||
| cpfp] fee bumping where the none of the funds from the transaction | ||
| being fee bumped can be spent---all the funds used for fee bumping | ||
| need to come from separate UTXOs, such as in [eltoo][topic eltoo]. |
There was a problem hiding this comment.
aren't anchor outputs the more relevant example here? Anchor outputs are already in practice while eltoo is far from being implemented.
There was a problem hiding this comment.
I don't think there's any advantage to anchor outputs being zero-value. The transaction containing them needs to be fee-bumped, so they might as well contain at least the dust amount of funds to contribute towards that fee bumping.
By comparison, most transactions in an eltoo or statechain system will remain offchain (even if they can all hypothetically be put onchain) and so they can't each pay some value towards an output without quickly draining the system of value. This is usually solved by them using some version of SIGHASH_SINGLE to allow adding additional outputs, but Jeremy Rubin made a case that avoiding SINGLE and using CPFP instead might avoid RBF pinning attacks.
| v2 onions in `node_announcements`. [Rust-Lightning #1204][], also | ||
| merged this week, updates that implementation to follow this updated | ||
| specification. | ||
|
|
There was a problem hiding this comment.
I added lightning/bolts#918 in a PR in @harding 's repo at harding#23 The PR is about dropping the requirement to ratelimit ping and pong messages which ensures higher quality of service for LSPs
There was a problem hiding this comment.
I did think this was minor, but I like the description of how it benefits LSPs. Merged. Thanks!
harding
force-pushed
the
2021-12-15-newsletter
branch
2 times, most recently
from
ba5e6d0 to
0f576a1
Compare
adamjonas
left a comment
adamjonas
left a comment
There was a problem hiding this comment.
A couple of notes but looking good!
| may create problems for no good reason. | ||
|
|
||
| However, there may be a use for zero-value outputs in [CPFP][topic | ||
| cpfp] fee bumping where the none of the funds from the transaction |
There was a problem hiding this comment.
| cpfp] fee bumping where the none of the funds from the transaction | |
| cpfp] fee bumping where none of the funds from the transaction |
| currently-used [HTLCs][topic htlc] and use less block space. | ||
|
|
||
| Teinturier is trying to produce a set of changes that can be made at | ||
| the same time the as the proposed `option_simplified_update` |
There was a problem hiding this comment.
| the same time the as the proposed `option_simplified_update` | |
| the same time as the proposed `option_simplified_update` |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Looking very nice. Got a couple suggestions.
| the same time the as the proposed `option_simplified_update` | ||
| [protocol change][bolts #867] (see [Newsletter #120][news120 | ||
| opt_simp_update]). A secondary goal is trying to make the | ||
| communication protocol compatible with the fast-forward's based PTLC |
There was a problem hiding this comment.
This apostrophe is throwing me off. Should this perhaps be:
| communication protocol compatible with the fast-forward's based PTLC | |
| communication protocol compatible with the fast-forwards-based PTLC |
| - [Bitcoin Core #14707][] updates several RPCs to also include bitcoins | ||
| received in miner coinbase transactions. A new | ||
| `include_immature_coinbase` option to the RPCs allows toggling | ||
| the inclusion of coinbase transactions before they are mature (have |
There was a problem hiding this comment.
Perhaps:
| the inclusion of coinbase transactions before they are mature (have | |
| the inclusion of coinbase transaction outputs before they are mature (have |
glozow
left a comment
glozow
left a comment
There was a problem hiding this comment.
Light review, just one comment
|
Made suggested edits, thanks @lightning-developer, @adamjonas, @xekyo, and @glozow! Also made final additions. |
bitschmidty
force-pushed
the
2021-12-15-newsletter
branch
from
45e3c0e to
1f0e927
Compare
Of course one can argue whether this is a notable code change. I think this feature is very useful for LSPs and it seemed to be heavily motivated from that context by Matt. As Optech reader are mainly professionals I thought I should at least suggest to write about the update.
bitschmidty
force-pushed
the
2021-12-15-newsletter
branch
from
1f0e927 to
3bfcd3a
Compare
|
Small fixup upon final review. Squashed. |
|
Final regular newsletter of the year! Thank you @harding @lightning-developer (two weeks in a row!), @xekyo, @glozow, @adamjonas |
6 participants
Bitcoin Core #20295rpc: getblockfrompeer @xekyoBOLTs #906introduce feature bit to gate new channel_type feature @dongcarl