Research on the ENS

[JustinDrake]

For a year OpenBazaar 1.0 users (mostly vendors) have tested the Blockstack naming protocol, predominently through the OneName gateway. Back in September 2016 it was quite clear that the Blockstack/OneName solution was not a great fit for OpenBazaar. User experience has been for the most part bad. 6 months later the situation is worse, with an increase in confirmation times (and mining fees, currently subsidised by OneName). Other pitfalls include that the OneName resolver does not include cryptographic proofs of ownership. I also believe that @cpacia concluded that the Blockstack reference light client implemented in Python is not easily integrated into openbazaar-go.

There is good news regarding OpenBazaar 2.0's potential naming system:

1. We can learn from OpenBazaar 1.0. I don't believe we're settled with Blockstack/OneName.
2. From the user's perspective the naming system is a technical detail that should be abstracted away. The choice of naming system can be made purely on technical merits.
3. As pointed below, the ENS is a possible alternative to Blockstack.

In this Reddit thread, Nick Johnson talks about his Ethereum Name Service (ENS). Six months later, we have detailed specs (see here and here). We also have an implementation which has been tested on Ethereum's Ropsten testnet. The mainnet contract has been deployed (see here) with imminent activation (see here).

I have started familiarising myself with specs and code. (There are also useful videos, e.g. here and here.) My initial gut feel based on a couple hours of research is that the ENS is pretty well designed (much more comprehensively than Blockstack) and could be better suited than Blockstack for OpenBazaar. I will be updating this issue as I uncover relevant details. In the meantime, I'm creating an issue to kickstart the discussion.

[cpacia]

There are some positives:

• Vitalik mentions the geth lite client (in Go) and possibility of Merkle proofs... which isn't really possible with Bitcoin. Though I don't see anything about Merkle proofs in the spec you linked to.

• Possibly cheaper than Bitcoin.

But negatives as well

• Looks like the spec has a 7 day auction period. That's arguably worse than just waiting for some Bitcoin txs to confirm.

• People would need to bother with both bitcoin and etherum to make it work. Which is a terrible UX.
  Only way around that would seem to be to have someone subsidize name registration and updates.

• Having to sync and maintain one chain is hard enough. Adding a second chain to manage would be burdensome. Unless the geth client could handle everything with minimal work on our part.

[hoffmabc]

Pinging @shea256 and @jcnelson

[hoffmabc]

I would love to hear what Blockstack plans to do to account for these primary critiques.

[JustinDrake]

Vitalik mentions the geth lite client (in Go) and possibly of Merkle proofs... which isn't really possible with Bitcoin.

cc'ing @Arachnid for comments on the light-client friendliness of the ENS.

Looks like the spec has a 7 day auction period. That's arguably worse than just waiting for some Bitcoin txs to confirm.

Yes the 7 day period is awfully long for OpenBazaar vendors to wait. Two things:

• It tries to solve a real problem with name squatting. BlockStack is First-Come-First-Served and a significant portion of the names (explorer here) is squatting.
• The registrars will be changeable. This particular auction policy is for the "initial" registrar tied to the .eth top level domain. Maybe down the line a different policy can be used for an .ob top level domain?

People would need to bother with both bitcoin and etherum to make it work

I believe the ENS only uses Ethereum, not Bitcoin.

have someone subsidize name registration

I don't believe that subsidisation is sustainable long-term, at least not if OpenBazaar is successful (which is what we should be planning for). Subsidisation is a dangerous game as it doesn't scale.

(A few stats to gauge the success of Blockstack with subsidisation. It has registered 70,000 handles (see here) while being operational since September 2015 (see here). It will be interesting to compare interest in the ENS, which I don't believe is being subsidised.)

Unless the geth client could handle everything with minimal work on our part.

Could @Arachnid comment on this?

[cpacia]

I believe the ENS only uses Ethereum, not Bitcoin.

My point is that telling your average non-cryptocurrency enthusiast that they need to acquire bitcoin to use OpenBazaar is already a hard sell. Telling them that, in addition to bitcoin, they will need to get this thing called ether to buy a username is an even tougher sell.

[JustinDrake]

My point is that telling your average non-cryptocurrency enthusiast that they need to acquire bitcoin to use OpenBazaar is already a hard sell. Telling them that, in addition to bitcoin, they will need to get this thing called ether to buy a username is an even tougher sell.

I don't understand this. OpenBazaar buyers are the only ones that "need to acquire bitcoin to use OpenBazaar" but they do not need a handle. Getting a handle mostly is relevant to buyers and moderators. Both buyers and moderators are on the receiving end of Bitcoin transactions.

[jcnelson]

Other pitfalls include that the OneName resolver does not include cryptographic proofs of ownership.

Not sure what you mean by this? Names are most definitely owned by public keys. Example:

$ blockstack whois judecn.id
{
    "block_preordered_at": 373622, 
    "block_renewed_at": 373622, 
    "expire_block": 489247, 
    "has_zonefile": true, 
    "last_transaction_height": 422657, 
    "last_transaction_id": "5e4c0a42874ac59a9e21d351ec8b06971231ed2c02e0bac61b7dcc8ee8cb1ad2", 
    "owner_address": "16EMaNw3pkn3v6f2BgnSSs53zAKH4Q8YJg", 
    "owner_script": "76a914395f3643cea07ec4eec73b4d9a973dcce56b9bf188ac", 
    "zonefile_hash": "4d718e536b57c2dcc556cf2cdbadf1b6647ead80"
}

The owner_address field is the base58-check-encoded hash of my public key. Only the owner of this key can issue valid name operations. If you try to issue a transaction to update or transfer my name, the Blockstack indexer will ignore it (even if it otherwise well-formed) since my key didn't sign it.

My initial gut feel based on a couple hours of research is that the ENS is pretty well designed

ENS doesn't even store names; it stores the hash of a name. There is no "list all names" operation, so OpenBazaar would not have a "list all store names" operation (unless they implemented and curated a list themselves).

It tries to solve a real problem with name squatting.

ENS's approach to stopping squatting differs from Blockstack in that instead of using a price curve, it uses a Vickrey auction to sell names to the highest bidder. This will not solve squatting either, since obviously a squatter can buy up names well in advance of the "legitimate" owner.

In fact, the only squatting "solution" I'm hearing from the folks building ENS is to govern it with off-chain oracles to resolve name-ownership disputes. Blog post here.

We do spam filtering on the Onename registrar so we do not pay for squatters' names, but we do not (and should not) stop them from buying themselves.

Having to sync and maintain one chain is hard enough. Adding a second chain to manage would be burdensome. Unless the geth client could handle everything with minimal work on our part.

Unlike ENS, Blockstack is portable to any blockchain. Should OpenBazaar need to switch from Bitcoin to a separate blockchain like Zcash, Blockstack can migrate with it (so only one chain would need to be synchronized, and only one currency would need to be used).

(A few stats to gauge the success of Blockstack with subsidisation. It has registered 70,000 handles (see here) while being operational since September 2015 (see here). It will be interesting to compare interest in the ENS, which I don't believe is being subsidised.)

One metric I'd like to see with ENS is how cheap names will be in practice. It would suck if a squatter could come in and quickly buy up most of the names for pennies each (since few legitimate users would be willing to buy names before they actually need them).

[JustinDrake]

Thanks for the replies @jcnelson

Not sure what you mean by this?

As designed the resolvers are trusted entities. See for example https://api.onename.com/v1/users/duosearch. OneName could easily change the identifier ad8a93b524ad02de23ddd7760e49a34bc55f9b19 to something else and users of the API wouldn't know any better. Where is the cryptographic proof (e.g. signature and/or Merkle proof) proving that duosearch does map to ad8a93b524ad02de23ddd7760e49a34bc55f9b19?

There is no "list all names" operation

What is the use case for listing all names? As far as I can tell the only operation required for OpenBazaar is, given an OpenBazaar handle, to resolve to the corresponding OpenBazaar ID. ENS can do that without listing all names. Storing hashes allows for arbitrary length handles, and an arbitrary character set, which I believe Blockstack does not support.

[jcnelson]

As designed the resolvers are trusted entities.

Thank you for clarifying. The solution is to run a Blockstack node locally. With the new fast_sync feature, you can get one up and running in ~15 minutes. The node itself takes about as much resources as a Chrome tab.

What is the use case for listing all names?

This is meant for users like Duo Search :). You can be sure that you have indexed the entire name set, since names do not get lost.

Related, does ENS let you store arbitrary data alongside the names, or is just a link to a Deed object? I ask since this is a feature that OpenBazaar uses on Blockstack--the ability to store and resolve arbitrary off-chain state via one or more existing storage systems.

[JustinDrake]

The solution is to run a Blockstack node locally.

This does not work for browser implementations of OpenBazaar. We can't expect users to sit and wait 15 minutes to get handles up and running. I'm assuming synching involves downloading tens of megabytes, which is not workable for mobile devices. We need the ability to trustlessly resolve an OpenBazaar handle from a resolver with very little data (say, < 1kB).

does ENS let you store arbitrary data alongside the names

I believe you can associate arbitrary data with names simply by linking to an IPFS hash.

[cpacia]

@jcnelson

The solution is to run a Blockstack node locally.

That's on top of bitcoind right?

[cpacia]

We can't expect users to sit and wait 15 minutes to get handles up and running. I'm assuming synching involves downloading tens of megabytes, which is not workable for mobile devices.

Btw justin the ethereum light client takes about 5-7 minutes to get up and running and requires close to 350 megabytes to be downloaded and stored.

[jcnelson]

This does not work for browser implementations of OpenBazaar. We can't expect users to sit and wait 15 minutes to get handles up and running. I'm assuming synching involves downloading tens of megabytes, which is not workable for mobile devices. We need the ability to trustlessly resolve an OpenBazaar handle from a resolver with very little data (say, < 1kB).

A couple things:

• Isn't OpenBazaar's recommended mode of operation to run a full Bitcoin node? If so, then having Blockstack sync up would be a proverbial drop in the bucket in the default case.
• Nevertheless, our current engineering sprints are geared towards getting Blockstack light clients to run in the browser (ETA is end of Q2 2017). This means getting end-to-end authenticity for name resolution, zone file resolution, profile resolution, and read/write data storage using only a known-good consensus hash.

That's on top of bitcoind right?

Either your own txindex=1 bitcoind node, or SPV headers if you're willing to have your node talk to our txindex=1 fleet (this is the default). With our light client protocol (SNV), you'd instead need a trusted source for a recent consensus hash (e.g. a full Blockstack node running on your laptop).

[JustinDrake]

the ethereum light client takes about 5-7 minutes to get up and running and requires close to 350 megabytes to be downloaded and stored.

Why is a "full" Ethereum light client required for lookups? An OpenBazaar client just needs to download a reasonable number of recent block headers (say, 1,000 headers) and verify proof of work on those. Then very short proofs can be submitted (see here):

if a node receives a state root from a trusted source that node has the ability to know with full certainty the validity of any information with the tree by only downloading a few kilobytes of data in a proof

[cpacia]

Why is a "full" Ethereum light client required for lookups?

I don't know what a full light client is but the client downloads headers from the last checkpoint. The headers are bigger than bitcoin headers and they come in every 12 seconds.

They should probably add an option to delete headers older than two weeks as they aren't really needed. Right now they just sit on disk growing pretty rapidly.

[JustinDrake]

I'm calling a "full" light client one that downloads headers from the genesis. I'm assuming that's where you got 350MB number from. As you mentioned, we only need recent headers (this can be customisable; I expect 1,000 headers—about 3 hours and 20 minutes—is more than enough for most).

The headers are bigger than bitcoin headers

Do you know how large the headers are?

[cpacia]

It's not downloading from Genesis but rather from a checkpoint. Same as our spvwallet. But you can't really just ask for the last 1000 headers as you have no way to verify they are correct. You can only hardcore a trusted checkpoint header and download everything after it.

You can update the checkpoint with each release but it's still the case that the node needs to download everything after that checkpoint (though it can properly delete older headers).

[JustinDrake]

you can't really just ask for the last 1000 headers as you have no way to verify they are correct

Proof of work? The reward is 5 ETH per block, so 1,000 headers correspond to 5,000 ETH of economic finality. At current market price of $27.11/ETH that is $135,550. Not to mention that a fake header attack would also require a Sybil attack. Of course with Casper economic finality will converge much faster, so 100 headers would probably be sufficient.

[hoffmabc]

You need a starting point to validate PoW against though as the checkpoint correct? Last 1,000 headers would just be arbitrarily accepting the last x headers from some peer. Might as well make it 50 or 10.

[JustinDrake]

You need a starting point to validate PoW against though as the checkpoint correct?

I don't think a checkpoint is required. You can use any header as a starting point that has a convincing timestamp and difficulty.

Might as well make it 50 or 10.

10 headers would be quite low security (~5 * 10 * $27.11 = $1,355). Someone with a GPU (e.g. you) can easily start mining and waste $1,355 to build 10 fake block headers with convincing timestamps and difficulty. 1,000 fake block headers is economically much harder to pull off. (Notice the "convincing timestamp" requirement makes your attack non-reusable in the future.) Of course, even with just 10 headers the Sybil attack remains, so in practice this may be a hard attack to pull off even with 10 headers.

[hoffmabc]

What constitutes convincing? Checkpoints are usually hardcoded into clients (i.e. satoshi client) preventing reorgs beyond those checkpoints. Picking an arbitrary header as a starting point that isn't an accepted checkpoint in the community seems risky to me.

What does convincing timestamp and difficulty mean?

I was being sarcastic about the 50 or 10 amount. I meant that if we're not starting from a proper checkpoint it might as well be no checking as the level of security is even worse than just normal checkpointing.

[jcnelson]

Of course with Casper economic finality will converge much faster,

Casper will make this problem even worse. With Casper (and PoS in general), there is no way for a client to distinguish between two conflicting chains without some external trusted source to tell it the current set of validators. This isn't "PoW maximalism;" it's a proven result from a recent paper from IC3 (more discussion here). This could take the form of hard-coding the last set of validators in the OB client (i.e. to avoid having to ask someone over the network), but then OB would have to release a new client every time the validator set changes.

[jcnelson]

They should probably add an option to delete headers older than two weeks as they aren't really needed. Right now they just sit on disk growing pretty rapidly.

I'm confused by this. Are you talking about Ethereum headers of Bitcoin headers? SPV headers are only 80 bytes each (~36MB for the entire chain at the time of this writing).

[hoffmabc]

36MB would take only several minutes at most to download on a fairly slow connection.

[cpacia]

Bitcoin headers aren't as bad as ethereum but ethereum adds at least 1mb of header storage per day.

Just storing headers from the last checkpoint takes 350 mb.

[muneeb-ali]

@JustinDrake wrote:

6 months later the situation is worse, with an increase in confirmation times (and mining fees, currently subsidised by OneName).

Justin, can you please tell me how is the situation worse? Back then users were getting long wait times because of spam filtering at our end. We've not only actively worked on ensuring that OpenBazaar users don't get caught in spam filters but have hired dedicated support staff to prioritize any OB issues. From our support tickets, issues regarding pending profiles have almost gone down to zero. Yes, the bitcoin network is seeing higher fees but OB registrations going through the Onename registrar have never been more stable and consistent. A lot of work went into ensuring that this is the case.

@JustinDrake wrote:

BlockStack is First-Come-First-Served and a significant portion of the names (explorer here) is squatting.

Can you please give more details on why you think a significant portion is squatting? Here is a research paper that actually studied squatting in decentralized namespaces and concluded that our namespace by far has the most real usage. I can give you stats on how many users are (likely) real and not spam and what are the metrics we use to calculate that. You'd be surprised by how good the ratio is. We've carefully designed our pricing schemes and spam filters to achieve this and are actively improving our system.

Speaking of running your own nodes, we have support from Microsoft Azure and (recently) AWS now. You can deploy nodes, do a fastsync, and get up and running in minutes.

Finally, let's keep the bigger picture in mind that ENS is not even launched yet and we have 2+ years of production experience. Naming systems are much harder to build than most people realize. It looks like a deceptively simple problem in the beginning. Let ENS roll into production, evaluate how it performs in the real world, and then let's continue this discussion.

[hoffmabc]

I'd like to also point out one other situation, which is that OpenBazaar perhaps supports multiple naming systems. They all essentially are key value mappings to IPFS nodes so as long you understand how to differentiate between two more naming systems we could provide support for them.

It does bring up a good point about ENS not even being live yet. I know we're a few months out from releasing OB2.0 and we want to have a good option for our users here, so I think the conversation is a good one to be having.

[JustinDrake]

What constitutes convincing?

For timestamps this means requiring that the timestamps of the 1,000 blocks follow (within variance) the Poisson distribution that is consistent with your local clock. For difficulty you can combine a floor (e.g. 100 TH) with a variety of semi-trusted sources (APIs and/or random survey of the network).

OpenBazaar perhaps supports multiple naming systems

How would that work with ob:// urls?

[JustinDrake]

For anyone interested, there's an AMA for the ENS running now.

https://www.reddit.com/r/ethereum/comments/5z4iiw/ama_we_are_the_ens_team_ask_us_anything/

[shea256]

@JustinDrake Thanks for starting this discussion and for providing feedback on Blockstack DNS. Super interested in chatting more about how we can improve the service for you and our users.

Also we have lots of improvements on the horizon, including a new release of a name registrar with a beautiful interface that will be leaps and bounds more convenient for your users. Would love to show this to you sometime.

Just to understand where your head is currently at, are you sold on ENS or are you open to being swayed in the direction of Blockstack, given certain milestones are reached?

[JustinDrake]

Just to understand where your head is currently at, are you sold on ENS or are you open to being swayed in the direction of Blockstack, given certain milestones are reached?

Totally open :) ENS is untested in production (not even live yet). I find it encouraging you guys have received a $4M injection. At the very least if OpenBazaar goes with Blockstack you should be able to subsidise the mining fees, and while my issues have been unaddressed for months I do hope Blockstack will pick up pace.

Anyway I'm not a decision maker for the OpenBazaar protocol so my opinion doesn't matter so much :)

[muneeb-ali]

@JustinDrake Your issues were fixed in the earlier release of v0.14.1. I just updated the status of your issues -- sorry that the status wasn't updated, we were doing a major reorganization of our Github repos and are now updating all pending issues.

Also, your feature request was marked as "discussion" in Feb. We'd love to chat more if it can be implemented in v0.15.

[shea256]

Totally open :) ENS is untested in production (not even live yet). I find it encouraging you guys have received a $4M injection. At the very least if OpenBazaar goes with Blockstack you should be able to subsidise the mining fees, and while my issues have been unaddressed for months I do hope Blockstack will pick up pace.

Great to hear that you're open and yes, it's important to us that we can bring cheap to free names for your users.

Also, thanks for bringing these issues up again. @muneeb-ali and I are responding in the threads you linked.

Anyway I'm not a decision maker for the OpenBazaar protocol so my opinion doesn't matter so much :)

Regardless, you're running a very important company in the OpenBazaar space and we highly respect your opinion. We absolutely want to make sure you can bring the best possible experience to your users.

[muneeb-ali]

@JustinDrake Did you see the recent ENS bug? No action is needed if you weren't already bidding on names.

The design choice of on-chain logic for Ethereum means that bugs in a live contract would be much harder to fix on the "heavy" blockchain. The bug would've been harder to fix if it was discovered after the ENS contract was actively used (like the DAO).

[rphmeier]

comments on the light-client friendliness of the ENS

Just to shed a little light on this, Parity will soon have a light client designed specifically for very resource-light use cases and for efficient interaction with even very complex smart contracts.

[JustinDrake]

Closing in favour of #553