Bitcoin Optech Newsletter #395

This week's newsletter describes a standard for verifying VTIC, so's across different

arc implementations.

It also links to a draft BIP that expands the minor usable non-C space in the block headers

and version field.

Also included are our regular sections.

They contain descriptions of discussions about changing consensus, announcements of new

releases and release candidates, and summaries of notable changes to popular Bitcoin infrastructure

software.

Use a standard for stateless VTX overification first, Jijima Kalpain posted to delving

Bitcoin about his proposal for VPAC.

VPAC is a stateless VTX overification standard.

It aims to give a way to independently verify and visualize VTXOs in the arc ecosystem.

The goal is to develop a lean verifier that can run on embedded environments such as hardware

wallets.

This will allow auditors to check off chain state and keep an independent backup of the

data required for a unilateral exit.

In particular, VPAC verifies that a unilateral exit path exists.

It does this by checking that the Merkel path leads to a valid on-chain anchor, and that

the transaction primages match the signatures.

However, second CEO Stephen Rousse pointed out that path exclusivity, that is verifying

that the arc service provider, which is ASP, did not introduce a backdoor, is not checked

for.

In response, Jijima Kalpain said that the topic would be given the highest priority in

the roadmap.

Because there are significant differences among arc implementations, specifically arcade

and bark, VPAC proposes a minimal viable VTXOs schema, which we call MVV.

This schema allows us to translate from an implementations dialect to a common neutral

format without needing an embedded environment to import all the specific implementations

codebase.

The VPAC implementation, known as LibPACRS, is open source.

A live tool that visualizes VTXOs, is available for testing.

Draft BIP for expanded N version, non-C space for minors.

Matt Corralo posted to the Bitcoin Dev mailing list a draft BIP to increase the number of

bits available in N versions, non-C space for minors.

From 16 to 24, this will enable more possible block candidates for header, only mining

without relying on rolling end time more often than once per second.

It would supersede BIP 320.

The motivation for this change is that BIP 320 previously defined 16 bits of N version

as additional non-C space.

But it turns out that mining devices have started using 7 bits from N time for extra

non-C space.

Given the limited utility of the additional N version bits for use in soft fork signaling,

the SPRP draft suggests instead that some of those signaling bits be used to expand

the N version extra non-C space.

The rationale behind this is that providing additional non-C space for the A6 to roll

without needing fresh work from the controller may simplify a sick design, and it is preferable

to do so in.

N version instead of N time, which can distort block timestamps, changing consensus, a monthly

section summarising proposals and discussion about changing Bitcoin's consensus rules.

Designs to standard tooling for template hash-site case support and to end point slot wrote

on the Bitcoin dev mailing list about his preliminary work to integrate the tape route

native OP template hash soft fork proposal into miniscript and PSPTs.

The new up codes require some reconsideration of the miniscript proper is because they break

the assumption that signatures and transaction commitments are always done together.

This work also emphasise is the limitations of scripts stack structure.

It requires an OP swap before each OP check sig from stack when used with miniscript without

further changes to the type system.

Because OP check sig from stack takes three arguments, either the message or the key or

both are computed by other script fragments, there is no obviously superior argument order

that avoids OP swap.

In most cases, the modifications required for PSPTs are simpler.

Primarily, it is a per output field that maps OP template hash commitments to their full

transactions for verification by signers.

Ioglass V2 update, Mike Casey posted an update to the Bitcoin dev mailing list for the

Ioglass protocol.

It aims to mitigate the market impact of quantum attacks against certain lost coins.

The earlier proposal was discussed here.

This soft fork would restrict the total value of P2PK locked Bitcoin that can be spent

in a single block.

It limits it to one spent output and one Bitcoin.

These specific values are somewhat arbitrary, but those responding seem to see them as

a reasonable shelling point for such a restriction.

Those who supported the change focused on the potential economic consequences if a quantum

adversary sold a large number of Bitcoins.

These who opposed it argued that having secret keys to unlock Bitcoin is the only way the

protocol can identify ownership.

Even if the underlying cryptographic security were broken, they felt the protocol should

not add extra restrictions on coin ownership or movement.

Algorithm agility for Bitcoin, Ethan Haleman wrote on the Bitcoin dev mailing list about

the potential need for RC76696 cryptographic algorithm agility in Bitcoin.

Haleman proposes that a cryptographic algorithm be made available in BAP360, P2MR scripts.

This algorithm is not meant for current spending.

Instead, it serves as a fallback bridge between primary signing algorithms.

If the current sect 256K1 based signing algorithm or any later primary algorithm becomes insecure,

this fallback can step in.

The core idea is that Bitcoin would support two simultaneous signing algorithms.

Then a future break of either one would not be as high stakes as the current worry about

a quantum break of sect 256K1.

Other developers replied with discussions about various backup signing algorithms that would

likely not break within Haleman's 75 year time horizon.

They also discussed whether BAP360, P2MR, or something that looks more like P2TR, but

opts into having the key spend later disabled by a soft fork, is preferable.

In P2MR, all spends are script spends.

They can use either a lower cost primary signature mechanism or a higher cost fallback chosen

from the Merkel leaves.

In a P2TR variant, the primary signature type is a lower cost key spend.

It remains in use until it is disabled by a cryptographic break.

Then only the fallback, which must be a Merkel leaf, remains.

Haleman suggested that cold storage users would prefer P2MR.

Hot wallets could switch to a new output type quickly when needed.

This makes the key spend with a script backup signature algorithm irrelevant for both major

types of users.

The limitations of cryptographic agility in Bitcoin, Pieta Weall wrote to the Bitcoin

dev mailing list about the limitations of the cryptographic agility mentioned in the

previous item.

Specifically, because Bitcoin, like all money, is based on belief, if the ownership of

Bitcoin is secured by multiple cryptographic systems, proponents of each scheme want

their scheme to be used.

Universally, importantly, they do not want other schemes to be used, because those would

weaken the fundamental invariant of ownership security.

We will posits that in the fullness of time, old signature schemes will need to be disabled

as part of the migration from one scheme to another.

Haleman proposes that the secondary signing scheme, which is proposed for algorithm

agility, is much more costly than the current scheme and hopefully a future primary scheme.

Therefore, it would remain a backup and only be used for migrations when the primary

scheme has been shown to be sufficiently weakened.

This avoids the need to disable the secondary scheme after each migration to a new primary

scheme.

John Light argues the opposite of Weall.

He says that turning off old signing schemes, even if they are insecure, is a bigger danger

to the shared belief in Bitcoin's ownership model than the coins that those insecure

schemes still protect.

Being taken by whoever breaks them, he says the most important part of Bitcoin's ownership

model is that each locking script stays valid from the moment it is created until it is

spent.

Conduition shows a different set of assumptions.

He demonstrates that because script is flexible, users can require signatures from several

signing schemes to unlock their coins.

That means users can express a wider range of security assumptions than the ones that

made Weall conclude that insecure schemes must be disabled and that users of each scheme

would prefer nobody.

Else to use them.

The discussion continues with some clarifications, but no firm conclusions as to how Bitcoin

can practically migrate from one crypto system to another, whether in response to a quantum

adversary or any.

Other reason, releases and release candidates, new releases and release candidates for

popular Bitcoin infrastructure projects.

Please consider upgrading to new releases or helping to test release candidates, Bitcoin

Core 28.

For RC1 is a release candidate for a maintenance release of a previous major release series.

It primarily contains wallet migration fixes and removal of an unreliable DNS seed, notable

code and documentation changes.

Notable recent changes in Bitcoin Core, Core Lightning, Eclare, LDK, L&D, Lipsect

2, 150, 6K1, Hardware Wallet Interface, HWI, RustBitcoin, BTC Pay Server, BDK, Bitcoin

Improvement Proposals, Bips, Lightning Bolts, Lightning Blips, Bitcoin Inquisition and

by Non-Us.

Bitcoin Core 30, 3616 skips the ephemeral dust-spend check.

Check ephemeral spends during block reoggs when confirmed transactions re-enter the

mempool.

Previously, these transactions would be rejected by relay policy because they're brought

back individually rather than as a package.

This follows the same pattern as Bitcoin Core 30, 354, CNU's letter 375, which skipped

truck topology checks during reoggs for the same reason.

Bitcoin Core 30, 4616 introduces a more accurate cost model for the spanning forest cluster

linearization, SFL algorithm, CNU's letter 380, 6, by using cost limits to bound the

amount of CPU time spent, searching for an optimal linearization of each cluster.

The previous model only tracked one type of internal operation, resulting in a poor

correlation between the reported cost and the actual CPU time spent.

The new model tracks many internal operations with weights calibrated from benchmarks across

diverse hardware, providing a much closer approximation of real time.

Eclare 3,250, 6 adds a new channel funding created event that event is emitted when a

funding or splice transaction has been signed and is ready to be published.

This is particularly useful for single funded channels.

The non-funding side has no opportunity to validate inputs beforehand.

It may want to force, close before the channel confirms, Eclare 3,250, 8 adds a validate

interactive TX plug-in trait.

That trait enables plugins to inspect and reject the remote, peers inputs and out, puts

in interactive transactions before signing.

This applies to dual funded channel opens and splices.

In those cases, both sides participate in transaction construction.

Eclare 3,250, 5 fixes the automatic channel type selection introduced in Eclare 3,250,

see newsletter 394.

It no longer includes SID alias for public channels, per the bolts, SID alias is only allowed

for private channels.

Ldk4,004, 102 fixes the HDLC claim timer to use the actual HDLC CLTV expiry rather than

the value from the onion payload.

For trampoline payments where a node is both a trampoline hop and the final recipient,

the actual HDLC expiry is higher than what the onion specifies because the outer trampoline

route added its own CLTV delta using the onion value caused the node to set a tighter

claim deadline than necessary.

Ldk10,006, 104 adds a SQL backend, SQLite or post goes for Ld outgoing payments database

as an alternative to the existing B-Bolt key value KV store.

This consolidation PR brings together several sub PR, notably 10,150, 3 which introduced

an abstract payment store interface, 9,140, 7 which implemented the SQL schema and core

backend and 10,480, 5 which added an experiment

until KV to SQL data migration.

Ld added support for post go SQL in newsletter 1, 160, 9 and SQLite in newsletter 2,137.

BIP1690, 9 publishes BIP4, 140, 2 specifying OP per commit, a new tap script op code that

pops two elements off the stack and pushes their tag to 682, 150, 6 hash.

This provides malt, I commitment functionality similar to what OPCAT enables but avoids enabling

recursive covenants.

OP per commit is part of the lnhance soft fork proposal alongside OP checked in plate

for E5BIP119, Objectsick from stack BIP358 and OP internal key BIP349,

Newsletter 130 for the initial proposal, BIP2001, 106 updates BIP350, 2 silent payments

to introduce a per group recipient limit of KMAX equals 2323.

This mitigates worst case scanning time from adversarial transactions.

See Newsletter 192.

This limit caps the number of out, puts that a scanner must check per recipient group

within a single transaction.

The value was originally proposed at 1000.

It was then increased to 2323 so that it matches the maximum number of P2TR out, puts that

can fit in a standard size transaction of 100 kilobytes.

This change also helps to avoid fingerprinting silent payment transactions.

First BIP2068 publishes BIP128, which specifies a standard JSON format for storing time-lock

recovery plans.

A recovery plan consists of two pre-signed transactions.

The first is an alert transaction that consolidates the wallet's axos to a single address.

The second is a recovery transaction that moves those funds to back up wallets after

a relative time-lock of two to 388 days.

If the alert transaction is broadcast prematurely, the owner can simply spend from the alert address

to invalidate the recovery.

Second Boltz-1301 updates the specification to recommend a higher dust limit Satoshi's

for anchor channels.

With option anchors, pre-signed HTLC transactions have zero fees, so their cost is no longer

factored into the dust calculation.

This means that HTLC out, puts the past the dust check, may still be uneconomical to

claim on chain.

The reason is that spending them requires a second stage transaction, whose fee can exceed

the output's value.

The spec now recommends that nodes set a dust limit that accounts for the cost of these

second stage transactions.

It also recommends that nodes accept values above Bitcoin cores, standard dust thresholds

from their peers.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly

Bitcoin Optek, recap on Riverside.fm.

The event is at 1730 UTC on March 10th.

The discussion is also recorded and will be available from our podcast page.