Newsletters: add 283 (2024-01-03) #1451
Conversation
harding
commented
Jan 2, 2024
•
harding
commented
- Lede, releases/RCs, topic entries @harding
| related to unspendable keys can be split between descriptors and | ||
| [BIP388][] wallet policies. | ||
|
|
||
| - **V3 transaction pinning costs:** Peter Todd [posted][todd v3] to the |
There was a problem hiding this comment.
FYI via Peter Todd:
"BTW I corrected my numbers a bit with a follow-up post: https://petertodd.org/2023/v3-txs-pinning-vulnerability"
|
|
||
| - **Fee-dependent timelocks:** John Law [posted][law fdt] to the | ||
| Bitcoin-Dev and Lightning-Dev mailing lists with a rough proposal for | ||
| a soft fork that could allow transaction time locks to optionally only |
There was a problem hiding this comment.
maybe
| a soft fork that could allow transaction time locks to optionally only | |
| a soft fork that could allow transaction [time locks][topic timelocks] to optionally only |
There was a problem hiding this comment.
Wow, I forget we had that topic. I bet I've missed adding lots of stuff to it. Will have to fix that at another time. Thanks!
| started using their contract. Bob is unable to get the transaction | ||
| claiming his funds confirmed, either because he doesn't have access to | ||
| enough bitcoins to spend on fees or because it would be cost | ||
| prohibitive to crate a claim transaction given the high feerates. In |
There was a problem hiding this comment.
| prohibitive to crate a claim transaction given the high feerates. In | |
| prohibitive to create a claim transaction given the high feerates. In |
| prohibitive to crate a claim transaction given the high feerates. In | ||
| the current Bitcoin protocol, Bob being unable to act would allow | ||
| Alice to claim her refund. With Law's proposal, the expiration of the | ||
| timelock that prevents Alice from claiming her refund would be delayed |
There was a problem hiding this comment.
Mixing of time lock and timelock, not sure if intentional
There was a problem hiding this comment.
Not intentional. My fingers are confused: I've previously preferred the one-word version but @murchandamus used the two word version in bip-bikeshed, which is what I used for Mastering Bitcoin. Switching everything here to use the one-word version consistent with our past newsletters; we should discuss switching to the two-word version in the future.
| generating the proof. In the last post in the thread at the time of | ||
| writing, Ingala notes that some of the work of specifying policies | ||
| related to unspendable keys can be split between descriptors and | ||
| [BIP388][] wallet policies. |
There was a problem hiding this comment.
No BIP388 merge yet, bitcoin/bips#1389
| - **V3 transaction pinning costs:** Peter Todd [posted][todd v3] to the | ||
| Bitcoin-Dev mailing list an analysis of the proposed [v3 transaction | ||
| relay][topic v3 transaction relay] policy on [transaction pinning][topic | ||
| transaction pinning] for contract protocols such as LN. For example, |
There was a problem hiding this comment.
I think it would help with clarity to note that this example pertains to current relay rules.
There was a problem hiding this comment.
Keeping as-is, but feel free to edit before merging. The example is chosen so that it applies both now and with v3 tx relay. A few sentences later, when we discuss Bitcoin Core's current rules (plus package relay), we say "Using Bitcoin Core's current default...". Then, in the next paragraph when we looking at the effect of v3 rules, we introduce that by saying "In the v3 ...".
| users want to exit, they each need to broadcast a separate | ||
| transaction, and each of those transactions will have at least one | ||
| input and one output---a total of five inputs and five outputs. | ||
| Ingala suggests a way those users could effect a single exit with a |
There was a problem hiding this comment.
?
| Ingala suggests a way those users could effect a single exit with a | |
| Ingala suggests a way those users could affect a single exit with a |
There was a problem hiding this comment.
I think "effect" is right here. I read it in the sense of "to bring about".
There was a problem hiding this comment.
I think effect is correct. "affect a single exit" would mean modifying the single exit in some way.
The way "effect" is used here is to "bring about" which the dictionary (at least the default Google one) gives as the definition of the verb form of effect.
| `OP_CHECKCONTRACTVERIFY`, and amount introspection from the proposed | ||
| [MATT][] soft fork, with him noting that it would be easier with the | ||
| addition also of [OP_CSFS][topic op_checksigfromstack] and 64-bit | ||
| arithmetic operators in tapscript. |
There was a problem hiding this comment.
| arithmetic operators in tapscript. | |
| arithmetic operators in [tapscript][topic tapscript]. |
| to Delving Bitcoin about edge-cases users may have experienced with | ||
| Bitcoin Core's [coin selection][topic coin selection] strategy and | ||
| proposes two new strategies, plus a method of choosing the best | ||
| strategy from among those available. He also summaries the benefits |
There was a problem hiding this comment.
| strategy from among those available. He also summaries the benefits | |
| strategy from among those available. He also summarizes the benefits |
| only a small number of nodes on the network support them (which is the | ||
| case now). | ||
|
|
||
| - [BIPs #1502][] updates BIP2 to allow any BIP to be written in |
There was a problem hiding this comment.
| - [BIPs #1502][] updates BIP2 to allow any BIP to be written in | |
| - [BIPs #1504][] updates BIP2 to allow any BIP to be written in |
| funds she pays him at any time but also gives herself the option to | ||
| claim a refund of her deposit after a time lock expires. As the time | ||
| lock expiration approaches, Bob attempts to claim his funds but | ||
| typical feerates are much higher than he and Alice expected when they |
There was a problem hiding this comment.
| typical feerates are much higher than he and Alice expected when they | |
| current feerates are much higher than he and Alice expected when they |
| Bitcoin-Dev mailing list an analysis of the proposed [v3 transaction | ||
| relay][topic v3 transaction relay] policy on [transaction pinning][topic | ||
| transaction pinning] for contract protocols such as LN. For example, | ||
| Bob and Mallory may share an LN channel. Bob wants to close a |
There was a problem hiding this comment.
| Bob and Mallory may share an LN channel. Bob wants to close a | |
| Bob and Mallory may share an LN channel. Bob wants to close the |
| In the v3 transaction relay proposal, the rules only allow a | ||
| transaction opting in to the v3 policy to have a maximum of one |
There was a problem hiding this comment.
| In the v3 transaction relay proposal, the rules only allow a | |
| transaction opting in to the v3 policy to have a maximum of one | |
| In the v3 transaction relay proposal, the rules allow a | |
| transaction opting in to the v3 policy to only have a maximum of one |
| users want to exit, they each need to broadcast a separate | ||
| transaction, and each of those transactions will have at least one | ||
| input and one output---a total of five inputs and five outputs. | ||
| Ingala suggests a way those users could effect a single exit with a |
There was a problem hiding this comment.
I think "effect" is right here. I read it in the sense of "to bring about".
| proposes two new strategies, plus a method of choosing the best | ||
| strategy from among those available. He also summaries the benefits |
There was a problem hiding this comment.
This sounds like it’s a new proposal, but we have been using the waste metric as a method of choosing an input set from all input set candidates for multiple major releases.
| proposes two new strategies, plus a method of choosing the best | |
| strategy from among those available. He also summaries the benefits | |
| proposes two new strategies. | |
| He also summaries the benefits |
Perhaps it could be added that the two new algorithms both aim to reduce input set size at high feerates and thus improve the mentioned edge-cases.
|
|
||
| - **Disclosure of past LND vulnerabilities:** Niklas Gögge [posted][gogge | ||
| lndvuln] to Delving Bitcoin about two vulnerabilities he had previously | ||
| [responsibly disclosed][topic responsible disclosures] and which led |
There was a problem hiding this comment.
| [responsibly disclosed][topic responsible disclosures] and which led | |
| [responsibly disclosed][topic responsible disclosures] which led |
|
|
||
| - A DoS vulnerability that could have led to LND running out of | ||
| memory and crashing. If LND is not running, it can't broadcast | ||
| time sensitive transactions, which can lead to loss of funds. |
There was a problem hiding this comment.
| time sensitive transactions, which can lead to loss of funds. | |
| time-sensitive transactions, which can lead to loss of funds. |
| timelock that prevents Alice from claiming her refund would be delayed | ||
| until there had been a series of blocks with median feerates below | ||
| an amount specified by Alice and Bob when they negotiated their | ||
| contract. This would ensure Bob had a chance to get his transaction |
There was a problem hiding this comment.
| contract. This would ensure Bob had a chance to get his transaction | |
| contract. This would ensure Bob has a chance to get his transaction |
| Law notes that this addresses one of the longstanding concerns noted | ||
| in the [original Lightning Network paper][] about _forced expiration | ||
| floods_ where too many channels all closing simultaneously may | ||
| result in there not being enough block space for all of them to be |
There was a problem hiding this comment.
| result in there not being enough block space for all of them to be | |
| result in insufficient block space for all of them to be |
| they exceed the fee-dependent lock, after which expiry of the | ||
| timelocks will be delayed until fees have come down to an amount low |
There was a problem hiding this comment.
| they exceed the fee-dependent lock, after which expiry of the | |
| timelocks will be delayed until fees have come down to an amount low | |
| they exceed the fee-dependent lock, after which | |
| timelock expiration will be delayed until fees have come down to an amount low |
There was a problem hiding this comment.
Leaving this as-is. I think the more verbose version is a little easier to read due to not introducing the term "timelock expiry".
| fees to exit the contract and enter a new contract, then even with an | ||
| improbably small spending transaction size of 100 vbytes, a | ||
| transaction fee of 100 sats/vbyte would consume their entire balance. | ||
| If they are able to move their combined funds of 1 million sats in a |
There was a problem hiding this comment.
| If they are able to move their combined funds of 1 million sats in a | |
| If they can move their combined funds of 1 million sats in a |
| single 200 vbyte transaction at 100 sats/vbyte, then each individual | ||
| user will only pay 200 sats (2% of their balance). |
There was a problem hiding this comment.
| single 200 vbyte transaction at 100 sats/vbyte, then each individual | |
| user will only pay 200 sats (2% of their balance). | |
| single 200 vbyte transaction at 100 sats/vbyte, then each | |
| user will pay only 200 sats (2% of their balance). |
| constructing party. Ingala roughly describes how this feature could | ||
| be added to a multiparty contract protocol using [OP_CAT][], | ||
| `OP_CHECKCONTRACTVERIFY`, and amount introspection from the proposed | ||
| [MATT][] soft fork, with him noting that it would be easier with the |
There was a problem hiding this comment.
| [MATT][] soft fork, with him noting that it would be easier with the | |
| [MATT][] soft fork, and noted that it would be easier with the |
There was a problem hiding this comment.
Leaving as-is. There's a conjunctive "and" a few words earlier also following a comma and I don't want this clause to look like a list item.
| results from simulations he performed using the different algorithms. | ||
| The ultimate goal is for Bitcoin Core to generally select the set of | ||
| inputs that will minimize the percentage of UTXO value that is spent | ||
| to fees over the long term, while also not creating unnecessarily |
There was a problem hiding this comment.
| to fees over the long term, while also not creating unnecessarily | |
| on fees over the long term, while also not creating unnecessarily |
| typical feerates are much higher than he and Alice expected when they | ||
| started using their contract. Bob is unable to get the transaction | ||
| claiming his funds confirmed, either because he doesn't have access to | ||
| enough bitcoins to spend on fees or because it would be cost |
There was a problem hiding this comment.
| enough bitcoins to spend on fees or because it would be cost | |
| enough bitcoins to spend on fees or because it would be cost-prohibitive |
| In the v3 transaction relay proposal, the rules only allow a | ||
| transaction opting in to the v3 policy to have a maximum of one |
There was a problem hiding this comment.
| In the v3 transaction relay proposal, the rules only allow a | |
| transaction opting in to the v3 policy to have a maximum of one | |
| In the v3 transaction relay proposal, the rules restrict a | |
| transaction opting into the v3 policy to have a maximum of one |
|
Made edits for all feedback (or left a comment in response), thanks everyone! Added lede, releases, and topic entries. I also opened #1452 with the new topic pages that were in the FIXMEs; I didn't include them here to allow them to get some actual review before we publish. Thanks everyone! |
bitschmidty
force-pushed
the
2024-01-03-newsletter
branch
from
3163e77 to
ee44c7f
Compare
bitschmidty
force-pushed
the
2024-01-03-newsletter
branch
from
ee44c7f to
eaf1042
Compare
|
Made a small correction in the lede, squashed, merged! Thank you @harding for the great newsletter writeup this week and for reviews from @LarryRuane and @murchandamus |
