Polygon ’s Side Of The Story: Hard-Fork Resolved A “Critical Vulnerability”

The Polygon team offered an explanation and here it is. A few weeks ago, the Ethereum Layer 2 network hard-forked their blockchain, seemingly without explanation. As usual, NewsBTC got to the bottom of the case and presented all of the available information. The only piece missing was a promised official report with a detailed explanation from Polygon’s experts. Is this it? Apparently so. 

Related Reading | Community Voted, Why Uniswap Will Be Deployed On Polygon

Before we get into it, let’s remember Polygon’s co-founder Mihailo Bjelic’s explanation as reported by us: 

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

“We’re making an effort to improve security practices across all Polygon projects,” Bjelic tweeted. “As a part of this effort, we are working with multiple security researcher groups, whitehat hackers etc. One of these partners discovered a vulnerability in one of the recently verified contracts. We immediately introduced a fix and coordinated the upgrade with validators/full node operators. No funds were lost. The network is stable.” 

It’s important to remember that the crypto ecosystem was concerned that the way that they managed to do all this seemed centralized. However, the co-founder assured everyone that “The network is run by validators and full node operators, and we have no control over any of these groups. We just did our best to communicate and explain the importance of this upgrade, but ultimately it was up to them to decide whether they will do it or not.”

However, this was Polygon node operator Mikko Ohtamaa’s further complaint:

“Next time it happens can you at least announce a critical update to all Polygon node operators. Now this looks super unprofessional and confusing for the community. It was not mentioned or pinned down in any major channels or publications.”

What Did The Polygon Experts Say?

Considering the infamous Poly Network exploit was merely in August this year, it’s good to hear Polygon is working hard in securing their whole operation. They’ve ”been investing significant effort and resources into creating an ecosystem of security expert partners, with the goal of improving the security and robustness of all Polygon solutions and products.” With that in mind, this is the company’s version of what happened:

Get 110 USDT Futures Bonus for FREE!

“Recently, a group of whitehat hackers on the bug bounty platform Immunefi disclosed a vulnerability in the Polygon PoS genesis contract. The Polygon core team engaged with the group and Immunefi’s expert team and immediately introduced a fix. The validator and full node communities were notified, and they rallied behind the core devs to upgrade the network. The upgrade was executed within 24 hours, at block #22156660, on Dec. 5.”

So far, so good. This rhymes with Bjelic’s explanation and gives the community more details. However, we know that they barely notified the validators and node operators. They don’t even have to lie about it, because they do have a great explanation as to why they ran the whole operation in stealth mode.

“Considering the nature of this upgrade, it had to be executed without disclosing the actual vulnerability and without attracting too much attention. We are still finalizing our vulnerability disclosure policy and procedures, and for now we are trying to follow the “silent patches” policy introduced and used by the Geth team.”

According to Ohtamaa, “there are multiple open source projects out there” that have done similar operations in a more effective manner. And that might be true, but it doesn’t take from the fact that Polygon’s actions were justified.  

MATICUSD price chart - TradingView

MATIC price chart on Binance | Source: MATIC/USD on TradingView.com

The Aftermath

In the end, the critical update worked out fine enough:

“The vulnerability was fixed and damage was mitigated, with there being no material harm to the protocol and its end-users. All Polygon contracts and node implementations remain fully open source.”

Related Reading | Polygon Opens Vault On MakerDAO, Commits $50 Million Worth Of Matic Tokens

Remember, one of the early criticism was that they forked the Polygon blockchain “to a completely closed-source genesis.” Here, the official source assures that “contracts and node implementations remain fully open source.” Is there something else they want to tell us?

“We are still working on closing the final proceedings with Immunefi and the whitehat hacker group, primarily in terms of their rewards and multiple rounds of reviews of the fixed vulnerability. We will post a detailed postmortem once this process is finished, likely by the end of next week.”

The team will publish yet another post with even more details for the technically oriented people. That’s above our pay grade. Stay tuned to Polygon’s blog if you’re interested.  

Featured Image by Diana Polekhina on Unsplash - Charts by TradingView


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.  



Tagged : / / / / / / / / /

Why Open Source Matters for Bitcoin

Listen To This Episode:

In this episode of “The Van Wirdum Sjorsnado,” hosts Aaron van Wirdum and Sjors Provoost discussed why it matters that Bitcoin software is open source and why even open-source software doesn’t necessarily solve all software-specific trust issues.

In theory, the fact that most Bitcoin nodes, wallets and applications are open source should ensure that developers can’t include malicious code in the programs: anyone can inspect the source code for malware. In practice, however, the number of people with enough expertise to do this is limited, while the reliance of some Bitcoin projects on external code libraries (“dependencies”) makes it even harder.

Furthermore, even if the open-source code is sound, this doesn’t guarantee that the binaries (computer code) really correspond with the open-source code. Van Wirdum and Provoost explain how this risk is largely mitigated in Bitcoin through a process called Gitian building, where several Bitcoin Core developers sign the binaries if, and only if, they all produced the exact same binaries from the same source code. This requires special compiler software.

See Also

Check out our video walkthrough on Unchained Capital’s Caravan tool for utilizing multisig bitcoin wallet security.

Finally, the hosts discuss Guix, a relatively new project that goes above and beyond the Gitian process to minimize the level of trust required to turn source code into binaries — including trust in the compiler itself.


Tagged : / / / / / / / / / /
Bitcoin (BTC) $ 41,502.12 5.06%
Ethereum (ETH) $ 2,250.05 3.87%
Litecoin (LTC) $ 73.82 2.47%
Bitcoin Cash (BCH) $ 250.21 9.70%