Bitcoin Optech #145: Lightning Network Offers, Taproot 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 progress on activating taproot, summarizes an update to LN offers to partly address stuck payments, relays a request for feedback on anchor outputs in LND, and announces the public launch of the Sapio smart contract development toolkit. Also included are our regular sections with summaries of changes to popular clients and services, new releases and release candidates, and notable changes to popular Bitcoin infrastructure software.

News

• Taproot activation release candidate: since our update on taproot activation in last week’s newsletter, the Bitcoin Core Project has merged a pull request implementing the Speedy Trial activation mechanism and a second PR containing the activation parameters. These PRs and a few others are currently part of the first Release Candidate (RC) for Bitcoin Core 0.21.1. Testing and other quality assurance tasks are expected to continue for at least several days after the publication of this newsletter. See the RC and merge summary sections below for more details.

• Using LN offers to partly address stuck payments: in some cases, an attempt to pay an LN invoice can result in the payment becoming stuck for an extended period of time. Until the failure is resolved, requesting a second invoice to make a second payment attempt can result in paying twice.This week, Rusty Russell posted to the Lightning-Dev mailing list a change to his proposed offers specification that allows the receiver of a payment to commit to a new invoice which supplants the previous invoice. If the spender pays the second invoice, there’s still a risk that they will pay twice, but the receiver’s signature on the offer combined with LN’s inherent proof of payment will allow the spender to prove the receiver acted deceitfully if both payments were accepted. When paying a receiver with an established reputation, such as a popular business, that may be enough to eliminate stuck payments as a major problem.The update to the offers specification also allows the receiver to indicate that they received the payment and the problem is with a downstream node. In that case, the funds for both the spender and the receiver are fully secure and the only consequence is that the spender will need to wait a while before they can reuse that particular one of their payment slots (HTLC slots). This ability to communicate interactively is a clear advantage of offers over plain invoices.

• Using anchor outputs by default in LND: Olaoluwa Osuntokun posted to the LND engineering mailing list about his desire for the next major version of LND to use anchor outputs by default. Anchor outputs will allow unconfirmed LN commitment transactions that close a channel to be CPFP fee bumped. Unfortunately, there are some challenges with CPFP fee bumping in the LN model:

Not always optional: for regular onchain transactions, many users can just wait longer for their transaction to confirm as an alternative to fee bumping. For LN, sometimes waiting isn’t an option—a fee bump will need to be submitted within a matter of hours or funds could be lost.

Timelocked outputs: for most regular onchain payments, a user who wants to CPFP bump can pay for a fee bump using the funds stored in their output from the transaction they want to bump. In the case of LN, those funds aren’t available until the channel close has been fully settled onchain. That means the user needs to use a separate UTXO to pay the fees.

• To address the above two concerns, LND is requiring users of anchor outputs to retain at least one confirmed UTXO of reasonable value in their wallet any time a channel is open. That ensures they can CPFP fee bump when necessary, but it has certain consequences, such as preventing spending the last of your onchain funds (even to open a new channel) while you still have at least one channel open.Osuntokun’s request is for wallets or services built on LND to let the development team know if any of the above concerns, or any other concerns related to anchor outputs, will cause serious problems. Although the question is specific to LND, the answers may have implications for all LN nodes.

• Sapio public launch: Jeremy Rubin posted to the Bitcoin-Dev mailing list an announcement that he has made available the Sapio smart contract development toolkit, a Rust-based library and associated tooling that can be used to create smart contracts expressible using Bitcoin Script. The language was originally designed to make use of Rubin’s proposed OP_CHECKTEMPLATEVERIFY opcode (OP_CTV), but it can simulate the existence of that opcode, and of other potential features for Bitcoin such as taproot, using a trusted signing oracle. In addition to the Sapio library, the release also contains extensive documentation and an experimental frontend.

Changes to services and client software

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

• Specter v1.3.0 released: Specter v1.3.0 includes additional RBF support, Bitcoin Core setup from within the application, HWI 2 support, and an option to use mempool.space as a block explorer and for fee estimation.

• Specter-DIY v1.5.0: Hardware wallet firmware Specter-DIY released v1.5.0 which adds custom SIGHASH flag support and full descriptor support including miniscript.

• BlueWallet v6.0.7 adds message signing: BlueWallet v6.0.7 allows users to sign and verify messages using Bitcoin addresses, among other features and fixes.

• Azteco announces Lightning support: Bitcoin voucher company Azteco announced support for redeeming purchased bitcoins via Lightning Network.

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.1rc1 is a release candidate for a version of Bitcoin Core that, if activated, will enforce the rules of the proposed taproot soft fork, which uses schnorr signatures and allows 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.

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 #21377 adds the activation mechanism and #21686 adds the activation parameters for the taproot softfork. Starting with the first difficulty adjustment after April 24th, miners will be able to signal readiness for Taproot activation on bit 2. If 1815 (90%) of one difficulty period’s 2016 blocks in the signaling window signal readiness, the softfork activation locks in. The signaling window ends with the first difficulty adjustment after August 11th. If locked in, taproot will be activated at block height 709632, which is expected to be reached around November 12th.

• Bitcoin Core #21602 updates the listbanned RPC with two additional fields: ban_duration and time_remaining.

• C-Lightning #4444 adds lnprototest (LN Protocol Tests) to the default targets for C-Lightning’s Continuous Integration (CI) tests and also makes it easier for developers to run the tests from C-Lightning’s usual build system. The LN protocol tests make it easy for an implementation to test that they’re following the LN protocol specification.

• LND #4588 skips creating a change output in cases where the amount of change is so small that it’s worth less than the amount it would cost to spend it.

• LND #5193 disables channel validation by default for LND instances using the Neutrino client (which implements the compact block filters protocol). This option assumes that channel advertisements received from a peer are correct, saving the client from having to download old blocks necessary to verify those advertisements. This has the downside that payment attempts made using falsely advertised channels will fail, wasting time but not causing the loss of money—a reasonable tradeoff for anyone already choosing to use a lightweight client. This new default behavior may be disabled by using the new configuration option –neutrino.validatechannels=true.

• LND #5154 adds basic support for using LND with a pruned full node, allowing LND to externally request from other Bitcoin nodes a block that has been deleted by the local node. LND can then extract whatever information it needs from the block without going through the pruned node. Because the user’s own full node previously verified the block, this doesn’t change the security model.

• LND #5187 adds new channel-commit-interval and channel-commit-batch-size parameters that can be used to configure how long LND will wait before sending a channel state update and the maximum number of changes it’ll send in one update. The higher these values are, the more efficient a busy LND node will be, although that efficiency comes at the cost of having a slightly higher latency.

• Rust-Lightning #858 adds internal support for interoperating with Electrum-style blockchain data sources.

• Rust-Lightning #856 updates how it handles funding transactions. Previously the wallet was asked to create the funding transaction that opened a new channel and to give Rust Lightning only that transaction’s txid. Now Rust Lightning accepts the full funding transaction. Similar to a recent change to C-Lightning (see Newsletter #141), this allows the LN software to check the funding transaction before it is broadcast and ensure it is correct.

• HWI #498 adds support for signing arbitrary Bitcoin-style messages using the BitBox02 hardware wallet.

• BTCPay Server #2425 adds support for receiving payjoin payments to the wallet even for addresses not associated with a BTCPay invoice.

Find the original post here.

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

Garzik Forks UnitedBitcoin Away from “Maximalists” to Support Altcoin Communities

A new project called UnitedBitcoin (warning: the site autoplays audio) promises to add smart contract features using the UTXO model, support for the lightning network and SegWit, and eight-megabyte blocks. Headed up by Jeff Garzik, the lead developer behind the failed SegWit2x hard fork, along with Matthew Roszak and SongXiu Hua, this UnitedBitcoin (UB) hard fork will offer replay protection to prevent people from accidentally spending their coins on both the Bitcoin and the UnitedBitcoin blockchains.

Garzik told Bitcoin Magazine that “10 of the total worldwide SHA-256 hash power” has moved to the new UB network, with much of the support coming from China and older mining equipment that was no longer profitable due to the escalating difficulty in mining bitcoin. He noted that UB is already supported on the ZB and EXX exchanges.

The UB white paper outlines how lost bitcoins have created deflationary pressure that has pushed the price up. Because those bitcoins are out of circulation, the supply is further decreased. One of the issues that UB seeks to address is to find a purpose both for those lost bitcoins and for “inactive” wallets by creating a stable cryptocurrency linked to their addresses.

All active Bitcoin addresses will receive the same balance on the UB chain, much like previous forks. The balances of UB on inactive addresses, however, will be confiscated by the UB Foundation and used to “serve the community.”

Inactive addresses are defined in the white paper as “addresses without activity since block height #494000 (November 11, 2017) and as a result didn’t automatically receive UBTC during phase 1 of the asset allocation procedure.”

UB does not distinguish between an “inactive” address and one which is simply being used by a long-time “hodler.”

“There is no difference. An inactive account is an inactive account,” said Garzik. “Like during [the] Ethereum new coin creation, you had to take a proactive step, otherwise you got zero [ether]. This is normal for new token creation — new chain, new ERC20, but different from all other Bitcoin Forks. We are trying to do something new and different.”

Anyone with a prior balance of 0.01 BTC in an “inactive” address at the time of the November 11 fork can still get UB tokens, so long as they are willing to take such a “proactive step”: that is, they make at least one transfer to their own Bitcoin address between Block 498,777 and Block 501,878 (December 12, 2017, to 12:00 GMT on January 3, 2018).

Only the original address can make the transfer to itself, and the receiving address must be used as one of the sending (input) addresses.

One privacy issue to consider is that in order to “proactively” claim BU tokens, the protocol forces users to reuse their Bitcoin addresses; this action puts privacy at risk and, unless it is done carefully, may link many of the users’ coins together.

https://twitter.com/jmcorgan/status/940981451402764289

User privacy protection is not the only part of the protocol that is drawing criticism, however.

“The code contains a god mode; it’s literally called that,” Blockchain developer Sjors Provoost said to Bitcoin Magazine. He said that it appears as if this “god mode” will create a multisignature address that belongs to a (yet-to-be-defined) UnitedBitcoin Foundation.

“Unlike previous airdrops, the initial coin distribution is not determined by a consensus rule,” he added. “This means that even if you were to run the full UB node software (which you should not), you will have no way of knowing for sure how many coins you get. Conversely, if you already had bitcoin, you won’t know how many of ‘your’ coins will be confiscated. You simply have to trust their promise to take and redistribute coins as their marketing promises.”

According to Provoost, the new consensus rule allows the owner of this foundation address to spend any UTXO they want. “These confiscations will be included in holy blocks, which can be created during the first 500 blocks after the fork. This is how they implement the redistribution as I just described, but they can do much more.”

Furthermore, Provoost is concerned about the quality of the code itself. “Garzik’s previous project SegWit2x tried to keep its changes relative to Core to a bare minimum. Although at the time of the planned fork their code base was about a year behind Bitcoin Core, it didn’t introduce many changes,” he pointed out.

“UnitedBitcoin on the other hand has introduced far more changes, making the task of tracking Bitcoin Core far more difficult. It’s not as many changes as Bitcoin Unlimited and Bitcoin Cash, and the problem is somewhat mitigated by them sunsetting the more complicated consensus changes like god mode. However, even the small change in SegWit2x had a widely publicized serious bug in it and there are rumors of more.”

What Happens to Those “Reclaimed” Tokens?

Garzik has plans to “build a better Tether” by using the UB reserve, funded by coins reclaimed from “inactive” addresses. According to the project, 70 percent of confiscated UB coins will be held as collateral to issue stable tokens pegged to a fiat currency.

“The UB reserve can be used as a backing asset for a stable, non-volatile currency,” said Garzik. “This is auditable and transparent and on the blockchain. It will be over-collateralized, 200–300 to maintain the stability even in the face of a volatile price of the reserve.”

The remaining 30 percent of the confiscated coins will support another new feature: owners of QTUM, H-shares and ether will receive a share of the remaining redistributed UB.

UB is experimenting with a new model: engage multiple communities — ETH, Qtum — rather than following the tired model of rewarding Bitcoin maximalists with a coin they dislike and will just dump on day 1.

According to Garzik, the specific claim process for the redistribution of UB has yet to be determined. “The UB board is still being put in place — things are moving very fast — and this will include more specifics on governance and community allocations.”

The scheduled timeline of what has been released and what is coming breaks down as follows:

December 12, 2017:

• Fork of Bitcoin to UnitedBitcoin (at block height #498,777) with support for: Increased block size to 8 MB SegWit support Replay Protection Asset Allocation

January 3, 2018:

• End of Asset Allocation phase #2

• Pegged currency based on color currency

February 28, 2018:

• Launch of smart contract support

April 28, 2018:

• Launch of lightning network support