Newsletters: add 306 (2024-06-07) #1714
Conversation
harding
commented
Jun 5, 2024
harding
commented
- Lede, releases/RCs, topic entries (also last week's entries!) @harding
- Testnet topic @harding
- Merge summaries @Gustavojfe
|
@Gustavojfe note, I wrote the description for BLIPs 32 because we've never done one for that repo, so I wanted to create a template we can use in the future. |
| - *Updating existing opcodes:* instead of adding new opcodes such as | ||
| `OP_ADD64`, the existing opcodes (e.g. `OP_ADD`) are updated to | ||
| operate on 64-bit numbers. Because the encoding for large numbers | ||
| is different than currently used for small numbers, scripts |
There was a problem hiding this comment.
| is different than currently used for small numbers, scripts | |
| is different than currently used for small numbers, script |
| - *Result includes a bool:* a successful operation not only places the | ||
| result on the stack but also places a bool on the stack that | ||
| indicates that the operation was successful. One common reason an | ||
| operation might fail is because the result is larger than 64-bits, |
There was a problem hiding this comment.
| operation might fail is because the result is larger than 64-bits, | |
| operation might fail is because the result is larger than 64 bits, |
| approach where the default opcodes simply fail if an overflow occurs, | ||
| rather than requiring scripts verify that operations were successful. | ||
| For cases where it would be useful to test whether an operation would | ||
| result in an overflow, new opcodes such as `ADD_OF` would be made |
There was a problem hiding this comment.
| result in an overflow, new opcodes such as `ADD_OF` would be made | |
| result in an overflow, new opcodes such as `ADD_OF` could be made |
| about theoretically using [functional encryption][] to add a full range | ||
| of [covenant][topic covenants] behavior to Bitcoin with no required | ||
| consensus changes. Fundamentally, this would require users of the | ||
| covenants trust a third party, although that trust could be |
There was a problem hiding this comment.
| covenants trust a third party, although that trust could be | |
| covenants to trust a third party, although that trust could be |
| the same script by performing multiple signature checks. | ||
|
|
||
| Besides the need for trusted setup, Rubin describes the other major | ||
| downside of function encryption as "under-developed crypto makes it |
There was a problem hiding this comment.
| downside of function encryption as "under-developed crypto makes it | |
| downside of functional encryption as "under-developed crypto makes it |
There was a problem hiding this comment.
Maybe also clarify that this is referring to crypto[graphy]?
| downside of function encryption as "under-developed crypto makes it | ||
| impractical to use presently". | ||
|
|
||
| - **Updates to proposed soft fork for 64-bit arithmetic:** Christ |
There was a problem hiding this comment.
| - **Updates to proposed soft fork for 64-bit arithmetic:** Christ | |
| - **Updates to proposed soft fork for 64-bit arithmetic:** Chris |
| offers] protocol, which will almost certainly be used as BIP21 | ||
| payloads. | ||
|
|
||
| - *Empty body:* BIP21 always expects an address to be provided in |
There was a problem hiding this comment.
| - *Empty body:* BIP21 always expects an address to be provided in | |
| - *Empty body:* BIP21 always expects a Bitcoin address to be provided in |
|
|
||
| - *New query parameters:* the update describes three new keys: | ||
| `lightning` for [BOLT11][] invoices (currently in use), `lno` for LN | ||
| offers (proposed), and `sp` for silent payments (propsed). It also |
There was a problem hiding this comment.
| offers (proposed), and `sp` for silent payments (propsed). It also | |
| offers (proposed), and `sp` for silent payments (proposed). It also |
| - *New query parameters:* the update describes three new keys: | ||
| `lightning` for [BOLT11][] invoices (currently in use), `lno` for LN | ||
| offers (proposed), and `sp` for silent payments (propsed). It also | ||
| describes how the keys for later parameters should be named. |
There was a problem hiding this comment.
maybe
| describes how the keys for later parameters should be named. | |
| describes how the keys for future parameters should be named. |
| `bob@example.com`. For example, Alice instructs her LN client to pay | ||
| Bob. Her client may not be able to securely resolve DNS addresses | ||
| directly, but it can use an onion message to contact one of its peers | ||
| that provides a resolution service. The peer retrieves the DNS TXT |
There was a problem hiding this comment.
| that provides a resolution service. The peer retrieves the DNS TXT | |
| that resolves it. The peer retrieves the DNS TXT |
There was a problem hiding this comment.
I'm unsure about this suggestion because the next sentence says that (and how) the peer resolves it.
| Alice. Alice verifies the information and uses it to request an | ||
| invoice from Bob using the [offers][topic offers] protocol. | ||
|
|
||
| {% assign four_days_after_posting = page.date | date: "%s" | plus: 345600 | date: "%Y-%m-%d 14:30" %} |
There was a problem hiding this comment.
Preview site is showing June 5th here which doesnt seem to jibe with the time the preview generation was made. (sorry I dont have the bandwidth to troubleshoot this)
| testnet4 that were discussed but not used. | ||
|
|
||
| - **Functional encryption covenants:** Jeremy Rubin [posted][rubin | ||
| fe post] to Delving Bitcoin a [paper][rubin fe paper] he's written |
There was a problem hiding this comment.
| fe post] to Delving Bitcoin a [paper][rubin fe paper] he's written | |
| fe post] to Delving Bitcoin his [paper][rubin fe paper] |
| `OP_ADD64`, the existing opcodes (e.g. `OP_ADD`) are updated to | ||
| operate on 64-bit numbers. Because the encoding for large numbers | ||
| is different than currently used for small numbers, scripts | ||
| fragments which are upgraded to use large numbers may need to be |
There was a problem hiding this comment.
| fragments which are upgraded to use large numbers may need to be | |
| fragments that are upgraded to use large numbers may need to be |
|
|
||
| Anthony Towns [replied][towns 64bit] arguing for an alternative | ||
| approach where the default opcodes simply fail if an overflow occurs, | ||
| rather than requiring scripts verify that operations were successful. |
There was a problem hiding this comment.
| rather than requiring scripts verify that operations were successful. | |
| rather than requiring scripts to verify that operations were successful. |
| operation completed successfully. | ||
|
|
||
| Anthony Towns [replied][towns 64bit] arguing for an alternative | ||
| approach where the default opcodes simply fail if an overflow occurs, |
There was a problem hiding this comment.
| approach where the default opcodes simply fail if an overflow occurs, | |
| approach where the default opcodes fail if an overflow occurs, |
| [Newsletter #292][news292 bip21]), almost all Bitcoin wallets are | ||
| using the URI scheme differently than specified, and additional | ||
| changes to invoice protocols will likely lead to additional changes in | ||
| use of BIP21. The major changes in the [proposal][bips #1555] |
There was a problem hiding this comment.
| use of BIP21. The major changes in the [proposal][bips #1555] | |
| the use of BIP21. The major changes in the [proposal][bips #1555] |
| Towns's post describes the script and the motivation for several of | ||
| its design choices. |
There was a problem hiding this comment.
| Towns's post describes the script and the motivation for several of | |
| its design choices. | |
| Towns's post describes the script and the motivation for several | |
| design choices. |
| - *Empty body:* BIP21 always expects an address to be provided in | ||
| the body part of the payload, with query parameters providing |
There was a problem hiding this comment.
| - *Empty body:* BIP21 always expects an address to be provided in | |
| the body part of the payload, with query parameters providing | |
| - *Empty body:* BIP21 expects an address to always be provided in | |
| the body part of the payload, with query parameters providing |
| payment protocol], specified new query parameters to use (see | ||
| [BIP72][]), but clients that didn't understand the parameter would | ||
| fall back to using the address in the body. In some cases, | ||
| receivers may not want to fallback to one of the base address types |
There was a problem hiding this comment.
| receivers may not want to fallback to one of the base address types | |
| receivers may not want to fall back to one of the base address types |
(verb instead of noun)
| `bob@example.com`. For example, Alice instructs her LN client to pay | ||
| Bob. Her client may not be able to securely resolve DNS addresses | ||
| directly, but it can use an onion message to contact one of its peers | ||
| that provides a resolution service. The peer retrieves the DNS TXT |
There was a problem hiding this comment.
I'm unsure about this suggestion because the next sentence says that (and how) the peer resolves it.
|
just pushed the 5 merged PR summaries, thanks for the feedback and review in advance. |
| - [Core Lightning #7252][] changes the behavior of `lightningd` to ignore the | ||
| `ignore_fee_limits` setting during a cooperative channel closure. This fixes | ||
| an issue where a Core Lightning (CLN) channel opener node overpays fees when | ||
| the counterparty is a LDK node. In this scenario, when the LDK non-opener node |
There was a problem hiding this comment.
| the counterparty is a LDK node. In this scenario, when the LDK non-opener node | |
| the counterparty is an LDK node. In this scenario, when the LDK non-opener node |
| accepts, resulting in Alice broadcasting a transaction with considerably | ||
| overpaid fees. | ||
|
|
||
| - [LDK #2931][] enhances the logging during path finding to include additional |
There was a problem hiding this comment.
| - [LDK #2931][] enhances the logging during path finding to include additional | |
| - [LDK #2931][] enhances the logging during pathfinding to include additional |
or maybe "path-finding"?
There was a problem hiding this comment.
good catch. 'pathfinding' is the right one. https://github.com/bitcoinops/bitcoinops.github.io/blob/master/STYLE.md
| over encrypted connections (enabled by default in Bitcoin Core). | ||
|
|
||
| - [BIPs #1541][] adds BIP431 to propose [Topologically Restricted Until | ||
| Confirmation (TRUC)][topic v3 transaction relay] (v3 transactions) which are a |
There was a problem hiding this comment.
I think it’s "TRUC transactions" not just "TRUC":
| Confirmation (TRUC)][topic v3 transaction relay] (v3 transactions) which are a | |
| Confirmation (TRUC)][topic v3 transaction relay] (v3) transactions which are a |
| block. Now difficulty-1 will only be used if every block in the | ||
| previous period had a timestamp more than 20 minutes after its | ||
| preceding block or if a regular mainnet-style difficulty adjustment |
There was a problem hiding this comment.
Note that the first block in each difficulty period must be mined at the actual difficulty, so in testnet4 as proposed it would only be possible to achieve difficulty-1 per organic difficulty adjustments.
There was a problem hiding this comment.
That's not correct if I understand the spec correctly. If every block in the preceeding 2016-block difficulty period was mined at diff-1, then the next period will be diff-1. From the spec:
Only if all blocks from the previous difficulty period have had a difficulty of 1 (possibly by the use of the 20-min rule), this is also used as the base for the calculation of the next difficulty period.
There was a problem hiding this comment.
No, the first block always has to be mined at the actual difficulty: see e.g.
- Testnet4 including PoW difficulty adjustment fix bitcoin/bitcoin#29775 (comment)
- BIP94 Testnet 4 bitcoin/bips#1601 (comment)
- Testnet4 including PoW difficulty adjustment fix bitcoin/bitcoin#29775 (comment)
which in turn means that an entire difficulty period can only be diff-1 if the actual difficulty was calculated to be diff-1.
There was a problem hiding this comment.
That's not correct if I understand the spec correctly. If every block in the preceeding 2016-block difficulty period was mined at diff-1, then the next period will be diff-1. From the spec:
Only if all blocks from the previous difficulty period have had a difficulty of 1 (possibly by the use of the 20-min rule), this is also used as the base for the calculation of the next difficulty period.
To clarify:
- If the actual difficulty is higher than diff-1, the first block must be mined at the actual difficulty. Therefore, the difficulty adjustment for the subsequent period will use the actual difficulty and the timestamps of first and last block as basis of calculating the new actual difficulty.
- This means that the only way all blocks in a difficulty period can have diff-1 is by the actual difficulty being diff-1. The subsequent difficult will be between diff-1 and 4×diff-1 depending on the timestamps.
There was a problem hiding this comment.
It looks like that text was added in a later revision of the draft BIP than what I read (I used the copy posted to the mailing list).
I'm sorry I didn't check the latest version of the draft BIP text when you reported this. I opened a fixup in #1717 but I'm hesitant to merge it until it's been reviewed.
There was a problem hiding this comment.
All good! I took a look at your fixup suggestion.
| the same script by performing multiple signature checks. | ||
|
|
||
| Besides the need for trusted setup, Rubin describes the other major | ||
| downside of function encryption as "under-developed crypto makes it |
There was a problem hiding this comment.
Maybe also clarify that this is referring to crypto[graphy]?
bitschmidty
force-pushed
the
2024-06-07-newsletter
branch
from
dcdc9fd to
b81ab6b
Compare
|
Pushed a small fixup to a testnet topic entry, squashed. Thank you @harding and @Gustavojfe for authoring and @vostrnad @LarryRuane @murchandamus for the 👀 ! |
| After this policy has a chance to be further discussed, it is the | ||
| intention of the project to begin disclosing vulnerabilities affecting | ||
| Bitcoin Core 24.x and below. It is **strongly recommended** that all | ||
| users and administrators upgrade to Bitcoin Core 25.0 or above within |
There was a problem hiding this comment.
Maybe better to recommend 25.2, as 25.0 is over a year old and 25.2 includes a number of backported bug fixes.
