As before, the donor prepares a 1,000 BTC transaction. They sign in almost the normal way, with the one difference being that they essentially generate their nonce in two parts: a true random nonce that they will forever keep secret, and their favorite number—which they’ll initially keep secret but which is safe for other people to discover. The donor generates a fully valid signature using both of these values, adding them together as if they were a single nonce.
BIP340 signature commitments use the nonce in two forms: a numeric representation (called a scalar ), which normally only the signer knows, and as a point on the Elliptic Curve (EC), which is published to enable verification.
The donor takes the commitment part of their valid signature and subtracts out the hidden scalar. This makes the signature incomplete (and thus invalid) but allows the donor to share the (invalid) signature commitment, the (valid) point for the complete nonce, and the (valid) point for the hidden number. Together these three pieces of information are a signature adaptor .
Using a slight variant on the BIP340 signature verification algorithm, anyone can verify that the signature adaptor would provide a valid signature if the hidden scalar was simply added back in to the (currently invalid) signature commitment. This is possible to verify even without knowing what that hidden number is. In short, it is now possible for users to trustlessly begin making guesses about the value of hidden scalar, secure in the knowledge that a correct guess will allow them to get the signature and send the transaction.
Like everyone else who received the donor’s signature adaptor, Alice and Bob now have a copy of the EC point for the hidden number. Also like everyone else, they don’t know the actual scalar. But, if you recall, all the donor did to turn their valid signature into an invalid signature is subtract out the hidden number from their signature commitment while continuing to have the signature commit to the point of the hidden number. Alice can just as easily create an invalid signature by not committing to the scalar she doesn’t know but still committing to the EC point she does know. She does this by creating her own nonce pair, using the private form when creating her (invalid) signature but commiting to the aggregation of the public form of her nonce and the EC point from the donor’s signature adaptor. This produces a signature adaptor for a transaction that pays Bob. If Bob learns the scalar, he can convert that adaptor into a valid signature and send the transaction, winning the bet.
But how does Bob learn the winning number? Does he have to wait for someone else who guesses it to publish a press release? Nope. Recall one more time that the signature adaptor the donor published was their actual signature minus the scalar. When the hidden number is discovered and somebody sends the 1,000 BTC transaction, they must publish the original (valid) signature commitment. Bob can take that (valid) signature commitment and subtract from it the (invalid) signature commitment in the original signature adaptor to get the scalar. He then uses that scalar to convert Alice’s adaptor into a valid signature.
Multisignature adaptors
The previous section shows individual users modifying how they create their signatures to produce signature adaptors. It’s also possible for the parties to a multisignature to use the same trick. That’s extraordinarily useful, as many cases where signature adaptors will be used require the cooperation of two users.
For example, when Alice and Bob make the bet above, they might start by depositing funds into a script only spendable by a multisignature between them. Then Alice can produce her partial signature in the form of a signature adaptor; if Bob learns the hidden number, he can transform Alice’s adaptor into her valid partial signature and then provide his partial signature to produce a full signature spending the money.
This gives signature adaptors all the same advantages of multisignatures in general: they look like and use the same amount of space as a single signature, minimizing fees and maximizing privacy and fungibility.
In next week’s preparing for taproot column, we’ll explore one of the main ways we expect to see signature adaptors used: Point Time Locked Contracts (PTLCs ), an upgrade for the venerable Hash Time Lock Contracts (HTLCs ) used extensively in LN, coinswaps, and a number of other protocols.
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 22.0rc2 is a release candidate for the next major version of this full node implementation and its associated wallet and other software. Major changes in this new version include support for I2P connections, removal of support for version 2 Tor connections, and enhanced support for hardware wallets.Bitcoin Core 0.21.2rc1 is a release candidate for a maintenace version of Bitcoin Core. It contains several bug fixes and small improvements.
Notable code and documentation changes
Notable changes this week in Bitcoin Core , C-Lightning , Eclair , LND , Rust-Lightning , libsecp256k1 , Hardware Wallet Interface (HWI) , Rust Bitcoin , BTCPay Server , Bitcoin Improvement Proposals (BIPs) , and Lightning BOLTs .
Bitcoin Core #22642 updates Bitcoin Core’s release process for upcoming version 22.0 to concatenate the GPG signatures of everyone who reproducibly built the binaries into a single file which can be batch verified (example ). Signatures from deterministic builders have been available for years, but this should make them more accessible and also reduce the existing dependency on the project’s lead maintainer signing the release binaries.Bitcoin Core #21800 implements ancestor and descendant limits for mempool package acceptance. Bitcoin Core limits the number of related transactions in its mempool as a protection against DoS attacks and so that block construction is tractable for miners. By default, those limits ensure that no transaction in the mempool, combined with its mempool ancestors, can exceed 25 transactions or 101KvB in weight. The same rules apply to the transaction combined with its mempool descendants.#21800 implements ancestor and descendant limit checks for validating arbitrary packages (i.e. when multiple transactions are considered for addition to the mempool at the same time). Mempool package acceptance was implemented for testing only in #20833 , and will eventually be exposed over the p2p network as part of package relay .Bitcoin Core #21500 updates the listdescriptors RPC with a private parameter that, when set, will return the private form of each descriptor. The private form contains any known private keys or extended private keys (xprvs), allowing this updated command to be used to backup the wallet.Rust-Lightning #1009 adds a max_dust_htlc_exposure_msat channel configuration option which limits the total balance of pending “dusty HTLCs” whose amounts are below the dust limit .proposed option_dusty_htlcs_uncounted feature bit, which advertises that the node does not wish to count “dusty HTLCs” against max_accepted_htlcs. Node operators would likely want to adopt this feature bit sincemax_accepted_htlcs is mainly used to limit the potential size of the onchain transaction if a force-close were to happen and “dusty HTLCs” are unclaimable onchain and would never affect the final transaction size.
Find the original post here.
Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.
