Newsletters: add 178 (2021-12-08)#696
Conversation
| ## News | ||
|
|
||
| - **Fee bumping research:** Antoine Poinsot [posted][darosior bump] to | ||
| the Bitcoin-Dev mailing list a detailed description several concerns |
There was a problem hiding this comment.
| the Bitcoin-Dev mailing list a detailed description several concerns | |
| the Bitcoin-Dev mailing list a detailed description of several concerns |
| transaction pinning]. Also included in his post is the result of | ||
| [research][revault research] into some of the ideas described earlier. | ||
|
|
||
| Ensuring that fee bumping works reliability is a requirement for the |
There was a problem hiding this comment.
| Ensuring that fee bumping works reliability is a requirement for the | |
| Ensuring that fee bumping works reliably is a requirement for the |
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Looks good to me so far, I have no comments.
| it possible to lose money?" | ||
| a2="With this change, the wallet allows importing taproot descriptors at any | ||
| time, i.e., even when taproot is not active and v1 segwit outputs can be spent | ||
| by anyone). This means it's possible to receive bitcoin at a taproot address |
|
|
||
| q2="Are there any theoretical issues with the change? For wallet users, is | ||
| it possible to lose money?" | ||
| a2="With this change, the wallet allows importing taproot descriptors at any |
There was a problem hiding this comment.
Suggest linking to the descriptors topic
| by anyone). This means it's possible to receive bitcoin at a taproot address | ||
| without taproot being active yet; if the chain also reorgs to a block prior to | ||
| 709,632, miners (or someone who can get a nonstandard transaction confirmed) can | ||
| steal those UTXOs." |
There was a problem hiding this comment.
@glozow it might be worth appending a sentence to a2 saying something like, "By the time this change is released in the next major version of Bitcoin Core, that will require producing proof of work equivalent to the work of the entire Bitcoin network over a period of several months."
That's kinda an obvious point to you and me, but one thing I've seen happen is that unqualified text written about highly-unlikely theft scenarios gets repeated by people who don't know what they're talking about in the most sinister way, e.g. "Bitcoin Core developers admit 'it's possible to receive bitcoin at a taproot output that miners can steal'".
There was a problem hiding this comment.
Ah sorry I didn't get back to this in time! 🙈 Good point for sure.
| it possible to lose money?" | ||
| a2="With this change, the wallet allows importing taproot descriptors at any | ||
| time, i.e., even when taproot is not active and v1 segwit outputs can be spent | ||
| by anyone). This means it's possible to receive bitcoin at a taproot address |
There was a problem hiding this comment.
| by anyone). This means it's possible to receive bitcoin at a taproot address | |
| by anyone). This means it's possible to receive bitcoin at a taproot output |
I'll update this but just so you know why I'm changing it, "taproot address" is discouraged compared to either "bech32m address" or "taproot output". See https://github.com/bitcoinops/bitcoinops.github.io/blob/master/STYLE.md#forbidden-terms-and-abbreviations
|
@bitschmidty thanks for the Bitcoin Core 23155 description. Sorry for not mentioning that I had already written my own version. I left yours in the history put used my version which was a bit longer, though maybe not more informative. Topic links added and I checked for additional releases/RCs (none found). Thank you @glozow @adamjonas @dongcarl @bitschmidty for the writing and @glozow @xekyo @bitschmidty for the reviews! |
There was a problem hiding this comment.
Suggested to add a bullet point about the deprecated TOR v2 Onion support on the Lightning Network
edit: You mentioned this in Bitcoin Optech Newsletter #119 when Bitcoin deprecated it.
| better experience---allowing them to spend 100% of the funds in the | ||
| channel. Since only the remote node is taking any risk, there's no | ||
| problem allowing the local node to accept such channels. | ||
|
|
There was a problem hiding this comment.
I think lightning/bolts#940 is worthwhile to be mentioned.
The support for TOR v2 Onions was being deprecated and Lightning Nodes should not announce TOR v2 Onion addresses in their node_announcements anymore. Rust Lightning has also implemented this in lightningdevkit/rust-lightning#1204
There was a problem hiding this comment.
@lightning-developer thanks! Per our schedule we'll be considering it for mention next week, since it was only merged two days ago.
There was a problem hiding this comment.
Ok I have just provided you with a patch at https://github.com/harding/bitcoinops.github.io/pull/22/files I did not know about your schedule. Sorry for the delay.
bitschmidty
force-pushed
the
2021-12-08-newsletter
branch
from
ddf906e to
ba210b5
Compare
|
Echoing the thank yous: Thank you @harding @glozow @adamjonas @dongcarl for the writing and @glozow @xekyo for the reviews! (and @adamjonas +1 for adding the topic!) |
7 participants
No description provided.