Ah, OK: bin integrity can be verifiable if they are linked into a hash-chain, so that each element includes hash of the previous one. It is enough to keep  last hash of each bin on verifying node to verify integrity of any bin.

Thus we have such space trade-off:

1. Normally verifying node stores whole blockchain. For example with 1 billion transaction and 250 bytes per transaction verifying node needs 250 GB of storage (minus whatever pruning can save). To send his money one needs to broadcast only his transaction, which is like 250 bytes for example.

2. On the other hand, if we move burden of proof to client using binning divide-and-conquer strategy, verifying node needs only block headers and most recent hashes in each bin. Suppose we use number of bins N = 1,000,000. Then bin hash storage requires 32 MB. 10 years worth of hashes requires ~ 42 MB of storage. So 74 MB total.

Client needs to store parts of Merkle tree which link his transaction to the root (this depends on number of transactions in block but likely something on scale of kilobytes) + all invalidation messages from the bin transaction belongs to. For example, with one billion transactions and one million bins, there are approximately 1000 messages per bin. One message is around 100 bytes. So total amount of information stored on client is 100 around KB per transaction. This information needs to be submitted to verifying node (unless it already has it cached).

So we have

1. 250 GB / 250 bytes in the first case
2. 74 MB / 100 KB in the second case

If we choose larger N we reduce amount of information client needs to store, but increase storage requirements on server.

For a very large N we'll have approximately one transaction per bin, so we get back to a situation where verifying node keeps track of every transaction. But for smaller N we essentially cluster many transactions in each bin, thus reducing storage requirements of verifying node.

As I said, this trade-off is similar to one used in hash tables and Bloom filters.

This scheme helps only with storage space but not with bandwidth. But a modest 10 Mbit/s connection can transfer entire 250 GB long blockchain in ~55 hours. So I'd say bandwidth won't be a bottleneck in scenarios considered here.

Disclaimer: I did not follow all developments in this area, so I apologize if it was discussed before.

It is expected that in the long term blockchain size will stabilize via pruning, but what if it will stabilize on a really high value, so high that few nodes will be able to chew it? Blockchain size is already a problem now...

I've heard that perhaps we could prune it harder, i.e. remove even those outputs which are still spendable. But then this aggressive pruning must be synchronized, otherwise if somebody prunes blocks before others do that he won't be able to verify blocks which mention UTXOs he pruned away...

Quite often performance problems can be solved through divide-and-conquer strategy. For example, in distributed hash tables large amounts of data can be spread among many nodes in such a way that each node carries only little amount of data.

But it won't work for blockchain because the whole point of blockchain is to prove lack of double spends, and apparently the only way to prove lack is to show the whole thing... Or is it?

I think some trade-off is possible here, remotely similar to trade-offs used in hash tables and Bloom filters...

So the problem we are trying to solve is giving person ability to prove that his transaction output is unspent, i.e. there was no transaction which spent it since it was introduced into blockchain. With existing approach such proof would consist of a full, non-pruned blockchain since transaction in question... Which might be a bit too big.

Can we make it smaller? Well, why not. Let's define N bins such that each transaction hash falls in one of them. (E.g. if N=10^20 bin would be identified by first 20 bits of txn hash.) With each block we'll include extra information which notes which transaction outputs were spent in this block for each bin. This information must be verified by miners in same way they verify transactions.

Now to prove that my output is not spent, I need to show only content of one bin, which is presumably something on scale of 1/N of total blockchain size... Which might be manageable for large N.

E.g. suppose we have 1 billion transactions, one spending notice is encoded in 40 bytes and we have N=1,000,000. Then  proof that output wasn't spent is just 40,000 bytes... Which is definitely manageable.

However, I did not account for one thing: we need to know which blocks have data for which bins, and this requires certain amount of bytes per block. higher N will generally requires more bytes... So there is likely some tradeoff where N is optimal for given amount of transactional activity.

Suppose A wants to exchange his coins for coins B has. I think minimal version is this:

1. A publishes an offer which has information on what coins A has, what he wants to receive, A's address, A's contact info.

2. B discovers A's offer, accepts it, creates a transaction and signs his input. But this transaction doesn't have A's signature. So it is again published somewhere.

3. A discovers B's incomplete transaction, signs his input and broadcast this full transaction into coin network.

Bitcoin nodes relay only correct transactions, so you cannot use this protocol to broadcast offers and incomplete transactions.

On the bright side, it's possible to use something as simple as IRC or email to do trading. (I plan to use HTTP for this.)

Yes, divisibility. Also, less blockchain bloat, I think.


Colored coins are also available and running right now. How so?

• they can "run" on top of any blockchain, particularly, Bitcoin and Namecoin
• basic implementation already exists
• implementation is not released to public yet, but neither is your hypothetic script

So I'd say right now colored coins are closer to becoming a real thing.

As for advantages of Namecoin, nobody stops you from using colored namecoins. So you can grab colored coin implementation, apply it to Namecoin client and then integrate it with Namecoin's advanced features.


"Truly decentralized but automatic exchange" are possible without WoT too, as atomic coin swaps are 100% secure. Some reputation system might be needed to prevent order book spam, but I doubt that WoT is needed here since there is no way for people to lose their money.


Atomic coin swap can make trade 100% secure: https://bitcointalk.org/index.php?topic=112007.0

As for order announces, it can be done over a simple p2p network. It's not a rocket science.

Colored coins are very similar to smart property (or maybe it's the same thing, depending on how you look at it), and currently there are people who work specifically on "trade shares of assets and pay dividends". See here: https://bitcointalk.org/index.php?topic=106373.0


I think we'll get a working proof-of-concept in a couple of weeks.

Also Jeff Garzik is working on pybond: https://github.com/jgarzik/pybond

Good point. But I work mostly on "low-level" stuff, I'll forward this consideration to people who work on app level.

There is a plenty of reasons.


I'd like to see it too, but that doesn't mean that there is no room for other solutions.

Particularly, I want to make one based on simple information exchange protocol on top of HTTP. (I.e. pieces of transactions and meta-information is serialized and stored/retrieved via HTTP.) It can easily scale from fully centralized to somewhat-decentralized to full p2p.

There is no reason to start with full p2p: it's far easier to start with something centralized and then scale it. (This isn't the only argument, though.)

(I should note that I'm not a stranger to p2p stuff: I once implemented an ed2k client, and I read articles on DHTs and whatnot... It's just that HTTP provides cleaner solution by decoupling of transport layer from layers which implement application semantics.)


As I already noted, p2p or not p2p is just a transport layer. It, broadly speaking, does not affect transferability of assets, trust requirements etc.

It really isn't just an idea anymore, concrete implementation is currently under development. There is a prototype which is demonstrated to work.

It is vouched for by some members of core development team, particularly Jeff Garzik. See here: https://bitcointalk.org/index.php?topic=106373.msg1225948#msg1225948

You cannot simply not believe in it, it's already a reality.


It's certainly your right to prefer one thing over another, but it would be more constructive if you listed concrete cons/pros of different methods.

You can find a discussion of colored coins vs. merged mining here: https://bitcointalk.org/index.php?topic=106449.msg1231210#msg1231210

Why do you think it's a good thing? If we don't want them to be mixed, they can be mixed only accidentally.

So, if accident happens, with order-based coloring you get uncolored output, so information is destroyed. Now if they represented something valuable, issuer can issue a new token and give it to last holder after he learns about an accident. So accident is resolved by issuer.

With your scheme, some random party might get ownership of valuable coins in case of accident. Yes, they won't be destroyed, but is lottery really a way to resolve this?

Well, this is quite similar to colored coins, aside from namecoin integration.

I've even mentioned your thread on colored coin project announcement: https://bitcointalk.org/index.php?topic=106373.0

You fail to understand that Bitcoin is secured via proof-of-work.

Miners do that work to get a reward.

What reward will they get if they'll mine your share alt-chains?

Yep, that's right, no reward at all.

Your alt-chains won't be secure through proof-of-work, so you'll end up with something equivalent to OpenTransactions in the best case.

On the other hand, colored coins run on top of Bitcoin system and do not require any additional mining power.

Also you can exchange different colored coins (particularly, buy coins which represent shares for BTC) via atomic coin swap, which is secure, unlike cross-chain trade. (Which is both very complex and insecure.)

It's more like "taint all the money!"

As I understand, this is largely compatible with order-based coin coloring, i.e. as long as transactions adhere to order-based coloring rules this proposal and order-based coloring will produce identical results.

The only practical advantage I see is that it's possible to pay fees with colored coins, i.e. miner can take advantage of coins' color.

However we I'm not convinced that we need this more complex system just to handle fees, since there are some ways to use colored coins for fees with order-based coloring.

Well, sometimes coins are lost, you cannot do anything with it. You know, lost wallets and stuff like that...

Same is true for paper securities: some promissory note might be lost in fire, for example.

Tainted coins are contagious: if you mix tainted coin with non-tainted one result is tainted.

Colored coin is counter-contagious: if you mix colored coin with non-colored one, or with a coin of different color, it loses its color tag, the result is uncolored.

So these things are almost unrelated.

There are existing tools which trace coin taints; "colored coin" tools won't help you with this at all.

Via a special coloring rules/algorithm. See here: https://bitcointalk.org/index.php?topic=114571.0


Uncolored. Essentially you're scrapping your colored coins for underlying BTC in this case.


If you pay fee with colored coin miner will get this money fresh and uncolored, so don't do that with coins more valuable than underlying BTC

There are several solutions to transaction fees with colored coins:

• don't pay fee. some transactions are eligible to be included into blockchain for free
• have a small amount of uncolored coins and pay fees with them. presumably your client software will do that automatically
• find someone to pay fee for you: you'll pay him colored coins, he will pay fee with his uncolored coins

Basically, there is a way to do it Basically, colored coins make trade secure, and so there is an easy way to automate such trade. (I.e. if it's secure anyway we don't need to hand-pick whom to trade with.

For a longer answer see here, second part particularly: http://www.reddit.com/r/Bitcoin/comments/110scc/glbse_closes_frauds_investors_might_be_facing/c6ijun1

See here: http://en.wikipedia.org/wiki/Orphan_structure
and here: http://en.wikipedia.org/wiki/Discretionary_trust
and here: http://en.wikipedia.org/wiki/Unit_trusts

Apparently nefarious activities were known well before Bitcoin, who would have guessed so...

1. Then companies outside of 'merica will have an edge.

2. Just don't call it "securities" and don't call it "companies". (See below.)

3. Again, auditor can be anywhere on the internet.

4. So you say if you compile a list of companies with ratings it is a crime? Holy shit. Do it over Tor then. Nobody gives a fuck about your real identity, all what matters is track record.

5. I don't think it's really possible to eliminate reliance on trust for all but few specific sectors.

---

If you don't want any legal protection for shareholders, simply say that it is a game and do not sign any contracts. Oh, this game items are traded for money? Well, I heard that WoW items are valuable too, but I doubt they are regulated.

If you want some legal protection for shareholders, but you do not want to issue securities, you can do it this way: Release an informal contract which would describe nature of securities, but it won't be signed, so it will effectively be same thing as "game items". Also you will make another contract which would acknowledge your debt to shareholders/bondholders, this contract will be properly signed. Something like "I owe %this% amount to people who can be identified in %such% way". Essentially, it is IOU. I doubt it qualifies as security. Anyway, only a trusted 3rd party (something like audit company) will have access to this contact, it won't be released to public. If shit hits fan, i.e. issuer defaults and shareholders won't to extract money from him, "auditor" will make contract public and so shareholders can demand their money legally.

But BEFORE shit hits fan all regulators can accuse you of is that there are some game items, traded in some weird cryptographic way, which might have some connection with what you do. Good luck with that.

---

Suppose you are, in fact, a 'merican company which wants to issue shares in crypto way. No way to do that? Think again.

First, it should be a private company. A part of it should be owned by an offshore trust(?) company, e.g. something on Cayman Islands. That offshore company will issue crypto shares, and will represent rights of crypto shareholders. Normally, dividends from private 'merican company will go to offshore company and from it to crypto shareholders. If something goes wrong offshore company can do something about it.

The only risk here is that offshore company will go rogue, but I imagine you can secure it same way you secure trust companies. Just say that beneficiaries are identified through a crypto protocol...

Exchange based on colored coins can be pretty much completely decentralized. It would be essentially a trading platform.

I imagine that if this thing will work, there will be a market for verification/rating/audit services.

If marketplace is completely open, ponzi funds and other bullshit investments will be numerous. But legit businesses would pay some "rating agency" to verify their existence, do audit etc.

Such rating agencies can build their track record and gain trust. Through competition most effective rating agency will win.

So, ironically, 100% open marketplace is a solution for ponzi and spam, IMHO.