Open to burning coins to an unspendable address?

[paulkernfeld]

Is GitTorrent open to burning coins to an unspendable address (e.g. 1GitTorrentXXXXXXXXXXXXXXXXXahssxC) when storing data in the Bitcoin blockchain? This would let the GitTorrent client retrieve usernames with an SPV client instead of a full client by taking advantage of BIP 37. An SPV client should require about 10,000x less bandwidth than a full client. You would still need to use OP_RETURN outputs to store the actual data; this would just help with retrieving it efficiently.

[cjb]

Interesting! I don't know anything about how SPV works, so that's the only reason it hasn't been considered yet.

@blockstack folks, any thoughts on that?

[paulkernfeld]

I'll try to summarize my thoughts on the advantages and disadvantages of sending coins to an unspendable address as an index, but I am definitely curious to hear what the blockstack people think.

Advantages:

• Scanning the blockchain will be way faster with an SPV client; no need to bundle a database of registered usernames with the GitTorrent repo.
• You can still run a full client if you want to.
• This would let GitTorrent take advantage of future optimizations in Bitcoin, such as ultimate blockchain compression.

Disadvantages:

• Additional complexity
• This uses the UTXO index for non-financial purposes, which is controversial.
• Transactions will cost slightly more in fees, since there will be an extra output. But this should add only like 30 bytes.
• A full node can currently trick an SPV client by omitting transactions. Ultimate blockchain compression might one day solve this. In the mean time, SPV clients could improve their chances of success by querying multiple nodes.

[adlai]

Calling it merely "controversial" is an understatement.

If a man dumps toxic waste in a river but nobody hears it splash, is it still "controversial"?

[paulkernfeld]

@cjb here is a library that could be used to implement an SPV-compatible solution. If you like this idea, I would be interested to try to implement a username registration system for gittorrent.

I have a few questions about how you think the gittorrent username registration system should work. Most of these questions are important whether or not you want to go with the SPV solution.

• Should someone register a username for gittorrent only or should it be a username that can be used for multiple services? I'd say the forward-looking solution might be to let the username be reused for multiple services; otherwise, in a future with many applications that use blockchain username registration, users will need to spend a fortune on registering usernames. That said, a reusable name would require some extra plumbing, because you'd need to create a way to represent ownership of names in an application-agnostic way. I believe that Blockstore's name registration system has a good way to do this using Bitcoin private keys.
• How should the owner of a name be determined? Blockname uses the "highest single payment." I think it might be a bit fairer to use the "total of all payments." With blockname's system, I'm imagining a scenario where party A and party B engage in an expensive bidding war for a particular name, and then party C swoops in and takes the name for a single payment.
• What characters should be allowed for a username, and how should a username be encoded?

[cjb]

@paulkernfeld Thanks for the generous offer! I'm afraid I don't know enough about SPV yet to be able to tell you whether I like it. My intuition's been to go with blockstore, just from seeing it pick up some community momentum.

But we could certainly support burnstream usernames under a namespace (along with other registration sources, e.g. dns TXT records), e.g. git clone gittorrent://paulkernfeld@burnstream/gittorrent, what do you think about that?

Just a quick question:

Blockname uses the "highest single payment."

It's been a while (and I'm still not very familiar with blockchain work in general), but I thought blockname simply scanned through blocks in order and the first REGISTER op it found for a name became that name's owner. How does payment come into it there?

[paulkernfeld]

@cjb now that you mention it, namespacing usernames sound like a really good idea; that would let you register names with blockstore, burn-stream, blockname, Namecoin, or whatever other system you want. To date, no blockchain name registration system has really proven itself successful, so it's probably a good idea to exercise caution with respect to your choice of registration system!

As for blockname, I believe that you can replace an already-registered name with another name by burning bitcoins, i.e. destroying them. This is from the blockname README:

In the background the resolver will continuously index all newly broadcast transactions that have a valid hints (any OP_RETURN starting with a *), storing only the unique hints that have the largest values associated with them. The value of the hint's own output (the "burned" value in satoshis) must be larger for the new hint to replace a previous one of the same name.

This leads me to believe that it chooses the highest-valued output for a given domain name. This may sound crazy to you (i.e. rich people will take over all the domain names), but taking the highest bid may be the only way to prevent squatting.

[cjb]

That does sound crazy to me!

I don't see the fuss around squatting. Twitter (and GitHub, and so on) ends up subject to worse squatting because it's completely free to register as many users as you like, and that doesn't seem to be going unacceptably badly. :)

@muneeb-ali, sorry to bug you -- is it true that blockname will replace a name registration with a later tx for the same name that has a higher burned value? Thanks!

[paulkernfeld]

That does sound crazy to me!

Haha, well played. Kalodner et al. seems to indicate that squatting is pretty rampant with Namecoin, so I think it's worth at least thinking about. If there is a better way to prevent squatting, I would definitely like to hear about it. BTW, if anyone is interested in this stuff, there's a really nice overview of a few different possible system designs on page 14 of the Kalodner paper.

I had never really thought about why squatting isn't a problem for centralized sites. Twitter says in their squatting policy that they prohibit the selling of usernames, which means that there's little reason for someone to squat a Twitter username, because you can presumably just report them and Twitter will deactivate their account.

[xloem]

I just wanted to add/clarify the information that clients store an index of output addresses in a database, so if you store information in an output address, it can be queried directly without having to scan through all the blocks. This view of information in the blockchain turns it into a key-value store, where the keys are the output addresses, and looking up an output address gives a list of all transactions that have ever sent to it.

The common-blockchain protocol ( https://github.com/common-blockchain/common-blockchain ) could be used to generalize this access for a wide variety of backends -- e.g. you can use many web services to look this up if no node is installed.

[xloem]

Thoughts re: name-owners:
I briefly looked through the blockname source and foudn that it did indeed consider the highest payment to a name to be its owner. This means that anybody can instantly steal a name by outbidding, and I believe it is a bad thing.

I might imagine something like this:

• First to register a name has the name. After two years, ownership will be recalculated.
• Coins may be sent to a name to bid on the name. Bids will only count if they are made greater than one year prior to ownership calculation, and are cumulative per bidder for two years only. This means bidding closes a year before the name expires.
• Names may be looked up by year. So if I want to be sure I am looking up a name I used in 2015, I can lookup somename:2015 or somesuch and know I am getting what I expect.

This prevents name owners from being surprised by suddenly losing what they have, squatting from lasting more than two years, and gives name users a path to deal with unexpected ownership change.

[paulkernfeld]

@xloem yeah... this tension between squatting and seizure seems to be unavoidable, and I'm not sure which is the lesser of two evils. It sounds like your proposal is strongly focused on preventing seizure, and it sacrifices the ability to register existing names quickly. Perhaps one could game this system by buying up a bunch of names cheap, then selling to people who aren't willing to wait the whole two-year period? I really like your proposal for queries using name-at-time!

If you have some time, I'd be interested to hear your thoughts on a new proposal that I'm working on in which names go to the highest bidder, but after a delay.

Perhaps only real-world experimentation will reveal the ideal balance between squatting and seizures.

[xloem]

Yes, I'm primarily concerned about seizure. It can lead to really nasty security issues. If somebody can spend $X to instantly steal my name they can deceive people who are using it. I feel long-term names are important -- like somebody's legal name, public key fingerprint, web address; rather than things that might pass around on a monthly basis.

I guess with my proposal, one would counter the concept of squatting for the impatient a few ways:

• First registration dynamics could change to require the year delay like those later
• First registration dynamics could change to allow continuous bidding ala blockname
• Timing of bidding cycles could be changed to a roughly exponential function. At first you bid on the name for a day and it expires after two days. After that a week. Then a month. etc. Thus names are more stable the older they are.

But personally I do not see a problem with squatting if it is time-limited.

I read your proposal! It's similar to my idea. Here are my thoughts:

• I would give each name its own burnstream. This allows for speedy lookup using existing bitcoin client databases without having to iterate all names and place them in a new database. I think the usage of space in utxo database would not change?
• Personally I prefer my solution of having a set time for owner calculation rather than a changing function. I think it makes it easier for name owners and users to understand when they may lose use of the name.
• A wealthy entity can abuse a less wealthy competitor by seizing their names at inopportune times. ("Oh, you're having a big internet event? (or a ton of people are about to log in to your banking interface?) Ha! Right now is when I'll choose to buy your name!"). I think the protocol should require at least a few days (!!) of delay for changing ownership, no matter how much is paid, preferably much longer.
• I do not feel the presence of squatted names on namecoin is an indication of failure at all. I think it just shows it is not yet popular.

[paulkernfeld]

@xloem thanks for the feedback, I appreciate you taking the time to read my design!

As far as the squatting vs. seizures debate, your concerns about seizures are definitely valid. One thing that I didn't really mention in the doc: my expectation is that the community will pitch in to "vote with their wallets" on which seizures are acceptable or unacceptable.

I think that only time will tell which kinds of systems end up working better, and I would definitely like to try out your proposal if you want to implement it! Perhaps even both systems will be independently useful: one could be the "secure enterprise solution," and the other could be the "cheap casual user" solution.

I think that your squatting solutions could work. They might introduce a third problem, though, which is that people who legitimately want names would be unable to register them quickly. I think there is probably an interesting mathematical theorem in here somewhere about the impossibility of constructing a system that is squat-resistant, seizure-resistant, and fast.

I would give each name its own burnstream. This allows for speedy lookup using existing bitcoin client databases without having to iterate all names and place them in a new database. I think the usage of space in utxo database would not change?

My design is optimizing mostly for SPV clients. A single burn-stream is good for them because it means that they will only need to make one pass over the blockchain to download everything. Your proposal is better in a situation where the client has direct access to the UTXO database, such as for a full client that has already downloaded the blockchain, or a web client connected to a server. You're right that the space used in the UTXO database would be equivalent.

Personally I prefer my solution of having a set time for owner calculation rather than a changing function. I think it makes it easier for name owners and users to understand when they may lose use of the name.

Yeah, I think there is a problem with BurnName's mechanism being kind of hard to understand. Maybe there's a way to change it to make it more intuitive.

A wealthy entity can abuse a less wealthy competitor by seizing their names at inopportune times. ("Oh, you're having a big internet event? (or a ton of people are about to log in to your banking interface?) Ha! Right now is when I'll choose to buy your name!"). I think the protocol should require at least a few days (!!) of delay for changing ownership, no matter how much is paid, preferably much longer.

I think that's a very good idea. Maybe I could replace the 30-day vesting period with a 14-day fixed delay. Or I could keep the vesting period and add in a 7-day minimum delay, perhaps. You're right that being able to instantly seize a name is almost certainly bad.

I do not feel the presence of squatted names on namecoin is an indication of failure at all. I think it just shows it is not yet popular.

I think that is a very good point; I'll remove that from BurnName. Here's maybe a better example of the idea that I'm trying to communicate: the Namecoin devs don't own "namecoin.bit," and they don't have any way to get hold of it.

[paulkernfeld]

I just wanted to add/clarify the information that clients store an index of output addresses in a database, so if you store information in an output address, it can be queried directly without having to scan through all the blocks. This view of information in the blockchain turns it into a key-value store, where the keys are the output addresses, and looking up an output address gives a list of all transactions that have ever sent to it.

@xloem Sorry, I just saw this. This is correct, but the blockchain can only be used as a key-value store after the full blockchain has already been downloaded, so you there's still the penalty of downloading the full blockchain. In an SPV client, you can download a filtered copy of the blockchain, but you still need to download part of each block. If you're using a web client that fully trusts a server, then you can use any index that the server has, which would definitely include the UTXO index.

[cjb]

@paulkernfeld @xloem Ah, I asked @shea256 about Blockstore on Twitter, he says that you can't steal a registration away with a higher burned value:

https://twitter.com/cjbprime/status/702872879784923136

[cjb]

Ohhh there's been super confusion here. I was talking about using blockstack and blockstore, and @paulkernfeld was quoting the spec of blockname, which is a totally different project. I wasn't proposing using blockname.

[cjb]

Here's more reading on Blockstack, which does not have outbidding problems, from their shiny new website:

https://blockstack.org/

[shea256]

Thanks for the shoutout @cjb and @paulkernfeld! Happy to answer any questions about Blockstack. Let me know if there's anything you don't find on blockstack.org and we can add it in to clarify.