Blockstack Annual Hard Fork 2017

[jude]

Hey Blockstackers,

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.

Simplified Operations

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.

Timeline

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!

[muneeb]

It’s the annual hard fork time! Feels like yesterday that we did the Sep’15 hard fork to introduce virtualchain and switch the underlying blockchain

+1 for BTC/USD exchange rate adjustment. It was a good call to include those variables in the code back then and with the recent bull run domains/names and namespaces are getting really expensive. I think that pricing domains in USD and adjusting for cryptocurrency exchange rate is a much simpler solution (even in the long run) than trying to get into more complicated concepts like stablecoins.

+1 for Segwit support. Other than the ~50% transaction cost reduction, I’m interested in sending more transactions per block for bulk operations. A lot of work went into enabling Segwit for Bitcoin and we should benefit from that work and add support for it.

+1 for optional feature of namespace creator getting registration fees. This can introduce an economic incentive for people to get more usage for the namespaces they start. The feature is optional and would’ve required more debate if this was a change to how all new namespaces will work.

+1 for simplified operations. This will require less transactions on the underlying network which reduces costs and operations will complete faster. It’s also less complexity because clients will not need to track the state of a registration and then send out an update only after the registration op completes.

It looks like this year the hard fork changes are straight-forward and might require less debate. Would love to hear more from the community!

[ryan]

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.

+1 for all of these.

The exchange rate adjustment is important because it ensures a reasonable cost for all names. And it was good foresight for us to decide to price names in USD and readjust them periodically when the Bitcoin price changes.

Segregated witness support will allow us to utilize the full scaling capabilities of the bitcoin blockchain, cutting transaction fees approximately in half.

As far as registration fees go, this is very important for incentivizing namespace creation and new business models for app developers. We’ve discussed this possibility in previous posts and talks and it’s really exciting.

+1 for simplified operations. This will require less transactions on the underlying network which reduces costs and operations will complete faster. It’s also less complexity because clients will not need to track the state of a registration and then send out an update only after the registration op completes.

Yes exactly. This will actually make a huge difference for the name registration process, especially for end users who register names own their own nodes and with the Blockstack Browser.

Very excited about all of these. Look forward to hearing more of everyone’s thoughts.

[1HZp4man3vbMzaQAZmY6]

All sounds good to me. I’m new here and have found the costs of .id registrations very high but now understand why. I’ve been struggling to register names, set default profiles and add usernames to profiles so anything that makes this smoother is good. Bringing improvement to the usability, speed of registrations with fewer transactions per use case etc has got to be good. Implementing segwit compatibility is just staying on the curve. I’ve watched you’re videos and am looking to get more involved by writing a decentralised app and very much support your vision.

[larry]

Hard forks provide an opportunity to make user-empowering adjustments to the protocol,

In the existing ICANN domain name system, the most common cause of unintentional loss of domain name is a registrant forgetting to renew it.

In response to this problem, ICANN implemented a Redemption Grace Periods for Deleted Names which gives registrants 30 days from the time their name expires or the name is deleted to correct the mistake through a registrar by renewing the name.

I propose adding similar functionality to Blockstack in this upcoming hard fork.

1. Users should have 30 days from name expiration to renew their names.
2. Users should have 30 days from name revocation to reverse the revocation by renewing their names.
3. During this 30 day period, names should *NOT function. Normal apps should see the names as invalid and not existing. Our explorer software and registration software should display the names as available for renewal only by the original owner.

By providing this grace period and doing so in a way that aligns with how the legacy domain system functions, we can match their current expectations as to how domain names should function and provide a better user experience.

Thoughts?

[jude]

I love this idea! We can easily fold this in.

Users should have 30 days from name revocation to reverse the revocation by renewing their names.

Do we want to be able to undo NAME_REVOKE? This operation was meant to be used in the event of a key compromise to stop a name from being misused.

[muneeb]

propose adding similar functionality to Blockstack in this upcoming hard fork.

+1 for this update. ICANN has a lot of operational experience and they clearly felt the need for a 30 day period where domains stop working but can be renewed. My guess is people only notice that the domain expired if something stops working. In the current system, some other party can register the domain when a user notices that something is broken and his/her domain is no longer working. It’s important to have this functionality. Keeping the rules exactly as ICANN help a lot as people already have a mental model for how domains work on ICANN.

[larry]

Do we want to be able to undo NAME_REVOKE? This operation was meant to be used in the event of a key compromise to stop a name from being misused.

In our current implementation, the bitcoin address is your identity and names are a pointer to it. If your key is compromised revoking the name doesn’t prevent the attacker from using the key.

If you want to continue using the name and be sure that attacker doesn’t have access to it, then your only option is to transfer the name to a new address and build up a new set of verifications around the new owner address before the attacker transfers the name.

Name revokation only makes sense as a protection mechanism in the instance of key compromise where names also the primary key for identity. Right now, owner address is used as the primary key, not the name.

I’d argue we still have more work to do in this area. Our current implementation leaves some question marks. Questions such as:

• my key was compromised and I sent a name to a new address so I can rebuild my identity:
  • what happens to all of app logins? (currently apps will see you as a new user)
  • what happens to my storage? (you lose access to it)

Having said that, I don’t think this work to address these questions needs to be addressed in the annual hard fork. We have other potential solutions to the above issues that don’t need to be implemented in the consensus layer.

I agree with @muneeb in that we should implement the feature in the same way ICANN has so that people don’t have to do get used to a new mental model. This means a 30 day grace period after deleting a name (which is what the revoke operation does).

Thoughts? @jude @aaron @ryan

[aaron]

The rationale for the revocation model isn’t 100% clear to me (could I achieve the same thing by transferring to the 0 address?), and weakening it by allowing for a 30 day grace period doesn’t seem problematic. However, since it would more closely align the protocol with what ICANN does, that seems like a positive.

So, I agree with @larry and @muneeb, +1 for grace period.

[jude]

The NAME_REVOKE operation was introduced with the intention of one day adding support for a dedicated key for revoking a name. You’d put your revoke key in a safe place, and only dig it out to stop someone who stole your name owner key from abusing your identity.

I don’t think ICANN has an equivalent feature, since ICANN registrars already have the power to transfer a name back to its rightful owner if the wounded party can prove it got stolen, squatted upon, or registered with the intention of causing harm to other users (e.g. phishing). I don’t think we want the consensus layer to emulate ICANN in this particular capacity, since it could easily be abused by registrars.

I propose leaving NAME_REVOKE's behavior alone for now, until we figure out a good way to manage separate revoke keys.

Related to emulating ICANN behavior, one thing we could do is make NAME_TRANSFER reversible up to a certain number of blocks. However, I propose waiting on this for now until we have implemented atomic name sales with the layer-2 token (then we can attack this problem in earnest).

[larry]

I propose leaving NAME_REVOKE’s behavior alone for now, until we figure out a good way to manage separate revoke keys.

Related to emulating ICANN behavior, one thing we could do is make NAME_TRANSFER reversible up to a certain number of blocks. However, I propose waiting on this for now until we have implemented atomic name sales with the layer-2 token (then we can attack this problem in earnest).

Agree on both points!

[blockpac]

@larry There seems to be a typo in the Github documentation on upgrading to the latest fork.

Run blockstack-core fast_sync to get a recent 0.17 snapshot.

The URL is missing in the above.

From another doc:

Download the Atlas snapshot

$ blockstack-core --debug fast_sync http://fast-sync.blockstack.org/snapshot.bsk

https://github.com/blockstack/blockstack-core/blob/master/release_notes/changelog-0.17.md