Lightning Speed: Taproot And The Lightning Network, A Match Made In Heaven

A little more than two months ago, Taproot went live. What does the biggest update to the Bitcoin network in years bring to the table? How can it help the increasingly popular Lightning Network? That’s exactly what the article we’re about to summarize is about. It starts by informing us that “Bitcoin even has a scripting language,” and that it’s called Script.

Related Reading | Number Of Bitcoin Lightning Network Nodes Jumps 23% In Three Months

But before we get into that, what is Taproot?

5 BTC + 300 Free Spins for new players & 15 BTC + 35.000 Free Spins every month, only at mBitcasino. Play Now!

“Taproot is a combination of three Bitcoin Improvement Proposals (BIPs) that enhance this scripting infrastructure: BIP340 – Schnorr, BIP341- Taproot and BIP342 – Tapscript. The key of Taproot that unlocks all the others is the introduction of Schnorr Signatures, which allow for key and signature aggregation. This means that multiple parties are able combine their keys to a single public key, thereby allowing them to sign a single message.”

It’s important to know that Taproot won’t allow “fully expressive” or “Turing complete” contracts like in Ethereum and all its related chains. Nor are those kinds of contracts a priority for the Bitcoin network, as our sister site Bitcoinist points out. Also, to curb our expectations, let’s read what Tales From The Crypt podcast’s host Marty Bent warned us about in his newsletter:

“It is important to understand that these benefits aren’t going to be immediate. They are going to come to market slowly over time as the software gets implemented into wallets and other services. Many are expecting Taproot to get activated over the weekend and all its potential benefits to be realized immediately. This is simply not the case and it is important that this fact is understood.”

Ok, let’s get into the meat and potatoes.

How Does Taproot Help The Lightning Network?

First of all, every Lightning channel consists of “2 of 2 multisigs”. So, a first benefit of being “able combine their keys to a single public key” is that “we have lighter transactions and therefore cheaper channel openings”. Not only that but “signature aggregation also offers enhanced privacy since its contents are indistinguishable from a single-signature transaction.”

Get 110 USDT Futures Bonus for FREE!

To clear up how does this benefit privacy, let’s quote the Binance Academy:

“Spending Bitcoin using Taproot could make a transaction in a Lightning Network channel, a peer-to-peer transaction, or a sophisticated smart contract become indistinguishable. Anyone monitoring one of these transactions would see nothing but a peer-to-peer transaction. It’s worth noting, though, that this doesn’t change the fact that the wallets of the initial sender and final recipient will be exposed.”

However, this is not quite true… yet. The Voltage article clarifies, “Does this mean that lightning channels are now unidentifiable on the blockchain? Well, the answer is ‘yes’ for private channels and ‘not quite yet’ for public channels.”

BTCUSD price chart for 01/04/2021 - TradingView

BTC price chart for 01/04/2021 on Gemini | Source: BTC/USD on TradingView.com

Private And Public Lightning Network Channels

What’s the problem? Well, the network doesn’t announce the creation of private channels. The public ones, on the other hand:

“Unfortunately, even if we do hide the channel openings on the blockchain, the current specification of the lightning protocol requires nodes to broadcast the details of the funding transactions when announcing their channels.

This might seem counterintuitive at first, but it’s also an elegant way to prevent nodes spamming the network with fake channels.”

Related Reading | How Big Is Bitcoin’s Lightning Network? The Answer Will Surprise You

Also, let’s take into account that surveillance firm Chainalysis already announced a Lightning Network-related service. We should assume there are “sybil nodes surveilling the network”. And that “With enough hostile nodes” a bad actor could paint “a fairly detailed picture of the flow of funds”. Well, Taproot has an elegant solution for that:

“Taproot’s introduction of Schnorr signatures paves the way for a type of smart contract called Point Time Locked Contracts (PTLCs). PTLCs operate in the same manner as HTLCs by allowing payments to be identified by nodes, but PTLCs come with a handy feature of being able to randomize its identifier with each hop thereby making it impossible for nodes to correlate the traffic of sending and receiving nodes.”

Understand that “Taproot is a door that opens many other doors”. It’s a new toolkit with which developers all over the world will create new features and improvements. The info this article contains is just the beginning, the low-hanging fruit that we can see from our advantage point. Remember what Marty Bent said, “these benefits aren’t going to be immediate.” The Taproot-enabled stage of Bitcoin is just starting.

Featured Image by Cooper Baumgartner on Unsplash  | Charts by TradingView

Source

Tagged : / / / / / / / / / / / / / / / / /

Taproot Update: Bitcoin Users Home In on Activation Plan, Date Still TBD

Many of Bitcoin’s most active stakeholders have just about nailed down the activation method for Taproot, the Bitcoin software’s biggest upgrade in years.

In a public meeting on Internet Relay Chat (IRC) Tuesday, Bitcoin developers, miners, business professionals and enthusiasts hashed out the specifics of how to package the Taproot upgrade into an update – and how to activate it once the code has been shipped.

The most active of the 200 or so participants on the chat (mostly, but not all, developers) seemed to agree on the Bitcoin Improvement Proposal (BIP) that would be used to activate Taproot. To prep the BIP for shipment, they also voted to “merge” two “pull requests” (PRs) on GitHub that outline the rules for Taproot’s activation logic into Bitcoin’s source code when the time comes to push the upgrade.


One of these, PR #1021, includes a measure to allow users force activate the upgrade should miners not support it, while PR #1020 only “recommends” this forcing but does not enable it by default. Since most all participants support BIP 8 without forced activation, as meeting leader and Bitcoin Core developer Michael Folkson noted in the chat, further discussion will pinpoint a date to begin activation – and further discuss the extent to which a “flag day” to force activation is necessary.

Why a Taproot flag day (probably) isn’t needed

Not that miners blocking the upgrade should be an issue for Taproot, which has some 91% miner support, according to a survey run by F2Pool VP Alejandro De La Torre.


The survey provides crucial feedback from miners for Bitcoin’s decentralized organization, which cannot unilaterally coordinate updates the way a centralized software provider can. Upgrades like Taproot require painstaking coordination between miners, full-node users (those running Bitcoin’s open-source code) and other stakeholders to ensure nothing goes wrong (like introducing a bug or splitting the Bitcoin network into two incompatible versions).


Because miners have shown no resistance to Taproot, most participants voiced a preference for BIP8 (false), with the (false) referring to the exclusion of a “flag day” to force activation through full nodes should the upgrade fail through lack of miner activation. 

BIP8 as currently devised would give Bitcoin miners and full-node operators a year to adopt the upgrade, after which point the upgrade would be “locked in” with enough support. In one version of this, BIP8 (false), the update simply fails without enough support. In another, BIP8 (true), a “flag day” would force miners to signal for the upgrade when the activation time frame expires if they did not do so beforehand.


Technical note: There are a few ways to upgrade Bitcoin, the easiest being through miner activation where mining pools upgrade and begin mining blocks under the new rules. Failing this, node operators can upgrade and choose to reject blocks from miners who have not signaled support for an upgrade. This so-called “user activate soft fork” (UASF), also used to activate SegWit, would force holdout miners to adopt the new upgrade.

“Completely anecdotal but I’ve not seen any [emphasis theirs] opposition to Taproot,” one willcl_ark said in the chat, referring to whether or not a flag day is necessary. “I think using the lowest common denominator of activation parameters (false) seems like the sensible choice to avoid any purposeful or accidental chain splits in the case miners don’t signal.”

What’s the holdup?

Still others, like prolific Bitcoin Core developer Luke Dashjr, are not convinced the inclusion of a flag day is unnecessary. In fact, it’s a matter of principle to demonstrate that node operators decide software, not miners.

“It doesn’t matter,” he said in the chat in reference to miner support. “Miners do not decide protocol changes,” he continued, intimating that it’s the node operators who decide instead by choosing what software to run. Further, he espoused that BIP8 (false), “let[s] miners decide” the fate of the upgrade. When the time comes, he said later in the chat, he will configure his node to run the BIP8 (true) version that rejects non-Taproot blocks from miners.

“BIP8 with mandatory [activation] is not an unnecessary show of force,” said hsjoberg, reiterating Dashjr’s belief that the user-choice of a UASF is a necessary check and balance on miner apathy.


Still, a show of force could introduce unnecessary risk and set an unwelcome precedent for future upgrade deliberations, especially when miners have given users no reason to be combative, so go the arguments in favor of BIP8 (false). 

“[BIP8 false] is safer than [true], so it’s worth doing [false] first given that we know hashpower is ~90% already pro-Taproot,” Bitcoin Core and CoinSwap developer Chris Belcher said.


Others like Suredbits and Bitcoin Core developer Ben Carman pointed out that you could configure the upgrade later on into activation to include the flag day should miners fail to signal, “making it safer and easy for users to enforce the UASF.”

At the end of the meeting, the participants agreed to merge pull requests on GitHub for both a non-forced activation route (PR #1020) and a forced activation route (PR #1021). With both of these rules in Bitcoin Core’s GitHub, the rules for a forced activation could be used only if necessary.

More deliberation

The chain split scenario that willcl_ark described is basically the bogeyman everyone wants to avoid here. The fear is that BIP8 (true) requires 100% of hashrate to signal for the upgrade after the Taproot activation deadline ends. Thus, if enough users went this route at the same time that others use BIP8 (false) for non-forced activation (which only requires 95% of hashrate), the two different code versions may create two incompatible histories of Bitcoin’s transaction ledger.

That’s why, if forced signalling must happen at all, it’s best to do so through AJ Townes’ PR #1021, which “makes it safer for the UASF option which is the most ‘dangerous’ scenario,” Carman wrote in the chat.

For now it seems as if those involved in discussions favor BIP8 (false) with the addition of a UASF through PR #1021 if needed, but further discussion is needed to hammer out the exact timeline of the initial activation period (or how long users have to upgrade after the update goes live), as well as what activation date to set.

These “what ifs” and “whens” will be hashed out, among other matters, in a meeting next Wednesday.  



Disclosure

Source

Tagged : / / / / / / / / /
Bitcoin (BTC) $ 27,757.44 1.59%
Ethereum (ETH) $ 1,896.24 1.09%
Litecoin (LTC) $ 91.09 0.33%
Bitcoin Cash (BCH) $ 114.58 1.49%