Newsletters: add 153 (2021-06-16) #590
Conversation
|
@dongcarl text looks good! If you want, you can throw in a screenshot; we've done that before for notable GUI stuff. I'm guessing your work on Guix building means you have an environment setup with all the normal build flags enabled (including GUI), but if you don't you can ask to use one of Provoost's screenshots from the PR or I can create a screenshot. |
murchandamus
force-pushed
the
2021-06-16-newsletter
branch
2 times, most recently
from
78689af to
027ea73
Compare
|
Fixed errant plural in my section. I appear to be even more grammar-challenged today than usually. 🙄 |
|
@harding - looks like you didn't add |
|
I've pushed a commit which adds a temporary placeholder png file to fix the build. |
jnewbery
left a comment
jnewbery
left a comment
There was a problem hiding this comment.
A few minor suggestions for the topic page. Can be updated after this PR.
_topics/en/fee-sniping.md
Outdated
|
|
||
| Alternatively, a miner could dishonestly attempt to re-mine the | ||
| immediately previous block plus a wholly new block to extend the | ||
| chain. That's fee sniping and their chance of succeeding at it if every |
There was a problem hiding this comment.
"That's fee sniping" seems a bit casual for introducing the term. Perhaps "This behavior is referred to as fee sniping".
_topics/en/fee-sniping.md
Outdated
| Core, anti fee sniping is also used today by Electrum, Blockstream | ||
| Green, LND, and C-Lightning. |
There was a problem hiding this comment.
Maybe:
| Core, anti fee sniping is also used today by Electrum, Blockstream | |
| Green, LND, and C-Lightning. | |
| Core, anti fee sniping is now used by several other wallets. |
so this sentence doesn't have to be updated as other wallets implement anti fee sniping.
| Core, anti fee sniping is also used today by Electrum, Blockstream | ||
| Green, LND, and C-Lightning. | ||
|
|
||
| All wallets that implement anti fee sniping today use nLockTime |
There was a problem hiding this comment.
I think this duplicate text could be removed from the topics page, or shortened to just the first two sentences: "All wallets that implement anti fee sniping today use nLockTime height locks to prevent a transaction from being included in the re-mined version of a previous block, but it’s also possible to implement the same protection using BIP68 nSequence height locks."
jonatack
left a comment
jonatack
left a comment
There was a problem hiding this comment.
Excellent newsletter, interesting fee-sniping discussion and exciting BIP proposal.
| layout: newsletter | ||
| lang: en | ||
| --- | ||
| This week's newsletter celebrates the lock in of the taproot soft fork, |
There was a problem hiding this comment.
s/lock in/lock-in/ here and on line 36
| [342][bip342] were locked in by signaling miners last weekend. | ||
| Taproot will be safe to use after block 709,632, which is expected in | ||
| early or mid November. The delay gives time for users to upgrade | ||
| their nodes to a release (such as Bitcoin Core 0.21.1) that will |
There was a problem hiding this comment.
(feel free to ignore, if this was omitted for a reason)
| their nodes to a release (such as Bitcoin Core 0.21.1) that will | |
| their nodes to a release (such as Bitcoin Core 0.21.1 or the upcoming 22.0) that will |
There was a problem hiding this comment.
Or just clarify that 0.21.1 is the first version that enforces
| fungibility as soon as the activation is complete. | ||
|
|
||
| Readers celebrating the lock in of taproot may also wish to read a | ||
| [short history][wuille taproot] of taproot's origins and history by |
There was a problem hiding this comment.
"history" used twice; maybe omit "and history"
There was a problem hiding this comment.
Perhaps
| [short history][wuille taproot] of taproot's origins and history by | |
| [short recount][wuille taproot] of taproot's origins and history by |
| adds support for using a pruned Bitcoin full node, allows receiving | ||
| and sending payments using Atomic MultiPath ([AMP][topic multipath payments]), | ||
| and increases its [PSBT][topic psbt] capabilities, among other improvements | ||
| and bug fixes. |
There was a problem hiding this comment.
This paragraph was in last week's newsletter; an unintentional orphan?
There was a problem hiding this comment.
Also included in the week before that. I don't usually change the text between RCs unless something notable happens. In this case, they didn't even change the RC number (which is fine IMO, especially since I think it's partly due to several people being in Miami).
| in Bitcoin Core. The most notable change is the use of the | ||
| optimized modular inverse code described in Newsletters [#136][news136 | ||
| safegcd] and [#146][news146 safegcd]. Performance evaluations posted | ||
| to the PR found it to speed up old block verification by about 10%. |
There was a problem hiding this comment.
I'm not sure if the infinitive is ok here (ignore me if yes). Maybe s/to speed up/accelerated|speeded up/
There was a problem hiding this comment.
Infinitive looks good to me here
_topics/en/fee-sniping.md
Outdated
| resolution would be centralization of mining---a cartel representing | ||
| a majority of hashrate agreeing to never reorg each others blocks | ||
| can restore stability to the system, but that comes with the | ||
| increased risk that they'll later choose to (or be pressured into) |
There was a problem hiding this comment.
"they'll later choose to censor (or be pressured into censoring)"
| unusable until the problem is resolved. We expect the most likely | ||
| resolution would be centralization of mining---a cartel representing | ||
| a majority of hashrate agreeing to never reorg each others blocks | ||
| can restore stability to the system, but that comes with the |
There was a problem hiding this comment.
maybe s/can/could/ and s/comes/would come/ (accord with "would be")
There was a problem hiding this comment.
I slightly prefer the current phrasing; it feels more direct.
_topics/en/fee-sniping.md
Outdated
| transactions they know about now and try to put them into the oldest block | ||
| they're working to re-mine. All other blocks would be empty, with | ||
| miners only creating them to bury their re-mined block under as much | ||
| proof-of-work as possible. |
There was a problem hiding this comment.
"proof of work" (per style guide)
_topics/en/fee-sniping.md
Outdated
|
|
||
| The problem is actually worse than described above because every miner | ||
| who chooses to mine dishonestly reduces the number of honest | ||
| miners trying to extended the chain. The smaller the share of hash |
_topics/en/fee-sniping.md
Outdated
| near the tip empty---those blocks will need to contain fee-paying | ||
| transactions. Other dishonest miners may attempt themselves to | ||
| fee snipe those transactions, reducing the revenue of the initial | ||
| fee sniping miner and possible discouraging them from fee sniping |
| [342][bip342] were locked in by signaling miners last weekend. | ||
| Taproot will be safe to use after block 709,632, which is expected in | ||
| early or mid November. The delay gives time for users to upgrade | ||
| their nodes to a release (such as Bitcoin Core 0.21.1) that will |
There was a problem hiding this comment.
Or just clarify that 0.21.1 is the first version that enforces
| fungibility as soon as the activation is complete. | ||
|
|
||
| Readers celebrating the lock in of taproot may also wish to read a | ||
| [short history][wuille taproot] of taproot's origins and history by |
There was a problem hiding this comment.
Perhaps
| [short history][wuille taproot] of taproot's origins and history by | |
| [short recount][wuille taproot] of taproot's origins and history by |
| Anti fee sniping is a technique some wallets implement to discourage | ||
| miners from trying to steal fees from each other in a way that would | ||
| reduce the amount of proof of work expended on securing Bitcoin and | ||
| limit users' ability to rely on confirmation scores. All wallets |
There was a problem hiding this comment.
Perhaps
| limit users' ability to rely on confirmation scores. All wallets | |
| limit users' ability to rely on initial confirmations. All wallets |
There was a problem hiding this comment.
The examples here focus on a single block reorg, but it can get much much worse.
| in Bitcoin Core. The most notable change is the use of the | ||
| optimized modular inverse code described in Newsletters [#136][news136 | ||
| safegcd] and [#146][news146 safegcd]. Performance evaluations posted | ||
| to the PR found it to speed up old block verification by about 10%. |
There was a problem hiding this comment.
Infinitive looks good to me here
| containing all pending transactions, leaving some transactions | ||
| for the next block. If the amount of transaction fee available | ||
| from honestly mining the next block is close to the amount of | ||
| transaction fee available from dishonestly re-mining the previous |
There was a problem hiding this comment.
| transaction fee available from dishonestly re-mining the previous | |
| transaction fee expected from dishonestly re-mining the previous |
|
I think all feedback has been addressed (except where I replied with a comment) and the blog post has been added. Thanks everyone for the work this week, especially since it was possibly a bit more than expected. |
bitschmidty
force-pushed
the
2021-06-16-newsletter
branch
from
51d8bb6 to
c5d0451
Compare
bitschmidty
force-pushed
the
2021-06-16-newsletter
branch
from
c5d0451 to
8f87b8d
Compare
6 participants
Closes #582
Bitcoin Core GUI #4UI external signer support (e.g. hardware wallet) @dongcarlC-Lightning #4591bech32m support @xekyoNote: Belcher's proposal mentions me, so I could be biased about it. Please let me know if you think it should be removed, trimmed down to a shorter length, or otherwise significantly altered in a way I might not like---I'll respect y'alls opinions.