Wrapped Bitcoin (WBTC) launched today on the Ethereum blockchain, with a total of 26 partners and 15 decentralized autonomous organization (DAO) members. First announced in October 2018 in partnership with Kyber Network and Ren, WBTC is an ERC20 token backed 1:1 with Bitcoin that brings Bitcoin to the Ethereum ecosystem.

BitGo’s role as a custodian

BitGo is lending its industry leading custody solution to the project, ensuring the secure storage of WBTC and providing proof of assets for the fully backed token. WBTC is the first asset-backed token with a transparent public dashboard where anyone can validate the total circulation of WBTC and number of Bitcoin stored. Supporting WBTC with the transparency of a 1:1 reserve brings trust to the token — a critical element that we are proud to have contributed.

Kyber Network, Prycto, and Airswap have minted WBTC from their own Bitcoin inventory, providing the token with initial liquidity and making it immediately available for swaps. View WBTC on CoinMarketCap.

Proof of Assets: Verify reserves yourself!

Here, we’ll show how you can fully validate (via the public blockchain) that BTC:WBTC are backed with a 100% reserve. While we have spent some time to build out the user interface as a demonstration, we invite savvy blockchain enthusiasts to build their own scripts to independently validate.

1. Go to https://www.wbtc.network/dashboard/order-book
2. The total WBTC is shown on this dashboard

3. To validate the total amount of WBTC supply check the blockchain or click the “token contract link” at:

https://etherscan.io/token/0x2260fac5e5542a773aa44fbcfedf7c193bc2c599

Note — you don’t have to rely on BitGo, you can view it on Etherscan

(as you can see, total supply is 72.4214 WBTC as of Jan 30, 2019)

4. To see the backing BTC assets click the “on-chain validation” link, which leads to the proof of asset page at https://www.wbtc.network/dashboard/audit

By clicking each Bitcoin address, you can validate the amount on chain. You can do this from any blockchain explorer like smartbit or blockchain.info.

Adding up the address balances leads to a total of 72.4216 BTC (as of Jan 30th, 2019). This matches the WBTC supply (viewed via Etherscan), and proves full 100% reserves.

Smart contract audit

All WBTC smart contracts having been audited by established firms including Solidified Technologies, ChainSecurity, Coinspect, and are publicly available.

The growing ecosystem

When we first announced WBTC, there were 12 partners on board. Today, WBTC is supported by 26 community partners including Dolomite, Dharma, Idex, Radar Relay, Blockfolio, SwitcheoNetwork, BZX, Ethfinex, dY/dX, imToken, CoinGecko, AirSwap, Compound, DDEX, Hydro, Gnosis, GOPAX, Loopring Protocol, MakerDAO, OmiseGO, Prycto, Ren, Set Protocol, The Ocean, Kyber Network, and BitGo.

The initiative is governed by a DAO committed to driving innovation for the entire ecosystem and maintaining a transparent governance structure. Working with this many partners on a single project was new, and a learning process for us. We’re pleased to have achieved community consensus and security via the DAO with multiple parties involved in minting and burning.

We thank everyone for their support in working together towards the development and prototyping of workflows, especially minting and burning. We’re excited to see the public already engaging with WBTC; our pre-launch mint and burn requests were discovered and shared with the community before the official launch and it is exciting to see such a warm response to this new token. You can view minting and burning via our dashboard here.

Why we’re excited about WBTC

What makes public blockchains like Ethereum so powerful is not just that many different participants can come together globally and trade, but that everyone can build emergent technology and infrastructure that is fully interoperable with an existing ecosystem.

Engaging with WBTC doesn’t require a special bridge, sidechain or additional technology. Any existing Ethereum ERC20 wallet can use it by adding the token address: 0x2260fac5e5542a773aa44fbcfedf7c193bc2c599.

When we first announced WBTC, we expected that the token would create additional liquidity for decentralized exchanges. Since then, we’ve been thrilled to see other applications and use cases, from decentralized lending to collateralization and insurance — that can be built on top of this infrastructure even without our involvement. The diverse blockchain community identifies exciting use cases far beyond what the technology was initially designed for. This unbound potential for new development is why we’re so passionate about building in this space.

January 15th 2019 Update

The Ethereum Constantinople hard fork has been postponed due to potential vulnerabilities. Visit the Ethereum blog for more information.

On January 16th 2019 the Ethereum blockchain will undergo a hard fork, implementing several significant upgrades to modernize and improve scalability of the blockchain. The Ethereum Constantinople hard fork is a key step in the roadmap before Ethereum 2.0.

The software upgrades are comprised of five Ethereum improvement proposals (EIPs) focused on improving the efficiency and lessening the costs associated with producing Ethereum transactions. The fork is expected to take place at block 7,080,000 — approximately 4:45am UTC based on current estimates.

Consensus for Constantinople

Unlike other hard forks, Constantinople is not a contentious fork for the Ethereum community. Consensus around activation of the EIPs appears to be reached for a seamless transition to the new, upgraded chain. We do not predict that the old chain will survive with significant hashpower.

That being said, at BitGo we treat hard forks carefully — even those that appear to have a majority consensus. To date, our methods for handling hard forks have kept client funds safe; during the Bitcoin SV hard fork in November clients funds were secured automatically with replay protection.

How we’re handling the hard fork

We will be suspending deposits and withdrawals for ETH and ERC20s during the hard fork. BitGo clients should expect approximately 30 minutes of downtime before and after the fork to have confidence that transactions can be conducted safely.

In preparation for the upcoming Constantinople upgrades, our Ethereum infrastructure has been updated. Clients running older software may be exposed to risk; they’ll see a version of their own chain which may have different sets of confirmed transactions.

Constantinople features five EIPs

EIP 145 will improve the Ethereum Virtual Machine (EVM) by adding native bitwise shift instructions. This will decrease the gas cost of this operation from 35 gas to just 3.

EIP 1014 will introduce off-chain transactions, similar to what Bitcoin’s Lightning Network provides, significantly improving the performance and throughput of Ethereum. Previously, Ethereum contracts had to be deployed on-chain before you could use them. Now, you can provide the address which corresponds to the contract you want to deploy, and the recipient can pay to the contract before you deploy. This means that developers are able to generate receive addresses without paying the deployment fee of the receive address until they want to spend from it. This EIP is also allows for certain off-chain state channel commitments to be possible without requiring a deployment of said state channel.

EIP 1052 provides a new EVM opcode that allows contracts to more efficiently verify another contract’s bytecode. By checking the contract by its hash (keccak256 hash of the contract’s code), the verification becomes much more cost effective.

EIP 1234 reduces the block reward from 3 ETH to 2 ETH and delays the difficulty bomb for 12 months as part of the transition from proof-of-work to proof-of-stake. The block time should remain at about 15 seconds.

EIP 1283 reduces gas costs for the contract storage opcode, enabling new usage for contract storage. This upgrade helps the Ethereum blockchain scale by allowing transactions to process faster and increasing adoption of decentralized applications by lessening their implementation costs.

If you have any questions regarding the hard fork, please contact us at support@bitgo.com.

Today we’re announcing Wrapped Bitcoin (WBTC), a collaborative effort with a community of partners to bring Bitcoin to the Ethereum network as an ERC20 token. The token will bring the stability and value of Bitcoin to Ethereum’s expansive ecosystem of decentralized applications.

BitGo will provide custody of the Bitcoin and tokenize it by minting WBTC together with approval from community members. It’s an exciting opportunity for us to build on our mission: making digital currencies usable for business.

WBTC users will be able to utilize Bitcoin in a wide variety of new decentralized use cases, including on decentralized exchanges (DEXs), as collateral for stable coins or lending, for payments and flexible smart contracts within the Ethereum ecosystem. The leading use cases will launch in early January, powered by important decentralized projects including Kyber Network, Republic Protocol, MakerDAO, Dharma, Airswap, IDEX, Compound, DDEX, Hydro Protocol, Set Protocol, Prycto, RadarRelay, and Gnosis.

For the first time, this digital asset will be tokenized with full proof of reserve, backed 1:1 with Bitcoin. Every Bitcoin will be accounted for on a dashboard displaying addresses and balances, and users will be able to verify on the blockchain each Bitcoin that is held in custody. This can be done by comparing the exact number of Bitcoin stored with the total supply of WBTC in circulation via a blockchain explorer like Etherscan.

This transparency brings trust to the digital currency, a critical element for any blockchain ecosystem. Trust is our business (in September we announced the launch of BitGo Trust Company, the first qualified custodian purpose-built for digital assets), and WBTC will employ the same secure processes that we have developed for institutional custody.

We’ve seen significant institutional interest in the tokenization of assets like securities, commodities, and real estate. For BitGo, WBTC is an opportunity to contribute technical leadership to the advancement of blockchain and tokenization platforms. We take a practical approach towards development: engineering and security efforts put into the creation of WBTC will be leveraged towards supporting future asset tokenization.

Last year we worked with industry partners, including the Royal Mint and CME Group, in an effort to tokenize gold, creating Royal Mint Gold (RMG). The WBTC initiative sees the tokenization of “digital gold”, and we look forward to applying our expertise with this token standard to further collaborations.

This is going to be a transformational community effort. We would love to invite all builders that see a need for tokenization and the use of WBTC to reach out and join the project!

January

Bitcoin began in January trading at $315, with Bitstamp taking heat shortly after when their hot wallet was compromised. Price action took a downward turn, hitting what would be lows for the year in the $170s. Braintree (Paypal) completed their integration with Coinbase, making it easy for merchants to accept Bitcoin. Later that month, Xapo announced that they would be bringing Bitcoin to satellites.

February

The conviction of Ross Ulbritch, founder of the silk road dark marketplace, was not a surprise; what did shock many was the subsequent discovery of corrupt agents involved in the investigation. That same month, Seals with Clubs, famed Bitcoin-only poker site, was shut down after a police raid. In better news for Bitcoin’s reputation, the first Bitcoin insurance policy with an A-rated insurer (XL Group) was announced by BitGo, the multi-sig platform running Bitstamp’s hot wallet.

March

BTCUSD rallied to just under $300 and then moved back down, where it would remain “stable” (in Bitcoin terms) in the $230-$250 range until July.

Abra announced their end-to-end remittance service to much fanfare, involving a network of mobile tellers in multiple countries (locking in the price of Bitcoin to prevent fluctuations).

Third Key Solutions launched it’s premium Key Recovery Service for handling backup keys in multi-signature wallets. Meanwhile, Chainlysis drew flak for launching fake Bitcoin nodes for the purposes of data forensics.

April

With an increasingly crowded exchange space and the lack of bull market trading volume, Buttercoin exchange abruptly closed it’s doors, unable to secure additional funding. It did not help that DD4BC, the hacking group attacking websites to demand Bitcoin ransoms, went full steam targeting Bitcoin companies. In other worrying news, problems brewing with the Bitcoin foundation surfaced, with an elected board member claiming funds were running dry (confirmed in December with 2 other members leaving).

May

This time it was Bitfinex in the spotlight as their hot wallet was compromised, losing 0.5% of the funds. They rebounded quickly and launched segregated multi-sig wallets with BitGo, where individual customers each have on-blockchain wallets. Also a watershed moment for Bitcoin was the opening of trading for $GBTC on public markets, and the launch of the NYXBT Bitcoin ticker on the New York Stock Exchange.

It was around this time that the block size / scalability debate surfaced, with many arguing for a larger block size to support the increased transaction throughput demands seen on the network. On the other hand, opponents pointed to the need for a fee market and the technical limitations of block propagation. The controversy continued for the rest of 2015.

June

Chain.com announced a partnership with Nasdaq to leverage “Blockchain technology” for stock issuance and transfer on private markets. This was part of the growing “blockchain” trend, a buzzword that grew in popularity with banks and financial institutions who wanted control of the technology. The New York Bitlicense was also released, imposing “Know Your Customer” requirements on even global companies, causing some of them to leave.

Blockstream released Elements, a working side-chains implementation capable of pegging tokens on a seperate blockchain to Bitcoin. This solution was seen by some as an alternative to scaling Bitcoin for payments. Coinwallet.eu also made reddit fame with their intent to “stress test” the Bitcoin network by spamming it with small transactions. Their “test” was scheduled for June 22 to demonstration the fragility of Bitcoin and as a statement against the block size. However, this first attack failed because their own servers and wallet couldn’t handle it.

July

Bitcoin transaction spammer Coinwallet.eu continued their spam attack, causing massive delays in transaction confirmations and forcing users to pay increased fees on the network. The adversarial network conditions also revealed many issues with unspent chains, dropped transactions and double spends. This continued until October where it was noticed that Bitcoin node numbers began to fall. Meanwhile, the price of Bitcoin tested the $300 point again, but did not succeed in breaking out.

August

Mark Karpeles, CEO of the failed MTGox exchange, was re-arrested and convicted of embezzlement. The blockchain vs bitcoin discussion continued. Bitcoin XT, a client running the BIP101 big blocks patch, was released, with the community divided and a potential fork of the currency looming on the horizon. As a response, the Scaling Bitcoin conference was planned to take place in September with hopes to bring developers / influencers together to deal with the issue.

September

BitPay, my favorite Bitcoin company (thanks to their selfless promotion of Bitcoin and contributions to open source), revealed that they had lost 5000 BTC as a result of a social engineering hack. Rumors had already been brewing, but the public saw visible cracks in their business when they laid off half their workers. While this was happening, blockchain startup R3 began gaining momentum, starting with support from 9 banks and growing to more than 40 by year end.

October

The blockchain narrative gained further steam with Coinprism launching OpenChain, Factom valued at 11m, and Microsoft Azure integrating Ethereum to provide blockchains-as-a-service. These organizations and several other startups (ChangeTip / Uphold / Circle) faced community backlash from their pivots towards blockchain / financial terminology. Will Bitcoin remain a settlement layer unknown to the common man? Not if the Cryptowall ransomware developers continue to infect computers — their virus netted them with $325 million in profit. Meanwhile, the adversarial environment on the Bitcoin network continued, with a transaction malleability attack causing more confusion and double-spending on users and wallets.

Bitcoin.com re-launched with a successful series of AMAs and /r/btc, gaining momentum due to certain amounts of censorship occurring on other popular communities such as /r/bitcoin and Bitcoin.org.

November

Just as the situation looked bleak for Bitcoin, hope appeared on the horizon when BTCUSD spiked up to the $400 range, reaching a short-lived high of $500 on the 4th of November and making headlines again. The price spurt caused increased interest, new entrants to the market, greater volumes on exchanges and more purchases using Bitcoin!

Coinbase partnered with shift card, making it possible to spend Bitcoins anywhere Visa was accepted. Also worth a particular mention was the release of the 21 Bitcoin Computer, promising a 402 Payment Required API marketplace where machine-to-machine payments and a self-sustaining Bitcoin ecosystem could thrive as the currency of the internet.

December

Scaling Bitcoin 2 was held in Hong Kong, with many core devs, important ecosystem players and almost all the miners in attendance. Shortly after, a roadmap of capacity increases for Bitcoin was published, involving segregated witness, IBLTs and the lightning network (all recommended reading). The improvements are possible with a soft-fork, as opposed to a block size increase. In other news, the SEC approved Overstock’s plan to issue stock on the Bitcoin blockchain. And on the 24th of December, Bitcoin celebrated the season with its 100th million transaction amid ever increasing usage volumes.

An action-packed 2015

Closing out on 2015, I have mixed feelings for the year. We have come far: just one year ago, exchange hacks were common and hardly anyone used multi-sig — today, it’s standard practice. We now have commercial deployments of payment channels and machine-to-machine APIs. But while Bitcoin has performed well enough to be declared the world’s strongest currency, the community is strongly divided over issues. Even though recognition of the blockchain has gone mainstream, many look to the blockchain and not Bitcoin as the catalyst to change the world.

Happy 2016, everyone! 2015 has been an exciting year. Here’s to the many more challenges we shall brave together on our epic journey to the moon!

Bitcoin Hackathon Ideas And Code To Bootstrap Your Project

My first hackathon experience began at Angelhack during the summer of 2012 at the AOL building in Page Mill road. I was excited because I wanted to build something fast, learn a new technology, and meet great people. There’s nothing like the late hour collaborations, open discussions with competitors, frantic coding (some of which I am not proud to show) and the satisfaction that I’d made something that worked. Over the years, I’ve noticed that my enjoyment level and chances at winning have been correlated with a combination of team quality, ideas, and preparation.

I’ll be judging and mentoring at the upcoming Bithack Bitcoin Hackathon at Plug and Play Silicon Valley. In this post I’ll share some Bitcoin ideas I’ve been thinking about and provide boilerplate resources for you to get a head start on your Bitcoin project.

Ideas

Bitcoin as a trigger to activate the Internet of Things

I believe very much in the concept of the connected home (see my girlfriend’s post on building an API for our z-wave based smarthome) and would love to see how Bitcoin can be used as a trigger to activate devices on the Internet of Things.

Currently at home, I’ve managed to integrate a Z-wave enabled lock such that paying with Bitcoin opens the front door, however I believe this concept can be extended further. Perhaps an Airbnb style app where paying users would pay Bitcoin to unlock the house, turn on the A/C, or use the washer? Going a little further, a vending machine could assign a Bitcoin address to each item, dispensing that item anytime payment is received. Implementation would not be challenging on the Bitcoin side — you could simply create a wallet and listen for transaction notifications to control your devices. Here are some other resources worth exploring on this topic.

Hash-locked Oracle Bitcoin Scripting

In the recent release of Bitcoin v0.10, standard script rules were relaxed for P2SH addresses. It is now (more practically) possible to create transactions which can require (Hash of X revealed and signed by X) OR (Hash of Y revealed and signed by Y).

A public service could be provided that revealed different hashes at various time intervals (e.g. every hour) depending on the outcome of an external state, such as: “Hash A will be revealed if BTC is above $250 USD on June 30th, or else Hash B will be revealed”. This information could be published on the blockchain for all to see.

This would enable any number of parties to utilize this hash within blockchain scripts such that they could make bets amongst themselves, without the service getting involved with any form of money. The service will have minimal reason to publish the wrong hash since everyone would know (and never trust them again).

Zero Click Automated MicroPayments

Bitcoin has payment protocols that allow you to specify how much to pay, but not when to pay it. At a past hackathon, I worked on ZeroClick, a chrome browser extension and service which utilized the unused HTTP 402 Payment Required status code as a trigger to automatically pay for videos and resources on the web (as opposed to a credit card payment or advertisements). I’ve also created a spec for the protocol, and there is various code in the wild at different stages of implementation.

Bitcoin opens a new world where machines can now transact with each other automatically. While we have some clue of how we think it should work, this idea is still in search of a truly compelling use case, and I believe that unlocking and launching the product will depend on service integrations for which scenarios have yet to be explored.

Pay to beacon (service in area)

I’ve used Bitcoin to pay for services and food (I love sushi!) on my phone, but this involved waiting for the waitress to give me a QR code to scan. This is a situation which we could solve better through the use of geofencing and the payment protocol. In my mind, the flow could be made as easier:

1. I inform my server when I’m ready to pay at a restaurant.
2. When I start my Bitcoin client app, my phone could use either geofencing (online coordinates database) or a local device (Bluetooth etc) placed at the venue to show me a list of potential payees.
3. The payment screen could allow me to select what to pay for (just in case there are multiple invoices to be settled). The items can be shown and the payment protocol should help identify the organization paid (by showing the cert owner on the top of the screen).
4. I should be able to pay and leave without using the phone keyboard.

It’s worth noting that this can be achieved without the need for a native app (though that would be preferable).

Subscription service

Bitcoin enables push transactions (as opposed to pull transactions with credit cards), and this model has made it difficult for merchants to accept recurring payments. If I were subscribing to various services in Bitcoin, I’d like to receive a monthly list of subscriptions so that I could pay for them all in one place. This could be a page where I could check off the subscriptions that I’d like to continue (e.g. Amazon Prime, Snack-box-a-month, domain renewal, etc) and to automatically cancel the others. The challenge would be in creating a way for the merchants to initiate such a service.

Backup Key Storage Service

A common multi-sig model adopted by co-signing wallet services (like BitGo, where I work) today involves the user creating 2 keys and the service creating 1 key (in order to preserve user custody of funds). However, most users do not want to hold multiple keys themselves:

• They don’t have more than 1 device capable of safely generating the keys.
• They are not technically savvy enough to generate keys on multiple devices.
• They prefer not to undergo the burden of holding so many keys.

The solution should be another party that provides backup keys as a service (such as Third Key Solutions). The need for such a service is real, but most of this is done manually today. A simple service and protocol could:

1. Signs users up with sufficient identifying information to be verified in the case where keys need to be used.
2. Generate a private/public keypair and store it securely, only revealing the public key for use in multi-sig transactions.
3. Provide a way to deliver the public key to the multi-sig wallet service and the user, and a means for these 2 parties to verify that key was not changed by a man-in-the-middle attack.

Better experiences when sending BTC to friends

Sending and receiving money between friends could and should be made easier. While the community has been decent at creating platforms and services for Bitcoin, sending money (for example, small amounts to pay for a meal) still often involves getting hold of a Bitcoin address or scanning a QR code — we can do better.

We need only look at examples of how products like Venmo, WhatsApp and Bump have leveraged social networks and locational services to link people up with each other. Venmo uses the Facebook graph, WhatsApp uses your phone contacts to pre-populate people to talk with, and Bump intelligently paired you up with people in close proximity. Using a combination of these techniques, we should be able to better solve peer to peer money transfer such that it doesn’t require the use of a camera or on-screen keyboard.

Bitcoin Plays Pokemon

Heard of Twitch Plays Pokemon? What if we made it such that small amounts of Bitcoin were table stakes for getting in on the game? It could minimize the number of spammers controlling Ash. This needs more thought, as the incentive structure for such a game would need to be tweaked. Further, the Bitcoin network can only take up to 7 transactions per second, so perhaps we’d need to look into either micropayment channels or other units of use to charge for (e.g. one transaction of 0.001 coins for up to 100 moves). This project would also make for a cool demo — I’ve wanted to work with micropayment channels for some time and there aren’t many applications of it in the wild.

Bitcoin Reward Campaigns

Many retailers have loyalty programs where users are given points or cashback rebates for shopping. This shouldn’t be limited to the big guys. What if such campaigns were simple to integrate and paid out small amounts of Bitcoin?

Further, social proofing and sharing is very desirable in our world today. Brands and events have taken to giving out rewards such as chances to win competitions, early access, etc just to get users to share their products and events (there’s even a service to set that up). Bitcoin rewards campaigns can be set up for desirable actions (share this post to get Bitcoin!) and not simply purchases. This would help get our magic internet money in the hands of more people!

Joint payment plans / Group-funding

There are many crowd-funding websites but they take large amounts of fees, and are not always suitable for personal use (amongst people who know each other). With Bitcoin, we can quickly create a simple and inexpensive way for multiple people to buy a gift together.

1. “Gift starter” chooses a gift (e.g. a Vase on Overstock) and the amount gets converted into BTC to be funded. A wallet with different receive addresses for each contributor can be created (on a multi-sig service like BitGo).
2. A page is set up (similar to a kickstarter page) on the service, asking for funding for the item (and displaying the wallet receive addresses), and giving a deadline. Meanwhile the item is “reserved” or placed on layaway on the merchant site. Individual users contributions can be tracked since there’s a separate address given to each one of them.
3. When the wallet has sufficient funds, the service processes the order. If the wallet does not reach the “tipping” point, then all funds are returned to the original owners.

Multi-Signature Physical Coins

The easter season has just passed, and I’ve been toying with the idea of a Bitcoin multi-signature easter egg treasure hunt. Each “egg” or “coin” would be a single private key in a 2-of-3 (or more) multi-sig address, and players would need to find more than one of them (or trade) in order to redeem prizes. This concept could be applied to physical-style casascius coins, where we could create physical multi-signature casascius coins that require multiple parts come together in order to spend funds.

I hope that these ideas will serve as a starting point to inspire hackers to unleash their creativity. I look forward to checking out cool hacks this Saturday!

Bootstrap your project with the Hackathon Starter boilerplate app — now comes with a Bitcoin Wallet!

Other than forming a team and coming up with an idea, the next (and probably easiest) advantage you can get before any hackathon is to prepare your development environment. Many hackathon projects will end up requiring a backend service, user login system, basic template design and other such patterns.

I came across Hackathon Starter, a node.js boilerplate app that ships with a large number of pre-integrated Oauth plugins and common API integrations (in a lightweight, easy-to-use manner). The codebase is simple to understand, and I was able to quickly “hack in” the full BitGo Wallet API to the list of pre-rolled integrations. A Bitcoin wallet now ships out of the box with zero configuration:

https://github.com/bencxr/hackathon-starter

All this can be yours in 10 minutes!

Good luck and have fun!

I’m really looking forward to being at the hackathon and meeting other great Bitcoin enthusiasts. See you there, and don’t forget to say hi!

How you can have your own crypto-currency exchange with multi-sig security

Bitcoin’s history is rife with drama about the closure of one exchange after another. Problems have ranged from outsider hacking attacks to insiders holding servers hostage. I've long been curious to understand these stories better — How do exchanges work behind the scenes? How much would it cost to set one up? And if that were cheap, how would one run an exchange and stay in business (without losing customer funds)?

Like many others, I had long toyed with the idea of building my own exchange. A few months ago, I registered the domain 21million.club, because there would only ever be 21 million bitcoins, and buying one would make you part of the club. I never got around to building the exchange due to time constraints. Also, for practical and security reasons, I didn’t want to re-invent the wheel.

Just recently, I was pleasantly surprised when friends over at BitSpark (a multi-currency exchange in Hong Kong) told me about Peatio, an open-source crypto-currency exchange that was free for anyone to download and run. It boasts several enterprise exchange features, including a high-performance matching engine, scalable distributed worker threads, and SMS 2-factor authentication out of the box. It also has several features relevant to crypto-currencies, such as integrated withdrawals and deposits to Bitcoind and a built-in proof-of-solvency audit. However, one security feature missing was support for a multi-sig cosigner. By default, Peatio connects to a BitcoinD instance with an unlocked wallet — this meant that any hacker with access to that machine would be able to get away with all the coins.

Peatio is great as an exchange, but I feared for those who ran it in production — would security on their machines be strong enough to prevent hackers from repeating history in the long run? Since I work at BitGo, I decided to embark on a side project to enable multi-sig support in Peatio. I wanted to do this as a challenge to see how difficult it was to get enterprise-grade security on open-source exchange software. If it were possible, I’d be a step closer to running my own exchange☺.

The goal was to hook Peatio up such that withdrawals and deposits would continue as usual during normal operations. The exchange software would sign one half of the transaction, and BitGo the other half, but with the added safety of co-signing policies. For example, if the number of withdrawals exceeded a daily limit, or the withdrawal requests came from an unknown IP, the co-signer could require additional steps to sign the transaction.

The following steps detail my journey and provide instructions on how anyone can now have an opensource exchange with multi-sig support.

Step 1: Set up Peatio

Using a fresh Linode Ubuntu instance with 4GB ram and 96gb SSD, I began by installing Ruby, Mysql, Redis, RabbitMQ, and BitcoinD. Then, I followed the instructions here to install Peatio. I hooked up the Bitcoind RPC in the currencies.yml file:

- id: 2
 coin: true
 quick_withdraw_max: 1000
 key: satoshi
 code: btc
 rpc: http://rpcuser:rpcpassword@127.0.0.1:18332

This worked! I was able to sign up for a customer account on the exchange and get a deposit address from the local bitcoind (note the address begins with m, a single-key address on testnet).

Step 2: Install BitGo Multi-Sig

Recently, during the integration with Bitstamp, BitGo built a drop-in replacement for BitcoinD. Called BitGoD, it responds to the same RPC commands as BitcoinD, including getbalance, listtransactions, listunspent and sendtoaddress. Since Peatio also uses BitcoinD in the backend, I saw this as the simplest integration path.

I installed BitGoD by cloning the open source project from git:

git clone https://github.com/BitGo/bitgod.git
cd bitgod
npm install

I inspected the Peatio code and identified that it was calling bitcoind expecting “payment” as the account name. BitGoD needed to be able to handle this:

bin/bitgod -masqueradeaccount=payment

Finally, I made a change to Peatio’s currency.yml file, pointing the RPC port to 19332 (which BitGoD was listening on)

- id: 2
 coin: true
 quick_withdraw_max: 1000
 key: satoshi
 code: btc
 rpc: http://rpcuser:rpcpassword@127.0.0.1:19332

I had to restart the Peatio daemons after this.

Step 3: Connecting the Multi-Sig Wallet

I excitedly went to the deposits page in Peatio, hoping to see a multi-sig deposit address created. This failed as BitGoD was running, but not yet connected to a wallet on BitGo (doh!).

To connect BitGoD to BitGo, an access token and a BitGo multisig wallet is required. To get the access token, create a Bitgo test account for the integration and head down to the Settings — >Developers tab. Then you can connect to the account using

bitcoin-cli -rpcport=19332 settoken [YourToken]

Next, create a BitGo wallet (from within the BitGo interface) and tell BitGoD the wallet address:

bitcoin-cli -rpcport=19332 setwallet [YourWalletAddress]

I had to create a new customer account on the exchange to generate a new address. From then on, the exchange gave out multi-sig addresses for deposits (as you can see in the example, the address starts with 2)!

Step 4: Bitcoin Deposit Integration

Although the deposit addresses were generating and showing up fine, incoming Bitcoin deposits to the addresses were not reflecting on the customer’s balance. The reason for that was that Peatio was not being notified of the incoming transactions.

To inform Peatio about the new coin deposits when they occurred, I added app/controllers/webhooks_controller.js to accept an incoming webhook:

class WebhooksController < ApplicationController

before_action :auth_anybody!
 skip_before_filter :verify_authenticity_token

def tx
 if params[:type] == "transaction" && params[:hash].present?
   AMQPQueue.enqueue(:deposit_coin, txid: params[:hash], channel_key: "satoshi")
   render :json => { :status => "queued" }
 end
end

(Note how Peatio only accepts the Transaction ID— the deposit_coins daemon uses this to kick off checks on the deposit address and then verifies the transaction amount)

Here is the new route in config/routes.rb:

post '/webhooks/tx' => 'webhooks#tx'

After restarting Peatio, I then set up BitGo to send transaction notifications to the new route using the wallet Webhook API:

WALLETID=2NEe9QhKPB2gnQLB3hffMuDcoFKZFjHYJYx
ACCESS_TOKEN=9e1194fd035e2c8d5268e648c796425429fc2bd57bb5da7fbebbf09e1711a6b6

curl -X POST \
-H “Content-Type: application/json” \
-H “Authorization: Bearer $ACCESS_TOKEN” \
-d “{ \”url\”: \”http://www.21million.club/webhooks/tx\", \”type\”: \”transaction\” }” \
https://test.bitgo.com/api/v1/wallet/$WALLETID/webhooks

I sent some coins in, and they showed up on my customer account in the exchange!

I waited a while for the deposit to be confirmed. The exchange software polled the transaction until it saw a confirmation before updating the customer account balance. It even sent me an email! ☺

Step 5: Withdrawals and Policy Limits

Now that customer multi-sig deposits were being handled, it was time to integrate withdrawals from the wallet. In order to do this, I needed to give BitGoD the wallet passphrase (used when creating the BitGo multi-sig wallet):

bitcoin-cli -rpcport=19332 walletpassphrase [passphrase] 1500000

Some background: when sending a transaction, BitGoD decrypts the user encrypted key with the wallet passphrase, creates/signs the transaction and sends it to BitGo for co-signing and transmission to the Bitcoin network. Since key decryption and signing is done locally, BitGo never has access to the user’s private key.

Withdrawals worked seamlessly in the exchange through the multi-sig wallet. I also set up a 2BTC policy limit on the wallet. In the above example, the 0.2BTC withdrawal was processed immediately, with the larger request pending approval by an additional user (such as the CTO or CEO) in the BitGo interface.

Such transactions require a human administrator to log in and input their OTP and wallet passphrase before being co-signed . This prevents theft by stealing private keys. I pondered developing a callback policy (through another route) to have BitGo perform an additional check with Peatio on whether the transaction matches the user balance... but decided to leave that optimization to a later time.

Final Thoughts

I had fun playing with Peatio as a free open-source wallet solution. As I was new to Ruby/Rails, it did take me some time to figure out the inner workings of the code and write the new webhook routes, but I felt it rewarding to be able to play with an exchange of my own.

We live in interesting times. Thanks to open-source, we now have free access to tried and tested exchange software to run businesses on. With Bitcoin and P2SH (multi-sig), it’s now possible to have multiple parties approve a transaction before funds get sent, while never putting control of funds in the hands of the security provider. There are few reasons left to code your own trading system or implement your own wallet security.

Build your exchange on a stable foundation and your customers will thank you for it in the long run. Let’s all stay a part of the 21 million club!

A Local REST service to sign transactions in a secured environment

I recently joined BitGo, leading the developer platform team tasked with helping Bitcoin exchanges and partners integrate multi-signature wallets. Over the past few months, I’ve come to notice that a major hurdle towards multi-sig integration has been the cost of engineering resources. A personal friend of mine who owns a small exchange told me that they’d need to delay multi-sig to work on growth features, such as Facebook connect and tipping. I see his point: end-users care about features, but often don’t care about security until it fails.

At BitGo, we operate 2-of-3 multi-signature wallets where we control a single key to co-sign transactions. The security model requires that transactions must be signed by the user, who should keep their key secret. Developers have asked for REST APIs accepting their private key, to which we had to refuse — that would make BitGo privy to more than one key, and thus in control of customer funds.

BitGo has a Javascript SDK to help create and sign transactions, and we are actively building support for other languages, but for the moment, companies not running NodeJS had to write code to provision private keys, craft transactions and sign them. I wanted to make sending Bitcoin as simple as a REST call. No matter the language of choice, a developer should not have to implement cryptography and low-level Bitcoin logic.

The solution: BitGo Express, a local service that runs in your datacenter to handle client-side Bitcoin operations involving customer keys. It exposes endpoints that will prepare, sign and send partially constructed transactions to BitGo. This is done in a unified interface on top of other existing (and proxied) API endpoints.

Here are some of the new endpoints available (click for documentation):

Send Coins
Send Coins to Multiple Addresses

Create a keychain locally
Provision a wallet (including creating keys)

We also provide some helpful utilities:

Decrypt an encrypted string
Encrypt a string
Verify a Bitcoin Address

BitGo Express is available today. Let me know how/with what languages you’re using it!