Newsletters: add 195 (2022-04-13) #745
Conversation
|
I keep a summary of what has been discussed during the PR Review Club meetings at https://github.com/kouloumos/review-club-summaries. It could probably be used for the related section @glozow. |
|
Thanks @kouloumos, your notes were very helpful! Added you as coauthor. |
| proposed BIPs for the *Taro* protocol that will allow users to use | ||
| Bitcoin's block chain to record creation and transfers of non-bitcoin | ||
| tokens. For example, Alice can issue 100 tokens, transfer 50 to Bob, |
There was a problem hiding this comment.
I stumbled on "allow users to use". Perhaps:
| proposed BIPs for the *Taro* protocol that will allow users to use | |
| Bitcoin's block chain to record creation and transfers of non-bitcoin | |
| tokens. For example, Alice can issue 100 tokens, transfer 50 to Bob, | |
| proposed BIPs for the *Taro* protocol that will allow users to | |
| record creation and transfers of non-bitcoin | |
| tokens on Bitcoin's block chain. For example, Alice can issue 100 tokens, transfer 50 to Bob, |
| both networks. If a node is running on Tor only, fingerprinting could be used to | ||
| link multiple Tor addresses belonging to the same node, or identify the node | ||
| if/when it switches to IPv4." | ||
| a3link="https://bitcoincore.reviews/24571#l-84" |
There was a problem hiding this comment.
@glozow: It seems like it may not have gotten covered in the meeting, but I'm kinda left hanging with the question how the attack is prevented by the PR. Looking at the PR itself, it seems that the defense is that the node will always request the stale header in order to not reveal whether or not it has seen it before in order to prevent fingerprinting. Perhaps this should be mentioned in the context of the Review Club summary.
There was a problem hiding this comment.
I agree that the summary does leave the reader hanging about the solution, and also that the solution doesn't seem to be mentioned in the actual meeting, so I'm going to leave this as an option for @glozow to add a description if she wants or we can leave the section as is---it's ok IMO if people need to DYOR to find the solution like @xekyo did.
|
|
||
| <!-- FIXME:harding to update Tuesday --> | ||
|
|
||
| - [Bitcoin Core 23.0 RC2][] is a release candidate for the next major |
There was a problem hiding this comment.
I think RC4 was tagged yesterday:
| - [Bitcoin Core 23.0 RC2][] is a release candidate for the next major | |
| - [Bitcoin Core 23.0 RC4][] is a release candidate for the next major |
| notes][bcc23 rn] list multiple improvements that advanced users and | ||
| system administrators are encouraged to [test][test guide] before the final release. | ||
|
|
||
| - [LND 0.14.3-beta.rc1][] is a release candidate with several bug fixes |
There was a problem hiding this comment.
I noticed that we already mentioned this RC in the last issue. Do we mention these in every issue while a RC is open?
There was a problem hiding this comment.
In general, yes. One exception I've made is for Rust Bitcoin, which has been in RC since January. If there are other cases where something seems to get stuck in RC without clear progress, I'll probably stop mentioning those as well.
I'm happy to take suggestions, though, e.g. if you think it'd be better to only mention an RC once to avoid saturating readers' attention.
|
Made edits (thanks @xekyo !), reviewed contributions (thanks @glozow, @kouloumos, and @adamjonas !), updated RCs/releases, and added topic links. Thanks everyone! |
Co-authored-by: Andreas Kouloumos <[email protected]>
bitschmidty
force-pushed
the
2022-04-13-newsletter
branch
from
2917af1 to
e91f88e
Compare
|
Thank you to @harding, @glozow, @adamjonas, @kouloumos, @xekyo for your contributions this week, good newsletter team! |
| - [Core Lightning #5165][] updates the name of the C-Lightning Project | ||
| to [Core Lightning][core lightning repo], or CLN for short. | ||
|
|
||
| - [Core Lightning #5068][] adds support for attaching |
There was a problem hiding this comment.
This "Core Lightning #5068" doesn't seem to link to a PR about adding option_payment_metadata. The PR it links to is about " Gossip node_announcement more aggressively, allow 2 updates per day for gossip. #5068 ". I also can't seem to find any open or closed PRs in the Core Lighting repo that mention option_payment_metadata. Or am I misunderstanding something?
EDIT: or maybe you meant this ACINQ PR? Add support for option_payment_metadata #2063
|
Whoops, looks like a transposition of the last two digits of the PR,
sorry! I'll update when I'm next at my computer. Correct PR is
ElementsProject/lightning#5086
…On 16.04.2022 07:26, Steve Myers wrote:
@notmandatory commented on this pull request.
-------------------------
In _posts/en/newsletters/2022-04-13-newsletter.md [1]:
> +- [Bitcoin Core #24098][] updates the `/rest/headers/` and
+ `/rest/blockfilterheaders/` RPCs to use query parameters for
+ additional options (e.g. `?count=<count>`) as an alternative to
endpoints (e.g.
+ `/<count/`). The documentation is updated to encourage use of the
+ query parameters over the endpoint parameters.
+
+- [Bitcoin Core #24147][] adds backend support for [miniscript][topic
+ miniscript]. Subsequent PRs [#24148][bitcoin core #24148] and
+ [#24149][bitcoin core #24149] will, if merged, add support for
using
+ miniscript in [output script descriptors][topic descriptors] and in
+ the wallet's signing logic.
+
+- [Core Lightning #5165][] updates the name of the C-Lightning
Project
+ to [Core Lightning][core lightning repo], or CLN for short.
+
+- [Core Lightning #5068][] adds support for attaching
This "Core Lightning #5068" doesn't seem to link to a PR about adding
option_payment_metadata. The PR it links to is about " Gossip
node_announcement more aggressively, allow 2 updates per day for
gossip. #5068 ". I also can't seem to find any open or closed PRs in
the Core Lighting repo that mention option_payment_metadata. Or am I
misunderstanding something?
--
Reply to this email directly, view it on GitHub [2], or unsubscribe
[3].
You are receiving this because you were mentioned.Message ID:
***@***.***>
Links:
------
[1]
#745 (comment)
[2]
#745 (review)
[3]
https://github.com/notifications/unsubscribe-auth/AAAO5KD35UX47RJCHFGOTLTVFLZ2XANCNFSM5S6D72BQ
|
Note: I asked Rusty whether he preferred "Core Lightning" or "CLN" and went with his choice. I may use CLN instead in cases where we're character-limited.