Newsletters: add 180 (2021-12-22) #702
Conversation
| that contain all the information necessary to allow a wallet or other | ||
| program to track payments made to or spent from a particular script or | ||
| set of related scripts (i.e. an address or a set of related addresses | ||
| such as in an HD wallet). Descriptors combine well with [miniscript][topic miniscript] in |
There was a problem hiding this comment.
suggest linking to /en/topics/hd-key-generation/ topic
| September, a new `OP_TAPLEAF_UPDATE_VERIFY` opcode was | ||
| [proposed][op_tluv] for creating these sort of covenants in a way that | ||
| takes particular advantage of taproot's ability to spend funds either | ||
| using just a signature (keypath spending) or a MAST-like tree of scripts |
There was a problem hiding this comment.
Suggest MAST link to /en/topics/mast/
|
I would like to add the following to the email version of this newsletter: "Due to the length of this Year-in-Review Special edition of the newsletter, some email clients may abruptly cut off the email's contents. Please view this [newsletter's web page][link to newsletter page] for the full newsletter." Would place this before the "Contents" heading. |
| state. Dual-funding is particularly useful for merchants whose primary | ||
| use of LN is receiving payments instead of sending them. |
There was a problem hiding this comment.
It's not clear to me why Dual-funding would be helpful for users that primarily receive. Either way, the counterparty has to either open the channel or participate in opening. Perhaps this point could be elaborated.
There was a problem hiding this comment.
I'll be pushing an edit but I'm not 100% sure it addresses your concern---I'm confused about why you're confused---so let me know if it doesn't help.
| capabilities | ||
|
|
||
| - [Bitcoin Core 22.0][] included support for [I2P][topic anonymity | ||
| networks] connections, removed support for [version 2 Tor][topic |
There was a problem hiding this comment.
I don't see the same link anywhere else. I think you may be referring to the version 2 address announcements in the Bitcoin Core 0.21.0 notes, which refer to the format how to announce node addresses, while the "version 2 Tor" here refers to Tor versions.
| in Bitcoin Core, the first step towards package relay. [Package | ||
| relay][topic package relay] will allow relay nodes and miners to treat | ||
| packages of related transactions as if they were a single transaction | ||
| for fee purposes. A package might contain a parent transaction with a |
There was a problem hiding this comment.
| for fee purposes. A package might contain a parent transaction with a | |
| for feerate purposes. A package might contain a parent transaction with a |
| risks to contract protocols such as LN from unexpected transaction relay | ||
| behavior. |
There was a problem hiding this comment.
| risks to contract protocols such as LN from unexpected transaction relay | |
| behavior. | |
| impact of transaction relay policy on contract protocols such as LN. |
There was a problem hiding this comment.
I made a slight edit here, but I wanted to try to understand your reason for suggesting this change.
| proposals][bip118 update] were updated to use taproot or [lessons | ||
| learned][bip119 update] from its activation. | ||
|
|
||
| - **August<!--taproot-->** was quiet for development, although some |
There was a problem hiding this comment.
| - **August<!--taproot-->** was quiet for development, although some | |
| - **August<!--taproot-->** was quiet for taproot development, although some |
| [Channel jamming attacks][topic channel jamming attacks], a known | ||
| problem for LN since 2015, received continued discussion throughout the |
There was a problem hiding this comment.
IIUC, first described in 2015 but always a been a problem?
| [Channel jamming attacks][topic channel jamming attacks], a known | |
| problem for LN since 2015, received continued discussion throughout the | |
| [Channel jamming attacks][topic channel jamming attacks], a known | |
| problem for LN discussed since 2015, received continued discussion throughout the |
There was a problem hiding this comment.
I think it wasn't "known" before then, and the description of it was before there actually was a LN (i.e. pre-segwit), so it wasn't exploitable originally.
|
Made edits (or left a reply) for all feedback. Thank you soooo much @bitschmidty @xekyo @glozow @adamjonas !!! |
| this key safety issue. | ||
|
|
||
| An idea original proposed in 2019 for LN saw renewed life in June. The | ||
| original *fast forwards* idea described how an LN wallet could receive |
There was a problem hiding this comment.
suggest adding link/credit to https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html like the ff expanded link in the following sentence. (though admittedly this could be found by clicking the next link)
| After years of discussion, January saw the first [release][bcc21] of a | ||
| Bitcoin Core version supporting [signets][topic signet], following prior | ||
| [support][cl#2816] by C-Lightning and followed by [support][lnd#5025] in | ||
| LND. Signets are test networks anyone can used to simulate Bitcoin's |
There was a problem hiding this comment.
| LND. Signets are test networks anyone can used to simulate Bitcoin's | |
| LND. Signets are test networks anyone can be used to simulate Bitcoin's |
bitschmidty
force-pushed
the
2021-12-22-newsletter-yir
branch
from
8e9d977
to
95afe77
Compare
|
Squashed and merged! Thank you @harding for a great edition and a great year! Thanks to @xekyo @glozow @adamjonas @lsilva01 for the reviews. |
Still some minor items to finish before this PR is complete, but the text is ready for review. I did leave myself a few optional todos if I have some spare time and want to make this a bit longer.