Idelto

Cryptocurrency news website

technical

Op Ed: Quantum Computing, Crypto Agility and Future Readiness

by

Over the past few decades, we have seen almost unimaginable progress in computation speed and power. A watch today is a more powerful computer than the first Macintosh that my parents bought me in 1984 (I was very lucky). The weakest and lightest laptop today is more powerful than the computers that I programmed on during my undergraduate studies in university. Do you remember the days of computers with 64 kilobytes of RAM? Now we count in gigabytes and, soon, terabytes. 

Yes, I know that I’m old (but at least I’m not reminiscing about punch cards and vacuum tubes), but that’s not really the point. The point is to understand where all of these extremely fast advancements in computing power came from. 

The answer is a combination of Moore’s law (stating that the number of transistors on a chip doubles every two years, although this has now slowed down), together with many architectural improvements and optimizations by chip manufacturers. Despite this, the basic way that our most powerful computers work today is the same as in the 1970s and 1980s. Thus, although improvements are fast and impressive, they are all in the same playing field.

Enter Quantum Computing

Quantum computing is a completely different ball game. Quantum computers work in a radically different way and could solve problems that classical computers won’t be able to solve for hundreds of years, even if Moore’s law continues. Stated differently, quantum computers don’t follow the same rules of classical computing and are in a league of their own. This does not mean that quantum computers can solve all computationally hard problems. However, there are problems for which quantum computers are able to achieve extraordinary speedups. 

Some of these problems are closely related to much of modern cryptography, and include the number factorization problem that lies at the core of the RSA cryptosystem, and the discrete log problem that lies at the core of Diffie-Hellman, ECDSA, EdDSA and other cryptosystems (as used in cryptocurrencies and blockchains). 

The big question that still has not been answered, despite what you may have read, is whether or not such quantum computers will ever be built. I want to stress that this is still an “if” and not a “when.” The fact that small quantum computers have been built does not mean that quantum computers at the scale and accuracy needed to break cryptography will ever be built. The problems that need to be overcome are considerable. I am not saying that I don’t think they will succeed; I’m just saying that it’s not a certainty. 

The next big question is: When will such a computer that is powerful enough to break RSA or ECDSA be built? Or maybe more relevant — when do we have to start worrying about this possibility? I personally believe that this is many years away (I will say at least a decade, but I think it will be more like two decades at least).

Google and Quantum Supremacy

Recently, Google’s scientists hailed what they believe is the first demonstration of quantum supremacy. This was widely understood to mean that quantum computers are now already faster than classical ones. And if this is the case, then modern cryptography may be broken very soon, in contrast to the time span that I predicted above. 

However, this claim by Google’s scientists needs to be understood in context. “Quantum supremacy” is a technical term used by the academic community to mean when a quantum computer can do just one thing faster than a classical computer. However, this is really not what we think about when we hear “supremacy,” nor is it really relevant to cryptography and other application domains. In particular, what we are really interested in knowing is when quantum computers will be able to solve hard, important problems faster than classical computers, and when quantum computers will be able to break cryptography. 

Whether or not quantum supremacy was even demonstrated is not absolutely clear (see IBM’s response). However, in any case, this quantum computation has no effect whatsoever on cryptography, blockchains and cryptocurrencies. 

The Need for Crypto Agility

So, what does this mean concretely for us as a community? First, we should rest assured that the cryptographic world is getting ready for any eventuality. In particular, we already have good candidates for post-quantum secure public-key encryption and digital signature schemes, and NIST is working on standardization now. As such, we will not be surprised and unprepared if post-quantum computers that threaten our cryptographic infrastructure become close to reality. 

This does not, however, mean that our actual products and software in use are ready for the post-quantum era, and this is often a really hard problem. The solution to this problem is called crypto agility, and it relates to the ease (or lack thereof) with which cryptosystems can be replaced in existing deployed systems. 

The Value Proposition

There are two main aspects to crypto agility. The first is how easily it is possible to change code so that one cryptosystem is replaced with another. The more the specific structure of the cryptosystem is relied upon in the code, the harder it will be to replace. The second is how to make this change while preserving backward compatibility and without introducing new vulnerabilities that can happen when new and old versions operate concurrently. 

These are (security) software engineering considerations, and there is no general right answer. However, asking your software team what the cost would be to swap out their crypto is a really important first step. 

The good thing about becoming more crypto-agile is that, even if the threat of quantum computing to cryptography never eventuates, it is still a good investment. Cryptosystems, key sizes, modes of operation and more change over time. This is a fact of life and will not change. Being more crypto-agile will enable you to respond faster to such changes and to be ahead of the market when new cryptography is introduced (whether it be for classic security systems or for cryptocurrencies and blockchains). That is always a good thing!

This is an op ed contribution by Professor Yehuda Lindell. Views expressed are his own and do not necessarily reflect those of Bitcoin Magazine or BTC Inc.

The post Op Ed: Quantum Computing, Crypto Agility and Future Readiness appeared first on Bitcoin Magazine.

Does Bitcoin Need Accounts? One Developer Thinks So, and He Figured Out How

by

Bitcoin doesn’t use typical “accounts.” Instead, with each payment, the funds are sent to a unique “transaction output.” In such an output, the Bitcoin address can potentially be reused, in which case the address would act a bit like a Bitcoin account. Reusing addresses in this way, however, makes it trivial to link different coins and transactions to the same user, which is horrible for privacy. Bitcoin users are instead encouraged to generate a new address for each receiving payment.

While a best practice for privacy, Spanish developer José Femenías Cañuelo believes this isn’t exactly user friendly.

“We are somewhat used to Bitcoin payments the way they are, but it’s really an atrocity,” Cañuelo told Bitcoin Magazine. “It’s like using the internet without domain names, relying only on IP addresses — only worse, because crypto addresses are way longer, uglier and constantly changing.”

To solve this issue, over the past year, the developer figured out how to bolt an account system on top of Bitcoin. Having extensively detailed the idea in a new white paper, Femenías is now proposing his Layer 2 protocol: Easypaysy.

While preserving Bitcoin’s most valuable attributes — such as privacy and self-sovereignty (no need to rely on custodians) — the Spaniard believes his proposal would improve the Bitcoin user experience significantly: It would enable non-repudiation, recurring payments, and more.

Easypaysy Bitcoin Accounts

As a key property of Femenías’ proposal, Easypaysy would not depend on any outside source. Both setting up the account as well as using it all happens on the Bitcoin blockchain itself.

This is possible because an account is created with a special transaction. This transaction has one input (the “sending” half of the transaction), which includes a two-of-two multisignature (multisig) address. This means that two public keys are revealed, signing the transaction. The transaction also has one output (the “receiving” half), which is an OP_RETURN output. In this case, the output doesn’t actually receive any funds; it just includes a little bit of data.

The two public keys used in the input belong to the account owner who also created the transaction, and both keys serve a function. The first public key is called the “Identity key,” and it is essentially the account holder’s digital identity. Anyone who wants to communicate with him privately must use this public key to encrypt the messages. The second public key is called the “Value key,” and it is used to receive payments.

There are two different public keys instead of one because the Value key is even more valuable than the Identity key: The latter is used for messages, the former for money. “The Identity key must be ‘online,’” Femenías explained. “That opens it up to vulnerabilities, in the same way that online wallets are more exposed than offline wallets. It may be wise to keep the Value key in cold storage, while the Identity key is more actively used to communicate.”

The OP_RETURN text in the output, then, also serves a function. It is a small JSON document (a machine-readable data format) called the “Rendezvous descriptor.” This document contains information about the account. Specifically, it details which types of payments the account owner is willing to accept and how. (Indeed, Femenías’ proposal supports various types of payment; more on this later.)

The two public keys and the Rendezvous descriptor are all the information the account needs to contain. When this special account-creation transaction is drafted, a fee is added (as such, the multisig address must have been minimally funded), and it is broadcasted to the Bitcoin network to be included in a block.

Easypaysy Bitcoin Account IDs

Now people need to be able to find the account.

This is where Femenías slipped in one of the nifty tricks of his proposal. Once the transaction is included in a block, the account is automatically assigned an account ID, based on its place in the blockchain. Specifically, the account ID consists of the exact block that the transaction is included in, and the location of the transaction in that block. This is combined with a blockchain identifier and a checksum.

Like so: [email protected]/checksum.

Let’s look at this step by step, with a random example.

Say we’re using Bitcoin. The blockchain identifier, then, is “btc.”

And let’s say the transaction is included in block 543,847. (This is a real Bitcoin block, mined in October 2018 — but that’s not important; we’re just making something up for now.)

Let’s also say that the transaction is the 636th transaction in that block. (Again, this transaction actually exists, but we’re just making something up here; there’s no need to look up the actual transaction.)

The checksum, lastly, is a cryptographic trick for extra security.

“It is extracted by hashing three items,” Femenías said, “the hash of the block that includes the account, the Merkle root of that block, and the hash of the account transaction itself. Thus, if anyone tries to send you bad account data, you can easily detect it.”

In our example, the checksum would be 577.

So, the 636th transaction included in Bitcoin block number 543,847 would result in account ID: [email protected]/577. More specifically, this would be the “canonical ID,” as the block, transaction and checksum are shown in numbers.

To make it even more practical, this canonical ID — [email protected]/577 — can also be expressed as a “mnemonic ID.” Leveraging the BIP 39 word format, used for Bitcoin wallet seeds, the numbers in the account ID can be converted into a couple of words (or combinations of words). This should be easier for humans to memorize.

The numbers in the account ID of this example can be cut into three chunks.

543847 = cancel-mind

636 = exhibit

577 = motion

As such, the mnemonic ID from this example would be: [email protected]/motion.

Lastly, the Easypaysy white paper also proposes “Domain IDs,” which would depend on the Domain Name System (DNS). In short, such IDs would include an actual domain name, as well as a blockchain identifier and a checksum, and link it to an account ID through the DNS system. For example, a domain ID would look like this: [email protected]/561.

These types of IDs would rely on an external source (DNS) and would cost money and some effort to maintain. Femenías expects they’d probably only be interesting to commercial parties.

Payments

So we have an account and an account ID. Now, someone — let’s just call him “the payer” — wants to pay the owner of our account, who we’ll call “the payee.” The payer has the payee’s mnemonic ID, because the payee gave it to him. (The account ID, in whatever form, can simply be shared with anyone, like an email address or a phone number.)

To make the payment, the first step for the payer is to convert the mnemonic ID back into the canonical ID. This step is trivial. Using the BIP 39 format, the payer simply converts the words in the mnemonic ID back into numbers, and ends up with the canonical ID: [email protected]/577.

With the canonical ID, the payer can use the checksum to make sure that the block height and the transaction number match. This isn’t strictly necessary, but it serves as an extra check to make sure there were no typos in the account, or maybe to prevent someone from nefariously handing over a similar-looking account.

Either way, the payer now knows where to find the account: It’s the 636th transaction in block 543,847. So he looks it up.

This transaction then includes the Rendezvous descriptor: the JSON document in the OP_RETURN output. This Rendezvous descriptor specifies which types of payments the account is willing to receive and how. This can be all types supported by the protocol or any selection of them.

Of the payment types that the payee accepts, the payer picks his favorite and makes the payment. Done.

Payment Types

So which payment types are possible? Femenías’ protocol includes four payment types.

Type 0

The first payment type — type 0 — is the simplest type but also the worst one for privacy. Type 0 payments are basically just payments to the Value key and, therefore, involve reusing the corresponding address, like many donation addresses do today. Femenías actually discourages this type, but he still wanted to include it in the protocol as an option for those who really want to use it.

Type 1

The second payment type — type 1 — requires interaction. For this type, the payer contacts the payee to ask for a new Bitcoin address. The Easypaysy protocol is flexible in how this contact is made; it can be by email, through a web page, in a chat app or by some other means.

When the address is provided (let’s say through email), the payee also signs the address with his Identity key. This offers confirmation to the payer that the address is really the payee’s — and not an address belonging to a hacker that gained access to the payee’s email account, for example.

Type 2

The third payment type — type 2 — requires no interaction. Resembling tricks previously used for stealth addresses, type 2 payments let the payer generate a new Bitcoin address for the payee, from which the payee (and only the payee) can spend.

To do this, the payer needs to generate a single-use public key pair. Using the private key of this key pair, in combination with the payee’s Value key, the payer generates a new public key and corresponding Bitcoin address. The payer sends the funds to this new address, and — importantly — adds the single-use public key to the same transaction as an OP_RETURN output.

Interestingly, the payee can use this single-use public key in combination with his Value key to generate a new private key that corresponds with the new public key, and thus the corresponding Bitcoin address. In other words, if the payee learns of the single-use public key, he (and only he) can spend the funds from the new Bitcoin address.

To learn of the single-use public key, the payee is either notified of the transaction by the payer, or the payee simply checks all new Bitcoin transactions with an OP_RETURN output. For each OP_RETURN output, he checks if it’s a public key that he can combine with his private Value key to spend the funds included in that transaction. This will often not be the case. But when it is the case, he knows he’s been paid.

(To read how this works in a little more detail, see this article on stealth addresses and reusable payment codes.)

Type 3

The fourth payment type — type 3 — is similar to the second type. This time, however, OP_RETURN outputs must be prefaced with the identifier “EP.” This makes them easier to spot for the payee, but they do cost a little bit extra in fees for the payer.

Benefits of Bitcoin Accounts

As a Layer 2 proposal, Femenías’ account system would not require any changes to the Bitcoin protocol, nor would it need industry-wide consensus. Individual wallets can adopt the proposal tomorrow, and after that users could use it immediately.

Femenías, of course, believes this would greatly benefit Bitcoin’s usability, opening up a whole new potential for the protocol.

“Of these, non-repudiability is a big one,” Femenías said. “Let’s say you go to the Lamborghini dealer to buy your new ride. Once you agree on the price, the dealer shows you a QR code and tells you to send the payment to that address. So you do. But the day after, the dealer’s accountant tells you they are still waiting for the payment. How do you prove you paid? Because Bitcoin addresses are pseudonymous, you can’t prove you sent the money to the Lamborghini dealer.”

With Femenías’ account system, this would no longer be a risk: The payer could always provide proof of payment to a specific account. For type 0 payments, this is obvious; the money was sent to the account’s publicly visible Value key. Type 1 payments are also easy to prove, as the provided Bitcoin address was signed with the payee’s Identity key. But even for Type 2 and 3 payments, the payer could prove that the payee was really paid: The single-use private key can cryptographically prove that the payee has all the information needed to identify the transaction as his and to compute the private key that lets him spend the funds.

Another benefit is that Femenías’ account system would make recurring payments much more feasible: think of rent, subscriptions, or other periodic transactions to the same entity. Wallet software could be programmed to accept payment requests from a specific account, up to some maximum amount per period. (For example, the landlord’s account would be allowed to charge up to 0.1 bitcoin per month, if that’s the monthly rent.)

Further, it would be much easier for merchants to return funds. This could be useful, for example, when someone makes a purchase, but the merchant later finds that the ordered product is out of stock. With an account system, the money can be returned to the customer easily, without needing to ask for a specific return address.

Lastly, Femenías’ account system would, for the first time, offer Bitcoin users a blockchain identity.

“This could, for example, mean that when you login to a website, you use your Easypaysy ID, and instead of asking for a password, the website challenges you to sign a message with your private key,” Femenías suggested. “Even if the website is hacked, you are always safe because they don’t store any passwords.”

Downsides 

All that said, one of Femenías’ account system’s most powerful features, may also be its biggest drawback: It relies fully on the Bitcoin blockchain by embedding account data in it. Block space is scarce, however, and scalability is a challenge.

To minimize this problem, Femenías in his white paper suggests that accounts could also be opened in bulk: One transaction could include hundreds or even thousands of accounts, for as many users. In this case, the OP_RETURN data would point to an outside source for all the account data, perhaps a website. The OP_RETURN would also include a Merkle root for all this account data, so the payer can check the account data against the Merkle root. While this solution would depend on an outside source (like a website), at least users could make sure the data isn’t tampered with.

An alternative solution could be to use a different blockchain — such as Litecoin’s — to open accounts. In this case, an index number is added to the account referring to Litecoin, or whichever blockchain is used. While this solution would arguably be secure enough in the case of Litecoin, it does, of course, come with the obvious downside that Bitcoin users would come to rely on a different cryptocurrency, to a certain extent.

For more information and details, see the Easypaysy white paper.

The post Does Bitcoin Need Accounts? One Developer Thinks So, and He Figured Out How appeared first on Bitcoin Magazine.

Bitcoin Core 0.19.0 Released: Here’s What’s New

by

Today, November 24, 2019, marks the official release of Bitcoin Core 0.19.0, the 19th major release of Bitcoin’s original software client launched by Satoshi Nakamoto almost 11 years ago and still the dominant Bitcoin implementation on the network today. (Though due to an issue that came to light in a late stage of the Bitcoin Core 0.19.0 release process, the version released for download is actually 0.19.0.1.) Overseen by Bitcoin Core lead maintainer Wladimir van der Laan, this latest major release was developed by over a hundred contributors over a span of about six months.

The result of 550 merged pull requests, Bitcoin Core 0.19.0 includes a range of performance improvements, modernizations and bug fixes, as well as other changes.

Here’s an overview of some of these changes.

Bech32 Addresses by Default in the GUI

The “bech32” address format (BIP 173) had already been introduced in Bitcoin Core 0.16.0, released in early 2018, but is now for the first time set as the default option in the Bitcoin Core wallet Graphical User Interface (GUI).

Bech32 addresses are the addresses starting with “bc1” (as opposed to addresses starting with a 1 or a 3.) These addresses are also a bit longer, but use fewer different characters than the current address format, as there is no longer a distinction between lowercase and capital letters. (This reduces the potential for human mistakes, for example, when an address is read out loud.) Bech32 addresses are also designed to limit mistakes caused by typos.

Additionally, bech32 offers benefits in the context of SegWit. Some wallets that offer SegWit — including the Bitcoin Core wallet by default up until now — do so by “wrapping” it into P2SH outputs (with addresses starting with a “3”). To spend bitcoin from such an address, users must reveal a piece of code — the “redeem script” — to show that the bitcoin were really locked up in a SegWit output. With the new bech32 addresses, this step can be skipped, which means that spending from a SegWit output will require a little less data to be transmitted over the Bitcoin network and included in the blockchain. This makes transactions from a bech32 output even cheaper than SegWit transactions from a P2SH output.

Since not all bitcoin wallets support sending to bech32 addresses yet, Bitcoin Core 0.19.0 users will still be able to optionally generate a PS2H receiving address instead, through a toggle in the GUI.

Two Block-Only Outbound Connections Extra by Default

Bitcoin nodes connect to several other Bitcoin nodes, together forming the peer-to-peer network. Over this network, the nodes share blocks, transactions and some additional transaction data.

But the peer-to-peer network can be subject to attacks, such as “partitioning attacks.” If an attacker controls a large enough number of Bitcoin nodes, it can potentially “cut off” certain parts of the Bitcoin network (or even specific nodes) by intercepting all traffic to it. The partitioned part of the network could then, for example, be fooled into accepting a minority chain — not the longest chain — as valid, which could, in turn, open the door to double-spend attacks.

A partitioning attack is countered if a node in the partitioned part of the network has even just one connection to an honest node on the main network. It would then receive and relay all transactions and blocks and would reject the minority chain in favor of the majority chain.

One way to realize this, and to make partitioning attacks harder to pull off, is to have nodes establish more connections to one another. More connections do come with more memory and bandwidth requirements, however; there is a trade-off.

Bitcoin Core 0.19.0 increases the default for outgoing connections by two, but — cleverly — these two extra connections are only used to relay blocks — they do not relay transactions or additional transaction data. This increases the added bandwidth requirements minimally, while still making partitioning attacks harder to pull off successfully. 

Bloom Filters Deprecated

Bitcoin Core is a full node implementation, which means that it downloads and verifies all Bitcoin blocks. While this is optimally secure, it doesn’t make it very well suited for low-resource computing devices, like mobile phones. Mobile wallets (as well as some desktop wallets) are, therefore, usually “light clients”: these only download transactions and (parts of) blocks that concern them specifically.

One way to do this is with Bloom Filters, used by a couple of wallets today. In short, Bloom Filters are a cryptographic trick used by light clients to request relevant data from more or less random full 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 their addresses to the full node. On top of that, supporting Bloom Filter requests does come at a cost in CPU and disk space for full nodes — with no direct benefit for the full node itself.

For the latter reason in particular, Bitcoin Core 0.19.0 no longer supports Bloom Filter requests by default. Users can still switch the default to support Bloom Filters if they so choose.

It’s also worth noting that the Bitcoin network as a whole will almost certainly continue to support Bloom Filters for years to come, even if no one switches their defaults, simply because older Bitcoin Core nodes typically continue to be in use for years after new versions have been released.

More Support for Compact Client-Side Block Filtering

An alternative to Bloom Filters is a newer solution called “compact client-side block filtering” (BIP 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. Light clients can then use these filters to figure out if transactions relevant to them may have happened in a block. If so, the light wallet will fetch the whole block and pick any relevant transaction data out of it.

Bitcoin Core 0.19.0 continues to move toward supporting compact client-side block filtering. Bitcoin Core nodes could already create the filters locally, but Bitcoin Core 0.19.0 users can now also make them available through a remote procedure call (RPC), for applications running on top of the node (like a wallet).

The filters are not yet available over the peer-to-peer network, however. This means that a Bitcoin Core 0.19.0 node will not automatically send filters to other Bitcoin users’ wallets. This feature could be added to a future Bitcoin Core release — or Bitcoin Core 0.19.0 users could opt to offer the feature through a custom application running on top of their Bitcoin Core node.

Payment Protocol Support Disabled From GUI

The Payment Protocol (BIP 70) was designed several years ago to improve Bitcoin’s payment experience. On top of the regular payment as broadcasted to the Bitcoin network, a user and a merchant would communicate additional details about a payment, such as a human-readable destination address (the name of the merchant) and a refund address in case something went wrong with the purchase.

While Bitcoin Core integrated the Payment Protocol in its GUI, the standard was never widely adopted. Instead, most wallets still use the more basic URI scheme (BIP 21) to receive payments: The clickable link or scannable QR-code format that, for example, communicates the payment address and amount. (The only notable exception today is payment processor BitPay, which does not support the URI scheme but uses a modified version of BIP 70.)

Perhaps more importantly than the lack of adoption, the BIP 70 payments protocol has been suffering a number of security and privacy vulnerabilities over the years. Some wallets have, therefore, actively rejected to implement the protocol. Bitcoin Core, too, had been planning to deprecate BIP 70 for some time, as maintenance of it wasn’t considered worth the effort — but BitPay’s adoption of it stalled this process.

In Bitcoin Core 0.19.0, BIP 70 has been removed from the GUI by default after all. Bitcoin Core 0.19.0 users would have to compile their node with a special configuration to still make use of the feature.

Other…

Besides the changes mentioned above, Bitcoin Core 0.19.0 comes with a long list of smaller improvements and modernizations. 

It’s now possible to start a pruned node immediately from setup, for example, which lets users with little disk space easily start up a new Bitcoin node. Bitcoin Core 0.19.0 also includes new features for the Partially Signed Bitcoin Transactions (PSBT) protocol, which is useful for multisignature and CoinJoin transactions. Likewise, there are several improvements in the domain of wallet descriptors, which is particularly useful for programmers working on Bitcoin applications. Bitcoin Core 0.19.0 nodes will also accept and relay transactions that use a future SegWit version to ensure that upcoming upgrades will proceed smoothly.

For a more extensive list of upgrades, also see the Bitcoin Core 0.19.0.1 release notes.

Thanks to Sjors Provoost for feedback on this article.

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

Op Ed: Want to Learn How to Contribute to Bitcoin? Try a ‘Good First Issue’

by

Continuing the series on the various ways one can learn about the technical aspects of Bitcoin, in this article we will focus on good first issues in the Bitcoin Core GitHub repository.

Bitcoin Core is widely recognized as the reference implementation for Bitcoin. Although the name “Bitcoin Core” wasn’t used until 2013, the client itself can trace its roots right back to the very first release by Satoshi Nakomoto in 2009. Other Bitcoin implementations like libbitcoin (C++), bcoin (Javascript) and btcd (Go) were created later. 

Get to Know GitHub

Bitcoin Core is an open-source project. The code and documentation can be viewed and downloaded by anyone with an internet connection. Bitcoin Core (and many other software projects) use the open-source and nonproprietary Git version control system for tracking changes in the codebase across distributed contributors. 

Git was developed by the creator of the Linux kernel, Linus Torvalds. In contrast, GitHub (recently acquired by Microsoft) provides proprietary software which offers convenient tools and social features around the Git protocol. Bitcoin Core is not dependent on GitHub for its ongoing survival though it would be inconvenient and disruptive if the project was suddenly moved or prevented from using GitHub software in the future. 

During the time of Microsoft’s acquisition of GitHub, there was discussion in the Bitcoin community and on other open-source projects as to whether they should transition away from any future reliance on GitHub. This view is becoming more popular as greater numbers of contributors and potential contributors are being banned from using GitHub software. There is also the possibility that Microsoft could make the first move and ban entire projects if they are perceived as politically controversial. Time will tell if Bitcoin Core and other Bitcoin implementations continue to leverage GitHub’s admittedly well-crafted, user-friendly features in the years to come.

Find a ‘Good First Issue’

One of those features is GitHub Issues which are used to announce and track bugs, enhancements and requests. Any GitHub user can create an issue, though it is recommended that they only open an issue after researching it and discussing it with existing contributors on IRC. You do not need to request permission to start working on an issue. But if you do, you are encouraged to comment on the issue to encourage collaboration with other contributors. It is also a good way to request assistance if and when you need it.

The purpose of the “good first issue” label is to highlight which issues are suitable for a new contributor who might not have a deep understanding of the codebase. A good first issue isn’t targeted toward software development beginners. At the very least, you’ll need basic Git proficiency and ideally C++ and/or Python proficiency, too, given that the Bitcoin Core codebase is written in these languages. 

Good first issues for Bitcoin Core highlight the “useful skills” for addressing that issue. It is a good idea to learn C++ and/or Python to make code-related contributions, but if you are not proficient in those languages you may choose to get started by making a material improvement to the documentation or finding a good first issue that requires shell scripting, Automake or CMake experience.

‘Typos’ vs. ‘Real’ Issues

Some people get started by correcting basic typos in variable names, comments or documentation. Jeremy Rubin has joked that he deliberately leaves typos in his contributions so that new contributors can find them and correct them. Although this is one way to get started as a new contributor, it is better to focus on good first issues rather than submitting pull requests (PRs) for typos.

Good first issues have been highlighted as something that is missing and of significant value to the project by existing contributors. They will not be set up to identify typos, and existing contributors and maintainers would prefer to focus their time on reviewing and merging high-priority for review pull requests. (Pull requests are proposed changes by contributors that are only merged by maintainers after review and when there is sufficient consensus to do so.) 

It would, therefore, be better to correct typos as part of a more substantive pull request. As discussed previously, it is worth remembering that reviewing existing PRs is generally more valuable than submitting new ones. John Newbery recommends that a good rule of thumb is to review 5–15 PRs for every PR that you submit personally. At the time of writing, there are approximately 300 open pull requests and 700 open issues requiring testing and review.

Plenty of Opportunities to Practise and Learn

Fabian Jahr, a recent new contributor to Bitcoin Core, has identified that the main skill often lacking in new contributors is sufficient Git proficiency, such as the ability to squash commits. Contributors are required to enter Git commands into the command line. If you are a beginner to the command line and/or Git, it is best to complete tutorials and practice on other projects that aren’t subject to the resource constraints of Bitcoin Core. 

There are many Git tutorials online (some of them free) and Justin Moon’s Mooniversity course (paid) will also help you learn the prerequisites for interacting with and contributing to Bitcoin Core from the command line. Don’t be afraid to request assistance from recent new contributors online or at your local Socratic Seminar if you need further guidance.

Ask for Help

One of the challenges with onboarding new contributors is that tasks that would take an experienced contributor a short period of time to complete may take a new contributor a much longer period of time. This requires new contributors to persist whenever they encounter challenges and ask for assistance when needed. Recent new contributors to Bitcoin Core can be a good first port of call, as they may be able to solve your problem; if not, they should be able to direct you to an appropriate long-term contributor. You can also comment on the issue you are working on to flag that you require assistance.

In an interview with Bitcoin Magazine’s Vlad Costea, Chaincode Labs engineer Carl Dong recalled setting up an IFTTT email alert which would flag every time there was a new “good first issue” posted by existing contributors. This was one of the strategies he used to get started with Bitcoin development and identify some mini projects that he had the skills to contribute to. Dong has since created the Twitter account @GoodFirstIssues which anyone can follow for notifications of new good first issues.

Thanks to Jon Atack and Marco Falke for their contributions to this article. 

The post Op Ed: Want to Learn How to Contribute to Bitcoin? Try a ‘Good First Issue’ appeared first on Bitcoin Magazine.

BIP 324: A Message Transport Protocol That Could Protect Bitcoin Peers

by

More than 10 years living in the world of Bitcoin has shown us that there is a long road ahead for Bitcoin developers, and BIP 324, created in March 2019, could be the next important step on that road.

The BIP was authored by Switzerland-based Bitcoin developer and cofounder of Shift Cryptosecurity Jonas Schnelli to help address a perceived concern around the messages exchanged between Bitcoin peers.

“Bitcoin: A Peer-to-Peer Electronic Cash System” is the title of the Bitcoin white paper and, as it suggests, the P2P layer is a major component of the Bitcoin network but also the one with significant inefficiencies and existing theoretical attack vectors. One of the major fields for potential research and upgrades to Bitcoin is in this P2P network and some of the recent prominent development in this sphere has sparked a lot of attention, including proposals like Dandelion (BIP 156) and Erlay.

So what is the P2P network architecture? Before Bitcoin, the most successful implementation of a P2P network was seen in the application for file-sharing services: originally Napster (with partial centralization by central server catalog) and, later on, BitTorrent.

In the ideal configuration, P2P networks shouldn’t have any hierarchy (all nodes are equal), and nodes should share the network load uniformly. This basic layer of a mesh of interconnected nodes is what helps Bitcoin to be censorship-resistant. As with torrent networks, governments have taken actions to block them on the search-engine level. One can only block the torrent search engines, but it’s much harder — close to impossible — to kill the P2P torrent network. The main question for these networks is: How private is it to use them? 

Problems With the P2P Layer of Bitcoin

One of the problems with Bitcoin’s current P2P implementation is a lack of enforced encryption over the message transport layer. It makes Bitcoin susceptible to man-in-the-middle (MITM) attacks. MITM attacks are performed by secretly connecting to both peers and relaying communications between them, so both parties think they are speaking with each other directly when the communication is really being controlled by the attacker. There are both “passive” and “active” MITM attacks, with passive MITM attackers only observing the state of the network and active attackers manipulating its traffic. 

The messages sent between nodes in the Bitcoin protocol are not encrypted, just sent in plain text, which opens the whole protocol to attack vectors. Internet Service Providers (ISPs), WiFi providers or other adversaries can perform an MITM attack to read through all of your inbound and outbound connections, without having to connect to you as a peer. In theory, this could be leveraged to intercept or even block the relay of specific data, like transactions to and from sanctioned entities. 

Because of the lack of message encryption on Bitcoin, a country’s ISPs may be able to detect a packet of bitcoin transactions as an MITM, see the plain data they contain and then block them. They could potentially attack miners and delay their validation of blocks. Or a surveillance program like PRISM might elect to passively observe all bitcoin traffic through an MITM attack and, upon finding a transaction it does not approve of, work to intercept or block it. Coordinated attacks over the P2P network could even segment the Bitcoin network on the continent or country level, known as a “partitioning attack.”

What may be most crucial to Bitcoin’s privacy as it’s currently implemented: Even if an MITM attack does occur, there would be no way for the affected peers to confirm it.

But why can’t we, as a Bitcoin community, be satisfied using tools like VPNs or Tor to obfuscate or encrypt the traffic? As Tor is an encrypted, onion-routed network, it hides the endpoints of transactions so, in theory, it’s impossible for ISPs to track activity this way. But there are downsides to using Tor-encrypted P2P services, mainly related to insufficient research on the integration of Tor over layers other than HTTP(S), the possibility of theoretical attacks and some dependency issues with Bitcoin Core software that may introduce attack vectors.

A Potential Solution for the P2P Layer of Bitcoin

That’s why Schnelli created a set of Bitcoin Improvement Proposals (BIPs) to address the issue. BIP 151 covers encryption of the traffic between the nodes, while BIP 150 narrates authentication that’s optional for the node and is based on Elliptic Curve Digital Signature Algorithm (ECDSA) private-/public-key cryptography.
For an avid reader, a recommendation would be to start from this BIP 151 article by Aaron van Wirdum, as this BIP was the first to propose a solution for lack of privacy on the P2P layer. Since this proposal was released, some parties have started to implement the solution into various Bitcoin client implementations and Schnelli decided to go with a new, upgraded BIP, numbered 324. 

BIP 324 is designed so that Bitcoin peers can tell if they are victims of an MITM attack. Though bad actors can still connect to Peer A and pretend to be Peer B and can connect to Peer B and Pretend to be Peer A, the actual Peers A and B can see that they do not have the same session IDs and that an MITM attacker is intercepting their communication. Though these peers would likely also want to leverage additional authentication mechanisms, that is outside of the scope of BIP 324.

“With the current unencrypted message transport, BGP hijacking, block delay attacks and message tampering are inexpensive and can be executed covertly (undetectable MITM),” as the BIP abstract puts it. “Adding opportunistic encryption introduces a high risk for attackers of being detected. Peer operators can compare encryption session IDs or use other forms of authentication schemes to identify attack.”

Ultimately, a would-be MITM attacker will still be able to read the unencrypted data that is on the Bitcoin blockchain, as it is open and decentralized. So, in practice, this solution would probably be most helpful in protecting against specific entities that are not peers, like ISPs and open WiFi providers, that can filter out specific transactions and intercept or block them. Of course, PRISM could observe Bitcoin traffic by simply becoming a peer on the network. Though it is more trivial for potential attackers to listen to unencrypted traffic: If it’s possible to monitor for MITM attacks, these passive blockchain observers would have to weigh the benefits of monitoring P2P messages with the negatives of being caught.

Still, BIP 324 is really just a building block in strengthening Bitcoin’s P2P layer against malicious MITM attacks. It may become a critical step in development work to determine whether MITM attacks pose a real threat to Bitcoin or it may be determined that they do not. But it’s hard to gather that data without tools like the ones suggested by BIP 324. 

BIP 324 is focused on providing tools to mitigate passive MITM attacks, while co-implementation with BIP 150 offers some potential tools for active MITM attacks.

Handshake 

The first action described in BIP 324 is a “handshake.” This is an act of establishing protocols for further communication between peers on the P2P layer. 

This handshake should be initiated if no other message has been sent between two parties as a way to start contact by sending the public key (derived from the ephemeral elliptic curve secp256k1 cryptographic function) to the counterparty. As the name of this type of key schema suggests (ephemeral), the keys should be wiped out from memory (RAM) after every successful handshake performed. So, an attacker wouldn’t be able to intercept these keys or decode the historic message transfers for this specific connection.
This attack vector requires access to the victim’s memory, so this problem is probably negligible in the scope of the P2P encryption and authentication.

The shared secret is crucial to establish end-to-end encrypted communication and can only be calculated if an attacker gets a hold of the private key and the counterparty’s public key. The latter is rather trivial for an attacker, but by the design, private keys shouldn’t be transmitted, so this component of the equation wouldn’t be available to an attacker. 

The last steps of handshaking is to derive symmetric encryption keys — the actual secret that is being used to encrypt the messages — and calculate the session ID. 

Encryption

From now on, parties can send messages between each other, without the fear of their content being watched by any third party. 

So, what actually happens when the message is encrypted? Similar to BIP 151, this proposal extracts the best parts of the cryptographic primitives ChaCha20 and Poly1305. Encryption doesn’t have only positive outcomes. Usually, it makes communication slower by making messages bigger and heavier to compute. Without getting into too many details, a new, proposed message structure can even make the encrypted message smaller and faster to compute, all because of choosing the right cryptographic primitives mentioned above. To compare, the unencrypted Bitcoin Core client currently uses the double SHA-256 hash (cryptographic standard) checksum of a sent message (truncated into 4 bytes), and it’s still a relic of Satoshi’s original implementation. 

This proposal is only one building block in the effort of making Bitcoin more private and fungible. It doesn’t have any impact on the Bitcoin consensus rules, it even assumes the opt-in behavior. As with Bitcoin Core updates, some nodes may not be able to return the handshake. In short, BIP 324 is backward compatible, which may count as a negative in its real-world ability to mitigate MITM attacks. 

After implementing this proposal (together with BIP 150) into Bitcoin Core, we could expect fewer MITM attacks, or at least have a tool in place that lets us compare session IDs and identify attacks. Also, it’s worth mentioning that although this proposal doesn’t cover the schemes for avoiding MITM attacks during the encryption initialization (known as Trust On First Use), BIP 150 does have this in its scope.

The author would like to thank Schnelli for his helpful comments on the article and would like to acknowledge the following sources:

  1. https://youtu.be/DKOG0BQMmmg?t=3h5m3s
  2. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016806.html
  3. https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52
  4. https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
  5. https://bitcoinmagazine.com/articles/bip-the-end-to-end-encryption-bitcoin-never-had-but-soon-will-1465401187
  6. https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch08.asciidoc
  7. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016355.html
  8. https://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-09-04-jonas-schenlli-bip150-bip151/
  9. https://bitcoinops.org/en/newsletters/2018/08/28/
  10. https://github.com/bitcoin/bitcoin/pull/14032
  11. https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52

The post BIP 324: A Message Transport Protocol That Could Protect Bitcoin Peers appeared first on Bitcoin Magazine.