The time for our annual hard fork is coming up. For the development of Blockstack, we generally execute a hard fork once per year (see Sep’15 fork, and Oct’16 fork) and have a community discussion around what changes should get incorporated. Hard forks provide an opportunity to make user-empowering adjustments to the protocol, and in this fork we want to (1) adjust BTC/USD rate (as scheduled), (2) add support for a broader range of transactions (3) improve the efficiency and simplicity of our existing protocol.
Updating BTC/USD exchange rate
For the purpose of convenience, names are meant to be priced in USD, rather than BTC. In order to enable this, we created a variable in the code that corresponds to the BTC/USD conversion rate, which would remain static for a period of time until it is readjusted in a future hard fork.
The BTC/USD exchange rate adjustment is important in Blockstack because cryptocurrencies can get expensive in a relatively short period of time. The BTC/USD exchange rate has increased over tenfold from when we launched Blockstack on the Bitcoin blockchain back in September 2015. We have seen name registrations go from less than $1 USD to over $60 due to increased transaction fees over that time period as well. We launched the
.id namespace for $10,000; it would have cost over $130,000 today.
Adjusting the BTC/USD rate is something we’ve always planned to do every year, and this year you’ll feel the impact more. Our original goal with name pricing is to keep them cheap enough for the everyday user to purchase but expensive enough to stop spammers. The annual readjusting helps us factor-in any BTC/USD fluctuations. We would reduce the cost of names 10x to accommodate Bitcoin’s 10x price increase.
As part of the BTC/USD adjustment, the prices of namespaces will be adjusted to account for the 10x Bitcoin price increase respectively. We have gotten a lot of interest from developers who want to create their own namespaces, but cannot do so because of the current price.
New Transactions: Support for Segwit
Blockstack simply ignores segwit transactions for the time being. However, if support for segwit transactions is accepted in a hard-fork:
(a) users of the network would experience up to a 50% decrease in the cost of each transaction.
(b) registrars run by different parties for bulk registrations could send out the name registration transactions faster, since segwit transactions are not vulnerable to malleability attacks.
This is a huge performance upgrade from how things currently work.
To be specific, we would implement support for P2SH-P2WPKH outputs (pay-to-witness-public-key-hash embedded in pay-to-script-hash) for names owned by a single key, and P2SH-P2WSH outputs (pay-to-witness-script-hash embedded in pay-to-script-hash) for names owned by multiple keys. It’s possible to include support for native P2WPKH and native P2WSH in a future hard-fork i.e., once BIP173 is standardized and once the rest of the Bitcoin ecosystem supports BIP173.
New Optional Feature: Namespace creators can opt to receive registration fees in Bitcoin
This applies more to app developers who want users to have names in the namespaces they launch. One thing we talked about when describing the future token system is the possibility that an app developer could create a namespace and stipulate that all name registration/renewal fees would go to one or more addresses of their choosing (instead of the burn address). The idea is to let users pay for extra services. For example, a blogging app developer could maintain a search index over users’ blogs, but only of the user had a name in the
.blog namespace. We could implement this for names paid in Bitcoin in this hard fork.
This will not impact any existing namespaces. This is a new, optional feature for anyone creating a new namespace. The previous method of creating namespaces where all registrations fees are burned will remain there.
Having seen the system in operation for nearly three years, and having received a lot of community feedback, it becomes clear that certain name operations can be reduced to a single operation. Merging them at the protocol level would reduce transaction fees, make issuing them simpler and easier to do correctly, and speed up their processing time.
Two examples stand out: allowing users to combine NAME_REGISTRATION and NAME_UPDATE, and allowing users to combine NAME_RENEWAL and NAME_TRANSFER.
When you register a name, you first have to preorder it, register it, and set its zone file hash. Each operation takes one transaction. We could merge registration and setting the zone file hash into a single transaction, so registering a name would only require two transactions (less fees and faster registration times). Users would still be able to send separate NAME_UPDATE transactions; all we are proposing is that the NAME_REGISTRATION transaction can include the same data as a NAME_UPDATE as well.
Merging NAME_RENEWAL and NAME_TRANSFER is meant more for registrars. Allowing these operations to be sent in the same transaction would simplify the process of transferring names to users or to other registrars while ensuring that the recipient won’t have to renew them on the spot. NAME_RENEWAL and NAME_TRANSFER would still be available as distinct transactions; we’re proposing allowing them to be optionally combined into a single transaction for this purpose.
In terms of code, most of these changes are minor with the exception of segwit support which requires more code changes. After a community discussion, we will lock-in the features that can be included in this hard-fork. We are looking to have a hard-fork release candidate ready to deploy by October 1, and activated by October 8. As always, node operators can choose not to upgrade and remain on the old (disconnected) network. In the future, establishing an economic majority of the network through the Blockstack token will improve the process of introducing hard-forks on the network.
We’d love to hear your thoughts!