What appcoin startups have in common with Midwest logging companies

Logging companies in the 19th century Midwest had a problem. In the remote forests where they set up shop, cash was hard to come by. Still, workers needed to be paid so they could buy food and other basic necessities. So the logging companies came up with a solution to the cash shortage: they would print their own currency.

This private currency, known as “scrip“, was denominated like U.S. currency and redeemable for goods and services exclusively at company-run stores. If a worker who received scrip in lieu of cash wanted to spend their paycheck elsewhere, the scrip would often trade at a steep 10 percent to 25 percent discount. Exchanging scrip for cash would result in additional exchange fees. And so most business was done at the company store.

Company scrip for the Network Age

Fast-forward 125 years and private currencies are once again being used by cash-strapped companies to keep operations running smoothly. Only this time, the companies are high-tech software startups instead of Midwest logging companies, and the currencies they are issuing aren’t simply a stand-in for cash. Private currencies have become a core part of new business models emerging around digital networks.

Often referred to as “appcoins”, these new private currencies are being used by issuers to simultaneously fund their businesses and bootstrap networks around their products. Unlike the company scrip of the past, appcoins are neither denominated in another currency nor redeemable for a fixed quantity of goods. Instead, the issuer designs their product in such a way that users have to dispose of some quantity of the appcoin to receive the value offered by the product. As a result, demand for the product results in demand for the appcoin, creating a virtuous cycle of adoption and price discovery.

The power of incentives

For early adopters of the appcoin, this virtuous cycle can result in a significant financial return, similar to the way that an early investor in a company can earn significant returns if the company is later successful and the value of their equity increases substantially. For example, if an early adopter of a product receives appcoins when there are only 1,000 users and the appcoin is valued at 100 satoshis each, and several years later the product has over 100,000 users and the price of the appcoin has increased to 10,000 satoshis each, this results in a 10,000 percent “return” for the early adopter.

The potential for financial return creates an incentive for people to adopt an appcoin product early on, even when the “cost” to doing so may be higher than using a more established alternative (for example, using a new social network app when there aren’t as many people to connect with as on other, more established apps). This incentive helps bootstrap the network, giving the app a fighting chance in the face of well-funded incumbents and speeding up the time-to-critical-mass that gives the network value and makes the app “sticky” for end users (or so the theory goes).

The future of appcoins

I have written before about why I am skeptical of appcoins. Disintermediation and centralization remain my top concerns. But given that there is no sign of the appcoin trend slowing down, with even “mainstream” apps with millions of existing users announcing plans to release an appcoin, it is worth thinking about what it would take for appcoin issuers to address these concerns and succeed with this model.

Appcoin issuers could reduce the likelihood of disintermediation by ensuring that there is as little friction as possible when exchanging currencies to use their app, while simultaneously doing all they can to increase the value of using the appcoin. And to minimize the risk that centralization has on the long-term value of their appcoin, issuers could create a succession plan to cede control of development to a more decentralized open source community.

The long-term future of appcoins is unknown. They could overcome these and other challenges and become a powerful tool for building products and bootstrapping networks. Or, they could disappear as dramatically as they appeared, destined to be a footnote in the pages of history like the company scrip that came before.

Featured image via WisconsinHistory.org

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1DbSQntfjitsJSLbqEiUpPuNdNC3JUFkD7

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

 

Bitcoin as the Trust Layer of the internet

In today’s era of ICOs, appcoins, and “permissioned blockchains”, I am often asked about what I think about the future of bitcoin. Will it still be relevant in 20 years? Will it ever be used as anything but “digital gold”? I believe the answer is “yes” to both of these questions.

Get you a blockchain that does both

First to answer the question “will bitcoin ever be used as anything but ‘digital gold’?” This idea of bitcoin as “digital gold” has been embedded in the minds of Bitcoiners since the beginning when bitcoin mining was first analogized to the process of gold mining, and the inflation curve was compared with the rate of gold production. Since then, however, this analogy has created what I see as an artificial and unnecessary debate about whether bitcoin is “digital gold” or “electronic cash”. The answer is that bitcoin is both.

Bitcoin the token is like a digital form of gold. The supply is limited, it gets harder to mine over time, and it’s valuable for monetary, industrial, and creative uses. At the same time, bitcoin transactions work a lot more like cash than a credit card payment. Transactions are expensive to reverse once confirmed, requiring a certain amount of computational “force” to pry coins out of the wallet of a recipient. And with the activation of Segregated Witness just weeks away, it will soon be possible to send bitcoin transactions worth fractions of a cent. Try that with the physical cash!

Beyond bitcoin as money

The feature that makes bitcoin valuable as both “digital gold” and “electronic cash” is the security or immutability of the blockchain. The computational guarantee that transactions are expensive to reverse provides a solid foundation upon which many useful applications and “Layer 2” protocols are being built. For example, enterprises are recording hashes in the blockchain to create verifiable timestamps for valuable datasets, and engineers are registering domain name records on the blockchain to create a more secure web architecture.

Despite snickers from veteran Bitcoiners over the “blockchain not bitcoin” rhetoric that dominated the FinTech press cycles in 2015, it turns out that both camps were off the mark. Permissioned blockchains are beginning to show real utility as auditable, cryptographically-secured, shared ledgers of record between disparate parties in given industries or business ecosystems. But to really gain the benefits of the blockchain, operators of these permissioned systems are realizing that they need a common “trust layer” that can be used to resolve disputes over conflicting transaction histories.

Thus we come full circle as “blockchain not bitcoin” becomes “blockchain with bitcoin”. The bitcoin blockchain is beginning to fill that need for a neutral “trust layer” upon which distributed applications and shared ledgers are being built. Developers are beginning to “anchor” snapshots of their databases into the bitcoin blockchain so that they can compare histories over time and catch any discrepancies in their records. They are also utilizing bitcoin’s Layer 2 protocols to create secure PKI and payment systems for their applications. It’s looking more and more like there will be many blockchains secured by bitcoin.

The bitcoin network of blockchains and applications

In the not-so-distant future we will see hundreds of blockchains processing trillions of transactions and thousands of applications with billions of users, all secured by bitcoin. There will be machines sending each other nanopayments for bits of information or joules of electricity, people transferring money overseas and across the internet, and applications anchoring data to and retrieving verifiable information from the blockchain.

These interactions will happen across layers of protocols that form fractal networks to enable robust and scalable application ecosystems. Sidechains and interoperability protocols like Interledger will enable trust-minimized transfers of bitcoin across different blockchains, each with their own unique features and applications. For example, people will be able to pay for Turing-complete smart contracts with bitcoin on the Rootstock sidechain, and the Liquid sidechain will enable faster, more discreet transfers of bitcoin between exchanges and wallets. The days of using altcoins for anything but pump and dumps and niche experiments will be a distant memory.

Keep It Simple, Silly

The reasons why I believe bitcoin will be the Trust Layer of the internet and not a competing open blockchain are twofold:

  1. Bitcoin already has a massive network effect, giving it a strong lead over competitors, and
  2. The bitcoin blockchain is relatively simple, which is great from a security perspective. As computer security expert Bruce Schneier has said, “Complexity is the worst enemy of security.”

The most obvious runner-up for the “Trust Layer of the Internet” title is ethereum, a cryptocurrency that has an impressive amount of hype for how unstable the network is. To its credit, ethereum is still very much a work in progress, and the hype is mostly due to overzealous startups and crowdsale investors than any concerted effort on the part of the core development team. That said, while ethereum seems to have the potential to catch up to bitcoin’s network effect, by its very nature it will never compare when it comes to simplicity.

I believe that the Trust Layer of the internet demands the simplicity of bitcoin’s limited scripting language, because it is much easier to reason about when analyzing the security properties of the system. With ethereum, it is fundamentally impossible to know whether or not a contract will be deployed that could crash the nodes in the network since anything is possible with a Turing-complete scripting language.

My personal view on this is that if you need Turing-complete contracts, you can use a sidechain or permissioned blockchain for that. Then if there’s a problem, it doesn’t damage the Trust Layer, the problem is isolated to the other blockchain. The same goes for any other experimental, novel, or exotic blockchain use-case.

Due to the costs of transacting on open and decentralized blockchains at-scale, most people will choose to transact off-chain anyways. Since the scripts required to support a range of off-chain transaction security models are relatively simple, it’s reasonable to conclude that bitcoin is “good enough” to serve as the Trust Layer upon which everything else is built.

My vision for the bitcoin application stack

After watching the evolution of bitcoin and the blockchain technology ecosystem over the last few years, the stack of protocols and services that developers are using to build the next generation of digital applications is becoming more clear to me. It looks something like this:

Bitcoin as the Trust Layer of the internet

Of course, developers won’t have to use each “brick” or even each layer in the stack when building their applications. But each component will be available for building centralized and decentralized applications alike, and at the bottom of the stack sits the Trust Layer, the decentralized arbiter of truth and justice – the bitcoin blockchain.

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1Cj8hNg9joC8FnS8D2FVFCvQUVy975VJZi

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

The differences between a hard fork, a soft fork, and a chain split, and what they mean for the future of bitcoin

Note: In this post, I will describe soft and hard forks in the context of the bitcoin protocol specifically, but generally speaking, these definitions and effects are the same for other blockchain protocols as well.

Update #1 07/31/17: Since the time that I first started writing this, a small group of bitcoin miners have decided to run software called “Bcash” that will initiate a hard fork on August 1, 2017. Godspeed to them.

Ever since the New York Agreement led to a new implementation of bitcoin called btc1, the topic of a bitcoin hard fork has been top of mind for many people in the bitcoin community, including myself. The btc1 implementation is designed to activate a hard fork (“Segwit2x”) approximately three months after the activation of Segregated Witness (“SegWit”), a soft fork upgrade to the bitcoin protocol.

With SegWit activation seemingly just around the corner, anxiety is building about the upcoming Segwit2x hard fork activation. But what is a hard fork, how is it different than a soft fork, and why are people so anxious about it?

To illustrate the difference between a hard fork and a soft fork, and the potential effects each may have on the bitcoin network, I will create several hypothetical scenarios. These scenarios will be intentionally extreme so that a hard fork and a soft fork can be shown in stark contrast and the differences may be clearly understood. By the end, I hope to permanently put to rest any misconceptions about each style of change and any misunderstandings about their definitions.

Soft forks

A soft fork is a change to the bitcoin protocol that restricts the ruleset enforced by full nodes that upgrade to enforce the soft fork rules. A block that is considered valid before the soft fork activates will be considered invalid by upgraded full nodes if it violates the new soft fork rules after the soft fork activates.

An example is a soft fork that restricts the block size limit from 1MB to 500kB. Even though a 1MB block was previously considered valid, full nodes that upgrade to support this soft fork will reject any blocks larger than 500kB after the soft fork activates.

Soft fork scenarios

In these example scenarios, I will show a soft fork “activating” even if there are no nodes or miners forcing activation simply for the sake of illustration. Imagine that there is software that would have activated the soft fork if it had been deployed.

All full nodes and all miners upgrade

SF - All nodes and all miners upgrade

In this scenario, there are no full nodes enforcing legacy rules and no miners producing blocks that conform to the legacy rules. All full nodes have upgraded to enforce the soft fork rules and all miners are producing blocks that conform to the soft fork rules. As a result, there is no chain split.

The winning blockchain in this scenario is the soft fork blockchain.

All full nodes but one upgrade and all miners but one with 1% of the hashpower upgrade

SF - All but one full node upgrades and all but one miner with 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the legacy rules. The rest of the full nodes are enforcing the new soft fork rules and the rest of the miners are mining blocks that conform to the new soft fork rules.

Since soft fork blocks are compatible with legacy rules, and the miners producing soft fork blocks have more hashing power than the one miner producing legacy blocks, both legacy nodes and soft fork nodes will follow the soft fork blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost cerainly the soft fork blockchain. The only way the legacy blockchain could win in this scenario is if it can attract substantial economic investment to catch up to the soft fork blockchain and overtake it. If it can do that, then in the eyes of the legacy nodes, the legacy blockchain will cause a reorganization of the blockchain and wipe out the soft fork blockchain. Soft fork nodes will not be aware of the legacy blockchain and will be safe from a blockchain reorganization.

All full nodes but one upgrade and only one miner with 1% of the hashpower upgrades

SF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the soft fork rules. The rest of the full nodes are enforcing the new soft fork rules and the rest of the miners are mining blocks that conform to the legacy rules.

Since legacy blocks are incompatible with soft fork rules, and legacy miners have more hashpower than the one miner producing soft fork blocks, legacy nodes and soft fork nodes will each see two different versions of the blockchain. This creates a chain split, albeit one that progresses very slowly on the soft fork side since the soft fork miner has only 1% of the hashpower.

However this scenario is not as clear-cut as it may seem. Remember that all full nodes but one have upgraded to support the soft fork rules, while all but one miner with 1% of the hashpower are producing legacy blocks. The miners on the legacy blockchain have only one full node that they can sell legacy bitcoin to, since all of the soft fork full nodes are rejecting legacy blocks.

Either the one legacy node will have to have a lot of purchasing power to sustain the legacy miners’ hashpower or the legacy miners will have to quickly upgrade to conform to the soft fork rules so that their blocks will be accepted by the larger soft fork-supporting full node network. This scenario is most likely to occur as a User Activated Soft Fork, a soft fork that is intended to be signaled by economic full nodes ahead of the activation date to give the miners time to upgrade and avoid a chain split.

The winning blockchain in this scenario is uncertain, depending on the relative economic power of the nodes enforcing the new soft fork rules and their willingness to experience long confirmation delays in the event of a chain split. The longer they can wait after a split, the more economic pressure they can put on the miners to upgrade.

If the miners do not upgrade, the soft fork blockchain will need to attract substantial economic investment to keep it safe from a 51% attack. With enough investment in hashpower, the soft fork blockchain could cause either a sustained chain split or, if it can catch up and overtake the legacy blockchain, a blockchain reorganization that wipes out the legacy blockchain.

Only one full node upgrades and only one miner with 1% of the hashpower upgrades

SF - Only one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is only one full node enforcing the soft fork rules and only one miner with 1% of the hashpower producing blocks that conform to the soft fork rules. The rest of the nodes are enforcing the legacy rules and the rest of the miners are producing legacy blocks.

Since the miners producing legacy blocks have more hashpower than the one miner producing soft fork blocks, the legacy nodes will follow the version of the blockchain produced by legacy miners. However because legacy blocks are considered invalid by the one soft fork node, there is a chain split, albeit one that progresses very slowly since the soft fork miner has only 1% of the hashpower.

The winning blockchain in this scenario is almost certainly the legacy blockchain unless the soft fork blockchain attracts substantial economic investment to keep it safe from a 51% attack, in which case the soft fork blockchain could cause either a sustained chain split or, with enough hashpower, a blockchain reorganization that wipes out the legacy blockchain.

No full nodes upgrade and no miners upgrade

SF - No nodes upgrade and no miners upgrade

In this scenario, all full nodes are enforcing the legacy rules and all miners are producing blocks that conform to the legacy rules. No full nodes have upgraded to enforce the soft fork rules, so there is no chain split.

The winning blockchain in this scenario is the legacy blockchain.

Hard forks

A hard fork is a change to the bitcoin protocol that loosens the ruleset enforced by full nodes that upgrade to enforce the hard fork rules. A block that is considered invalid before the hard fork activates will be considered valid by upgraded full nodes if it follows the new hard fork rules after the hard fork has activated.

An example is a hard fork that increases the block size limit from 1MB to 2MB. Even though a 2MB block was previously considered invalid, full nodes that upgrade to support this hard fork will accept any blocks up to 2MB in size after the hard fork has activated.

Hard fork scenarios

In these example scenarios, I will show a hard fork “activating” even if there are no nodes or miners forcing activation simply for the sake of illustration. Imagine that there is software that would have activated the hard fork if it had been deployed. I will also assume that the new hard fork rules do not contain a soft fork rule that makes legacy blocks invalid.

All full nodes and all miners upgrade

HF - All nodes and all miners upgrade

In this scenario, there are no full nodes enforcing legacy rules. All full nodes have upgraded to enforce the hard fork rules and all miners are producing blocks that conform to the hard fork rules, so there is no chain split.

The winning blockchain in this scenario is the hard fork blockchain.

All full nodes but one upgrade and all miners but one with 1% of the hashpower upgrade

HF - All but one full node upgrades and all but one miner with 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the legacy rules. The rest of the full nodes are enforcing the new hard fork rules and the rest of the miners are mining blocks that conform to the new hard fork rules.

Since hard fork blocks are incompatible with legacy rules, and there is one full node enforcing the legacy rules, there is a chain split, albeit one that progresses very slowly since the miner producing legacy blocks has only 1% of the hashpower.

The winning blockchain in this scenario is almost certainly the hard fork blockchain. For all intents and purposes, legacy nodes and miners have been “forked off” the network. The only way the legacy blockchain could survive is if it attracts a substantial economic investment to keep it protected from a 51% attack, in which case there could be a sustained chain split or, with enough hashpower, a blockchain reorganization that wipes out the hard fork blockchain.

All full nodes but one upgrade and only one miner with 1% of the hashpower upgrades

HF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is one full node enforcing the legacy rules and one miner with 1% of the hashpower producing blocks that conform to the hard fork rules. The rest of the full nodes are enforcing the new hard fork rules and the rest of the miners are mining blocks that conform to the legacy rules.

Since legacy blocks are compatible with hard fork rules, but hard fork blocks are not compatible with legacy rules, the legacy blockchain will out-compete the hard fork blockchain and both hard fork nodes and legacy nodes will follow the legacy blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost certainly the legacy blockchain. Although identical in network topology, this scenario ends differently than the soft fork version described above because hard fork nodes will not reject legacy blocks. So even though the vast majority of the network is running hard fork full nodes, there is no chain split and no economic pressure on miners to upgrade.

The only way the hard fork blockchain could win in this scenario is if it can attract substantial economic investment to catch up to the legacy blockchain and overtake it. If it can do that, then in the eyes of the hard fork nodes, the hard fork blockchain will cause a reorganization of the blockchain and wipe out the legacy blockchain. Legacy full nodes will not be aware of the hard fork blockchain and will be safe from a blockchain reorganization.

Only one full node upgrades and only one miner with 1% of the hashpower upgrades

HF - All but one full node upgrades and only 1% of the hashpower upgrades

In this scenario, there is only one full node enforcing the hard fork rules and only one miner with 1% of the hashpower producing blocks that conform to the hard fork rules. The rest of the nodes are enforcing the legacy rules and the rest of the miners are producing legacy blocks.

Since legacy blocks are compatible with hard fork rules, but hard fork blocks are not compatible with legacy rules, the legacy blockchain will out-compete the hard fork blockchain and both hard fork nodes and legacy nodes will follow the legacy blockchain. As a result, there is no chain split.

The winning blockchain in this scenario is almost certainly the legacy blockchain unless the hard fork blockchain can attract substantial economic investment to catch up to the legacy blockchain and overtake it. If it can do that, then in the eyes of the hard fork nodes, the hard fork blockchain will cause a reorganization of the blockchain and wipe out the legacy blockchain. Legacy full nodes will not be aware of the hard fork blockchain and will be safe from a blockchain reorganization.

No full nodes upgrade and no miners upgrade

HF - No nodes upgrade and no miners upgrade

In this scenario, all full nodes are enforcing the legacy rules and all miners are producing blocks that conform to the legacy rules. No miners have upgraded to produce hard fork blocks, so there is no chain split.

The winning blockchain in this scenario is the legacy blockchain.

Chain splits

As described in some of the scenarios above, a chain split is a scenario where there are two or more competing versions of the blockchain that share the same history up to the point that their rulesets diverge. While the term “chain split” can elicit feelings of fear among even the most battle-hardened bitcoin veterans, a chain split is not always the disaster scenario that some make it out to be.

As shown in the above hypothetical scenarios, it is possible for both a soft fork and a hard fork to cause a chain split. For example, in July 2016 a planned soft fork rule change called BIP66 led to a chain split and blockchain reorganizations due to some miners not validating the rules of the blocks they were mining on. Bitcoin recovered and here we are today.

Equally important to note is that it is possible for both a soft fork and a hard fork to avoid a chain split. The barrier to avoiding a disruptive chain split is much higher for a hard fork due to its incompatibility with legacy full nodes, but it is technically possible. For example, in August 2013 a planned hard fork was deployed in order to fix a bug that caused a chain split and blockchain reorganization in March 2013. The August 2013 hard fork resulted in virtually no disruption to the network since nearly all miners and economic nodes had upgraded their software by then.

It is also worth noting that chain splits can occur without a planned soft or hard fork rule change. A chain split can be caused by an unintentional incompatibility between two different versions of full node software, such as with the March 2013 chain split. Chain splits can even occur during normal bitcoin network operations as miners race to build a “winning” version of the blockchain that earns them new block rewards. The latter happens quite regularly, which is likely one reason why older versions of the Bitcoin Core wallet suggested waiting six confirmations before considering a transaction settled.

Sustained chain splits

The type of chain split that is perhaps most damaging to bitcoin, at least in the short term, is the sustained chain split. In a sustained chain split, there is sufficient economic and hashpower support on two or more versions of the blockchain to lead to there being multiple competing versions of the blockchain for an extended period of time. Holders of bitcoin on the “legacy” blockchain will also control an equal balance of “forkcoin” on each version of the blockchain that is extended when the divergence occurs.

There are several technical issues that can arise with a sustained chain split. One is the issue of replay attacks, where transactions meant for one blockchain are confirmed on another, which can lead to accidental losses of money. Another issue is the blockchain reorganization, where one version of the blockchain gets overtaken by another, potentially leading to a loss of funds by users who were relying on the history of the blockchain that was overtaken.

One of the biggest issues with a sustained chain split is longer-term and more social than technical: which blockchain gets to keep the name “bitcoin”? And will the brand confusion between the multiple competing versions of the blockchain damage investor confidence in bitcoin? These are questions that cannot be answered with a simple software patch, instead requiring subjective decision-making on the part of developers and industry leaders with regards to branding and public relations.

What these differences mean for bitcoin now and in the future

The version of SegWit that is activating soon is a soft fork. As of the time of this writing, 100% of the last 100 blocks are signaling support for SegWit (you can monitor this progress here). If this trend continues, then SegWit will activate with 0% chance of a temporary or permanent chain split. However three months after SegWit activates, btc1 will trigger the activation of the Segwit2x hard fork. Miners representing over 80% of the network hashpower committed in writing to supporting Segwit2x, leaving 20% who may continue to support the legacy blockchain, or possibly another blockchain, potentially causing a temporary or sustained chain split.

There is also the possibility of an “emergency” hard fork (EHF) at the time of the Segwit2x hard fork if there is a large enough part of the economy that rejects Segwit2x. This EHF may include a difficulty adjustment and/or a change to the Proof of Work algorithm to preserve the usability and security of the EHF blockchain. If users take this route, then Segwit2x could still lead to a chain split even with 100% legacy miner adoption. The probability of this happening depends on how strong the negative feelings are that users have towards Segwit2x.

This year will be looked back on as a pivotal year in the history of bitcoin. Given the incentives built into the system, I am confident that bitcoin will come out of all of this stronger than it was before. Multiple forks of the bitcoin blockchain may be competing for liquidity as a result of various fork proposals, and that’s okay as long as there is no unnecessary brand confusion in the marketplace. The incentives ensure that miners will eventually converge on the most valuable blockchain, or else go bankrupt.

I know what blockchain I’ll be using: the blockchain that secures the most value, with the most hashpower, the greatest potential for future adoption, and the best ability to preserve the “golden rule” of transaction immutability.

Header image via http://distributingchains.info/resources/the-blockchain-is/

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1Cj8hNg9joC8FnS8D2FVFCvQUVy975VJZi

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

New feature on the blog: bitcoin payment codes

Yesterday I took some time to download the latest version of the Samourai Bitcoin Wallet and register my new bitcoin payment code on their website paymentcode.io. I have started going through my back-catalog of blog posts and adding the payment code so people can send me tips if they like the content. You can see an example of what this looks like at the bottom of this post.

I have been interested in the idea of “stealth addresses” since they were first proposed several years ago and later implemented in Dark Wallet, and am glad to see the concept live on in the Samourai wallet in the form of BIP47 Reusable Payment Codes. Definitely check it out if you are interested in preserving your financial privacy while using bitcoin. Be aware that Samourai is still in alpha so manage your expectations accordingly.

Here is a video showing how payment codes work in the Samourai wallet:

 

Bitcoin tips accepted:

Bitcoin address (what’s this?) (QR code)

1Cj8hNg9joC8FnS8D2FVFCvQUVy975VJZi

Bitcoin payment code (what’s this?) (QR code)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

37 Days to SegWit: When SegWit is Live…

Ever since SegWit was first introduced at Scaling Bitcoin Hong Kong in 2015, I have found myself starting sentences with, “When SegWit is live…”, followed by some prediction about how this technology will supercharge bitcoin. In the spirit of the optimism around growing support for SegWit among miners and the broader bitcoin economy, I thought I’d share some of the things I’m excited about for “when SegWit is live” on bitcoin in 37 days (or less!).

When SegWit is live…

  • More transactions will fit in each block, and as far as I can tell this will not come at the expense of node or hashpower decentralization. In my humble opinion, more transactions per block is always a good thing as long as we don’t sacrifice the security of the system.
  • Transaction malleability will be fixed for SegWit transactions, enabling advanced scaling technology such as a more secure version of the Lightning Network. Lightning Network is very exciting because it opens up whole new micropayment-related use-cases that have simply not been possible on-chain.
  • It will be safer to increase the block size limit, due to the way that SegWit fixes the quadratic scaling of hashed data problem. As mentioned earlier in this post, more transactions per block is a good thing so long as bitcoin’s security is not compromised.

I’m very excited to see these and other benefits added to bitcoin because taken together, they strongly reenforce bitcoin’s leadership in the cryptocurrency market since virtually any cryptocurrency feature or use-case someone could think of will be possible either on bitcoin’s “mainchain” or a Layer 2 protocol such as sidechains or Lightning. This adds a tremendous amount of utility for the millions of people using bitcoin, and further increases the network effect and security that makes bitcoin such a powerful technology.

To the moon!

Bitcoin tips accepted:

Bitcoin address (what’s this?)

16XukVGi8YCiHwxrfjbmmXL241Dpmf9NcH

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

46 Days to SegWit: Growing Consensus in the Bitcoin Economy

You can read previous posts in this series here and here. You can find my guide about how to enforce the BIP148 UASF with your Electrum bitcoin wallet here. For templates that you can use to fill-in-the-blank and request that your favorite economic nodes and mining pools support the BIP148 UASF, scroll to the bottom of this post.

A lot has happened since last week’s blog post about the BIP148 UASF. Bitmain, the largest ASIC miner manufacturer, released their “contingency plan” for a “User Activated Hard Fork” in case the BIP148 UASF activates before the Segwit2x soft fork. The way I read this is that Bitmain is willing to do whatever it takes to avoid activating SegWit, which is quite surprising given that less than a month ago they signed the Segwit2x agreement to activate SegWit. If Bitmain would just signal for SegWit via BIP141 now, that would go a long way towards preventing a chain split on August 1. But I digress.

In more positive news, bitcoin developer James Hilliard submitted a pull request to the Segwit2x GitHub repository yesterday with code that attempts to make the Segwit2x deployment compatible with BIP148. While it’s not as good a solution as it would have been to make the proposal compatible from the start, this is likely the next best thing at this juncture. For that, I thank James for making the effort.

Continuing the theme of support for SegWit and BIP148, several important economic nodes have recently announced their support, undoubtedly thanks to the many supporters who have voiced their preference in public and private messages. These economic nodes include Ledger, a hardware wallet manufacturer, and the team behind Bitsquare, a decentralized exchange application. You can learn more about the growing support for SegWit and BIP148 among developers and economic nodes on this page of the bitcoin wiki.

If you support the BIP148 UASF, you should contact the folks behind your favorite wallets and exchanges if you haven’t already and ask them to enforce the BIP148 UASF. You can find fill-in-the-blank templates to do this at the bottom of the post here.

Since last week’s blog post I was also invited onto three different YouTube shows to discuss SegWit and the BIP148 UASF. You can watch these episodes below:

Hungarian Crypto Show

https://www.youtube.com/watch?v=dmtaQ55AZac

This Week in Bitcoin

https://www.youtube.com/watch?v=0wiWWQKswuY

Bitcoin News #42

https://www.youtube.com/watch?v=fXxW5wyeGrk

Bitcoin tips accepted:

Bitcoin address (what’s this?)

12Y353a3o6vLCNxEuenqydcc3jq47qKUwc

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ

How to enforce the BIP148 UASF with the Electrum bitcoin wallet

During a recent interview I did on This Week In Bitcoin, I was asked how to enforce the BIP148 UASF with the Electrum bitcoin wallet. I didn’t have a quick answer at the time so I decided to write up this guide.

Here are some easy instructions for how to do that:

(You can skip to step 3 if you already have the Electrum bitcoin wallet installed.)

Step 1. Install Electrum

Step 2. Create a new wallet and save your master seed in a safe place. You can also hook up your hardware wallet if you have one. [Ledger] [Trezor]

Step 3. In the menu bar click Tools -> Network

Step 4. Uncheck “Select server automatically”, paste electrum.satoshiportal.com into the Server field, then click OK.

Screen Shot 2017-06-10 at 12.57.56 AM

That’s it! The wallet is now talking to a server run by Francis Pouliot that will automatically enforce BIP148 for you. Use this wallet for all of your transactions to ensure that your wallet is enforcing BIP148. If you’re really tech-savvy you can also run your own Electrum server and configure it to enforce BIP148 for you.

WARNING: In the event that neither the economic nor hashpower majority supports BIP148 by August 1, you should undo the steps taken here to enforce BIP148. You can do that by checking the “Select server automatically” box on the Network page as in Step 3 above. If you don’t check this box, you could end up transacting on a minority blockchain after August 1, and your transactions will be at risk of getting reversed.

If you want to better protect your privacy when using Electrum, then on the Network screen select “SOCKS5” proxy on localhost port 9150 then click OK. Close Electrum then open Tor on your computer. Restart Electrum and it should sync with the Electrum server over Tor. Make sure whenever you use Tor with Electrum that you start Tor BEFORE you open Electrum and close Tor AFTER you close Electrum.

For more info about the BIP148 UASF you can read through these posts and the links contained therein:

https://lightco.in/2017/06/02/segwit-uasf/

https://lightco.in/2017/06/09/no-chain-split/

Bitcoin tips accepted:

Bitcoin address (what’s this?)

13aTqJXeRUDrfjBU8VwyWKvWpjNfFtvM5J

Bitcoin payment code (what’s this?)

PM8TJSxeAdmFzCyejSZsKwD5AN1Zxqm5Y4px6bJYTS63Lvu9x6patBZKHo693QCHxYKjgvZwrZN5cmgzwQgNzUPpri42NYHkhTe7A8cZoC6fdHDhS7TJ