Categories
Crypto News Updates

Bitcoin Optech #147: Miner Activation Of Taproot And More

This week’s newsletter encourages miners to begin signaling for Taproot, discusses closing lost Lightning Network channels and more.

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter encourages miners to start signaling for taproot and describes continued discussion about closing lost LN channels using only a wallet seed. Also included are our regular sections with announcements of releases and release candidates, plus notable changes to popular Bitcoin infrastructure software.

Action items

  • Miners encouraged to start signaling for taproot: miners who expect to be willing to enforce the new consensus rules for taproot are encouraged to begin signaling and to ensure they’ll be able to run Bitcoin Core 0.21.1 (described below) or other compatible taproot-enforcing software by the minimum activation block specified in BIP341.
    Anyone wanting to trustlessly monitor signaling progress can upgrade to Bitcoin Core 0.21.1 and use the getblockchaininfo RPC. For example, the following command line prints the number of blocks in the current retarget period, the number of those blocks which have signaled, and whether it’s possible for taproot to activate in this period (assuming there’s no reorg):

$ bitcoin-cli getblockchaininfo

| jq ‘.softforks.taproot.bip9.statistics | .elapsed,.count,.possible’

353

57

false

  • If you prefer a graphical representation with supplementary information about miner progress and don’t need to use your own node, we recommend taproot.watch by Hampus Sjöberg.

News

  • Closing lost channels with only a BIP32 seed: as described in Newsletter #128, Lloyd Fournier proposed a method for creating new channels that would allow a user who lost all information except for their BIP32 wallet seed to re-discover their peers using only public information about the LN network. Once the user found their peers, they could request the peers close their mutual channels using the BOLT2 data loss protection protocol (see Newsletter #31). The proposed method isn’t perfect—users should still create backups1 and replicate them across independent systems—but Fournier’s proposal provides additional redundancy that would be especially useful for everyday users.
    Two weeks ago, Rusty Russell restarted the thread after trying to specify and implement the idea. After some additional mailing list discussion with Fournier and a group conversation in the weekly LN protocol development meeting, Russell indicated he was leaning against the idea, saying “I see encrypted backups as a more-likely-to-be-implemented solution though. Because they’re useful to send to places other than peers, and they can also contain HTLC information if you want.” Being able to contain HTLC information would allow settling payments that were pending at that time, which is a capability no recovery mechanism based solely on a BIP32 seed could provide.

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 0.21.1 is a new version of Bitcoin Core that contains activation logic for the proposed taproot soft fork. Taproot uses schnorr signatures and allows the use of tapscript. These are, respectively, specified by BIPs 341, 340, and 342. Also included is the ability to pay bech32m addresses specified by BIP350, although bitcoins spent to such addresses on mainnet will not be secure until activation of a soft fork using such addresses, such as taproot. The release additionally includes bug fixes and minor improvements.
    Note: due to a problem with the certificate authority that provides the code signing certificates for the Windows versions of Bitcoin Core, users on Windows will need to click through an extra prompt to install. It is expected that there will be a 0.21.1.1 release with an updated certificate when the problem is fixed. If you are planning to upgrade anyway, there’s no reason to delay using 0.21.1 because of this problem.
  • BTCPay 1.1.0 is the latest major release for this self-hosted payment processing software. It includes Lightning Loop support, adds WebAuthN/FIDO2 as a two-factor authentication option, makes various UI improvements, and marks a switch to using semantic versioning for version numbers moving forward.

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 #19160 is the next PR in the multiprocess project and adds the ability for the bitcoin-node process to spawn other processes and communicate with them using Cap’n Proto. These features are currently only used for testing, but the next PR in the project will allow Bitcoin Core to be started in multiprocess mode with the bitcoin-core process spawning separate bitcoin-wallet and bitcoin-gui processes.
  • Bitcoin Core #19521 nearly completes the coin statistics index project to dramatically speed up the gettxoutsetinfo RPC. Until now, the RPC defaulted to scanning the full UTXO set every time it was called, making it difficult for users to continually and quickly verify the coin supply or compare UTXO set hashes between different nodes. Users can now start their nodes with the -coinstatsindex configuration option to begin building the coin statistics index in the background. Once it is synced, gettxoutsetinfo runs nearly instantly and users can specify a height or block hash for the statistics. Being able to get the statistics for a particular block will be especially useful for allowing community verification of assumeUTXO chainstate archives.
  • Bitcoin Core #21009 removes the RewindBlockIndex logic triggered when updating a pre-segwit node (v0.13.0 or older) to a segwit-enforcing version. Pre-segwit nodes only processed stripped blocks that lacked the (segregated) witness data. The RewindBlockIndex logic discarded its copies of such blocks, re-downloaded them in their complete form, and validated them using segwit’s rules. As pre-segwit nodes have been end-of-life since 2018, the scenario has become uncommon. Future releases will instead prompt the user to reindex for an equivalent outcome.
  • LND #5159 builds on previous work to add support for making spontaneous Atomic Multipath Payments (AMPs) by manually specifying payment parameters to the sendpayment RPC. Invoking sendpayment with an AMP invoice is expected to be implemented in follow-up PRs.
  • Rust-Lightning #893 only allows accepting a payment if it includes a payment secret. Payment secrets are created by the receiver and included in invoices. The spender includes the payment secret in their payment in order to prevent attempts by third parties to reduce the privacy of multipath payments. Alongside this change are several API changes designed to reduce the chance that a payment will be accepted incorrectly.
  • BIPs #1104 updates the BIP341 specification of taproot with activation parameters based on the Speedy Trial proposal (see Newsletter #139).

Footnotes

  1. The data loss protection protocol, and other proposed methods such as covert requests for mutual channel closes requires your channel peer to still be online and responsive. If they’ve become permanently unavailable and you don’t have a backup, your funds are permanently lost. If, instead, you recover from a backup, you might still lose all of your funds if you broadcast an old state, but you have a chance to recover your funds if you backed up the latest state or if your peer doesn’t contest an old state. 

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Source: Bitcoin magazine

Categories
Crypto News Updates

Bitcoin Optech Newsletter #143: LN Node Software

This week’s Bitcoin Optech newsletter includes a release for LN node software and notable changes to Bitcoin Core.

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

News

No noteworthy news to report this week.

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.

  • C-Lightning 0.10.0 is the newest major release of this LN node software. It contains a number of enhancements to its API and includes experimental support for dual funding.
  • BTCPay 1.0.7.2 fixes minor issues discovered after last week’s security release.

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 #20286 removes the fields addresses and reqSigs from the responses of the RPCs gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and the REST endpoints /rest/tx, /rest/getutxos, /rest/block. When a well-defined address exists, the responses now include the optional field address instead. The deprecated fields had been used in the context of bare multisig which has no substantial use on the network today. The deprecated fields can be output via the configuration option -deprecatedrpc=addresses until the option is removed in Bitcoin Core 23.0.
  • Bitcoin Core #20197 improves the diversity of peer connections by updating the inbound peer eviction logic to protect the longest-running onion peers. It also adds unit test coverage for the current eviction protection logic. Onion peers have historically been disadvantaged by the eviction criteria due to their higher latency relative to IPv4 and IPv6 peers, leading to users filing multiple issues. An initial response to the issue began reserving slots for localhost peers as a proxy for onion peers. Later, explicit detection of inbound onion connections was added.
    With the updated logic, half of the protected slots are allocated to any onion and localhost peers, with onion peers receiving precedence over localhost peers. Now that support for the I2P privacy network has been added to Bitcoin Core (see Newsletter #139), a next step will be to extend eviction protection to I2P peers, as they generally have higher latency than onion peers.
  • Eclair #1750 removes support for Electrum and the corresponding 10,000 lines of code. Electrum was previously used by Eclair for mobile wallets. However, a new implementation, Eclair-kmp, is now recommended for use by mobile wallets, making Electrum support for Eclair unnecessary.
  • Eclair #1751 adds a blocking option to the payinvoice command which causes calls to payinvoice to block until the payment is completed. Previously, inefficiently polling the getsentinfo API was required for users to know when payments completed.

Find the original post here.

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month.

Source: Bitcoin magazine

Categories
Crypto News Updates

Bitcoin Optech #141: Signature Delegation And Taproot Activism

This week’s Bitcoin Optech newsletter covers signature delegation, Taproot’s effect on Bitcoin’s resistance to quantum cryptography and more

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a technique for signature delegation under Bitcoin’s existing consensus rules, summarizes a discussion about taproot’s effect on Bitcoin’s resistance to quantum cryptography, and announces a series of weekly meetings to help activate taproot. Also included are our regular sections describing notable changes to services and client software, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • Signing delegation under existing consensus rules: Imagine Alice wants to give Bob the ability to spend one of her UTXOs without immediately creating an onchain transaction or giving him her private key. This is called delegation and it’s been discussed for years, perhaps most notably in recent times as part of the graftroot proposal. Last week, Jeremy Rubin posted to the Bitcoin-Dev mailing list a description of a technique to accomplish delegation using Bitcoin today.
    Let’s say Alice has UTXO_A and Bob has UTXO_B. Alice creates a partially signed transaction spending both UTXO_A and UTXO_B. Alice signs for her UTXO using the sighash flag SIGHASH_NONE, which prevents the signature from committing to any of the transaction’s outputs. This gives the owner of the other input in the transaction—Bob—unilateral control over the choice of outputs, using his signature with the normal SIGHASH_ALL flag to commit to those outputs and prevent anyone else from modifying the transaction. By using this dual-input SIGHASH_NONE trick, Alice delegates to Bob the ability to sign for her UTXO.
    This technique appears to be mainly of theoretical interest. There are other proposed delegation techniques—including graftroot, OP_CHECKTEMPLATEVERIFY, and OP_CHECKSIGFROMSTACK—that would likely be superior in several ways, but only this technique is currently usable on mainnet for anyone who wants to experiment with it.
  • Discussion of quantum computer attacks on taproot: the original Bitcoin software provided two ways to receive bitcoin:
    • Pay-to-Public-Key (P2PK) implemented the simple and clear method described in the original Bitcoin paper of receiving bitcoins to a public key and allowing those coins to be spent by a signature. The Bitcoin software used this by default when the public key material could be handled entirely by software.
    • Pay-to-Public-Key-Hash (P2PKH) added a layer of indirection, receiving bitcoins to a hash digest that committed to the public key to be used. To spend the coins, the public key would need to be published alongside the signature, making the 20 bytes dedicated to the hash digest an overhead cost. This was used by default when the payment information might need to be handled by a person, e.g. an address that could be copied and pasted.
  • Nakamoto never described why he implemented both methods, but it’s widely believed that he added the hash indirection in order to make Bitcoin addresses smaller so that they could be communicated more easily. Public keys in the original Bitcoin implementation were 65 bytes, but address hashes were only 20 bytes.
    In the decade since, there have been a number of developments. To make certain multisig protocols simple and secure by default, it was determined that scripts for multiparty protocols should probably use a 32-byte commitment. Bitcoin developers also learned about previously known techniques that could compress a public key down to 33 bytes—later describing how to optimize that to 32 bytes. Finally, taproot’s primary innovation showed that a 32-byte public key could commit to a script with security similar to that of a 32-byte hash. All of this means that it no longer changes the amount of address data people have to communicate whether they use a hash or a public key—it’s 32 bytes either way if they want a universally applicable address format. However, directly using public keys still eliminates the extra bandwidth and storage resulting from hash indirection. If every payment went to a public key instead of a 32-byte hash, it would save about 13 gigabytes of block chain space per year. The BIP341 specification of taproot describes space savings as the reason it accepts payments to public keys in the P2PK style instead of hashes in the P2PKH style.
    But P2PKH hash indirection does have one advantage: it can hide keys from public view until they’re needed to authorize a spend. This means an adversary who has the ability to compromise the security of a public key might not be able to start using that ability until a transaction is broadcast, and they may lose the ability to steal funds controlled by that key once the transaction is confirmed to a certain depth. This limits the amount of time available for their attack and means a slow attack might not work. Although this has previously been discussed at length in the context of taproot’s choice to directly use public keys in the P2PK style (see 1, 2, and newsletters #70 and #86), it was the subject of renewed discussion this week on the Bitcoin-Dev mailing list after the publication of an email opposing taproot out of fear that we could see a quantum computer powerful enough to attack Bitcoin-style public keys “as soon as the end of the decade.”
    None of the participants in the mailing list discussion said they also opposed taproot, but they did examine the argument’s premises, discuss alternatives, and evaluate what tradeoffs would be implied by those alternatives. A selection of those conversations are summarized below:
    •  Hashes not currently doing a good job at QC resistance: as of a 2019 survey, an attacker with a powerful QC and nothing else besides a copy of the Bitcoin block chain could steal over 1/3 of all bitcoins. Most of those would be the result of users reusing addresses, a discouraged practice—but one that seems unlikely to go away soon.
      Additionally, discussion participants pointed out that anyone who shares their individual public keys or BIP32 extended public keys (xpubs) with third parties would also be at risk from a powerful QC if their public keys leaked. This would likely include most bitcoins stored with a hardware wallet or in an LN payment channel. In short, it’s possible that even though we almost universally use P2PKH-style hashed public keys today, nearly all bitcoins could be stolen by a powerful QC with access to public or third-party data. That implies that the choice to use P2PK-style non-hashed public keys with taproot doesn’t significantly change Bitcoin’s current security model.
    •  Taproot improvement in post-QC recovery at no onchain cost: if Bitcoiners learn that a powerful QC has manifested, or soon will, they can reject any taproot key-path spends—the type of spend where only a single signature is used. However, a user who prepares ahead when creating their taproot address can also spend bitcoins received to that address using a script-path spend. In that case, the taproot address commits to a hash of the tapscripts the user wants to use. That hash commitment can be used as part of a scheme to transition to a new cryptographic algorithm that’s safe against QCs, or—if such an algorithm is standardized for Bitcoin before QCs become a threat—it can allow the owner of the bitcoins to immediately transition to the new scheme. This does only work if individual users create backup tapscript spending paths, if they don’t share any public keys (including BIP32 xpubs) involved in those backup paths, and if we learn about a powerful QC before it does too much damage to Bitcoin.
    • Is the attack realistic? One respondent thought a fast QC by the end of the decade was “on the wildly optimistic side of projected rate of progress.” Another noted it was a “fairly straightforward engineering challenge” to turn the design for a single slow QC into a farm of QCs that could work in parallel, achieving results in a fraction of the time—making any protection from P2PKH-style hash indirection irrelevant. A third respondent proposed constructing special Bitcoin addresses that could only be spent from by someone making progress on fast QCs; users could voluntarily donate bitcoins to the addresses to create an incentivized early warning system.
    •  We could add a hash-style address after taproot is activated: if a significant number of users really do think the sudden appearance of a powerful QC is a threat, we could use a follow-up soft fork to add an alternative P2PKH-style taproot address type that uses hashes. However, this has consequences that caused several respondents to oppose it:
    • Bandwidth/storage costs versus CPU costs: it’s possible to eliminate the extra 32-byte storage overhead from hash indirection by deriving the public key from a signature and the transaction data it signs, a technique called key recovery. Again, this was opposed. Key recovery requires a significant amount of CPU that would slow down nodes and also prevents the use of schnorr batch validation that can make historic block verification up to three times faster. It also makes anonymous membership proofs and related techniques both harder to develop and much more CPU intensive. There may also be a patent issue.
  • As of this writing, it appears the mailing list discussion has concluded without any obvious loss of community support for taproot. As researchers and businesses continue improving the state of the art in quantum computing, we expect to see future discussions about how to best keep Bitcoin secure.
  • Weekly taproot activation meetings: ten weekly meetings to discuss details related to activating taproot have been scheduled for each Tuesday at 19:00 UTC in the ##taproot-activation IRC channel, with the first meeting occurring yesterday (March 23rd).

Changes to services and client software

In this monthly feature, we highlight interesting updates to Bitcoin wallets and services.

  • OKCoin launches Lightning deposits and withdrawals: A blog post outlines OKCoin’s Lightning deposit and withdrawal support. They also lowered their minimum deposit/withdrawal limit from 0.001 to 0.000001 BTC as a result. At this time, 0.05 BTC is OKCoin’s limit when transacting using LN.
  • BitMEX announces bech32 support: In a blog post, BitMEX detailed the launch plans for bech32 deposit support. BitMEX had previously rolled out bech32 withdrawal (send) support.
  • Specter v1.2.0 released: Specter v1.2.0 includes support for Bitcoin Core descriptor wallets and coin control features.
  • Breez streams audio for Lightning payments: Breez wallet has integrated an audio player which, combined with keysend, allows users to listen to podcasts while streaming payments to the publisher and sending one-off tip payments.
  • Key manager Dux Reserve announced: Thibaud Maréchal announced Dux Reserve, a beta open source desktop key manager supported on MacOS, Windows, and Linux and supporting Ledger, Coldcard, and Trezor hardware wallets.
  • Coldcard now using libsecp256k1: Coldcard’s version 4.0.0, among other features, switches to using Bitcoin Core’s libsecp256k1 library for its cryptographic operations.

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.

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 #20861 implements support for BIP350 (Bech32m format for v1+ witness addresses). Bech32m supersedes bech32 (BIP173) as the address format for native segwit outputs of version 1-16. Native segwit version 0 outputs (P2WPKH and P2WSH) will continue to use bech32. This PR would enable Bitcoin Core users to send payments to Pay to Taproot (P2TR) addresses once taproot outputs (BIP341) were defined on the network. The change should not affect any mainnet systems, but may cause address incompatibility issues in testing environments such as signet where taproot is already active using bech32-encoded addresses as previously proposed. Bech32m support will also be backported to Bitcoin Core 0.19, 0.20, and 0.21.
  • Bitcoin Core #21141 updates the -walletnotify configuration setting that calls a user-specified command each time a transaction is seen that affects a loaded wallet. Two new placeholders are added to the arguments that can be passed to the command, %b for the hash of a block containing the transaction and %h for the height of the block. Both are set to defined values for unconfirmed transactions.
  • C-Lightning #4428 deprecates the fundchannel_complete RPC’s acceptance of txids, requesting instead that a PSBT be passed. The PSBT can be checked to ensure it contains the funding output, eliminating a problem where a user who passes incorrect data can lose the ability to recover their funds.
  • C-Lightning #4421 implements the funding transaction recovery procedure covered in last week’s newsletter. Users who mistakenly funded channels with a first-party malleated transaction (e.g. using RBF) but haven’t used the channel yet can now supply their transaction output to the lightning-close command to negotiate recovery with a peer supporting the shutdown_wrong_funding feature.
  • LND #5068 makes available a number of new configuration options for limiting how much network gossip information LND processes. This can help on systems with limited resources.
  • Libsecp256k1 #831 implements an algorithm that can speed up signature verification by 15%. It can also reduce by 25% the amount of time it takes to generate signatures while still using a constant-time algorithm that maximizes side-channel resistance. It additionally removes some of Libsecp256k1’s dependencies on other libraries. See Newsletter #136 for more information about this optimization.

BIPs #1059 adds BIP370 specifying version 2 PSBTs as previously discussed on the mailing list (see Newsletter #128).

Source: Bitcoin magazine

Categories
Crypto News Updates

Bitcoin Optech #140: Rescuing Lightning Transactions

This week’s Bitcoin Optech newsletter describes discussion on rescuing lost Lightning Network funding transactions, announcements of releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter describes a discussion about rescuing lost LN funding transactions and includes our regular sections with announcements of releases, release candidates, and notable changes to popular Bitcoin infrastructure software.

News

  • Rescuing lost LN funding transactions: LN funding transactions are not safe in the presence of transaction malleability. Segwit eliminated third-party malleability as a concern for most transactions, but it doesn’t address the case where the creator of a transaction mutates its txid themselves, such as by fee bumping the funding transaction using Replace-by-Fee (RBF). If a txid mutation happens, then the pre-signed refund transaction is not valid, so the user can’t get their funds back. Additionally, the remote node may not automatically see the funding transaction and so may not be able to help the funder get their money back.This week, Rusty Russell posted to the Lightning-Dev mailing list about a quick and experimental feature he implemented in C-Lightning to help a user with this problem recover their funds. He also described alternative solutions for related problems as well as the impact of the proposed channel dual-funding protocol on this problem. Christian Decker also posted a proposed change to the LN specification to help facilitate funding recovery efforts. As LN software adds support for funding channels from external wallets (e.g. C-Lightning as described in Newsletter #51 and LND in Newsletter #92), developers may want to give this type of failure scenarios more attention.

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.

  • HWI 2.0.0 is the release for the next major version of HWI. Among other improvements, it contains support for multisig on the BitBox02, improved documentation, and support for paying OP_RETURN outputs with a Trezor.
  • Rust-Lightning 0.0.13 is the latest release for this LN library containing improvements aimed at forward compatibility with multipath payments and future script upgrades such as taproot.
  • BTCPay Server 1.0.7.0 is the latest release for this self-hosted payment processing software. Notable improvements include a more featureful and visually appealing wallet setup wizard, the ability to import wallets created using Specter, and more efficient QR codes for bech32 addresses.

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 #21007 adds a new -daemonwait configuration option. It has been possible to run Bitcoin Core as a background daemon process since early versions by starting the program with the -daemon configuration option. The -daemon option causes the program to immediately start the daemon process in the background. The new -daemonwait option is similar, but only puts the daemon process in the background after initialization is complete. This allows the user or parent process to more easily know whether the daemon started successfully by observing the program’s output or exit code.
  • C-Lightning #4404 allows the keysend RPC (see Newsletter #107) to send messages even to nodes that don’t explicitly signal that they support the feature. As discussed, the signal was never standardized and the procedure implemented by LND didn’t depend on signaling, so this change should allow C-Lightning to send to roughly the same set of nodes that LND can address.
  • C-Lightning #4410 brings the experimental implementation for dual-funded channels in line with the most recent draft specification changes. Most notably, the use of Proof of Discrete Log Equivalency (PODLE) has been dropped, at least temporarily (see Newsletter #83 for original discussion of PODLEs and Newsletter #131 for discussion about alternatives). Subsequent to this merge, a new PR was opened that will make experimenting with dual-funding more accessible by eliminating the need to compile C-Lightning with special build flags (although a special configuration option will still be required).
  • LND #5083 allows a PSBT to be read from a file rather than by reading the standard input (stdin) file descriptor. Some terminals have a limit on the number of characters that can be added to stdin simultaneously (i.e. pasted), which made PSBTs over 4096 base64 characters (equivalent to 3.072 bytes of binary) unusable. Especially now that several hardware wallets require PSBTs include previous transactions for segwit spends (see Newsletter #101), it’s common to create PSBTs over 3 KiB in size.
  • LND #5033 adds an updatechanstatus RPC that can advertise that a channel has been disabled (similar to your node going offline) or that it’s been re-enabled (similar to your node coming back online).
  • Rust-Lightning #826 increases the maximum allowed OP_CHECKSEQUENCEVERIFY delay to 2,016 blocks for the output paying the node that is unilaterally closing the channel. This fixes an interoperability issue when opening channels with LND, which may request a delay up to 2016 blocks, larger than the previous Rust-Lightning maximum of 1008 blocks.
  • HWI #488 implements a breaking change in how the displayaddress command handles multisig addresses when used with the --desc option for output script descriptors. Previously, HWI applied BIP67 lexicographic key sorting automatically based on what the device involved used (e.g. applying BIP67 for Coldcard devices, not applying it for Trezor devices). The way this was implemented created problems when the user explicitly specified the sortedmulti descriptor option that implements BIP67 key sorting. After this change, users of descriptors need to specify sortedmulti for devices that require lexicographic key sorting or multi for those that don’t.

Source: Bitcoin magazine

Categories
Crypto News Updates

Bitcoin Optech: Bitcoin Technical Updates Newsletter #139

This issue of Bitcoin Optech covers Taproot activation discussion, the release of Eclair 0.5.1 and more.

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

This week’s newsletter summarizes continued discussion about proposed methods for activating taproot and links to an effort to document existing software building on top of taproot. Also included are our regular sections with the summary of a Bitcoin Core PR Review Club meeting, announcements of releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure projects.

News

  • Taproot activation discussion: the previous weeks’ discussions about activation saw different groups of people opposing either BIP8 LockinOnTimeout=true (LOT=true) or LOT=false, so most discussion on the mailing list this week focused on alternative activation mechanisms. Some proposals included:
    • User Activated Soft Fork (UASF): a plan being discussed to implement BIP8 LOT=true in a software fork of Bitcoin Core that mandates miners signal for activation of taproot by July 2022 (as widely proposed), but which also allows miners to activate it earlier.
    • Flag day: several proposals (1, 2) to program into nodes a specific block height or time roughly 18 months from now (as proposed) where taproot activates. Miner signaling is not required to cause activation and cannot cause earlier activation. Anthony Towns wrote a draft implementation.
    • Decreasing threshold: several proposals (1, 2) to gradually decrease over time the number of blocks that must signal readiness for miners to enforce taproot before the new consensus rules lock in. See also Anthony Town’s proposal from last year described in Newsletter #107.
    • A configurable LOT: in addition to previously-discussed proposals to make BIP8’s LOT value a configuration option (see Newsletter #137), rough code was posted showing how LOT=true could be enforced via an external script calling RPC commands. Additional code was created showing how LOT=true could also be opposed by node operators who were worried about it creating block chain instability.
    • A short-duration attempt at miner activation: an updated proposal to give miners approximately three months to lock in taproot, starting from soon after the release of a full node implementing the activation logic. If the attempt failed, the community would be encouraged to move on to a different activation method. If the attempt succeeded, there would still be a several month delay before taproot activated to allow most of the economy to upgrade their nodes. A draft implementation for this proposal based on Bitcoin Core’s existing BIP9 implementation was also written by Anthony Towns. Andrew Chow created an alternative draft implementation based on the previously proposed BIP8 implementation.

    It seemed unlikely any of the proposals would ever become almost everyone’s first choice, but it appeared that a large number of people were willing to accept the short-duration attempt under the name Speedy Trial. There were still a few concerns with it, including:

    • Could be co-opted for mandatory activation: even though the proposal explicitly encourages making other activation attempts if miners don’t quickly signal sufficient support for taproot, a concern was expressed that it could be co-opted by a group of users seeking fast mandatory activation, although it was noted that no group has previously expressed the desire to attempt mandatory activation on such a dangerously short timeline.
    • Using time-based or height-based parameters: the proposal describes the tradeoffs between setting its start, timeout, and minimum_activation parameters using either times (based on the median of the previous 11 blocks) or block heights. Using times would result in the smallest and easiest to review patch to Bitcoin Core. Using heights would provide a bit more predictability, especially for miners, and would be compatible with other attempts using BIP8.
    • Myopic: there was concern that the proposal is too focused on the short term: “Speedy Trial fully prepares for the (likely) case where miners activate taproot, but it does nothing to codify lessons learned from Segwit’s failure to activate in a timely manner. We have an opportunity with the activation of taproot to create a template for future activations that will clearly define the roles and responsibilities for developers, miners, merchants, investors, and end users in all the ways an activation can progress, not just the best-case outcomes; in particular enabling and enshrining the final arbiter role held by Bitcoin’s economic users. Defining this will only get more difficult in the future, both because we’ll only do so when we’re already in crisis, and because Bitcoin’s growth means future agreement will need to be done at greater scale and so with greater difficulty.”
    • Speed: the proposal, based on initial discussion from the ##taproot-activation IRC channel, proposes giving miners about three months to lock in taproot and waiting a fixed six months from the start of signal measuring before activation (if lock in is achieved). Some people have sought either slightly shorter or slightly longer timelines.

    We’ll continue tracking the discussion around the various proposals and will summarize any significant progress in future newsletters.

  • Documenting the intention to use and build upon taproot: In discussion about activation methods, Chris Belcher noted that a large list of software was compiled whose developers stated their intention to implement segwit during the debate around activating that soft fork. He suggested that a similar list could be created to document for posterity the amount of support taproot has. That way it could be clear that taproot was desired by a large segment of the economy no matter how it ends up being activated.Jeremy Rubin posted to the Bitcoin-Dev mailing list a link to a somewhat related wiki page where developers can post links to projects they’re building on top of taproot’s new proposed features. This can provide assurance that taproot provides solutions people actually want and is designed in such a way that its features will get used.

Bitcoin Core PR Review Club

In this monthly section, we summarize a recent Bitcoin Core PR Review Club meeting, highlighting some of the important questions and answers. Click on a question below to see a summary of the answer from the meeting.

Erlay: bandwidth-efficient transaction relay protocol is a PR (#18261) by Gleb Naumenko that proposes to implement BIP330 in Bitcoin Core.

The review club discussion focused on the tradeoffs, implementation and potential new attack vectors involved with Erlay. In subsequent meetings, the review club discussed Minisketch, a library implementing the PinSketch set reconciliation algorithm that is the basis for the efficient relay protocol in Erlay.

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.

  • Eclair 0.5.1 is the latest release of this LN node, containing improvements to startup speed, reduced bandwidth consumption when syncing the network graph, and a series of small improvements in preparation for supporting anchor oututs.
  • HWI 2.0.0RC2 is a release candidate for the next major version of HWI.

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 #20685 Adds I2P support by using the I2P SAM protocol. This feature has long been requested and was only recently made possible by the addition of addr v2 Though documentation for node operators hoping to run I2P is still being created, a Bitcoin StackExchange Q&A provides hints on getting started.
  • C-Lightning #4407 updates the listpeers RPC with new fields that provide information about each channel’s current unilateral close transaction, including its fee (both in total fee terms and as a feerate).
  • Rust-Lightning #646 adds the ability to find multiple paths for a payment so that it will be possible to add multipath payment support.
  • BOLTs #839 adds funding transaction timeout recommendations to save funding fees when there’s a failure to confirm funding transactions, providing stronger guarantees for the channel funder and fundee. The new recommendations suggest that the funder commits to ensuring the funding transaction confirms in 2016 blocks and recommends that the fundee forget the pending channel if the funding transaction not confirm within those 2016 blocks.
  • BTCPay Server #2181 uppercases bech32 addresses when presenting BIP21 URIs as QR codes. This results in less dense QR codes as uppercase substrings can be encoded more efficiently. The change was preceded by an extensive compatibility survey of wallets with the BIP21 URI scheme.

Source: Bitcoin magazine

Categories
Crypto News Updates

Bitcoin Optech: Bitcoin Technical Updates Newsletter #138

This week’s newsletter covers the BIP70 payment protocol, proposals for a standardized way to exchange fraud proofs for Discreet Log Contracts (DLCs) and more.

The Bitcoin Optech newsletter provides readers with a top-level summary of the most important technical news happening in Bitcoin, along with resources that help them learn more. To help our readers stay up-to-date with Bitcoin, we’re republishing the latest issue of this newsletter below. Remember to subscribe to receive this content straight to your inbox.

News

  • Discussion about a BIP70 replacement: Thomas Voegtlin started a thread on the Bitcoin-Dev mailing list about a replacement for some of the features of the BIP70 payment protocol, specifically the ability to receive a signed payment request. Voegtlin wants to be able to prove that the address he paid was actually the address provided to him by the receiver (e.g. an exchange). Charles Hill and Andrew Kozlik each replied with information about protocols they’re working on. Hill’s scheme is intended for use with LNURL but could be repurposed to serve Voegtlin’s intended use case. Kozlik’s scheme is closer in spirit to BIP70 but drops its use of X.509 certificates and adds features for exchange-based coin swaps (e.g. trading BTC for an altcoin or vice-versa).
  • Fraud proofs in the v0 Discreet Log Contract (DLC) specification: Thibaut Le Guilly started a discussion on the DLC-dev mailing list about the goal to include fraud proofs in the version 0 DLC coordination specification. Two types of fraud were discussed:
    • Equivocation: where an oracle signs for the same event more than once, producing conflicting results. A proof of equivocation can be automatically verified by software without third-party trust.
    • Lying: where an oracle signs for an outcome that users know is wrong. This will almost always depend on evidence not available to the user’s contract software, so this type of fraud proof must be verified manually by the user, who can compare the original contract to the outcome signed by the oracle.

    Discussion participants seemed to all favor providing an equivocation proof, although there was some concern that it could be too much work for the v0 specification. As an intermediate solution, it was suggested to focus on proofs of lying. When the format of those proofs has been established, software can then be updated to take two separate proofs for the same oracle and event to create a proof of equivocation.One concern with proofs of lying was that users could be spammed by fake proofs, forcing users to either waste their time verifying false proofs or give up checking fraud proofs altogether. Counterarguments included being able to get part of the proof from an onchain transaction (which requires that someone paid an onchain fee) and also that users could choose where they download fraud proofs from, preferring to get them from a source that was known for only propagating accurate information.

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 #16546 introduces a new signer interface, allowing Bitcoin Core to interact with external hardware signing devices through the HWI or any other application which implements the same interface.Bitcoin Core has been able to interface with hardware signers using HWI since Bitcoin Core version 0.18. Until this PR, however, the process required use of the command line to transfer data between Bitcoin Core and HWI. This PR simplifies the user experience by enabling Bitcoin Core to directly communicate with HWI. The PR includes full documentation on how to use the new signer interface along with HWI.The new signer interface is currently only accessible through RPC methods. A draft PR adds support for the signer interface to the GUI, allowing the use of hardware signers with Bitcoin Core without any use of the command line.
  • Rust-Lightning #791 adds support for polling BlockSource interfaces on startup to sync blocks and headers, with fork detection during sync. As described in Newsletter #135, BlockSource allows software to obtain data from sources other than a standard Bitcoin Core compatible node, allowing redundancy that can help prevent eclipse attacks or other security problems.
  • Rust-Lightning #794 enables support for the BOLT2 option_shutdown_anysegwit feature that permits future segwit versions when initiating shutdown. If option_shutdown_anysegwit is negotiated, a channel party sending a shutdown message to initiate closing may send a scriptpubkey for payment, provided the script complies with the standard BIP141 witness program form of a version byte (a 1-byte push opcode of OP_1 through OP_16) followed by a witness program (a byte vector push of 2 to 40 bytes). These shutdown scripts are limited to standard forms to avoid expensive fee-heavy scripts or transactions with oversized scripts not propagating due to non-standardness. As it became possible to relay payments to any segwit script in Bitcoin Core 0.19.0.1 (released November 2019), it’s now safe to include them in LN’s standard forms.
  • HWI #413, #469, #463, #464, #471, #468, and #466 significantly update and extend HWI’s documentation. Particularly notable changes include a link to the documentation on ReadTheDocs.io, new and updated examples, and a new policy that describes the criteria new devices must meet for HWI to consider supporting them.
  • Rust Bitcoin #573 adds a new method SigHashType::from_u32_standard that ensures the provided sighash byte is one of standard values that Bitcoin Core will relay and mine by default. Each signature’s sighash byte indicates what parts of the transaction need to be signed. Bitcoin’s consensus rules dictate that non-standard sighash values are treated as equivalent to SIGHASH_ALL, but the fact that they aren’t relayed or mined by default can theoretically be used to trick software using offchain commitments into accepting an unenforceable payment. Developers of such software using Rust-Bitcoin may which to switch to this new method from the SigHashType::from_u32 method that accepts any consensus-valid sighash byte.
  • BIPs #1069 updates BIP8 to allow for a configurable activation threshold and to include 90% as a recommendation, down from 95% previously, based on the most recent taproot activation discussion.

The original post can be found here: https://bitcoinops.org/en/newsletters/2021/03/03/

Please subscribe to the Bitcoin Optech newsletter directly to receive this content straight to your inbox every month: https://bitcoinops.org/en/newsletters/

Source: Bitcoin magazine