Category Archives: Bitcoin

Bitcoin, btcwallet

Paymetheus: A Windows Bitcoin Wallet

Leave a comment
Paymetheus screenshot

Early Paymetheus screenshot. Can you spot the bug?

The btcsuite project started out of a desire to create high quality and usable Bitcoin tools and libraries. Early on, it was decided that Go, a type-safe and portable language, would be used. Go has been a great tool for us, but one sticking point has been the area of native graphical frontends for our software. Some previous attempts were made to write GUIs in Go, but the user experience always suffered in one way or another.

We still wanted to provide a nice graphical interface to our software that a user would enjoy using. To solve this issue, we took the pragmatic approach of developing native GUIs with languages well supported by their respective operating systems.

Paymetheus is the first result of this development. It is a Bitcoin wallet for the Windows 7/8.1/10 operating systems written in C# and WPF. Paymetheus reuses much of our existing Go code by using RPC to communicate with btcwallet under the covers. Like all of our open source software, it is freely available under the ISC License.

Continue reading →

Bitcoin, btcd

Iterating Bitcoin

Leave a comment

After spending more than 2.5 years financing and overseeing the development of an alternative full-node Bitcoin implementation, btcsuite, it has become clear that Bitcoin has several serious organizational problems. In my previous blog entry, I characterized these problems and their various facets. The main problems are governance, funding development and proof-of-work (PoW) miners having too much power. Over the past 1.5 years I and several developers have been working to propose, code, test and evaluate modifications to Bitcoin that would address these issues. The most fundamental of the changes we have made are based on proposals for hybridized PoW/PoS (proof-of-stake) systems, such as MC2 and proof-of-activity (PoA) by Iddo Bentov, Charles Lee, Alex Mizrahi and Meni Rosenfeld. In order to create a sustainable system of governance, we have created a project Constitution and extended the notion of consensus hybridization to apply more generally as one of several layers in a stratified consensus system. This stratification allows various groups of stakeholders to have representation at various consensus layers. Beyond a layered hybridized consensus system, we have added a consensus rule that allocates 10% of each block reward to a development fund that will be used to pay for ongoing development and related activities. By allocating 10% of each block subsidy to the development fund, continuous development and improvement of the software is possible without the conflicts of interest present in current Bitcoin Core (BC) development process.

151207 iterating bitcoin

Iterating Bitcoin

Hybridized PoW/PoS

The notion of hybridized PoW/PoS is fundamental to what follows, so a bit of an overview is warranted. A consensus system that uses pure PoW is subject to a number of issues: denial-of-service via mining empty or artificially small blocks, censorship by not including certain transactions in blocks and miners having the ability to block or force consensus changes. One way of looking at this situation is to view PoW as providing a single authentication factor to the consensus system, where the PoW is typically performed by one of a small number of entities that do not necessarily represent the rest of the participants in the system. While this process is fundamentally decentralized, practical considerations lead to the PoW mining process becoming very centralized, similar to trusted 3rd party systems, e.g. banks. Hybridizing PoW and PoS creates a second authentication factor for consensus, wherein PoS miners can vote for or against the previous block generated by a PoW miner. If enough PoS miners vote against the previous block, the PoW reward from that block can either be reduced or eliminated entirely, meaning that PoS miners act as a check on the behavior of PoW miners. In the scenarios described above, PoS miners can vote against PoW blocks that they disapprove of, providing a clear incentive for PoW miners to not engage in what most of us would agree is questionable behavior.
Continue reading →

Bitcoin

Bitcoin’s biggest challenges

7 Comments

I have been participating in the Bitcoin ecosystem for the past 2.5 years, and it has become clear to me that there are several persistent and serious issues with Bitcoin from an organizational perspective. While many people are not familiar with who I am, they may be familiar with the btcsuite project, which I finance entirely by myself and contribute to via the developers I work with. In early 2013, after one of my developers had a less-than-pleasant interaction with the Core developers regarding porting bitcoind to OpenBSD, I decided that making an alternative from-scratch implementation of Bitcoin would be an interesting project and benefit the Bitcoin community by offering an alternative to the Bitcoin Core (BC) monoculture. Having rebuilt the Bitcoin infrastructure from the ground up on my own dime, I have a rather unique perspective on Bitcoin despite being late to the game. I have identified what I consider to be several persistent and severe problem areas with Bitcoin: project governance, funding development and proof-of-work miners having too much power.bitcoin biggest challenges

Project governance

As many of you are well aware, Bitcoin has been suffering from a long-running clash of views about whether to increase the maximum block size or not. Informal surveys and content on twitter indicate the majority of businesses and miners support increasing the block size, but a majority of BC developers oppose this increase. There are at least 2 less-than-ideal resolutions to this argument:

  • Allow BC developers to force the maximum block size to stay at 1 MB, effectively vetoing the community.
  • Create a fork of BC that allows larger blocks, and have enough miners and businesses switch to force the block size increase, effectively vetoing the BC developers.

Neither of these options are very appealing, and more importantly than any resolution that is eventually reached, it reflects a very real crisis in governance. In order to better understand the current crisis, it is worthwhile to quickly recap the history of Bitcoin governance since it was introduced in 2009.
Continue reading →

Bitcoin, btcd

Btcsuite: Announcing Btcd 0.12.0 Release

Leave a comment
btcd

btcd

We’ve just released btcd version 0.12.0 beta! It is a highly recommended updated since it contains code to ensure new upcoming network rules are properly enforced (CLTV), new protocol enhancements, various optimizations, and several other enhancements.

Overview

In addition to announcing the new release, the purpose of this blog is to discuss a few points of the release in more detail. For those of you who are simply looking for the release notes and updated Windows binaries, they are located here.

The most important changes this post will cover are:

  • CHECKLOCKTIMEVERIFY (CLTV) support (BIP0065)
  • Enforce LowS signatures for transaction relay
  • New flag for controlling the minimum relay fee
  • Bloom filter service bit support (BIP0111)
  • New signature validation cache
  • Developer-centric changes:
    • Refactored peer package
    • New options when querying address index
  • Under development

Continue reading →

Bitcoin, btcwallet

Btcwallet 0.6.0 Release

Leave a comment

Today we are releasing btcwallet 0.6.0, along with a minor release to btcd (0.11.1) which is required to build the new btcwallet. This wallet release primarily focuses on adding account support, integrating transaction history in the new database, and making wallet an importable package for reuse in other binaries. As always, general fixes and improvements all around are included. See the release notes for the full details.

Accounts

Multiple account support

Multiple account support

btcwallet takes a different approach to accounts compared to Bitcoin Core wallet, and it’s important to understand why this is done and how it affects usage. In Bitcoin Core, account balances and the addresses used to receive outputs are separate concepts, and balances can be moved across accounts without an on-chain transaction. While this model certainly has its uses, we feel that it comes with disadvantageous privacy implications as well, since outputs received by an address of one account can be spent when debiting a balance from an unrelated account.

Continue reading →

Bitcoin, btcd

Btcsuite: Announcing Btcd 0.11.0 Release

1 Comment
btcd

btcd

We’ve just released btcd version 0.11.0 beta! This release contains quite a few enhancements and is a required update.

Overview

In addition to announcing the new release, the purpose of this blog is to discuss a few points of the release in more detail. For those of you who are simply looking for the release notes and updated Windows binaries, they are located here.

While it certainly doesn’t cover everything in the release, the main topics this blog will cover are:

  • Required update
  • Transaction malleability reduction (BIP0062)
  • Support for a limited RPC user
  • Enhanced peer control
  • Upcoming changes

Continue reading →

Bitcoin

Btcwallet 0.5.0 Release and Roadmap

Leave a comment

Last week saw the 0.5.0-alpha release (and a 0.5.1-alpha bugfix release) of btcwallet, our Bitcoin wallet daemon.  This release was largely focused on architectural changes for improved security, privacy, and performance.   Highlights of the release include a new wallet database and the introduction of a hierarchical deterministic address manager.

caption

Example BIP0032 hierarchy: All keys for all accounts are deterministically derived from a single seed.

Continue reading →

Bitcoin, opsec

Faraday cages and Bitcoin

Leave a comment

Bitcoin has redefined what it means to possess and transfer value, in that the value is no longer entrusted to a 3rd party, e.g. a financial institution, and is instead based solely on the cryptographic keys (“keys”) possessed by the owner or controller of that value. While it is substantially liberating to not require 3rd parties to effect transfers of value, this liberty comes with a substantial increase in personal or organizational responsibility on part of the party that controls the keys that correspond to that value. In order to spend bitcoins, one must create a transaction signed with one or more of these keys on some kind of computer hardware, whether it’s a desktop computer or a calculator-like device. Compromise of the hardware or software that handles these keys could lead to immediate irrevocable theft of the funds they correspond to, which is a much worse failure mode than what could happen with funds stored at a typical financial institution.

Put bluntly, this means “if you get hacked, your funds are gone”, a rather serious and hopefully avoidable failure scenario. Taking a note from military and intelligence services, I felt that it made sense to electromagnetically isolate hardware used to handle Bitcoin keys from their surroundings to reduce their attack surface. Conveniently enough, this problem has already been addressed for the past several decades by a number of companies, so I contacted LBA Group about making a customized version of an existing Faraday cage they manufacture, the EMFaraCage FC-10S. The customized cage has filtered 110V power, an internal power strip, intake and exhaust fans and can hold 2 desktop computers.

EMFaraCage front (open)

EMFaraCage front (open)


Continue reading →