Newsletters: add 281 (2023-12-13) #1428
Conversation
|
Pushed commits for client/services as well as stack exchange sections. I let @murchandamus know there were some potential additional stack exchange questions that I didnt get to this week so optional for him to add. |
murchandamus
force-pushed
the
2023-12-13-newsletter
branch
from
4de3d65 to
f62a9b3
Compare
|
|
||
| ## News | ||
|
|
||
| - **Discussion about griefing liquidity ads:** Bastien Teinturier |
There was a problem hiding this comment.
Totally optional, but readers could be interested in some our chat with Lisa/tbast a couple weeks ago? (could just be a link). https://bitcoinops.org/en/podcast/2023/11/30/#update-to-the-liquidity-ads-specification-transcript
| procedure. | ||
|
|
||
| - [BTCPay Server #5490][] begins using [fee estimates][ms fee api] from | ||
| [Mempool.space][] by default, with a fallback on fee estimates from |
There was a problem hiding this comment.
| [Mempool.space][] by default, with a fallback on fee estimates from | |
| [mempool.space][] by default, with a fallback on fee estimates from |
| even more performant code. | ||
|
|
||
| - [BTCPay Server #5389][] adds support for [BIP129][] secure multisig | ||
| wallet setup (see [Newsletter #136][news136 bip129]. This allows |
There was a problem hiding this comment.
| wallet setup (see [Newsletter #136][news136 bip129]. This allows | |
| wallet setup (see [Newsletter #136][news136 bip129]). This allows |
| A mitigation suggested by Teinturier and discussed by him and others | ||
| was attempting to only encumber the liquidity contribution by the | ||
| timelock (e.g., only Alice's 10,000 sats). This introduces | ||
| complexitise and inefficiencies, although it may solve the problem. |
There was a problem hiding this comment.
| complexitise and inefficiencies, although it may solve the problem. | |
| complexities and inefficiencies, although it may solve the problem. |
| funding] created from [liquidity advertisements][topic liquidity | ||
| advertisements]. For example, Alice advertises that, for a fee, she's | ||
| willing to commit 10,000 sats of her funds to a channel for 28 days. | ||
| The 28 day timelock prevents Alice from simply closing the channel |
There was a problem hiding this comment.
| The 28 day timelock prevents Alice from simply closing the channel | |
| The 28-day timelock prevents Alice from simply closing the channel |
| balance in the channel isn't the 10,000 sats she received a fee | ||
| for---it's almost 10,000 times higher than that amount. If Bob is | ||
| malicious, he won't allow those funds to move again until the | ||
| expiration of the 28 day timelock to which Alice committed. |
There was a problem hiding this comment.
| expiration of the 28 day timelock to which Alice committed. | |
| expiration of the 28-day timelock to which Alice committed. |
|
|
||
| - **Discussion about griefing liquidity ads:** Bastien Teinturier | ||
| [posted][teinturier liqad] to the Lightning-Dev mailing list about a | ||
| potential problem with timelocks on [dual funded channels][topic dual |
There was a problem hiding this comment.
| potential problem with timelocks on [dual funded channels][topic dual | |
| potential problem with timelocks on [dual-funded channels][topic dual |
| expiration of the 28 day timelock to which Alice committed. | ||
|
|
||
| A mitigation suggested by Teinturier and discussed by him and others | ||
| was attempting to only encumber the liquidity contribution by the |
There was a problem hiding this comment.
| was attempting to only encumber the liquidity contribution by the | |
| was attempting to encumber the liquidity contribution using only the |
| A mitigation suggested by Teinturier and discussed by him and others | ||
| was attempting to only encumber the liquidity contribution by the | ||
| timelock (e.g., only Alice's 10,000 sats). This introduces | ||
| complexitise and inefficiencies, although it may solve the problem. |
There was a problem hiding this comment.
| complexitise and inefficiencies, although it may solve the problem. | |
| complexity and inefficiency, although it may solve the problem. |
| numerous blocks whose random coinbase field content happens to match the | ||
| mandatory height prefix of a later block. Block 1 983 702 being the first | ||
| for which it would be practically possible to repeat the coinbase transaction | ||
| of the prior block. In a [related question]({{bse}}120836) Murch and |
There was a problem hiding this comment.
| of the prior block. In a [related question]({{bse}}120836) Murch and | |
| of the prior block. In a [related question]({{bse}}120836), Murch and |
|
|
||
| - [What are hash functions used for in bitcoin?]({{bse}}120418) | ||
| Pieter Wuille lists over thirty different instances across consensus rules, | ||
| peer to peer protocol, wallet and node implementation details that make use |
There was a problem hiding this comment.
| peer to peer protocol, wallet and node implementation details that make use | |
| peer-to-peer protocol, wallet and node implementation details that make use |
|
|
||
| - [Libsecp256k1 #1446][] removes some x86_64 assembly code from the | ||
| project, switching to using existing C language code that has always | ||
| been used for other platforms. The assembly code was human optimized |
There was a problem hiding this comment.
| been used for other platforms. The assembly code was human optimized | |
| been used for other platforms. The assembly code was human-optimized |
| - [Libsecp256k1 #1446][] removes some x86_64 assembly code from the | ||
| project, switching to using existing C language code that has always | ||
| been used for other platforms. The assembly code was human optimized | ||
| several years to improve performance but, in the meantime, compilers |
There was a problem hiding this comment.
| several years to improve performance but, in the meantime, compilers | |
| over several years to improve performance but, in the meantime, compilers |
(Or "for several years" or maybe even "several years ago"?)
| - [What are all the rules related to CPFP fee bumping?]({{bse}}120853) | ||
| Pieter Wuille points out that contrary to the [RBF][topic rbf] fee bumping | ||
| technique that has a list of associated policy rules, the [CPFP][topic cpfp] | ||
| fee bumping technique has no additional policy rules. |
There was a problem hiding this comment.
This isn't a comment on the PR here, but mention of "policy" reminds me that recently I saw a useful distinction that I wasn't aware of, it may have been in a Murch tweet (sorry, post on X). Transaction "standardness" relates to properties of a single transaction considered in isolation; "policy" involves multiple transactions (ancestor and descendant counts, for example). Previously, I had thought of these two words as somewhat interchangeable. Just thought I'd pass that along in case others here weren't aware of those definitions!
There was a problem hiding this comment.
I don't think that's quite right. I agree that standardness relates to the properties of a single transaction (inclusive of its prevouts), but I consider policy to be a superset of standardness rules that also includes all other rules related to whether a node will accept a transaction into its mempool and relay it. I think this is evidenced by IsStandard() and IsStandardTx being defined in policy.*.
|
Made edits for all feedback (thanks @bitschmidty @jirijakes @LarryRuane @0xB10C !). Added lede, releases/RCs, and topic entries. Reviewed contributions (thanks @bitschmidty @murchandamus !). Thanks everyone! |
bitschmidty
force-pushed
the
2023-12-13-newsletter
branch
from
8dfc845 to
c35249e
Compare
6 participants
Uh oh!
There was an error while loading. Please reload this page.