Crypto News Updates

Taproot Locks In: Bitcoin Protocol Upgrade Will Activate In November

Taproot has locked in with the Bitcoin protocol upgrade now set to activate in November.

Bitcoin is upgrading.

Taproot, the Bitcoin protocol upgrade that makes smart contracts more private and compact, has locked in. As of just now, more than 90 percent of all blocks that will be mined in the current difficulty period have signaled support for the upgrade, which means that Bitcoin Core versions 0.21.1 and newer will start enforcing the new rules in November of this year, as will the alternative Taproot activation client.


Taproot is the first Bitcoin protocol upgrade to go live since Segregated Witness activated in 2017. First proposed by former Blockstream CTO Gregory Maxwell and developed by Bitcoin Core contributors including Pieter Wuille, Anthony Towns, Johnson Lau, Jonas Nick, Andrew Poelstra, Tim Ruffing, Rusty Russell and Maxwell himself, Taproot will make Bitcoin’s smart contract features more compact, potentially more private, and in some cases a bit more flexible. As a soft fork, the upgrade is backwards compatible as long as a majority of miners enforce the new rules.

Taproot really consists of two big upgrades rolled into one. The first is the introduction of Schnorr signatures. Many cryptographers consider the Schnorr signature scheme to be the best in the field, as its mathematical properties offer a strong level of correctness, it doesn’t suffer from malleability and it is relatively fast to verify. The most notable benefit in the context of Bitcoin, however, is that Schnorr’s “linear math” enables a new class of smart contracts, where tweaks to a signature can be used to embed various spending conditions.

This tweaking of signatures is used for the second part of the upgrade, which is the part that’s really called Taproot itself. Leveraging cryptographic tricks like Merkle trees, Taproot lets users cryptographically combine several spending conditions in a single output (simplified, in a single “address”). The funds in this address can be spent in multiple ways, for example by different people depending on which other conditions are met.

To a large extent this is already possible on Bitcoin, but Taproot lets these different people cooperate to make the transaction that spends the funds indistinguishable from regular (single user) transactions. This is more efficient because not all potential spending conditions need to be revealed when the funds are spent (translating into lower fees), and it is more private because such transactions better blend in with other transactions. (As a notable example, Lightning channel closing transactions can be made to look like regular payments.)

Taproot Activation

Activating upgrades on the Bitcoin network has in the past sometimes proven difficult. The Segregated Witness activation process, in particular, turned into a bit of a battleground, where (some) miners refused to activate the upgrade, until (some) users presented them with a somewhat controversial ultimatum in the form of a user activated soft fork (UASF), defined in BIP148.

For some time, this controversy appeared to carry through into the discussion around Taproot activation. Some developers and users argued that a similar UASF-style activation should be built into the activation mechanism from the start, while other developers and users objected to such a solution as they considered it too risky and/or aggressive.

A compromise was ultimately found between the two main camps in the form of “Speedy Trial” (although some proponents of a built-in UASF did still release their own client). The Speedy Trial activation mechanism would give miners three months to signal support for the Taproot upgrade. If miners would signal support for the upgrade in 90% of all blocks within a single two-week difficulty period (1,815 or more blocks out of 2,016), Taproot would activate on block 709,632, estimated to be mined this November.

The 1,815th signaling block of this two-week difficulty period (the third difficulty period since Speedy Trial’s signaling period started) was just mined. This means that the Bitcoin ecosystem — users, miners, businesses, projects — have about five months to get ready for the upgrade, by upgrading to compatible software, or perhaps by taking alternative security precautions.

Since Taproot is a soft fork upgrade and miners have indicated that they are ready for the upgrade, even non-upgraded software should remain compatible with the Taproot rules, however; this non-upgraded software just won’t enforce or benefit from these new rules.

For more information on what Taproot is exactly, also see this explainer.

Source: Bitcoin magazine

Crypto News Updates

LOT=true Or LOT=false? This Is The Last Hurdle Before Taproot Activation

The discussion on Taproot activation appears to have reached its final stage, with the remaining decision revolving around the activation parameter LOT.

The code for Taproot, a proposed Bitcoin protocol upgrade for compact and privacy-preserving smart contracts, has been included in the most recent version of Bitcoin Core, currently the de-facto reference implementation for the Bitcoin protocol. The only remaining step is for the upgrade to activate on the Bitcoin network.

But as a consensus system without central authority, Bitcoin protocol upgrades can be challenging. If one segment of the network upgrades to a new version of the protocol before another segment does, different nodes might enforce different rules, introducing the risk that the network fractures between them.

A soft fork upgrade, which Taproot is, is backwards compatible to minimize this risk. As long as a majority of miners (by hash power) enforce the new rules, both upgraded and non-upgraded nodes accept their version of the blockchain: upgraded nodes because the new rules are properly enforced, and non-upgraded nodes because none of the legacy rules are being broken.

Several of Bitcoin’s previous soft forks have therefore been deployed by leveraging hash power as a coordination mechanism, which is referred to as a miner activated soft fork, or MASF. Once (usually) 95 percent of newly mined blocks included a bit that signaled readiness, all upgraded nodes would start enforcing the new rules. If this threshold wouldn’t be met within (usually) a year, the upgrade would instead expire.

In 2017, the Segregated Witness (SegWit) MASF got close to expiring; in the midst of a heated scaling debate, miners refused to signal readiness for the upgrade. In response, a grassroots group of users and some developers released a special Bitcoin software client: the BIP 148 client. The BIP 148 client would activate SegWit on a given date even if there was insufficient hash power support to meet the original 95 percent threshold, an upgrade mechanism referred to as a user activated soft fork, or UASF. Right before the SegWit UASF would activate, miners started signaling readiness.

Now, about four years later, the events around SegWit activation have spurred a new discussion on soft fork activation in the context of the Taproot upgrade. This discussion is in a small part about the hash power threshold and duration of the activation period — but these seem to have mostly settled on 90 percent and one year, respectively. (Which the remainder of this article will also assume.)

The last remaining point of contention is about the lock-in on timeout (LOT) parameter, which can be set on either “true” (LOT=true) or “false” (LOT=false).

What Are LOT=true And LOT=false?

The mechanics of both the LOT=true and LOT=false options are straightforward. In either case, miners have a year to activate Taproot through hash power signaling. If within that year 90 percent of hash power signals support for the upgrade, Taproot-ready nodes will start enforcing the new rules.

The difference lies in what happens if, when the year is up, miners have not signaled for activation.

In the case of LOT=false, the activation simply expires, like a regular MASF. At that point, Taproot would not have activated, and nodes continue to use the current Bitcoin protocol without Taproot. A new activation period could then be scheduled, this time presumably using LOT=true.

In the case of LOT=true, the activation wouldn’t expire. Instead, like a UASF, nodes in the final weeks of the activation period start rejecting blocks that don’t signal for Taproot activation. When only blocks that signal readiness for Taproot are accepted, the activation threshold will necessarily be reached, assuming of course that Taproot-signaling blocks are mined at all. (There is actually a little bit more nuance to this process, because a small number of non-signaling blocks would still be allowed, but that’s a technical detail and not very important in the context of this article.)

The main argument in favor of LOT=true, is that LOT=false would give miners a “veto” on the upgrade. They could block Taproot activation by refusing to signal readiness, even when there is broad consensus for the upgrade. During the SegWit activation period, it appeared that this veto was being leveraged by miners in an attempt to influence Bitcoin protocol development.

LOT=false proponents, however, argue that this veto isn’t really a veto at all, since it can be overruled. In the end, miners cannot block Taproot activation, because users can always upgrade to LOT=true clients, even if they initially used LOT=false. This can be done in two main ways. Either, users switch to LOT=true clients before the activation period is over, that is, before the end of the year. Or, as already mentioned, they can wait until the activation period is over, and schedule a new activation period.

Proponents of LOT=true however point out that these two different options to overrule the veto could be another recipe for community conflict. If, say, six months into the activation period miners haven’t signaled support for the upgrade, one segment of users may prefer to deploy LOT=true clients before the year is over, while another segment may prefer to wait until after the first activation period before deploying a new activation mechanism. This would essentially reintroduce the current debate between LOT=false and LOT=true, but this time with only six months to resolve the issue. This is easily avoided, LOT=true proponents figure, by simply not giving miners a (sort of) veto in the first place.

But there are arguments in favor of LOT=false and against LOT=true as well.

For one, LOT=false more closely resembles the activation mechanics of previous soft forks, most of which rolled out fairly well. While the SegWit upgrade wasn’t as smooth, LOT=false proponents argue this was due to exceptional circumstances of the “scaling wars,” which are now behind us. (Some LOT=true proponents however believe that LOT=false might invite such circumstances again.)

Second, given that most mining pools have indicated support for the Taproot upgrade, LOT=false is likely to do the job without it ever coming to a timeout scenario. This makes LOT=true unnecessary. (LOT=true proponents instead argue that stated intentions shouldn’t be a factor in designing a technical upgrade mechanism, and that LOT=true would best align incentives to ensure that miners indeed upgrade before the end of the year.)

Third, in the unlikely scenario that a problem with Taproot is found, LOT=false makes it easy to back out of the upgrade: miners would simply refrain from signaling readiness, and the proposal would expire without requiring users to upgrade their software again. (LOT=true proponents believe Taproot is well reviewed, and shouldn’t be up for activation in the first place if that weren’t the case. And even if a problem is found after all, it should be relatively easy to defuse Taproot activation through technical means.)

Fourth, LOT=true could feed into the perception that Bitcoin Core developers have the power to change the Bitcoin protocol. Since LOT=true would “guarantee” Taproot activation, their code would “force” this change of the protocol rules. This perception could attract unwanted attention towards developers.

This perception would be mostly false, as also pointed out by proponents of LOT=true. In the end, users would need to voluntarily choose to adopt the new Bitcoin Core software. Developers can ship code, but they can’t make users run it. Most LOT=false proponents agree, but argue that the perception of developer power might be there regardless, and that perception alone may be harmful enough — even if wrong.

But probably most importantly, the fifth argument for LOT=false and against LOT=true is that LOT=true could in some scenarios result in an unstable network and perhaps even a split in the blockchain. This could lead to a loss of funds for users and miners, and undermine trust in the Bitcoin project altogether.

LOT=true proponents, however, argue that it’s the other way around, and LOT=false in Bitcoin Core would represent the greater risk of this scenario unfolding.

To understand this discrepancy, let’s look at some scenarios…

What If There Is No Network Consensus On LOT?

If there is consensus on either LOT=true or LOT=false — that is, all nodes on the network use one or the other — the scenarios are straightforward. In either case, Taproot would probably activate during the activation period. If not, the upgrade would activate by the end of the year in the case of LOT=true, and miners would have little choice but to accept this (else they’d mine blocks that the network rejects, and they’d be wasting their hash power). Or, in the case of LOT=false, the proposal would expire, and a new activation period would be deployed, this time presumably using LOT=true. (Unless consensus already shifted to LOT=true before the end of the activation period, in which case Taproot would also activate before the year is over.)

It becomes more complex if there is no consensus on either LOT=true or LOT=false. In the unlikely event that the activation period expires, and one segment of the network runs LOT=true clients while another segment runs LOT=false clients, it comes down to the support for each option. (We’ll ignore a third, but important segment for now: users that run neither LOT=true or LOT=false… more on this group in a bit.)

The first thing to note is that if any majority of miners (by hash power) signals support and uses LOT=true, Taproot is guaranteed to upgrade. These miners would by the end of the activation period start rejecting blocks that don’t signal readiness, and since they’d produce a longer blockchain than the minority of non-signaling miners, and because both LOT=true and LOT=false clients would accept this chain as valid, everyone would accept this Taproot-signaling blockchain and activate the upgrade. In other words, the hash power activation threshold would in the last weeks effectively drop from 90 percent to 51 percent.

But if less than half of all miners use LOT=true and the signaling period expires, the Bitcoin blockchain could “split” between LOT=true and LOT=false nodes. LOT=true nodes would only accept signaling blocks, even if non-signaling blocks make a longer blockchain. They would essentially be on their own “LOT=true chain.” LOT=false nodes, meanwhile, would reject the LOT-true chain in favor of the longer “LOT=false chain.”

The result would be a blockchain fork, and ultimately perhaps two different blockchains, each with their “own” transaction history, and essentially their own coins, potentially with their own exchange rates: a “coin split.” Users of either blockchain might consider their own version the “real Bitcoin.”

Barring further protocol changes on the LOT=false chain, however, the LOT=true chain would in this case have a strong game-theoretic advantage. LOT=true nodes and miners would never accept the LOT=false chain, no matter how much longer it were to become. In a “worst case” scenario, it would remain a minority coin.

LOT=false nodes, in contrast, would accept the LOT=true chain if it ever became the longer chain. They’d then abandon “their own” LOT=false chain, and lose any coins they received or mined on it since the split. In short: LOT=false nodes and miners would risk losing money. Therefore, they’d have a strong incentive to just join the LOT=true chain before this can happen. (Especially since they, presumably, don’t object to the Taproot upgrade itself.)

The incentive to join the LOT=true chain would be particularly strong if most users prefer the LOT=true chain, or more accurately, if this chain would have the “economic majority.” If most of the Bitcoin economy prefers to accept and hold coins on a hypothetical LOT=true chain, these coins should demand a higher price and more transaction fees, which would draw in the most miners. This would in turn ensure that the LOT=true chain becomes the longest and therefore only chain.

Here’s the rub. The incentive to join the LOT=true chain before a potential split to be on the “safe side,” would only have an effect if users and miners are aware of what’s going on to begin with. Anyone who assumed that LOT=false would be the upgrade mechanism and therefore didn’t switch, could still lose money if and when a split occurs and the LOT=false chain is abandoned afterwards.

The same is true for the third segment of users, the segment we ignored so far but is actually important to take into consideration: users that run neither LOT=true or LOT=false. These could for example be users that, for whatever reason, don’t keep up with Bitcoin’s upgrade process at all. Like LOT=false users in this scenario, these unsuspecting users could lose money, arguably through no fault of their own.

LOT=false proponents argue that LOT=true essentially “forces” other users to upgrade, which they consider undesirable, if not downright unethical. LOT=false proponents therefore believe LOT=true should only be used as a last resort, if a MASF fails.

LOT=true proponents counter this by positing that the best way to avoid such damage is to deploy LOT=true in a Bitcoin Core release. They believe some segment of users will run a LOT=true client even if it’s not included in Bitcoin Core, and while this may be a small group, it might be big enough to cause a chain split, and the outcome could be ugly.

Implementing LOT=true in Bitcoin Core would therefore be safer, they argue. Since it’s the most widely used Bitcoin implementation on the network, a Bitcoin Core release with LOT=true would likely guarantee that the economic majority uses LOT=true, ensuring that incentives for miners to activate Taproot would be too strong to ignore, minimizing the risk of a coin-split scenario.

So What Will Actually Happen?

It’s impossible to predict how the discussion around LOT=true and LOT=false will resolve — if it will resolve at all.

As a general principle, the Bitcoin Core development process is guided by rough consensus; contentious code shouldn’t make it into a new release. This is of course very true for protocol upgrades like Taproot, but it is probably equally true for code that activates protocol upgrades. While there appears to be rough consensus for Taproot itself, so far there is no rough consensus for an upgrade mechanism.

Perhaps consensus eventually settles on either LOT=true or LOT=false (or perhaps some other solution, like a configurable option for users to choose between the two). But as long as no rough consensus emerges for either, it’s possible that neither option will be included in Bitcoin Core. The Taproot upgrade would effectively be put on hold, at least temporarily.

Another possibility is that consensus emerges to include LOT=false in Bitcoin Core after all, but only because LOT=true proponents independently release an alternative client with LOT=true. This would resemble how SegWit was activated, with the BIP 148 client serving as the equivalent of a LOT=true client. This would however open the door to some of the coin-split risks described in this article.

It’s also possible (but probably less likely) that neither LOT=true or LOT=false is adopted by Bitcoin Core, but either or both options are included in alternative clients. If enough users switch to such alternative clients — even if these are LOT=false clients — Taproot could activate without Bitcoin Core’s involvement. Bitcoin Core could then release a Taproot-compatible version of its software once the rest of the network has upgraded. (This is similar to how some alternative Bitcoin clients, like Libbitcoin, have historically adopted protocol upgrades.)

Or perhaps, a new possibility will present itself.

Author’s note: Some of the arguments and scenarios described in the article are simplified for the sake of readability. In the event of a chain-split, more factors could affect the outcome, while a lack of consensus on LOT=true or LOT=false could also result in smaller (but still harmful) disturbances than the ones described.

To keep up with the Taproot activation process, the bitcoin-dev mailing list and the #taproot-activation channel on Freenode (IRC) are currently the most relevant discussion channels.

The post LOT=true Or LOT=false? This Is The Last Hurdle Before Taproot Activation appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Bitcoin Core 0.21.0 Released: What’s New

Today marks the official release of Bitcoin Core 0.21.0, the 21st major release of Bitcoin’s original software client launched by Satoshi Nakamoto about 12 years ago. 

Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by well over a hundred contributors in a span of about six months. The result of over 600 merged pull requests, Bitcoin Core 0.21.0 is one of the biggest Bitcoin Core releases in recent years, introducing various new features as well as privacy and performance improvements, while taking a big step towards the Schnorr/Taproot protocol upgrade.

Below are some of the more notable changes.

Descriptor Wallets

When coins are sent to a Bitcoin address, what actually happens under the hood is that they are “locked up” in an unspent transaction output (UTXO), to only be “unlocked” (spent) in a later transaction if the conditions hidden in the UTXO are met. A typical condition is the inclusion of a valid signature corresponding to a specific public key. But conditions can for example also consist of the inclusion of a secret code, the lapse of a timelock or a combination of signatures (multisig).

Until now, Bitcoin Core was designed to manage the UTXOs in its wallet around their corresponding private keys — even though private keys are just one of several potential conditions for spending coins. Bitcoin Core 0.21.0 instead introduces “descriptor wallets.” Descriptor wallets let users categorize their UTXOs based on the types of conditions that are required to spend them. (For example: one wallet for UTXOs that just require a valid signature, and one wallet for multisig UTXOs.)

Descriptor wallets are especially useful for application developers who design software on top of Bitcoin Core. A particular application can now easily be designed to utilize only a specific type of UTXO, like multisig UTXOs, and ignore any non-multisig UTXOs.

Regular users may also notice a difference now that descriptor wallets are implemented. Perhaps most notably, no default wallet will be created when a new Bitcoin Core node is started up. Instead, a new wallet is only created when a user specifically chooses to do so, allowing them to create only the specifically desired type of wallet. Descriptor wallets also better support Watch Only wallets: wallets that keep track of certain UTXOs even though the node doesn’t have the private keys needed to spend them.

Bitcoin Core users that upgrade to Bitcoin Core 0.21.0 will still be able to use their legacy wallet for now. (Legacy wallets will eventually be deprecated, meaning users will need to migrate their legacy wallet to a descriptor wallet, but this won’t be strictly necessary until a future Bitcoin Core release.)

Serving Compact Block Filters Over The Peer-To-Peer Network

“Light clients” are Bitcoin wallets and applications that don’t download and validate the entire Bitcoin blockchain, but instead only download and validate parts of blocks and transactions that concern them specifically. This is not optimally secure, but is much less resource intensive.

One popular way to do this is with Bloom Filters. In short, Bloom Filters are a cryptographic trick to request relevant data from more or less random peer nodes on the network. Unfortunately, however, it has become clear over the years that Bloom Filters are rather privacy-unfriendly: they essentially reveal all of the user’s addresses to the (more or less random) peer node, which could of course be operated by a privacy-invading snoop.

A newer and much more privacy-preserving alternative to the Bloom Filter solution is called “compact client-side block filtering” (BIP 157/158). Compact client-side block filtering essentially turns the Bloom Filter trick on its head. Instead of light wallets creating filters to send to full nodes, full nodes create filters for each block and send these to light clients on request. Light clients then use these filters to figure out if transactions relevant to them may have been included in a block. If so, the light wallet will fetch the whole block and pick any relevant transaction data out of it. (There will be some false positives; blocks that won’t have relevant transaction data in them even though the filter suggested they might.)

Existing Bitcoin Core releases could already create the filters locally, and make them available through a remote procedure call (RPC) for applications running on top of the node (like wallets). Bitcoin Core 0.21.0 now also includes the option to make these filters available over Bitcoin’s peer-to-peer network on request. This makes it possible to now operate standalone light clients that use bloom filters.

Fewer Rebroadcast Attempts

Besides Bloom Filters, snoops can also break the privacy of Bitcoin users through network analysis. If they can figure out from which node a particular transaction originated, that node’s Bitcoin address(es) can be tied to its IP address, which can in turn be associated with a real-world identity.

Until now, when Bitcoin Core nodes broadcasted a transaction to the Bitcoin network, they’d try to re-broadcast the transaction every fifteen minutes, until the transaction was included in a block. This meant that if these Bitcoin Core nodes were connected to a snooping peer, it would be obvious for the snoop that the Bitcoin Core node trying to re-broadcast a certain transaction every 15 minutes was also the node where that transaction originated.

Bitcoin Core 0.21.0 greatly diminishes the frequency with which it tries to re-broadcast transactions: only once every 12 to 36 hours. Having to re-broadcast less frequently makes it much more likely that the transaction has been confirmed since the initial broadcast, so the node is less likely to have to re-broadcast at all.

In future Bitcoin Core releases, this privacy leak will be fixed entirely. A Bitcoin Core node will then only re-broadcast transactions that should have been confirmed based on its own mempool and fee calculations. Furthermore, it will re-broadcast other transactions as well, not just its own.

Tor V3 Support

Due to a recent upgrade to the privacy-preserving Tor protocol, new V3 (version 3) Tor-addresses are longer than the V2 (version 2) addresses that came before them. V2 addresses are still in use, but will be deprecated in about a year from now.

Deprecation of V2 addresses would have posed a problem for Bitcoin Core users who want to use Bitcoin over the privacy network. Bitcoin Core nodes find peers by sharing with each other Tor addresses of known Tor-using Bitcoin nodes. They shared this through the same message they use to share other nodes’ regular IP addresses. While Tor V2 addresses could be “hidden” in the regular IP address format (IPV6), Tor V3 addresses are too long for that; in other words, the current messages are too limited to be compatible with the Tor upgrade.

Bitcoin Core 0.21.0 therefore introduces a new format to share IP/Tor addresses with peers. These messages can be big enough to share the Tor V3 addresses.

Schnorr/Taproot Code and Signet/Regtest Deployment

Schnorr/Taproot is poised to be Bitcoin’s first protocol upgrade since Segregated Witness (SegWit) in August 2017. Having been in development for well over two years, the Schnorr signature algorithm is considered an all-round improvement over Bitcoin’s current ECDSA signature algorithm. In combination with Taproot — a clever trick to hide various conditions to spend coins in a cryptographic hash tree — the upgrade promises to offer more smart contract flexibility in a scalable and privacy-preserving manner.

The Schnorr/Taproot code is now included in Bitcoin Core 0.21.0. Barring unexpected developments, this means it will not be subject to any more change, which for example means that application developers could start designing software around the upgrade. In addition, Schnorr/Taproot is now available on Signet (a newer and more reliable variant of testnet, used by developers to test new Bitcoin software) and potentially also on Regtests (additional local testnet variants).

Schnorr/Taproot will not, however, be available on Bitcoin’s mainnet just yet. For this, the upgrade will first need to activate, which requires activation logic that isn’t yet included in this Bitcoin Core release. Activation logic is expected to be included in a minor Bitcoin Core release, possibly somewhere in the next months.


On top of the changes above, Bitcoin Core 0.21.0 includes various bug fixes and performance improvements that won’t be as apparent for regular users. The Bitcoin Core wallet will for example switch from using the Berkeley DB to the SQLite database, which is better suited as an application data file and offers several guarantees in regards of compatibility, support and testing. Of interest is also that Bitcoin Core 0.21.0 includes a transaction request overhaul: the new message protocol that Bitcoin nodes use to learn about new transactions is better tested, better specified and easier to maintain and review.

For a more extensive list of upgrades, also see the Bitcoin Core 0.21.0 release notes, or see this blog post by Bitcoin Core contributor Andrew Chow for a more extensive explanation of descriptor wallets (as well as legacy wallets) and SQLite (as well as Berkeley DB).

Thanks to John Newbery for information and feedback.

The post Bitcoin Core 0.21.0 Released: What’s New appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Bitcoin’s 2020 In Tech

Seemingly undisturbed by 2020’s craziness, and largely unfazed by bitcoin’s wild price swings that concluded with new all-time highs in December, Bitcoin’s technical community continues to plow ahead. Bitcoin’s software and the many projects around it were gradually improved throughout the year, as software was optimized, bugs fixed and privacy leaks patched. The bulk of this work, as vital as much of it is, doesn’t attract headlines.

Yet, a bird’s-eye view on Bitcoin’s tech development over the span of a year helps highlight new milestones in Bitcoin’s ongoing technological march forward. In 2020, too, the consistently growing Bitcoin development community introduced a number of useful new features, several particularly important upgrades and some especially notable improvements.

As this volatile year is drawing to a close, these were some of Bitcoin’s most notable technical developments over the past 12 months…

New Privacy Tools With PayJoin And CoinSwap

On Bitcoin’s privacy front, the PayJoin and CoinSwap projects this year represented two promising advancements.

PayJoin, also known as Pay to Endpoint (P2EP), is a trick that lets recipients of a transaction partake in the transaction through a CoinJoin, to basically send funds to themselves while also receiving the actual payment from the real sender. If a snoop, conducting blockchain analysis, were to assume that all coins sent in a transaction belonged to the same person — as they normally would — they’d be wrong. This already benefits the privacy of both sender and receiver, as the snoop would confuse (past) coin ownership between them. Moreover, if enough people use PayJoin, it could render this important heuristic for blockchain analysis useless altogether, in turn benefiting even the privacy of those who didn’t make PayJoin transactions themselves.

Although demo versions of the PayJoin tool had already been implemented for online gambling game Bustabit and the coin mixing software JoinMarket in late 2018, and Samourai Wallet in 2019 released its own — more limited — version under the Cohoots umbrella (with slightly different privacy tradeoffs), PayJoin was this year implemented in several popular Bitcoin projects. This notably included the widely used payment processing software BTCPay in April, allowing BTCPay users to accept PayJoin transactions from compatible wallets. The privacy-focused Wasabi Wallet was the first wallet to offer this compatibility later that same month, while JoinMarket (September), Blue Wallet (October) and Sparrow Wallet (November) followed later in the year.

Meanwhile, Bitcoin developer Chris Belcher set out to realize an implementation of CoinSwap, a privacy technique first proposed in 2013 by Bitcoin Core contributor Gregory Maxwell. CoinSwap leverages Atomic Swaps (the trick that also underpins the Lightning Network) to let users exchange coins without needing to trust one another. Each user would end up with coins that can’t be linked to their own transaction history.

Belcher, one of the world’s foremost experts in Bitcoin privacy, in May published a detailed outline of how the CoinSwap protocol could be implemented to ensure maximum privacy. The proposal would make CoinSwap transactions indistinguishable from other transactions, use splitting techniques to obscure amounts, route payments to frustrate snooping participants and more. A few months later, in June, The Human Rights Foundation announced that its first Bitcoin development grant would go to Belcher and his efforts to realize the project.

Having worked on his implementation for most of the year, Belcher in December announced a “big day for bitcoin privacy and fungibility”: he’d made the first-ever successful CoinSwap transaction on Bitcoin’s test network (testnet).

The Lightning Network Became More Robust With Watchtowers (And More)

The Lightning Network, Bitcoin’s Layer 2 protocol for faster, cheaper and more private payments, continued to improve across the board in 2020. With Lightning implementations LND, Eclair, C-Lightning and — since July — Electrum rolling out a number of new software releases, and a growing number of projects building on top of the protocol, Lightning development was more active than ever. Among the more notable developments, Watchtowers resolved one of the Lightning Network’s remaining weaknesses, resulting in a more robust protocol.

One of the Lightning Network’s tradeoffs is that users need to keep an eye on their payment channels to ensure that payment channel partners aren’t trying to cheat by broadcasting old channel states to claim more funds than attributed to them. Lightning users can step in if a channel partner attempts to cheat, but this does require monitoring of the Bitcoin blockchain, which casual users might not do very regularly.

To decrease the risk that an attempt at cheating is missed, the Lightning protocol allows channel monitoring to be outsourced to impartial observers called Watchtowers. Adding to the first Watchtower software introduced by LND by late 2019, February of this year saw the alpha release of the dedicated Watchtower implementation Eye of Satoshi. Shortly after, the proposed Watchtower protocol specification was updated, while C-Lightning rolled out support for Eye of Satoshi in May. Version 1 of Eye of Satoshi followed in July.

Other notable Lightning developments in 2020 include the continued work on anchor outputs to ensure users can claim funds from a channel unilaterally even when on-chain fees have gone up more than expected since the last payment channel update, Multipath payments which let users make Lightning payments in smaller chunks, the Lightning Network-native messaging application Juggernaut, channel management tool Faraday, the Lightning Loop beta release, but also some newly discovered weaknesses as well as (proposed) solutions, and a lot more more.

After Miniscript, Bitcoin Programming Was Made Easier With Minsc

The code embedded in Bitcoin transactions that specifies what conditions must be met to spend the coins in a next transaction is written in a programming language specifically designed for Bitcoin, called Script. Script can be tricky to work with, however: in programmers jargon, Script is hard to “reason about.” This means that, especially as it becomes a bit more complex, it can be difficult to understand what a piece of script actually allows: a transaction may unintentionally include code that allows the coins to be spent under different conditions than originally intended. This is one reason why many Bitcoin software applications, like wallets, refrain from utilizing Script’s full potential.

Over the past years, (former) Blockstream researchers Andrew Poelstra, Pieter Wuille and Sanket Kanjalkar designed a “stripped down” version of Script, called Miniscript. Miniscript is a selection of “tools” from the “Script toolkit” that are carefully selected to enable practically anything that can be done with Script, but it’s easier to use and easier to verify by programmers. So, while a line of Miniscript is still a valid line of Script, it essentially avoids human error by preventing unexpected, perhaps unintended, outcomes of the code; Miniscript is easier to reason about. In November of this year, Head of Research and Development at Rugged Bytes Dmitry Petukhov published a formal specification of Miniscript.

To make creating Bitcoin transactions even easier, Wuille had also designed a “policy language” for Miniscript, a programming language of its own that could compile (convert) into Miniscript, and thus Script. Building on Wuille’s work, Bitcoin developer Nadav Ivgi this year developed another new programming language called Minsc. First announced in July, and followed up with a major upgrade in November, Minsc is still a work in progress, but is set to greatly simplify the creation of Bitcoin transactions. This could help unlock a range of promising features that take full advantage of Bitcoin’s versatility, like interoperable CoinJoin wallets, smart contract solutions, Layer 2 protocols and more.

Smart Contracts Became Smarter With DLCs

Whenever smart contracts depend on external data — data that doesn’t live on the blockchain — they rely on an external source for that data referred to as an “oracle.” If two users want to bet on the outcome of a sports match, for example, the oracle would have to use the result of the match to settle the bet in favor of whoever made the correct prediction (at least in case of a dispute).

A very basic sports betting setup could consist of a two-of-three multisignature (multisig) address where both players and the oracle all hold one key each, and the oracle is informed of the details of the bet. After the match, the two players could cooperate to send the funds from the multisig to the winner without the oracle’s key. But if the loser refuses to cooperate, the oracle can use its third key to cooperate with the winner to send them the funds from the multisig. This system works, but has two main downsides. One, both players need to trust the oracle not to collude with their opponent. And two, the oracle needs to be informed of the bet and perhaps play an active part in the settlement process: this means players have no privacy from the oracle, while the setup doesn’t scale very well if more than a few players want to bet.

A better solution was in 2017 proposed by MIT Media Lab’s Digital Currency Initiative researcher Thaddeus Dryja: discreet log contracts (DLCs). DLCs use a clever mathematical trick where the oracle publishes a cryptographic signature that corresponds with the outcome of an event. In the example above, the oracle would publish one signature if the first team wins, and a different signature if the other team wins. The trick: the smart contract is designed to let the winning player use the published signature to claim the funds.

In a DLC, the oracle’s involvement with the smart contract is minimized to the publication of a signature; this could, in the sports betting example for instance, be done by an existing news service, as part of its regular broadcast. This also means that the oracle doesn’t need to be informed about the details of the bet, and in fact doesn’t even need to know there was a bet at all. Meanwhile, any number of people can use the signatures to settle their bets with no further involvement from the oracle, greatly benefiting scalability. And while oracle could in theory still collude with someone and broadcast the wrong result, such dishonest behavior would be obvious to anyone and tarnish the oracle’s reputation going forward.

In January of this year, CEO Chris Stewart announced that his company Suredbits, in collaboration with Crypto Garage, had begun work on a specification for DLCs. In February, Suredbits engineer Nadav Kohen followed up with the first working code. And by September, Suredbits and Crypto Garage had developed their software to the point where it could be used: Stewart and Bitcoin developer Nicolas Dorier engaged in Bitcoin’s first-ever DLC to bet on the outcome of the U.S. presidential election. Stewart, who’d bet on Biden, claimed his winnings in December.

Holding Is Getting Safer With Bitcoin Vaults

The long list of exchange hacks and other bitcoin heists are testament to the fact that securely storing private keys continues to be a challenge, especially where many coins are at stake.

But more secure solutions to store coins are in development. Bitcoin vaults — a concept dating back to 2016 — are a type of smart contract that secure coins so that it takes several confirmed transactions and a time delay to really spend them. This gives potential victims the opportunity to revert a heist before it is too late.

2020 saw the release of two types of vault prototypes.

The first vault prototype was announced by Bitcoin Core contributor Bryan Bishop in April. In short, Bishop’s design is based on a pre-signed (and not-yet-broadcast) transaction that spends (some of) the coins from the vault to a user’s regular (“hot”) wallet with a time-lock delay, while an alternative spending option without a timelock can redirect the coins to an alternative address; perhaps a new and even more secure vault. Importantly, the private key used to sign the pre-signed transactions is deleted when the vault is created, so an attacker could only ever steal the pre-signed transaction itself.

The setup makes it exceedingly difficult for an attacker to claim the coins. Even if the pre-signed transaction is stolen, the thief could merely spend the coins to the hot wallet, and if the victim doesn’t trust the security of his hot wallet he can use the baked-in time delay to move the coins to the extra-secure address instead. (To prevent the thief from stealing the coins by simply compromising the hot wallet and waiting patiently until the vault user sends his coins there, Bishop’s design only lets users withdraw from the vault in small chunks at the time.)

A little later in April, Bitcoin developer Antoine Poinsot announced an alternative Vault demo which he designed with Chainsmiths CEO Kevin Loaec, called Revault. Revault resembles Bishop’s Vaults in some ways, like its use of pre-signed transactions, but is specifically designed for multi-user setups, using a multisig address. Revault lets a predetermined subset of a group of users spend coins from the vault to a hot wallet, also with a time-delay. Any vault participant can use this time-delay to return the funds to the vault if they disagree with the spend, however, or they can redirect the funds to an alternative extra secure address if they don’t trust what’s going on at all.

In addition, Revault requires that upon withdrawing from the vault, when the time-lock kicks in, users immediately create a transaction from the hot wallet, which also requires a server to co-sign. The server is programmed to sign any transaction, but never a conflicting transaction, so if an attacker compromised (both the vault and) the hot wallet, they would have to try and claim the coins before anyone else and before the time-lock expires. This should make it obvious if the hot wallet is compromised, alarming the group of Revault users, and allowing them to redirect the funds before time-lock expiry.

Taproot Is Now Good To Go, As Activation Is Under Consideration

Taproot is set to be the first Bitcoin protocol upgrade since Segregated Witness activated in August 2017. First proposed by Bitcoin Core contributor Gregory Maxwell in January 2018, Taproot lets users “hide” smart contracts in regular-looking Bitcoin transactions: complex multisig construction could be indistinguishable from a simple payment.

The Taproot upgrade would also include the Schnorr Signature algorithm. Many cryptographers consider the Schnorr signature scheme to be the best in the field, as its mathematical properties offer a strong level of correctness, it doesn’t suffer from malleability and is relatively fast to verify. Schnorr’s “linear math” would also allow for a range of new possibilities, like more compact types of multisig solutions, nifty smart contract setups and, of course, Taproot itself.

After continued development throughout 2020, Taproot’s code was merged into the Bitcoin Core codebase in October, and will be part of Bitcoin Core 0.21.0, which is set to be released any day now, with release candidates currently available. Bitcoin Core 0.21.0 will not include activation logic for Taproot, however. This will likely be included in an upcoming minor Bitcoin Core release (probably Bitcoin Core 0.21.1).

The activation logic has itself been a topic of discussion throughout much of 2020, however, with a range of potential activation mechanisms under consideration. Most of these would initially leverage hash power coordination, to eventually reach a deadline where the upgrade activates even without hash power support. But as an October poll published by Bitcoin Core contributor AJ Towns made clear, not all Bitcoin Core contributors agree that the deadline should be pre-programmed, or how far out the deadline should be (as well as some other minor disagreements).

But regardless of which activation mechanism is ultimately chosen, it seems increasingly likely that Taproot can be activated smoothly through hash power coordination. In November, major mining pool Poolin launched an initiative encouraging other mining pools to voice their opinion on Taproot and Taproot activation. The response so far is very favorable of Taproot, with over 90 percent of total hash power in support, and no mining pools opposing the proposed upgrade.

For an even more extensive and detailed summary of Bitcoin’s 2020 tech developments, also see the Bitcoin Optech 2020 Year-in-Review Special.

The post Bitcoin’s 2020 In Tech appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Video: RSK, Federated Sidechains And Powpeg

YouTube Video

Listen To This Episode:

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discuss RSK’s shift from a federated sidechain model to the project’s new Powpeg solution.

RSK is a merge-mined, Ethereum-like Bitcoin sidechain developed by IOVlabs. Bitcoin users can effectively move their coins to this blockchain that operates more like Ethereum, and move the coins back to the Bitcoin blockchain when they so choose. Some Bitcoin miners utilize their hash power to mine bocks on the sidechain, and earn some extra transaction fees by doing so.

The tricky part of any sidechain is allowing users to securely move their coins between blockchains. This is technically done by locking coins on the Bitcoin blockchain and issuing corresponding coins on the sidechain, and vice versa: locking coins on the sidechain to unlock the coins on the Bitcoin blockchain.

So far, RSK has done this by locking the coins into a multisignature address, for which the private keys were controlled by a group of well-known companies (known as a federated sidechain model). A majority of them was needed to unlock the coins, which they were to only do if and when the corresponding sidechain coins were locked.

RSK is now switching to a Powpeg model where the keys to the multisignature address are controlled by special tamper-proof hardware modules that are in turn programmed to only unlock coins on the Bitcoin blockchain if and when the corresponding coins on the sidechain are locked, and the transactions to lock these coins up have a significant number of confirmations.

The hosts explain how this works exactly, and discuss some of Powpeg’s security tradeoffs.

The post Video: RSK, Federated Sidechains And Powpeg appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

RSK Is Evolving; Powpeg Leverages Hash Power To Switch From Bitcoin To Sidechain And Back

RSK, the Ethereum-like sidechain for Bitcoin developed by IOVlabs, is evolving. The federated pegging mechanism, which is based on a Bitcoin multi-signature (multisig) address, is migrating to a system that leverages hash power through RSK’s new special-purpose hardware security modules.

“We’re very excited with this release as it is a big step towards a full decentralized smart contract platform on top of Bitcoin,” IOVlabs Chief Scientist Sergio Demian Lerner told Bitcoin Magazine. “This is something the ecosystem requires.” 

Sidechains And Two-Way Pegs

Bitcoin sidechains are alternative blockchains with tokens that are pegged to bitcoin; one token can always be exchanged for one bitcoin, so their values should be the same. A sidechain can be designed with different protocol rules, however. The RSK sidechain uses many of Ethereum’s rules, enabling for Turing-complete smart contracts.

RSK is merge-mined by a subset of all Bitcoin miners, with a majority of Bitcoin miners (by hash power) currently taking part. They use their existing hash power to produce sidechain blocks, and earn some extra transaction fees by doing so.

RSK tokens, which are called “bitcoin on RSK” or rBTC, are backed one-to-one by actual bitcoin on the Bitcoin blockchain (BTC) by locking bitcoin up in a multisig address on the Bitcoin blockchain to issue an equal amount of rBTC on RSK (“peg-in”). This happens through an RSK smart contract called the “bridge contract” that keeps track of the Bitcoin multisig address. Unlocking the BTC only happens when an equal amount of rBTC is locked by sending it back to the RSK bridge contract (“peg-out”).

A “federation” of renown cryptocurrency businesses are holding the keys to the Bitcoin multisig address. (The original announcement consisted of 24 companies, an unknown subset of which is currently partaking.) They are collectively trusted to only unlock BTC from the multisig when an equivalent amount of rBTC is locked. But technically, they could collude and steal the contents of the multisig address, leaving rBTC holders without the option to exchange their sidechain tokens for real bitcoin.

In the new RSK upgrade, Powpeg, the multisig will be controlled by a larger group of high-profile companies (called “Pegnatories”). Each of the Pegnatories runs a special-purpose hardware security module that holds the signing keys (called “PowHSMs”). These modules will only ever unlock bitcoin from the multisig if the equivalent amount of rBTC is locked by sending them back to the RSK bridge contract, and if this RSK transaction has 4,000 confirmations (which is approximately equivalent to 200 Bitcoin confirmations). The hardware modules make sure that the peg-out transaction has 4,000 RSK confirmations by checking an RSK Simplified Payment Verification (SPV) proof.

Without 4,000 RSK confirmations, or without cooperation from a majority of PowHSM holders, the bitcoin stay in the multisig. (Powpeg is what IOVlabs calls a “vetocracy.”)

“The Powpeg adopts a defense-in-depth approach to security, stacking security layers, such as the Bitcoin hash rate confirmation of peg-outs,” Lerner said. “This allowed us to achieve a unique multisignature vault with transparent and auditable time-delayed access. I believe this is very important because the decentralized financial system must be built on the strongest security foundations.”

The identities of the high-profile companies that will act as Pegnatories will be announced over the coming weeks. After that, additional technologies could be developed to further decentralize the peg, including the capability to permisionlessly introduce competing pegs.


RSK, formerly spelled out as “Rootstock,” was launched in January 2018. The sidechain currently supports all the transaction types and smart contracts that Ethereum supports. This also means that it supports any programming language that can be used for Ethereum, like Solidity, Julia and Vyper.

As decentralized finance (DeFi) solutions where users can borrow, lend and trade coins are becoming popular in the Ethereum community, IOVlabs hopes to bring these use cases to Bitcoin through RSK.


“We believe RSK should be the DeFi platform of choice for bitcoiners. We are committed to the ecosystem spirit and mindset of decentralization and security, and wish to make bitcoin and bitcoin-based financial opportunities available to all”

With Powpeg representing another step toward decentralizing the RSK sidechain, IOVlabs still plans to eventually turn RSK into a drivechain: a sidechain that is completely secured by hash power, for which two Bitcoin Improvement Proposals (BIPs) have been proposed. Instead of a federated system (with or without secure elements), “moving” coins between Bitcoin’s blockchain and the sidechain would be based on hash power alone. Lerner said it would be very easy to update the current RSK design to a drivechain.

For more information on Powpeg, also see this Medium post by Sergio Demian Lerner.

The post RSK Is Evolving; Powpeg Leverages Hash Power To Switch From Bitcoin To Sidechain And Back appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Video: Mempools, Child Pays For Parent and Package Relay

YouTube Video

Listen To This Episode:

In this episode of The Van Wirdum Sjorsnado, hosts Aaron van Wirdum and Sjors Provoost discussed Bitcoin mempools, Child Pays For Parent (CPFP) and package relay.

Package relay is the project that Gloria Zhao will work on as part of her Brink fellowship, which was announced earlier this week, and would make the Lightning Network more robust (among other benefits). Mempools are the collections of unconfirmed transactions stored by nodes, from which they forward transactions to peers. Miners usually select the transactions from their mempools that include the highest fees, to include these in the blocks they mine.

Mempools can get full, however, at which point transactions that pay the lowest fees are ejected. This is actually a problem in context of CPFP, a trick that lets users speed up low-fee transactions by spending the coins from that transactions in a new transaction with a high fee to compensate. Tricks like these can be particularly important in the context of time-sensitive protocols like the Lightning Network.

In this episode, van Wirdum and Provoost explained how package relay could enable CPFP, even in cases where low-fee transactions are dropped from mempools, by bundling transactions into packets. And they explore why this may be easier said than done.

The post Video: Mempools, Child Pays For Parent and Package Relay appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Gloria Zhao And Brink Are Set To Give Bitcoin Mempools An Upgrade

Brink, the new nonprofit founded by John Newbery and Mike Schmidt to train and support Bitcoin developers, today announced Gloria Zhao as its first fellow. After graduating from Berkeley with a degree in computer science this month, Zhao will familiarize herself with contributing to Bitcoin Core and related open-source projects under mentorship of Newbery. Her year-long fellowship is funded by donations from Square Crypto and the Human Rights Foundation.

“I want to be a serious and long-term Bitcoin Core developer, which I don’t imagine is an extremely rare interest or anything, but there are a ton of technical and psychological barriers to overcome,” Zhao told Bitcoin Magazine. “Having a supportive community has been extremely important in my personal journey and, in general, John’s demonstrated a strong interest and ability to foster new contributors into long-term contributors. My main reason for joining the Brink fellowship instead of grants is the mentorship he’s offering.”

Zhao will in particular focus on package relay, a proposed upgrade to Bitcoin’s handling of unconfirmed transactions which could improve Bitcoin’s user experience, optimize fee market dynamics, and — perhaps most importantly — make Layer 2 protocols like the Lightning Network more robust.

Package Relay

A Bitcoin node’s mempool (memory pool) is the collection of transactions it has received but that have not yet been confirmed in a block. Nodes forward transactions from their mempool to peers on the network, and miners select transactions from their mempool to include in a new block.

Mempools have a size limit. This limit can be configured for each node (the default for Bitcoin Core nodes is 300 megabytes) but when it is full, some transactions must be dropped from the mempool before new transactions can be added. Currently, this selection is based on fees: transactions that include the lowest fees are dropped from mempools in favor of transactions that include higher fees.

This may seem like the obvious solution, because miners normally apply the same policy when selecting which transactions they include in blocks: the transactions that pay them the most fees. Yet, there is a subtle — but important — difference. To maximize their income, miners don’t just select on the basis of fees included in individual transactions, they also select based on the combined fees of transactions that depend on each other.

If, in technical terms, the “parent” transaction sends coins from address A to address B, and the “child” transaction sends the coins from address B to address C, the child can’t confirm if the parent doesn’t also confirm. So, a miner might choose to include a parent in a block even if it includes a very low fee, as long as the child includes a high enough fee to compensate.

It sometimes comes in handy that miners base their selection on clusters of transactions instead of just individual transactions. If a transaction with a low fee which is taking long to confirm, the recipient can opt to spend the coins from the unconfirmed transaction to themselves in a new transaction with a high fee to get both confirmed. This trick is called Child Pays For Parent (CPFP).

CPFP can be especially important in scenarios where a transaction requires a confirmation before a time-lock expires. The most obvious example is a “justice transaction” (also known as a “penalty transaction”), which is key to the security of the Lightning Network. These transactions require timely confirmation to prevent a malicious Lightning channel partner from claiming more funds than they have the right to.

While CPFP can be used to prevent such scenarios, it doesn’t always work.

“The danger comes when, in a CPFP scenario, the child is fine, but the parent doesn’t meet the mempool minimum policy,” Zhao explained. “Say the mempool is so full that the parent’s fee is lower than the lowest-fee transaction in the mempool. Then, your hands are tied. As of right now, the validation logic doesn’t consider CPFP for such a transaction.”

In other words, if nodes drop the parent transaction from the mempool because it doesn’t have enough fees, they won’t accept the child transaction either: it spends coins that the nodes aren’t aware of. In the context of Lightning, this means the justice transaction wouldn’t confirm in time, and the malicious channel partner gets away with their theft.

Package relay would solve this problem by introducing a change to a node’s mempool and transaction relay policies that lets it apply CPFP-type logic. Although implementation details are yet to be worked out, it would essentially allow for the bundling of dependent transactions. Bitcoin nodes would accept and relay transaction packages, protecting transactions that don’t meet mempool policy individually.


“Package Relay will strengthen Bitcoin’s base-layer security guarantees, enabling Bitcoin’s ecosystem to safely expand in functionality and usability through protocols like the Lightning Network.”

The Fellowship

Brink’s year-long fellowship program, which is unique in the Bitcoin industry, will help more developers contribute to Bitcoin projects. Fellowships will be funded by donations, with Zhao’s program to be funded by gifts from Square Crypto ($100,000) and the Human Rights Foundation’s Bitcoin Development Fund ($50,000).

Square Crypto is the Bitcoin development arm of Square, the payments company founded and run by Jack Dorsey (also the co-founder and CEO of Twitter). Besides employing a small team of Bitcoin developers, whose main focus is the Lightning Development Kit, Square Crypto has so far issued 19 grants to different Bitcoin projects and developers. Zhao’s Brink fellowship will be the 20th.

“Brink is creating the first bitcoin mentorship program of its kind, and we want to support it,” Square Crypto lead Steve Lee told Bitcoin Magazine. “We are thrilled Gloria was chosen as the first fellowship recipient, and we are happy our funding will go to her. The package relay project is very valuable for bitcoin, crucial for security and very aligned with Square Crypto’s goals.”

The Human Rights Foundation (HFR) is a New York-based nonprofit that promotes and protects human rights globally. Earlier this year, the foundation launched its Bitcoin Development Fund, a donation-based fund to support Bitcoin developers who make the Bitcoin network more private, decentralized and resilient. Zhao’s fellowship represents the fourth grant awarded by the Human Rights Foundation.

”HRF is delighted to support Gloria through our Bitcoin Development Fund,” said HFR Chief Strategy Officer Alex Gladstein. “The focus of her work is on critical infrastructure that paves the way for Bitcoin to become more private at scale, and is very much aligned with our mission.” 

He added: “This gift will be amplified by the fact that it is helping support Gloria’s fellowship at Brink, where she will receive world-class mentorship and guidance, making her work as effective and efficient as possible.”

The post Gloria Zhao And Brink Are Set To Give Bitcoin Mempools An Upgrade appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

John Newbery’s New Nonprofit Brink Will Train And Support Bitcoin Developers

How do we fund Bitcoin developers, and how do we ensure there are enough of them in the first place? 

Former Chaincode Labs developer John Newbery and Blockstream alumnus Mike Schmidt are launching a nonprofit to help answer both of these questions.

The new organization is called Brink (a nod to the newspaper headline embedded in Bitcoin’s genesis block), a new London-based, independent nonprofit to support open-source development for Bitcoin and related technologies. Through Brink, Newbery and Schmidt — who also collaborate on the Bitcoin Optech project — will issue developer grants and mentor new contributors.

“We believe that Brink’s unique model of funding, grant awards and focus on mentoring will further decentralize Bitcoin’s protocol development and strengthen the Bitcoin network and developer ecosystem,” Newbery told Bitcoin Magazine.

Brink’s most distinctive activity will perhaps be its new fellowship program. Over the course of a year, talented developers will, under the mentorship of Newbery, get the opportunity to learn the ropes of contributing to Bitcoin projects like Bitcoin Core or one of the Lightning projects. Newbery and Schmidt hope this will help more developers get started contributing to Bitcoin projects.

“The fellowship is pretty unique,” Newbery told Bitcoin Magazine. “Other than the Chaincode Residency [a shorter trainee program for Bitcoin developers that Newbery went through himself and later helped organize], it’s hard to establish yourself as a Bitcoin Core dev. There’s a steep learning curve, I hope to help move the needle on that with Brink.”

Besides the fellowship program, Brink will also issue funding to existing Bitcoin developers. Newbery and Schmidt’s company will in this sense act as an intermediary between individuals and organizations that would like to sponsor Bitcoin development (but that don’t have the time and/or expertise to select worthy recipients) and developers working on open-source projects that add value to the Bitcoin ecosystem.

“Individuals can sponsor developers,” Newbery said. “We’ve already seen some GitHub sponsorships, but this is a way to scale up funding.”

The Brink team consists of seasoned Bitcoin experts. Besides co-founders Newbery, who will be Brink’s executive director; and Schmidt, who will be the company secretary; Brink’s board of directors will also include Bitcoin Optech newsletter writer Dave Harding. Organizational funding has been provided by investor John Pfeffer and Xapo CEO Wences Casares. The Human Rights Foundation, Square Crypto and Gemini are funding Brink’s first two fellows, and Kraken is sponsoring its first grantee.

Brink has applied to be a 501(c)(3) in the United States. If granted, this designation would let U.S. citizens make tax-exempt donations to the organization. Brink would then be the only organization exclusively devoted to Bitcoin development that takes direct donations from the public in this way.

For more information about Brink, visit its website at If you’d like to contribute to Brink, contact More information about Brink’s grant and fellowship programs can be found at

The post John Newbery’s New Nonprofit Brink Will Train And Support Bitcoin Developers appeared first on Bitcoin Magazine.

Source: Bitcoin magazine

Crypto News Updates

Video: Erebus Attacks And How To Stop Them With ASMAP

YouTube Video

Listen To This Episode:

In this episode of The Van Wirdum Sjorsnado, Aaron and Sjors discuss the Erebus Attacks. The episode is a follow-up from last week’s episode on Eclipse Attacks, a type of attack that isolates a Bitcoin node by occupying all of its connection slots to block the node from receiving any transactions. Erebus Attacks are Eclipse Attacks in which an attacker essentially spoofs a whole part of the internet.

The internet is made up of Autonomous Systems, basically clusters of IP-addresses owned by the same entity, like an ISP. Last week, the hosts explained how Bitcoin Core nodes can counter Eclipse Attacks by ensuring that they are connected to a variety of IP addresses from different Autonomous Systems. As it turns out, however, some Autonomous Systems can effectively act as bottlenecks when trying to reach other Autonomous Systems.

This allows an attacker controlling such a bottleneck to launch a successful Eclipse Attack even against nodes that connect with multiple Autonomous Systems.

Since its most recent release, Bitcoin Core includes an optional feature — ASMAP — to counter these types of Eclipse Attacks. The hosts explain how mapping of the internet has allowed Bitcoin Core contributors to create a tool which ensures that Bitcoin nodes not only connect to various Autonomous Systems, but also ensures that they avoid being trapped behind said bottlenecks.

The post Video: Erebus Attacks And How To Stop Them With ASMAP appeared first on Bitcoin Magazine.

Source: Bitcoin magazine