Newsletters: add 135 (2021-02-10) #515
Conversation
| layout: newsletter | ||
| lang: en | ||
| --- | ||
| This week's newsletter links to the summary of last week's taproot |
There was a problem hiding this comment.
| This week's newsletter links to the summary of last week's taproot | |
| This week's newsletter links to a summary of last week's taproot |
There was a problem hiding this comment.
Other people have written summaries (e.g. Folkson's email links to Rusty Russell's toot summary), so I think "a" is the most appropriate article here.
| --- | ||
| This week's newsletter links to the summary of last week's taproot | ||
| activation meeting and announces another scheduled meeting for next | ||
| week, plus describes recent progress in discreet log contracts and a new |
There was a problem hiding this comment.
| week, plus describes recent progress in discreet log contracts and a new | |
| week, plus it describes recent progress in discreet log contracts and a new |
| deployment about one year subsequently. | ||
|
|
||
| More controversial was whether the `LockinOnTimeout` (LOT) parameter | ||
| should be set to *true* (requiring miners either eventually signal |
There was a problem hiding this comment.
probably fine as-is, but for similar construction as the next clause ("allowing miners to signal...")
| should be set to *true* (requiring miners either eventually signal | |
| should be set to *true* (requiring miners to either eventually signal |
| arguments he's seen for the two different options and announcing a | ||
| follow-up meeting to discuss them (and some less controversial | ||
| issues) in the Freenode ##taproot-activation channel on February | ||
| 16th at 19:00 UTC |
There was a problem hiding this comment.
| 16th at 19:00 UTC | |
| 16th at 19:00 UTC. |
| adaptors][topic adaptor signatures], effective compression algorithms | ||
| for DLCs contingent on numeric outcomes, and support for k-of-n | ||
| threshold signing from oracles "even supporting numeric cases where | ||
| some bounded difference is permitted between oracles". |
There was a problem hiding this comment.
feel free to ignore, but (and see line 207 below ;)
| some bounded difference is permitted between oracles". | |
| some bounded difference is permitted between oracles." |
|
|
||
| - [Bitcoin Core #20764][] adds additional information to the output | ||
| produced using `bitcoin-cli -netinfo`. New details include the number | ||
| of manually added peers, peers using [BIP152][] "high-bandwidth" |
There was a problem hiding this comment.
Ah nice!
I know the BIP writes it with the hyphen, but while adding High Bandwidth to the GUI peer details in bitcoin-core/gui#206, I realized that it's incorrect/poor style (and will fix in the -netinfo docs in the next change ;)
| of manually added peers, peers using [BIP152][] "high-bandwidth" | |
| of manually added peers, peers using [BIP152][] "high bandwidth" |
There was a problem hiding this comment.
The update also adds the connection types. Example (with I2P peers, high bandwidth peers, the works):
|
Pushed edits and additional content, and reviewed everyone else's contributions (thanks!). |
| deployment about one year subsequently. | ||
|
|
||
| More controversial was whether the `LockinOnTimeout` (LOT) parameter | ||
| should be set to *true* (requiring miners either eventually signal |
There was a problem hiding this comment.
s/should/should, by default,
| (with witnesses). Version 2 is required to reconstruct segwit | ||
| blocks. Segwit was activated in August 2017, so providing version 1 | ||
| pre-segwit compact blocks to peers is no longer useful; without the | ||
| witnesses, peers are unable to validate the consensus rules on |
There was a problem hiding this comment.
"validate the consensus rules on them" sounds awkward to me. "of them", "against them" maybe?
|
ACK 394e7c3 |
| - [HWI #433][] adds support for signing PSBTs with OP_RETURN outputs. | ||
|
|
||
| - [Bitcoin Core #19509][] adds per-peer message capture between nodes as well | ||
| as the ability to produce JSON outputs from those logs. Using the newly |
There was a problem hiding this comment.
s/produce JSON outputs from those logs/parse the dumped messages into JSON/
There was a problem hiding this comment.
I like it better the way it is (though I'd probably not have pluralized "outputs"; if that's your concern, we could possibly just drop that word without otherwise changing the sentence).
There was a problem hiding this comment.
I wanted to distinguish between logs (which I'd generally understand as a file that records specific events in the code) and what we have here, which is message dumps/message capture. It's not very important.
|
|
||
| - [Bitcoin Core #19509][] adds per-peer message capture between nodes as well | ||
| as the ability to produce JSON outputs from those logs. Using the newly | ||
| introduced command line argument `capturemessages`, any message |
There was a problem hiding this comment.
s/capturemessages/-capturemessages/ (with dash)
| warning that the use of non-English word lists is not widely supported | ||
| and so is not recommended for implementation. | ||
|
|
||
| - [Rust-Lightning #744][] adds support for fetching blocks and headers from |
bitschmidty
force-pushed
the
2021-02-10-newsletter
branch
from
504cd5c to
82e73a8
Compare
or @jnewberyBIPs #1048@hardingHWI #433@xekyoBitcoin Core #19509@adamjonasRust-Lightning #744@dongcarlMy stuff isn't finished on this yet, sorry, but I hope to get it done early Monday UTC-10. I suggest deferring reviews until I take this out of draft---I wanted to get the PR open so y'all'd be able to add your own contributions.