New Features Enabled by a Layer-2 Token


#1

An earlier post on this forum talks about more accurate ways to establish an economic majority on the decentralized Blockstack network. This enables voting (based on ownership of tokens) for protocol upgrades amongst other benefits. If you haven’t read the decentralized governance & incentivized protocols post, we encourage you to take a look at that post first.

This post lays out some other features that are enabled by a layer-2 token on Blockstack.

A quick recap: a layer-2 token is where a blockchain is built (logically) on top of an existing blockchain (similar to virtualization technology) and that blockchain has its own token.

#1: Support for advanced registration and payment features

Layer-2 tokens can enable more advanced “smart contract” like features. These include:

Atomic swaps: One of these is atomic swaps of assets (like domain names) with coins. For example, a seller of a domain name can put out a transaction indicating that the domain name is up for sale and then a buyer can put out a second transaction that puts up the money and triggers the simultaneous release of the domain name. This enables a truly decentralized exchange of assets (without any trusted middlemen or exchanges).

Namespace bidding: Another example is the ability to auction off namespaces so that namespaces aren’t too expensive for typical buyers at the same time they aren’t auctioned off too cheaply.

Advanced payments: It’s possible to send domain registration payments to a set of names/addresses (instead of burning the registration payments). This can incentivize namespace creators to help build an ecosystem around their namespace and encourage active use of the namespace.

#2: The ability to migrate away from failing blockchains

At Blockstack, we believe that it’s too early to pick a winning blockchain. We don’t know which blockchain is going to be alive and reliable 5 years from now. Individual blockchains might fail, but a decentralized internet built on top of blockchains needs to live for hundreds of years to come. Our early experience with moving away from Namecoin shows that a layer-1 token might become irrelevant for the Blockstack network after a migration. Layer-2 tokens can enable a seamless migration as:

  1. They provide a transparent mechanism for the stakeholders to vote on whether or not a move should take place and if so when.
  2. They allow people to continue using the system after a migration with their existing inventory of (layer 2) tokens.

#3: Support for light clients

Blockstack users run full-nodes to independently verify transactions and data mappings. However, running a full-node is too resource intensive for mobile devices or may not be allowed by mobile platform vendors. We currently have a protocol that lets light clients (on mobile or desktop) verify data fetched from untrusted nodes, given a trusted consensus hash. However, this requires establishing a “trust channel” or getting a trusted consensus hash offline. With a layer-2 token, we can get rid of this limitation and enable independent verification of the longest layer-2 chain by light clients. This opens the door to bitcoin-like SPV client support and truly decentralized apps on mobile devices.

It’s important to note that a Blockstack layer-2 token enables all these new features without taking away any of the existing functionality. The new features are added to the system while preserving existing functionality.


Blockstack does not need a new token
#2


Since nobody else has asked, I guess I will.
Whats the eta for the token? :slight_smile:


#3

Hi Muneeb thanks for taking the time to share more details about the Blockstack token proposal. Replies are inline below:

This enables a truly decentralized exchange of assets (without any trusted middlemen or exchanges).

You can do this already with bitcoin using cross-chain atomic swaps.

https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts#HTLCs_in_cross-chain_atomic_swaps

You could also use a protocol like BitMarkets to do this - completely trustless and p2p.

Another example is the ability to auction off namespaces so that namespaces aren’t too expensive for typical buyers at the same time they aren’t auctioned off too cheaply.

Are you sure this couldn’t be done with bitcoin? If not, why not?

It’s possible to send domain registration payments to a set of names/addresses (instead of burning the registration payments).

Same question as above, why can’t this be done with bitcoin?

They provide a transparent mechanism for the stakeholders to vote on whether or not a move should take place and if so when.

I suggested in the Part 1 thread that voting could also be done using blockchain IDs by inserting a vote into the zone file for a given ID and then weighting the vote according to the registration price of the ID.

They allow people to continue using the system after a migration with their existing inventory of (layer 2) tokens.

I don’t see why people couldn’t just buy tokens for the new blockchain if they plan on moving over to it anyways.

Blockstack has already migrated blockchains once with virtually no usability impact to users, sans Blockstack token. I don’t see why the same can’t be repeated again in the future if necessary.

With a layer-2 token, we can get rid of this limitation and enable independent verification of the longest layer-2 chain by light clients.

You’ll have to explain this part in more detail, because with the given information I do not see the relation between tokens and SNV.


Blockstack does not need a new token
#4

Hey John, thanks for your reply. The TL;DR of my response is that there are details on how these features will be implemented that will require the use of a layer-2 token. Let me see if I can answer some of your questions.

You can do this already with bitcoin using cross-chain atomic swaps.
https://en.bitcoin.it/wiki/Hashed_Timelock_Contracts#HTLCs_in_cross-chain_atomic_swaps1

We would like it to be possible for someone to set the price of a name they own and then allow anyone to buy it at that price within a given window of time. We would like to be able to do this efficiently on-chain, so no 3rd party registrar service (like GoDaddy) will be required. However, this cannot be done with HTLCs alone to the best of my knowledge, since HTLCs require the seller to learn the address of the recipient before sending the transaction (which would require a 3rd party discovery service).

You could also use a protocol like BitMarkets to do this - completely trustless and p2p.

You have to know the recipient’s address and network location in order to construct the transactions necessary for their 2-party escrow to work. This also necessitates an off-chain 3rd party service for discovering willing buyers, which we’re trying to avoid.

I suggested in the Part 1 thread that voting could also be done using blockchain IDs by inserting a vote into the zone file for a given ID and then weighting the vote according to the registration price of the ID.

Name ownership is not an accurate measurement of economic stake in the ecosystem, nor is it a measure of the system’s overall success. For example, Namecoin has over 3 million domains registered, but hardly anyone uses it. Notably, the protocol for signaling Namecoin upgrades is proof-of-work, not proof-of-name-registration. Good thing for them, since most of their domains are squatted for nearly free.

The most reliable way to signal economic activity that I know of is to do so via irreversible and sustained resource expenditure (e.g. burning electricity). Acquiring and burning a layer-2 token through virtual mining to send a signal is equivalent to doing so by mining and burning layer-1 tokens—energy (or its monetary equivalent) is irreversibly and consistently spent to send a signal.

There are two other problems with using names to signal upgrades. First, it’s inefficient, and second, the number of names you own and the worth of those names does not reflect how strongly you feel about a particular upgrade. Regarding point (1), if you own more than one name, you have to send a transaction to update each name in the signaling interval. If you feel strongly about the upgrade, you’d be incentivized, perversely, to squat a bunch of names just to send your signal. If instead signaling were done by burning a token (be it layer-1 or layer-2), you’d only have to send one transaction per signaling interval (and no names would be locked up). Moreover, the signaling system would require a proof-of-burn for every signaling period, since this would make it equivalent to spending electricity to signal in proof-of-work by block-mining.

Regarding point (2), let’s walk through an example. Suppose a protocol upgrade is proposed that causes all compliant resolvers and registrars to disable support for names with underscores in them. This might be pushed by a coalition of users who want all names to be DNS-compliant, for example. But if I’m an app developer and my app’s name has an underscore in it, it would be very important for me to block this protocol upgrade. I would be willing to spend much more money than the cost of my name to signal “no.” As we can see, the value of my “no” signal is much higher than the cost of my name, and the choice to purchase my name at its given cost (which was purchased before the upgrade proposal) was not related to the signal I chose to send.

Anyway, the point I’m trying to make is that acquiring and burning a token for signaling (be it layer-1 or layer-2) is a more efficient and more accurate way to signal protocol upgrade preferences than updating name zone files. The reason you’d want to use a layer-2 token specifically is that doing so limits signaling to the system’s stakeholders, and thus makes the signal more reflective of their wishes. We see this in other contexts as well–for example, when you’re playing the board game Monopoly and trying to auction off a deed, you would only settle deed ownership with Monopoly money from other players instead of USD from a complete stranger. If you want to have a say in the auction, you must first acquire Monopoly money by participating in the game. It would not be fair to the game players if random strangers could interfere with the game without any stake in it.

(re: namespace auctions) Are you sure this couldn’t be done with bitcoin? If not, why not?

We’d like to be able to implement a Dutch auction system for namespaces. In a Dutch auction, the price of the item being sold is set at a high price, and decreases at a fixed rate with time until someone buys it. For example, a namespace might cost 1 BTC at block X, 0.99 BTC at block X+1, 0.98 at X+1, etc. We’d prefer to implement a Dutch auction over e.g. a Vickrey auction (what ENS does for names), since it only needs two transactions: one to start the auction, and one to place the bid.

To the best of my knowledge a Dutch auction cannot be implemented with Bitcoin script, since the price of the namespace would be a function of the block height after the auction started. In order to implement the Dutch auction, the amount debited from the bidder would need to be determined by the block height at which the bid transaction was included in the blockchain. This information is only known after the transaction is sent; it cannot be included by the bidder. To the best of my knowledge, there is no way to express the necessary command “pay X BTC to address A, minus Y BTC for each block after the height H at which this transaction was included.”

I don’t see why people couldn’t just buy tokens for the new blockchain if they plan on moving over to it anyways.

We’d like it to be possible for people to “load up” their names with tokens, so they auto-renew every expiry period. Their balance would be automatically debited at the expiry block without the need to send a name-renewal transaction. The biggest reason to have this feature is that it lets us spread out the transactions required to renew names—you can pay as you go, and you can pay in advance. In the event of a migration, we’d like the balance a user has accumulated on their name to come with them.

This can’t be done with Bitcoin alone. While it is possible to restructure the NAME_RENEWAL transaction semantics so that users can preemptively renew a name for the next K expiry periods, keeping track of whether or not the users have paid enough and keeping track of how many expiry periods remain for a name is functionally equivalent to creating a separate unit of account for measuring the name’s remaining lifetime (i.e. an implicit layer-2 token).

You’ll have to explain this part in more detail, because with the given information I do not see the relation between tokens and SNV.

Sure thing. SNV (Simple Name Verification) lets you prove that a past transaction happened, given a later consensus hash. A layer-2 token would let you distinguish between two consensus hashes to identify which one’s virtualchain has a greater overall resource expenditure (e.g. by looking at how many layer-1 and layer-2 tokens are destroyed for name registration, mining, and protocol upgrade signaling). While the layer-2 token does not resolve conflicts between virtualchains (recall that virtualchains are fork*-consistent), it does give a bootstrapping user a hint as to which virtualchain has more economic activity. Name registration fees alone cannot do this.

Anyway, I hope this is helpful.


#5

I don’t see why this information couldn’t be put into the zone file. Or why a decentralized marketplace like OpenBazaar couldn’t be used for market discovery.

If the vote is stored in the zone file, yes. The vote could also be stored off-chain and signed with your on-chain public key, so no new transactions are needed during the voting period.

I don’t see how this incentive is any more perverse than the incentive to buy tokens. Either way, a scarce resource is taken off the market.

This actually brings up the point that you don’t need a new token to do the PoB voting. You could just burn bitcoin and insert your vote into the OP_RETURN field or something like that. Or instead of making it a burn, you could vote with coin-age to avoid polluting the UTXO set.

I see the point you are trying to make here. The point I am making in this an previous comments is that there are lots of options besides “create a new token” for solving the decentralized governance problem. I have provided several examples already and if we really feel like this is problem worth solving then I’m sure we could come up with more.

That it appears you guys did not even consider these or other alternatives makes it look a lot like you consider the need for a token to be a foregone conclusion. Indeed, you published a blog post yesterday announcing that the token sale is definitely happening, despite this ongoing debate within the community. Not the best way to win over collaborators. Why should I participate if you will just make unilateral decisions while debate is still happening? This is completely counter to an open, decentralized development process. If that’s what you are aspiring to, you are already failing.

Creating a new token seems a high economic price to pay for such a trivial feature.

So you get the benefit of a layer 2 token, without the economic implications. Sounds like a good thing to me.

You will have to provide a concrete example of what this looks like in practice. I cannot visualize how a hash alone would tell you how many layer-2 tokens are burned in a given period.


#6

It’s important to note the ability for a 2 layer token to support decentralized apps on mobile. If we truly want this technology to scale in a way that reaches the underserved (developing world) we are going to need a mobile-first solution.

The only rub here is user adoption of a 2nd layer token, but I can forsee ways that can be handled within user onboarding to the platform.

Running a namespace for design stuff would also be fun.

Overall its important to also note that we face serious competition from our centralized incumbents. These companies all have great economies of scale and monetization strategies that we find untenable. In order for us to compete a logical method would be tokenization. From an economic incentives perspective there is nothing simpler than voting with your currency.


#7

I think this is going to be the biggest win from the token. Being an application platform, Blockstack needs better mobile support for applications built on it for those apps to compete with their centralized alternatives. And light clients connecting to untrusted nodes is going to be a huge move in that direction. I think this rationale alone would justify the need for an L2 token.

There is also the resources argument:

I believe this argument for the token is being undersold.


#8

I agree with the layer-2 token approach since I think the ability to migrate away from underlying Blockchains is fundamental.

When a critical product feature is dependent on underlying tech outside of your control (Bitcoin Blockchain in this case), it’s best to keep options in hand especially if thinking seriously long-term; beyond the founding team and community.

Double down on that if working on hard tech and the decisions taken now are hard to reverse later unlike agile SW development. Additionally it appears we can continue to use Bitcoins.

The more options when it comes to hard tech, the better the chances of success in my opinion.


#9

First of all, I’m really looking forward to finally see all these possibilities in action!

I’m sure that the core team has put much effort and thought into this and I already can’t stop thinking about new use-cases :smiley:

I fully agree. If this platform should survive in the long term, it’s much better to go with an own token to be flexible instead of trying to solve as much as possible with a L1 token. Things are much easier with an own tailored system where you don’t have to press everything into a fixed environment.

At some point we need to step forward to further assure future innovations.

I think this was only possible because Onename paid the registration fee for every user. Without that everybody had to spring in and move the current funds over to a new system.
A L2 token simplifies this process remarkable, a user just needs to put funds on an address and then lets the name renew automatically – without caring about possible future migrations.

Exited to see this live! :thumbsup:


#10

Thanks everyone for your comments. I want to update the community that this topic has been discussed extensively outside of these forum threads as well. Here is a quick summary:

Core developers: The developers who’ve contributed the bulk of the code on Blockstack Core, and the Blockstack Browser are 100% in favor of a layer-2 token. These are the people who’re doing the actual work on a daily basis and their opinion matters a lot.

App developers: We have a bunch of developers who’re actively developing apps on top of Blockstack (@jeremyrwelch from Casa and @vsund who is developing a coin-operated file viewer are two examples). We have broad support from the app developers for a layer-2 Blockstack token, especially given the rewards to app developers baked into the protocol. Aligning incentives with app developers is extremely important, and the opinion of developers who want to build on Blockstack carries a lot of weight.

Mailing list: We have a 10,000+ members mailing-list and so far all the feedback we’ve received from the community members on the mailing-list shows strong support for the layer-2 token and the exciting new features it enables.

In-person discussions: We had a Blockstack Summit in Mountain View recently, and 400+ people attended it. We didn’t conduct a scientific poll, but from the discussions, some of the core developers had with the broader community, only a handful of people (out of hundreds) had reservations about a layer-2 token (John Light is a good representative of the group that had reservations at the event).

Financial Supporters: Any successful protocol that replaces the current internet will need financial capital to make a dent. This is an incredibly ambitious project, and financial supporters are an important component of building a new eco-system of decentralized apps. So far we’ve seen tremendous support from financial supports who want to kick-start an app ecosystem on top of Blockstack by enabling various ways for developers to get access to capital.

As a reminder, the new layer-2 token is not taking away existing functionality. Existing namespaces (like .id) can continue to use the layer-1 token, and future namespaces can also choose to use the layer-1 token.

As we think more about a layer-2 token, it’s important to keep in mind these different parties and community members and look into how each category is approaching a layer-2 token and why. We really appreciate the feedback we’ve received over the past months. There is clear strong majority support for a Blockstack token.


Blockstack token whitepaper v1.0.1 feedback
#11

Well, everything is possible with on/side chains, but it does not mean will be easy. Just a simple example, why coming with Ethereum? I mean we can do smart contracts on bitcoin chain !?

There are so many good reasons why not to pick Bitcoin:

  1. most expensive real estate as far as blockchain data goes
  2. highly politicized already, which bitcoin chain? btc, bch, next hard fork coming this fall ?
  3. the hardest jump for new comers is exactly FIAT to BTC, then BTC to ANYcoin is easy, so no big benefits for quick adoption IMO
  4. even more …

So it seems own token is a way to go …

Thanks for the valid points and that indeed tech already exist around for many of blockstack needs.


#12

Will it be possible to mine the Blockstack token with Asic and/or GPU rigs?


#13

If the blockstack token also has these feature,it would be great.
1.Double deposit for buyers and sellers
2.0 transaction fee