-
Notifications
You must be signed in to change notification settings - Fork 145
Newsletters: add 284 (2024-01-10) #1457
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
|
||
| ## News | ||
|
|
||
| - **Discussion about proposed v3 transaction relay policy:** |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I might be biased, but perhaps a more suitable title might be "Discussion about LN anchors and v3 proposal." I think a partial motivation of the post was to move out-of-scope discussion (especially the criticisms of CPFP and LN anchors in general) away from the PR, and a good amount of the summary is not v3-specific.
| over 55% of hashrate has a 99% chance of getting a transaction | ||
| confirmed within 6 blocks<!-- 1 - (1 - 0.55)**6 -->, likely resulting | ||
| in little effort being made to pay small miners of 1% or less | ||
| hashrate. If small miners are paid less than large miners, mining |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perhaps:
| hashrate. If small miners are paid less than large miners, mining | |
| hashrate. If small miners are paid less than large miners in proportion to the blocks they find, mining |
or
| hashrate. If small miners are paid less than large miners, mining | |
| hashrate. If smaller miners cannot profit without access to out-of-band fees, mining |
Since it's expected that less hashrate => less revenue, but it's problematic when out-of-band fees are significant.
|
|
||
| - **Discussion about proposed v3 transaction relay policy:** | ||
| Antoine Poinsot [posted][poinsot v3] to Delving Bitcoin to | ||
| foster`discussion about the proposals for [v3 transaction relay |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| foster`discussion about the proposals for [v3 transaction relay | |
| foster discussion about the proposals for [v3 transaction relay |
_topics/en/out-of-band-fees.md
Outdated
| - title: "Improvements to features for miners that accept out-of-band fees" | ||
| url: /en/newsletters/2023/05/10/#bitcoin-core-pr-review-club | ||
|
|
||
| - title: Discussion about the effect of out-of-band fees on proposed fee-depenndent timelocks |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - title: Discussion about the effect of out-of-band fees on proposed fee-depenndent timelocks | |
| - title: Discussion about the effect of out-of-band fees on proposed fee-dependent timelocks |
_topics/en/out-of-band-fees.md
Outdated
|
|
||
| The advantage to Alice of paying small miners out of band is minuscule, | ||
| likely meaning they will not receive the same opportunity to earn fees | ||
| as large miners. If large miners are significantly more profitable than |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| as large miners. If large miners are significantly more profitable than | |
| as large miners. If large miners are disproportionately more profitable than |
?
| policy][topic v3 transaction relay] and [ephemeral anchors][topic | ||
| ephemeral anchors]. The thread appears to have been motivated by | ||
| Peter Todd [posting][todd v3] a critique of v3 relay policy on his | ||
| blog. We've arbitrarily divided discussion in to several parts: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| blog. We've arbitrarily divided discussion in to several parts: | |
| blog. We've arbitrarily divided the discussion into several parts: |
| its dependency on exogenous fees significantly incentivizes paying | ||
| out-of-band fees. In particular, the unilateral close of a | ||
| channel with no pending payments ([HTLCs][topic htlc]) would | ||
| allow a large miner acceping out-of-band fees to include twice as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| allow a large miner acceping out-of-band fees to include twice as | |
| allow a large miner accepting out-of-band fees to include twice as |
| offering a moderate discount to users paying out of band. Peter | ||
| Todd calls that a threat to decentralization. | ||
|
|
||
| The post does suggest some uses of exogenous fees in protocols is |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| The post does suggest some uses of exogenous fees in protocols is | |
| The post does suggest that some uses of exogenous fees in protocols is |
| - **Implications of exogenous fees on safety, scalability, and costs:** | ||
| Peter Todd's post also noted that existing designs such as | ||
| [LN-Anchors][topic anchor outputs] and future designs that use | ||
| [ephemeral anchors][topic ephemeral anchors] require each user keep |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| [ephemeral anchors][topic ephemeral anchors] require each user keep | |
| [ephemeral anchors][topic ephemeral anchors] require each user to keep |
(or maybe "require that each user keep")
| zero-pending commitment transactions don't have any | ||
| timelock-dependent urgency, many honest users might choose to be | ||
| patient and get their transaction confirmed at the attacker's | ||
| expense. The attack does also work when HTLCs are used, but it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| expense. The attack does also work when HTLCs are used, but it | |
| expense. The attack also works when HTLCs are used, but it |
| herself. That means she can't accept payments from Bob where he | ||
| spends the money he would need for the 1,000 s/vb variant. For | ||
| example, a commitment transaction with 20 HTLCs would make 1 | ||
| million sats temporarily unspendable ($450 USD at time of |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| million sats temporarily unspendable ($450 USD at time of | |
| million sats temporarily unspendable ($450 USD at the time of |
| implementation][poc lns] he made of the [LN-Symmetry][topic eltoo] | ||
| protocol (originally called _eltoo_) using a software fork of Core | ||
| Lightning. LN-Symmetry provides bi-directional payment channels that | ||
| guarantee being able to publish the latest channel state onchain |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| guarantee being able to publish the latest channel state onchain | |
| guarantee the ability to publish the latest channel state onchain |
|
|
||
| - [LND #8308][] raises the `min_final_cltv_expiry_delta` from 9 to 18 as | ||
| recommended by BOLT 02 for terminal payments. This value affects external | ||
| invoices that not supply the `min_final_cltv_expiry` parameter. The change |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| invoices that not supply the `min_final_cltv_expiry` parameter. The change | |
| invoices that do not supply the `min_final_cltv_expiry` parameter. The change |
_topics/en/out-of-band-fees.md
Outdated
| [CPFP][topic cpfp] fee bumping. Instead, she contacts a miner directly | ||
| and pays them to include the transaction in their candidate blocks, | ||
| which will eventually lead to confirmation (unless the miner gives up). | ||
| Alice's payment can be completely independent from her transaction; she |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| Alice's payment can be completely independent from her transaction; she | |
| Alice's payment can be completely independent of her transaction; she |
| as large miners. If large miners are significantly more profitable than | ||
| small miners for a long period of time, we would expect large miners to | ||
| control a majority of total network hash rate. The fewer entities | ||
| control a majority of hash rate, the fewer entities there are that need |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| control a majority of hash rate, the fewer entities there are that need | |
| that control a majority of hash rate, the fewer entities there are that need |
| soft fork, a hard fork, or neither? Why?" | ||
| a8="It's not a consensus change, it's just a network acceptance | ||
| policy change. Even though block timestamp acceptance is | ||
| not part of consensus, it's [essential][se timestamp accecptance] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think "block timestamp acceptance" is general enough a concept to include MTP, and MTP is clearly part of consensus. Maybe this could be phrased a bit differently to clarify that there can be no consensus rule that includes data from outside the block chain, such as data from each user's own clock.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Excellent point, pushed a fixup commit (1700347). Let me know if it could be improved further, thanks.
1700347 to
365eb1a
Compare
Also, there's a PR with some new topics originally intended for last week's newsletter at #1452