Newsletters: add 241 (2023-03-08) #1036
Conversation
|
This piece of news was passed to me for consideration in the newsletter. Im not sure we cover roadmaps on their own, but I suppose if there is a related LND/bolt12 update it could be worked in. |
|
Added review club summary 8122c2f |
| is a PR by Anthony Towns that improves activation and deactivation | ||
| logic for the [Bitcoin Inquisition][] project, which runs on [signet][topic signet]. |
There was a problem hiding this comment.
I quite strongly think "improves" is not the right word here. It swaps it out for a different mechanism; they are used in different contexts with very different goals. I don't think there is any notion of one being better than the other.
| is a PR by Anthony Towns that improves activation and deactivation | |
| logic for the [Bitcoin Inquisition][] project, which runs on [signet][topic signet]. | |
| is a PR by Anthony Towns that adds a new method for activating and deactivating | |
| soft forks in the [Bitcoin Inquisition][] project, designed to be run on [signet][topic signet] | |
| and used for testing. |
| While most of the [Bitcoin Inquisition PRs][bi prs] implement specific consensus or | ||
| relay policy changes, this PR modifies the Bitcoin Inquisition framework itself. |
There was a problem hiding this comment.
| While most of the [Bitcoin Inquisition PRs][bi prs] implement specific consensus or | |
| relay policy changes, this PR modifies the Bitcoin Inquisition framework itself. |
It's unclear what "the Bitcoin Inquisition framework" would mean.
| Specifically, this PR replaces [BIP9][] block version bit semantics with what | ||
| are called [Heretical Deployments][]. |
There was a problem hiding this comment.
I think the paragraph would flow better if this was the first sentence, rather than the last sentence.
| The threshold of merging consensus changes to a signet-only repository | ||
| is much lower than merging to Core. | ||
| Merging changes to Core that aren't yet activated introduces the | ||
| risk that bugs can leak in a way that affects existing behavior." |
There was a problem hiding this comment.
| The threshold of merging consensus changes to a signet-only repository | |
| is much lower than merging to Core. | |
| Merging changes to Core that aren't yet activated introduces the | |
| risk that bugs can leak in a way that affects existing behavior." | |
| Merging consensus changes to a separate repository is much less risky than merging to Core; | |
| adding soft fork logic, even if not activated, may introduce bugs that affect existing behavior." |
| machine period (this period is fixed for Heretical Deployment)." | ||
| a2link="https://bitcoincore.reviews/bitcoin-inquisition-16#l-126" | ||
|
|
||
| q3="Why is Taproot buried in signet?" |
There was a problem hiding this comment.
| q3="Why is Taproot buried in signet?" | |
| q3="Why is Taproot buried in this PR?" |
LarryRuane
force-pushed
the
2023-03-08-newsletter
branch
from
2d99feb to
2663704
Compare
|
Force pushed to address @glozow's suggestions -- thanks! |
LarryRuane
force-pushed
the
2023-03-08-newsletter
branch
2 times, most recently
from
89e4349 to
70e84a5
Compare
|
Pushed edits for all reviewer feedback, thanks @paulkania @xekyo @bitschmidty @glozow ! Added lede, updated releases/RCs, and added topic links. Reviewed contributions by @LarryRuane and @adamjonas (thanks!). Thanks everyone! |
bitschmidty
force-pushed
the
2023-03-08-newsletter
branch
from
cdcb166 to
a8242bd
Compare
|
Thank you @harding for authoring the newsletter (and blog post announcement!) with @adamjonas @LarryRuane! And thanks to @glozow @paulkania @xekyo for the reviews 🚀 |
|
|
||
| One of the advantages to users of this approach over the original | ||
| `OP_VAULT` design is that the freeze leafscript can contain any | ||
| authorization conditions Alice wants to specify. In the `OP_VAULT` |
There was a problem hiding this comment.
For what it's worth, this was the case with BIP 345 before Sanders made these suggestions. Search for optional auth. scriptPubKey in the current text of the BIP. Greg's rework doesn't add this in.
There was a problem hiding this comment.
Was that the result of some previous change in the design? In our original coverage of the idea, we linked to a post by AJ where he mentioned that as a concern, see https://bitcoinops.org/en/newsletters/2023/01/18/#proposal-for-new-vault-specific-opcodes where we wrote,
Towns notes that [...] any third party who learns the address can also freeze the user’s funds (although they’ll have to pay a transaction fee to do so), creating an inconvenience for the user.
If it was a previous change to the proposal that added the ability to allow requiring arbitrary authorization for freezing, then I think we're technically correct to say the an advantage of Greg's approach over the original approach (as posted to the ML on Jan 9th) is this ability.
However, I also get that it's misleading in the sense that it's not an advantage over what you wanted to ship at the time Greg suggested it. Would you like us to print a correction in next week's newsletter?
Also adds a blog post announcing the podcast.