Sabtu, 29 September 2018

Making a Bitcoin service HD Wallet Web - It looks like Bitcoin is developing really fast these days, both on the usage and on the technical side. There are a lot of usability issues, and ideas for bitcoin services that look great on paper but don’t exist yet. Many of those ideas will be created with time, some of them though it’s better to go ahead and make as soon as possible, to let people use and see the advantages and disadvantages.

One of the most interesting ideas I’ve read so far is the creation of the Hierarchical Deterministic Wallet, or Bitcoin Improvement Proposal (BIP) 32. It is trying to solve the problem that currently the standard Bitcoin clients need generate independent new Bitcoin addresses to the user, and store a piece of secret in a wallet file for every Bitcoin address a person has. If that file is gone and not backed up, the person will lose access to those coins permanently.

Others tried to fix this too, like Armory and Electrum, two clients that can generate a whole chain of addresses, though have their own limitations that I don’t go into (though at the moment I’m using Electrum for most my coins).

BIP32 on the other hand can generate infinite number of new address from a master secret, and all of that arranged in a hierarchy that one can create well separated accounts and addresses very easily. One example is creating a separate wallet for each of the branches of a store, or for different websites a person is working on.

One practical problem with BIP32 was that I couldn’t find any wallet management software for it. Electrum has that in the works (I think for the 2.0 version) but they are not there yet. Had to make one myself to try it out.

Design choices

I wanted to make something easy to use (as much as possible given the hairy details), secure, and powerful enough.

For ease of use, it’s a single web page that does all the work with Javascript and HTML; try to have as few moving pieces as possible; make sensible default choices, e.g. for the structure of the hierarchy.

For security the keys entered in the page are never transmitted over the network; the created transactions can be checked independently by a 3rd party (can decode it with; the single page can be saved

For power it can use both public keys for querying balance, and private keys for actually preparing transactions; it generates addresses automatically; it has everything needed for transactions within one page, with very little external dependency; have access to advanced functions if needed.


It took a few day, it it was too bad to get to a working prototype: it is hosted on, but can be downloaded with all the code to makei it a stand-alone application.

I didn’t want to implement the BIP32 extended public/private keys generation because someone better than me already did it at, and it is also a good way to separate responsibilities. Two independent crooked website is much less likely than one, isn’t it?

The Bitcoin functions, including using the BIP32 keys, are delegated to the bitcoinjs library. Apparently there are a bunch of forks of the original one at various stage of advancement, and incompatible added features. I have chosen the fork one that looked the most active, by BitGo, to import into this project. So far so good, maybe will do some porting of features between the forks later.

The “standard” way of creating addresses from here is creating two chains: an external that the user is supposed to share with whoever wants to pay him or her, and an internal chain for change addresses (to eliminate address reuse as payments are sent). The site creates the bunch of these addresses starting from the 0th one (as computer programming so often start to count from 0).

All of these addresses are checked with the JSON API whether they ever had any transactions. If they did, then check for the spendable coins, and generate some more addresses in the chain. This tries to reduce address reuse and ensure that all addresses used so far are checked. Of course, this is one of the weaknesses of BIP32 – one can never really be sure without a lot of computation or out-of-band communication whether all the addresses ever used with the key are accounted for.

If any spendable coins are found, then the user can create a new transaction. I didn’t put in too much effort into finding a good coin-selection algorithm, just start from the oldest one and add more to the input side of the transaction until there are enough to cover the desired outgoing amount. Apparently, though, that is a good way to do it, so fair enough.

If the extended public key is used, then the page only knows enough to create an unsigned transaction. This can be checked, and hopefully later I’ll be able to implement the feature of signing such transactions  (with the same page) when being offline for security. If the private key is present, then a proper signed, spendable transaction is made, and ready to be submitted via the Broadcast Transaction tool.

The receiving addresses have QR generation too. The chain addresses not, because they shouldn’t be used directly – this is just some opinionated programming.


The incoming BIP32 keys are generated as it is described in the help section of my page: choose a hard enough passphrase, and generate a child key as custom m/i’ child path (this should really be standard, by the way). It just means take the master key (m), and create the ith child in “private derivation” mode (hence the prime). Can see the original BIP32 page for some of the details.

This leaves you with an extended public key (something starting with xpub…) and an extended private key (xpriv…). Should keep the passphrase from the previous step as well, but definitely these two keys.

When one of these keys is plugged into the page, it starts to generate the appropriate keys for the two wallets, and the balance shows up. When any balance is found, a new transaction can be created, and sent off to the network with

To prove that I made this work before at least, the extended public key to generate the listed donation address of 17NWCFWo8EvFp7vtkbRH6ec3DEdxZhrhrd is xpub69i6TTB6JU2mwcQ7pKeDG8aAMnc2AZ2UdpuphoNak4nT4UTWYhkSGqpDgbGjHGbxYVK8jNF4eXMRk1aeGweLxiCWWB5EjKm3k6YMKoWN5VT (receiving address chain index 1) – go ahead, try it. Also used the page to create a small transaction – sending the from receiving address chain index 0, which also used the change chain index 0 address. When that worked, that was a relief. :)


There’s a lot to do about this project and related services to make it more usable and interesting, the Issue Tracker is bursting with ideas. Here are some with higher priorities:

  • really make it offline usable (which would remove a lot of security concern, probably). Will need to think much more about the internal implementation then, how’s the most user friendly to create new transaction if you cannot go online to get data (what and how to import between online and offline)
  • make a usage video
  • generate addresses in the receive/change chain at arbitrary indexes (could be useful)
  • add QR code reading to the input field, probably via jsqrcode.
  • implement storage of retrieved data so it’s more user friendly when on non-public computer
  • talk to the bitcoin network directly, either to get the input or to send the transaction. Some groundwork is laid down in a blogpost recently about using the raw Bitcoin protocol in Python.
  • implement my own server/API for Bitcoin/Litecoin/Dogecoin that can be used with BIP32 wallets, and probably compatible. Currently there are no good service for such altcoins (even if it would be pretty straightforward I think), and for the Testnet (so not risking real value to try things out)
  • implement a Point-of-Sale app (I guess on Android), that uses an extended public key to generate receive addresses for incoming transactions (totally hold-up-safe, and crooked-employee-safe payment method)
  • implement a WordPress plugin that uses extended public key to generate per-post donation addresses (for the donations themselves, as well as analytics-via-payment)
Well, at least the first step is done. All source up on Github. Would love to hear from anyone who used it, and what do you think could be improved upon.

Kamis, 23 Agustus 2018

US Securities and Exchange Commission Rejects ProShares Bitcoin ETFs

by. MarketWatch - The US Securities and Exchange Commission has rejected two ETF proposals filed by ProShares.

The company currently has about $30 billion in assets under management and filed with the SEC back in September. The exchange-traded funds would have tracked BTC futures traded on the Chicago Board of Options Exchange and traded on NYSE Arca.

Here’s a look at the key reason given for the ProShares rejection:
“This order disapproves the proposed rule change. Although the Commission is disapproving this proposed rule change, the Commission emphasizes that its disapproval does not rest on an evaluation of whether bitcoin, or blockchain technology more generally, has utility or value as an innovation or an investment. Rather, the Commission is disapproving this proposed rule change because, as discussed below, the Exchange has not met its burden under the Exchange Act and the Commission’s Rules of Practice to demonstrate that its proposal is consistent with the requirements of the Exchange Act Section 6, in particular the requirement that a national securities exchange’s rules be designed to prevent fraudulent and manipulative acts and practices.
Among other things, the Exchange has offered no record evidence to demonstrate that bitcoin futures markets are ‘markets of significant size.’ That failure is critical because, as explained below, the Exchange has failed to establish that other means to prevent fraudulent and manipulative acts and practices will be sufficient, and therefore surveillance-sharing with a regulated market of significant size related to bitcoin is necessary to satisfy the statutory requirement that the Exchange’s rules be designed to prevent fraudulent and manipulative acts and practices.”

The SEC also rejected ETF proposals from GraniteShares and Direxion today, for similar reasons. You can check out the full ProShares document from the SEC here.

Exchange-traded funds track an index or group of assets but trade like stocks, and are widely viewed as having the potential to bring a crush of institutional investors into the cryptocurrency market.

This latest rejection follows a similar denial last month, when the SEC rejected a proposal filed by Gemini founders Cameron and Tyler Winklevoss. All eyes will now be on the VanEck/SolidX Bitcoin ETF, which was recently delayed and will now receive a yay or nay from the SEC by September 30th.

Source :

Before Bitcoin ETFs Pass, A Clear Crypto Narrative Is Needed

by. - Bitcoin exchange-traded funds (ETFs) are having a hard time clearing the bar in the U.S., where nine applications were rejected by the Securities and Exchange Commission (SEC) yesterday.

The SEC is now moving to review the decisions. Commissioner Hester Peirce tweeted: "In English: the Commission (Chairman and Commissioners) delegates some tasks to its staff. When the staff acts in such cases, it acts on behalf of the Commission. The Commission may review the staff's action, as will now happen here."

If the products are ultimately approved, then the largest cryptocurrency by market value, bitcoin, would have likely seen a substantial price increase. For now, however, HODLers will have to sit tight and wait patiently with their coins shivering in cold storage a little longer. (The next major deadline is in September when VanEck and SolidX will have their joint proposal heard, though that deadline can be extended int0 2019.)

In the meantime, though, that isn't quelling speculation about how an ETF would benefit those who hold bitcoin as an investment.

In a post on Medium from June, Ironwood's Michael Strutton teases us some with his perspective on the potential of a bitcoin ETF, "If ETFs add 24 million U.S. investors, and the upward momentum adds 14 million from the rest of the world, then that adds $84 billion and $336 billion, respectively, to the market cap."

"Over the past six months, bitcoin's market cap has swung from $326 billion to $110 billion. Adding $420 billion to the market cap could put bitcoin's price range from $26,000 to $44,000," he continued.

The estimates, while just estimates, still showcase an underlying belief that an ETF will provide a boost for investors. Still, from yesterday's market movements, it's clear the opposite is true.

Crypto prices are hypersensitive to government regulation and it came as no shock when prices tumbled last night as news broke that the SEC had rejected the applications.

With so much capital at risk, the SEC has been fairly clear about its stance and the regulator is right to express concern about fraud and manipulation of bitcoin markets. It is important to spend an enormous amount of effort cataloguing the potential risks from all angles before approving a bitcoin ETF.

However, crypto fans should not take the SEC's decision personally. There is the need for a professional-grade market which has the liquidity and depth to support the hedging activities of a U.S.-based bitcoin ETF issuer.

For perspective, it helps to take a step back and look at the U.S. ETFs market in general.

Once-upon-a-time, new and exotic ETF products were always first to be launched in the U.S., with Europe and Asia propelled by the American market. After years of unbridled growth, the introduction of new ETFs have been running into hurdles as regulators within the securities industry crackdown.

Struggling with bitcoin narrative

Still, there are tasks that the technology's evangelists can take up in the meantime.

CoinShares, chief strategy officer, Meltem Demirors, made an excellent point on CNBC in August, when she highlighted, "The narrative around bitcoin is still really hard to grasp," she said.

"Really the only metric we have for most cryptocurrencies is the price, and price is such an imperfect metric. What does actual utilization look like? That's really the struggle for crypto right now," Demirors added.

The regulatory community has put forth a similar idea – that time is on the side of innovators.

As SEC Commissioner Hester Peirce articulated in an argument in favor of a bitcoin ETF, saying: "Bitcoin is a new phenomenon, and its long-term viability is uncertain. It may succeed; it may fail."

Peirce added that she doesn't believe the SEC to be positioned for either outcome, but that could change with time, and with more clarity as to the narrative surrounding the technology.

Why do most bitcoin investors want a Bitcoin ETF? Today, the most obvious reason is so the prices rise and investors can ride the high again like in December. We can bet regulators will want to have more nuanced reasons for an approval.

For now, investors need to take a step back and assess the risks involved. The SEC has been nothing but clear and the language used in each rejection is telling.

Back down, sit tight and be patient. The SEC has your best interest at heart.

Source :

US SEC to Review Rejection of Nine Bitcoin ETF Applications

The U.S. Securities and Exchange Commission (SEC) will review its decision to reject nine applications to list and trade various Bitcoin (BTC) exchange-traded funds (ETFs), Reuters reported August 23.

On Wednesday, the SEC disapproved a total of nine inquiries from three companies to bring BTC-based ETFs to market, claiming that the products did not comply with the requirements by the “Exchange Act Section 6(b)(5), in particular the requirement that a national securities exchange's rules be designed to prevent fraudulent and manipulative acts and practices."

Shortly after, the SEC released letters stating their intention to review the decision, having delegated authority to take action on the applications. However, the letters do not specify a deadline for the decision nor what the review will entail.

ETFs are marketable securities that track an index, commodity, or basket of assets, that are proportionately represented in the fund’s shares. ETFs experience price changes throughout the day as they are purchased or sold on a stock exchange. If the SEC allows a BTC ETF, a fund would purchase an underlying amount of actual BTC and distribute those funds into shares, which further are distributed to shareholders.

Last month, the SEC rejected an appeal for a Winklevoss BTC ETF fund by Bats BZX Exchange, Inc. The first application was rejected by the SEC in March 2017, because of “the largely unregulated nature of BTC markets.”

A day later, SEC Commissioner Hester M. Peirce published a statement of official dissent from the agency’s disapproval of the Winklevoss fund appeal. Peirce argued that the SEC fundamentally erred with its latest decision and that the agency overstepping its “limited role,” when it focused on the characteristics of the underlying BTC market, rather than the derivative. She suggested that the disapproval order will likely “inhibit” the institutionalization of the BTC market.

Source :