Many companies listed on litecoinglobal.com sold shares/bonds to buy equipment. E.g. ESECURITY SA and OPCU are hosting companies which need servers. ART is going to be a ceramic art studio which requires expensive equipment. And so on...

Maybe it's not representative sample, but it's still an interesting case.

I proposed a solution in other thread... It is possible to use blockchain as an address book without namecoinesque complexities.

To reference a public key you can reference certain transaction input. Transaction input can be identified using triple <block_index, transaction_index, output_index>.

Applying certain optimizations and trade-offs you can encode this tripple in a 32-bit (or even 24-bit) number.

PGP word list can encode 8 bits in one English word. So to encode a 32-bit ID you need four words.

So, basically, we can make public key IDs like "absurd replica cranky decadance".

And this is, like, also a name of a company...

This was proposed many times, I even provided links to some of such proposal in the first post of this thread: https://bitcointalk.org/index.php?topic=54033.0 , https://bitcointalk.org/index.php?topic=52494.0 , https://bitcointalk.org/index.php?topic=66868.0


If you'll think more about this, you'll see that colored bitcoins is actually a smart way to do this:

• it's possible to implement all desired features
• it is automatically as secure as bitcoin, there is no need for any mining just for colored coins
• most importantly: you can buy and sell things for Bitcoins

That said, a separate blockchain could be nice. But the problem is that it is hard to even make a list of features it should have.

If you'll lurk more you'll find ripplecoin proposal

The whole point is that company will get smart property instead of money. This smart property will enforce certain smart contract which would discourage misuse.

There are several different ways to do this. Some are relatively easy to implement and other are hard or impossible.

While some proof-of-concept probably can be done in a couple of days, a smartphone app and all the stuff is pretty involved, it would likely take months to implement and polish it.

So, basically, it's unlikely to happen without a business plan of some sort... Very few people can spend a couple of months of their time just on some fun app.

LOL. So many tech companies looked completely invincible at their peak, earning billions and billions for their shareholders, only to fade into non-existence later...


You cannot take open source technology for yourself, you can either develop or use it.


That's kinda ironic, have you looked up who is currently sponsoring p2p exchange development?

(For the record, I'm not currently working for anybody and I, in fact, had to refuse some offers.)


Well, the main point is that issuers and shareholders do not depend on a particular exchange platform, they cannot be held as a hostage.

(I'm posting this now because tech sorta kinda works. I mean, we need to fix a couple of problems and make it more robust and friendly, but basically people can create assets and exchange them securely without depending on anyone. (OK, transport is kinda centralized now, but it's a tiny issue.))

I was renting a server from Fennec. Can't say it was perfect, there were some connectivity issues likely on some switch in datacenter, but they were quickly resolved.

So, flawless: no; legit: yes.

Note that price is fixed in BTC, which is cool, but BTC crawled up a lot in past few months so it's now a bit too pricey.

This encoding scheme: http://en.wikipedia.org/wiki/PGP_word_list

Basically, you make some transactions using your address. Each transaction gets an unique 4-byte ID once it is in blockchain. Each corresponds to an unique combination of PGP words. You just pick combo you like, and it becomes your company's moniker. Of course, you cannot pick exactly the name you want, but you might pick something reasonable.

It is kinda like 1-800-FLOWERS. Each digit is associated with a couple of letters  on phone's keyboard, and you can find mnemonic which will help people to memorize your number.

Effectively we are using blockchain as an address book, which is cool.


4 byte ID is simply a transaction addressing scheme, people don't need to do it, software will do it automatically.

We need to use this addressing to use blockchain as an address book. The alternative is to scan blockchain for the name, which is infinitely more expensive. ( O(N) vs O(1) )

BTW we can probably shrink IDs to 3 bytes (thus three-word names instead of four-word names), but it will work for a limited time, say 4 years or so.

EDIT: Oh, nevermind... There is a 24-bit encoding scheme which will last for about 44 years and is more-or-less reasonable. In 44 years we'll have to change scheme, LOL. So, I, for one, welcome our "cranky corporate absurd" overlords!

Oh, forget about firstbits, it was a bad idea. Public key can be identified by three small numbers: block index, transaction index, input index. I don't think you need more than 4 bytes to encode this.

So invoice or color definition includes 4-byte ID. You can find public key corresponding to that ID in the blockchain.

You can then check that signature on invoice or color definition corresponds to this public key.

Thus nobody can impersonate this short 4-byte ID: attacker has no access to private key, so he can't produce valid signature.

What do I win?

Namecoin isn't very different from approach I've outlined, you still need to scan whole blockchain... Namecoin chain is certainly shorter than Bitcoin chain, but depending on that isn't cool.

Well, full scan is needed only once... It isn't impossible to download 5 GB of data if you're connected to wifi. It just takes some time.

Yep, but I was considering a scenario where one uses p2ptrade to purchase a voucher. p2ptrade is already trust-free and secure as long as you have a valid ID. And SSL won't help you to find valid ID unless you can get it from a trusted party or you already know it.

I don't know which of bitmitt.net and bitmit.net is valid without getting this name from a reputable source.


ID can be made short thanks to firstbits, and it can be encoded using PGP word list so it is pronounceable and memorizable.


If it is just 4 distinct words it isn't hard to get it right.


You use google to find product, then find reviews on reputable sites...


They don't need to, browser integration solves that.


How is that different from finding product ID in a reputable catalog?


Yes, SSL is better than nothing, but I'm just demonstrating an alternative here.

OK, let's consider a concrete example:

• 1. User has pre-existing or out-of-band knowledge that bitmit.net is a reputable merchant. We take this for granted.
• 2. Goes to bitmit.net site on his computer and makes an order
• 3. His second factor device shows invoice from bitmit.net, so user can confirm that computer isn't infested.

Now let's consider example with vouchers:

• 1. User has pre-existing or out-of-band knowledge that "cranky corporate classic company" is a reputable merchant. We take this for granted.
• 2. Goes to finds items sold by "cranky corporate classic company" and initiates purchase of a voucher
• 3. His second factor device shows that he is purchasing a voucher issued by "cranky corporate classic company", so user can confirm that computer isn't infested.

I really see no difference, aside that "cranky corporate classic company" looks somewhat funny and we are used to names like "bitmit.net".

Now I guess you would ask: how can we  register "cranky corporate classic company" in such a way that it is unambiguous and we can verify that vouchers come from this entity?

Well, that's simple:

1. Company creates a vanity address which starts from 1mctXXXXX... such that no other address mentioned by blockchain so far has same prefix. Perhaps XXXXX should be chosen in such a way that it makes a good name when it is PGP-word-list-encoded.

2. When such address is created company sends transaction to and from this address. Now we have hash and public key mentioned in the blockchain.

3. XXXXX now becomes four word list... We can convert them back to address: "cranky corporate classic company" is encoded as XXXXX, then we scan blockchain for the first address with prefix 1mctXXXXX. We also know public key associated with this address.

4. Voucher color definition is signed by company's private key.

5. Having color definition ID we can fetch color definition, which includes public key it is signed with (we should check the signature). Then we can display that it was signed by "cranky corporate classic company".

The only problem I see is that firstbits lookup requires full blockchain scan, which is sort of expensive.

Oh, if it is the only problem then it's pretty much a solved thing.

There is a plenty of ways to shorten an ID, make it pronounceable and memorizable. For shortening, one could take an approach similar to firstbits: blockchain acts as a disambiguator for short binary fragments.

Then if binary is a problem one might use Bubble Babble or PGP word list encoding.

Perhaps you would like to buy some "topmost Istanbul Pluto vagabond" socks... Four-word phrase gives you 2^32 combinations which is probably enough for product identification.

Merchants might specially look for word combinations which match their products the best, same way people generate vanity Bitcoin addresses.

So... it appears people have a choice: use some funny names for merchants and products, or bend over to our certification authority overlords. What will they choose?

I guess I know the answer, but this is kinda ridiculous: use domain registrars and SSL simply to have pronounceable IDs... Which aren't even as visually/verbally unambiguous as PGP words...


See above. Also, don't forget about QR codes.


It's possible to make names which are more distinguishable than domain names.


IIRC google.ru (or was it gmail.ru?) was not owned by Google for quite some time. This is a ridiculous solution in any case.

I'm afraid you're cargo-culting this. It doesn't matter how much hard work they did if it has no real advantages.

Can you point to a specific case where SSL can save your ass from paying to a scammer?


He might copy-paste it via IM program (which likely uses SSL), send it as a text message... Or we can find some way to encoded this ID as something pronounceable. Just like firstbits can deterministically shorten addresses.

I don't want to talk about specifics here... In the end, your friend endorses certain identifier.


This is a good point. I believe that use of smart property vouchers is just more flexible w.r.t. problems of identification, and so it would be easier to find a solution which properly takes human behaviour into account.

For example, it works well with 3rd party endorsements and catalogs, and this is exactly how people shop around.

Maybe there is a good way to handle person-to-person verbal recommendations too, I dunno.

We haven't settled on this yet, there are several proposals and no implementation. (There is a lot of discussion in bitcoinx google group.) Proposals:

1.Issuing address: All coins sent from a certain address are colored. So company's officers which have access to private key, they can create new shares. You have to trust the company anyway, otherwise shares are worthless. So you can trust that they issue correct amount. The problem is that private key might be stolen and thief will issue and and try to sell unlimited amount of shares.

Possible ways to mitigate the problem:

• Cool-off period: coins are not considered valid for, say, first 144 blocks, and so people have time to react to new issuance. If issuance is not authorized, they will freeze all trade and find a way to fix this, e.g. replacing color
• Limit total number of coins in color definition, then client will consider freshly issued coins only if it sees that some shares were destroyed
• Better protection for private key: use multiple signatures, offline storage etc.

2. Color definition replacement: Company creates a new color definition, signs it and uploads it into color directory. Client software periodically checks for updates. If definition is updated, client software asks user whether he trusts new definition, and user might do some out-of-band check before he makes color definition active. Meanwhile, if you haven't updated your color definition and others did, you won't be able to trade these coins on market as colorid is different. So you cannot accidentally purchase newly issued coins on market if you haven't activated color definition replacement.

3. Color definitions embedded into blockchain. I'm not sure if anybody is advocating that right now, so I won't go into details.

(I'm personally for color definition replacements... Color definition is like a contract, and contracts are meant to be amendable.)


ArmoryX creates a list of all colored transaction outputs, I think it won't be hard to calculate total amount, but it doesn't do it now.


Well, if we are talking about shares, I don't think they were destroyed...

On a fundamental level, we track ownership of an asset through a chain of digital signatures, each signing the transfer.

If coins were mixed then transfer did not happen (analogy: a garbled message was signed), so previous owner still technically owns them.

From this point of view, person who signed that color-mixing transaction still owns shares, but he cannot transfer them because of limitations of the protocol. So his shares are effectively frozen, and issuer's action is needed to unblock them.

But that's how we humans look at it... Client software will simply show 0 balance on both ends, as it shows only what can be transferred. So human is supposed to check blockchain to see what happened and fix the situation. (Of course, it can be automatized, but I doubt it will happen so often that it makes sense...)

By the way, while we are here, dividends should be paid to addresses which hold shares by a certain block. And same thing applies to voting. If dividends are paid at block 210000, software should create a list of owning addresses and their shares at that time. If somebody transfers shares in block 210001, he won't receive block-210000 dividends. (All this stuff with votes and dividends isn't implemented yet, but I think that's how it is supposed to work.)

My proposal addresses this issue, sort of, just in a very different way.

Basically, the difference is that each invoice must be signed by domain owner.

But vouchers can be signed all at once, by anybody who is trusted.

E.g. suppose somebody there is a web site, let's call it bitmutt.com, it finds reputable merchants/vendors, hosts descriptions and so on.

Somebody recommends me bitmutt.com, I go to it, browse product catalog, click on alpaca socks, and it shows up in my bitcoin client as alpaca socks vouchers endorsed by bitmutt.com

So, yes, bitmutt.com, the catalog, needs SSL. But individual merchants do not.

Of course, you don't always need to go through a catalog... Say, your friend might mention that 26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good, so you put this ID into your color-aware client and buy a voucher.


I would call that out-of-band verification: your friend confirms that bitmit.net is a reliable merchant.

What if there was bitmitt.net which looks exactly like bitmit.net, but doesn't ship goods?

You absolutely need to verify correct spelling before you pay. And your friend is the source of correct spelling, without his help you can't tell which from bitmit and bitmitt is legit. Both look the same!


I don't think there is a difference between "26546d600e1a6a278eba2170559afe415ddcdd88 alpaca socks are really good" and "hey Mike, check out bitmit.net, it's awesome".

So all benefits of SSL boil down to shorter names... Which can be really solved in a different way.


Yes, but the thing is that it doesn't need same kind of identity resolution. In case with vouchers, you don't really care about merchant's identity, you care about endorsements. Is it endorsed by your friend? Is it endorsed by a reputable catalog? Is it endorsed by people on WoT? That matters.

I don't care if I buy from bitmit.com or bitshit.com if their socks are good and they really ship them. Identity is irrelevant.

If I buy something very expensive I'll need to be able to sue the merchant, THEN I'll check his identity.

I was stupid enough to send my coins to MomentoVPS before reading messages on forum. SHIT!

One thing is that it wasn't 'momento' at all, coins were credited to my balance like a day later. I decided to choose momentovps because I neede server ASAP. It is definitely not a problem on my side, balance was 0 after 12 confirmations (this is what I remember).

Now I'd rather get a refund, I don't really need it anymore. (I haven't purchased anything, I simply added coins to balance.) Ticket is unanswered for two days...

So I think dude which runs it deserves scammer tag, and also it should be removed from en.bitcoin.it/wiki/Trade

As for cheapness, it is bullshit. According to price on the front page,  VPS with 1 GB RAM and 40 GB disk and 1 IP costs about 18 USD per month.

I currently rent a VPS from prgmr.com, it costs $16/month when paid for a whole year, ($20 per month when per month), and it's really high quality service. Say, currently I have uptime of 453 days and I don't remember any network outages.

If you have shitty services simply advertise it as such, do not assume we would infer it from price!

If I get it correctly, the current proposal is to use SSL-signed invoices to improve usability and provide confirmation of purchase. (I.e. so that  I can prove that merchant owes me something.)

I propose an alternative to this: it is possible to use smart property/colored coins + decentralized market instead of singed invoices and get similar benefits.

It might sound outlandish, but I'm not saying it's worth implementing it right now. Besides that, I've just implemented a proof-of-concept decentralized market for colored coins based on "atomic coin swapping" (it is called p2ptrade), so I believe this kind of technology is relatively easy to implement. Say, it would take me about a week to implement a functional proof-of-concept.

So here's how it can work:

1. Let's say merchant has 1000 alpaca socks in stock. He will create 1000 alpaca socks vouchers using smart property or colored coins. I recommend colored coins, though. So, basically, one who owns a smart coin-based voucher can get alpaca socks.

2. Merchant sells these voucher tokens on decentralized market, let's call it p2ptrade for simplicity. He doesn't care who buys them as long as they pay. If he is using colored coins, he can get paid in any colored coin-based currency, not just Bitcoins.

3. Optional: These vouchers might be bought by resellers, who can them sell it on same market for a different price or for different currency.

4. End-user buys voucher via p2ptrade. Of course, it might work via highly specialized GUI which might work like app store: he simply searches for a product, reads overview and clicks buy.

5. End-user who is in possession of voucher can order shipment: he will sign message like "Ship alpaca socks to <this> address" with Bitcoin address which currently holds voucher, then he sends voucher to merchant's address to complete the purchase.

6. Merchant now gets this voucher back and it sees user's message (ideally message should be incorporated into blockchain), he should ship socks.

7. User has hard evidence that he have purchased socks, so he can use it against merchant if that fails to deliver the product.

I haven't thoroughly analyze this, but here are some potential advantages compared to signed invoice approach:

1. Merchant needs to sign smart property or color definition, he doesn't need to sign each invoice. This means that he can keep his private key offline, signing a new batch of vouchers once per week, for example.

2. We don't really need SSL. Well, end users need to make sure that voucher indeed come from merchant, but there is plenty of options for such verification. It can be entirely out-of-band, for example. Perhaps a catalog company will endorse vouchers and provide insurance (think like Amazon, eBay), so user only needs to trust that company. It can also work with web-of-trust-like things.

3. It can easily work with multiple currencies via colored coins. Say, merchant sells vouchers for USDcoin, then resellers sell them for GoldCoin, Bitcoin, EURcoin etc. It can also work with ripple-style colored-coin-based currencies.

4. Wide opportunities for reselling (user doesn't care whether he buys voucher directly from merchant or from resellers).

5. You automatically get features like gift cards, catalogs etc.

Well, if we are dealing with cryptocurrency shares of a company can go *poof* in many ways. Wallet lost, sent to wrong (particularly, non-existing) address.

We can assume that if coins got mixed it's also likely that they went to a wrong address.

What's the sensible reaction here? I'd say destruction is a feature, not a bug. Original owner can prove that he owned that shares and he can ask for replacement from issuer. Issuer can investigate the situation, and if shares were indeed destroyed he can issue some new ones and give them to this shareholder free of charge.

However, if coins are not destroyed, they might end up in a wallet of a person who isn't supposed to own them, and you cannot fix that if that person does not cooperate.

So I think it's better to destroy color label in case of a dubious transaction and rely on manual resolution.


Considerably more complex implementation: each transaction output now has a spectrum rather than a single color, and value for each color is represented by infinite precision fraction. I.e. you can end up owning 230918409134/21332840932904832984 of a company.

But, importantly, it doesn't really address the problem: if coins were diluted due to some software problem, we can't be sure that, diluted or not, output went to a correct address.

Also, you can't undilute coins, if they are mixed, they are mixed forever.

Note that with my approach towards mixing, automatic un-mixing  is possible, it just needs to be issuer-mediated.

For example, issuer publishes unmix-this-please address. If there is a fuck-up, person sends his mixed coins to that address, issuer transfers them internally and returns some part of coins via his issuing address, thus making them colored again. The rest is returned via a normal address, which leaves them uncolored.

If several colors are mixed, issuers can use deterministic satoshi tracking algo to verify correctness. (The idea is to assign an unique number to each coinbase satoshi, tracking it through transactions and fees. Then color of satoshi is preserved under all transformations.)


Eh, what? If you more than one color together it ALWAYS get diluted?

Then there is no way to implement decentralized exchange via atomic coin swapping, for example. Not to mention that even sending coins is problematic (i.e. you cannot pay a fee and get change in same transaction, you'll have to prepare utxos with exact change value in advance).

IMHO decentralized exchange is colored coins raison d'être, so any implementation which doesn't allow that is largely useless.


People mentioned dilution as an alternative to destruction in case of mixing, but not as a coloring algorithm on its own.

Other proposed alternatives are deterministic satoshi tracking (order-based) and color tagging.