Bitcoin technically has the capability to store at least 1K bytes per transaction using multi-sig outputs. 66 bytes per output * 15 possible outputs (for standard transactions) = 1K bytes. And you could do even more than that with non-standard transactions, making transactions with 3K bytes or more.
That said, you probably don't want to do this, because it contributes to blockchain bloat.
We made the decision of storing the data in a DHT because it's more efficient and you can store much more data than a few thousand bytes.
Hey buddy. You're killing it man. Thanks for all that you do.
One thing I've still not grokked about your vision: What kind of redundancy can you expect for the DHT? It seems clear that, for the foreseeable future, there will be millions of copies of the bitcoin blockchain. How can you know that there will be a sufficient number of copies, distributed in a sufficiently diverse pattern, in order to ensure preservation of the DHT?
1. The replication factor of the DHT is set to be high.
2. We'll be committed to seeding the network and will work with others to have them run nodes.
3. We will provide a full index of the DHT, so the data can be retrieved via our API as an alternative to checking the DHT (the data can be stored and mirrored anywhere, since it's hash-addressed).
I've been doing some analysis of the bitcoin blockchain and there are only around 17,400 transactions that take up a total of 16 MB in transactions and 550KB of OP_RETURN data. Some protocols use OP_CHECKMULTISIG, OP_CHECKSIG and other methods so this doesn't account for everything.
However, the vast majority of bitcoin blockchain "bloat" is from standard bitcoin transactions.
Financial and accounting data has always contained more than just integer values of credit and debit. Who, how, when and why are just as important to good bookkeeping as to what was transacted.
Blockstore, by creating transferable digital property in the form of a key/value store, creates an economic incentive to use Bitcoin. Right now, Bitcoin needs all the help it can get. Consumer adoption will not happen if Bitcoin is just trying to be a public ledger of integer values that attempts to compete with MasterCard and Western Union.
No single entity controls it, but that doesn't mean you can do whatever you want. If someone is abusing the blockchain by bloating it with useless garbage, there will be consensus for fixing that. So don't build a business or technology around abusing Bitcoin's blockchain, because you will be left out.
Why not set clear rules? 1 byte of blockchain costs XXX millibitcoins. You like it — you use it. You don't like it — you don't use it. It's clear that if anyone can use blockchain as information storage, someone WILL do it, now or later. I think it's better to set the rules sooner than fix things later when they are out of control.
It's tough to set any simple firm rules that maintain the right incentives, because (roughly) each byte incurs costs on every node storing/verifying the blockchain, while any set one-time fee can only be collected by some subset of those nodes up-front.
Thus you can expect continuing push-and-pull negotiations, perhaps requiring a separate system of continued payments, if you really want indefinite, reliable, unalterable storage.
No, because the miner who gets the fee isn't the only one who will have to work extra. All full nodes will have to relay and store that transaction. And there is no known way to pay full node operators in a way that can't be abused.
Hi Ryan! Right, we need to avoid faster blockchain bloat(btw we already have this problem even with financial transactions, as Toshi node bootstrap takes few weeks even on a relatively powerful server), but best way is to store data into not-Bitcoin chain I guess, and better, to work on chains with optional storage for different kinds of data(financial state not depends on).
1) Every username system has some limitation on usernames. Look at Twitter. There are 650 million twitter users, and all of them picked usernames in the same global namespace. This demonstrates that using a global namespace is quite doable.
2) You're right, people usually have multiple Bitcoin addresses and quite a few people prefer to use different addresses for different transactions. However, the protocol is extensible and is not limited to a single address. In the future, the protocol will support a list of bitcoin addresses instead of a single address. Further, you can use a hierarchical bitcoin address and direct people to different addresses in the hierarchy. In that sense, the bitcoin address listed is just a way to identify the tree of addresses the user owns. Last, the protocol supports data to be linked to from the blockchain, so if you want, you can have a next pointer lead to an API endpoint that returns a different bitcoin address every time.
3) As far as supporting only [a-z0-9_], those are the characters that most username systems support, including twitter. Some say this is due to the fact that those are the only "word" characters. Also, using this set makes it more difficult to confuse addresses. The domain name system has similar restrictions for similar reasons. I know that international readability takes a bit of a hit, but I'm sure we'll find ways to improve the experience. We're all up for suggestions.
Don't underestimate how much work Twitter has to do with a global namespace. Brand protection complaints and negotiation, conflict resolution, allowing renames, allowing reuse of abandoned names...it's not trivial, and unlike the Internet (where every registrar deals with a piece the userbase), they centralize all that labor.
I love your pgp-messenger idea - you should do it!
And you're right - the pretty front end is a big component. Two things, though - 1) we're working on open sourcing the profile crawler 2) it shouldn't be that difficult to roll your own pretty front end.
No this is a feature. Big profiles (larger than 519 bytes) are chunked into multiple key-value entries in the blockchain. The "head" chunk has a next pointer to the next chunk and so on. The head chunk's key is the username, in the "u/" namespace. We didn't want to polute the u/ namespace with follow on chunks, so we just decided to go with "i/", but really the next pointer can go to any key in the KV you want.
We're working on a profile updating tool for the typical user and should have it out in the next couple of days.
In the meantime, if you're somewhat tech savvy, you can update your profile as follows:
1) download/install Namecoin-Qt or Namecoind
2) use the OneName profile builder and grab the JSON
3) calculate your WIF formatted private key from the passphrase (just a sha256 then a conversion to base58check - you can use https://github.com/halfmoonlabs/coinkit for that)
4) import your WIF into your namecoin client (you should now see the username in your possession)
5) perform a "name update" operation with the new JSON profile data
We don't have your private key, and so we have you write down a passphrase that can derive the key (sha256(passphrase)). In addition, we have a last resort mechanism to help you recover your private key if it ever gets lost. We use shamir's secret sharing to split up the secret key, and send you a share. The pk can only be reconstructed when both shares are combined. We have zero information about your pk.
Why email it to me though? If all you need to essentially recreate the private key is this tidbit you've emailed me (plaintext, available to anyone), plus the (potentially compromised) tidbit on your server... What am I missing? Shamir's secret sharing doesn't help me if you already have access to all the pieces (your email account and a hacked server).
I assume, by "they don't have it", they actually mean "they had it when you input it into their sign-up form, kept it just long enough to put it into an email, and then erased it."
Sha256 is not a suitable key derivation function. Attackers could then crack the keys pretty easily (now the keys are only as secure as the passphrases). Use something like pbkdf2/bcrypt/scrypt.
You should consider cities or regions as namespaces and not countries like tld, because as you see with Ukraine, Kosovo etc they change. Birthcity or village remains through generations. Language is also very crowded, names just arent unique.
I don't want my identity tied to my city or region. I might not want to give out my birth city, or I may simply not identify with it anymore.
Forced namespacing is just a poor solution. Users can add whatever namespaces they want to their own username if they want to, after all, it's just a string.
We need to be clearer with this so apologies for the confusion. Calculate the sha256 of the passphrase to get the namecoin private key (in hex form). Then import the pk into namecoind or namecoin-qt with importprivkey.
Thanks for the clarification, though I'm a tiny bit confused.
Using my passphrase, I can successfully generate a sha256 and then import my bitcoin client, which then provides the same bitcoin public address as shown on my profile (I left it as the default on profile creation).
This shows that I have calculated the hash on the correct passphrase (no errors). However when importing the same key into namecoin-qt I'm getting "Invalid private key (code -5)".
Am I doing something fundamentally wrong, the key should be able to be imported into both -qt clients right? One for the ownership of the bitcoin address and the other for ownership and management of the u/name. I'm determined to get my head around this
Edit:
Ok it looks like Armory will happily accept the 64 long private key, but namecoin-qt seems to prefer the 51 long keys. Perhaps in 'wallet import format'. No error anymore, still trying to determine if its worked though.
Yes, when importing the private key into Namecoin-Qt, it needs to be in wallet import format. Make sure it's a Namecoin WIF, though. You might find this library helpful: https://github.com/halfmoonlabs/coinkit.
I imported the address into namecoin-qt but don't see anything under Manage Names and I don't even see a transaction? Do we need to re-index or anything after importing the private key?
That said, you probably don't want to do this, because it contributes to blockchain bloat.
We made the decision of storing the data in a DHT because it's more efficient and you can store much more data than a few thousand bytes.