It is possible to implement this using hashes, I've even written a script which does that: https://bitcointalk.org/index.php?topic=8821.msg286271#msg286271 (read starting from BTW).

It's a pity that it's hard to get support for new transaction types in Bitcoin.

p2p exchange is almost complete: we now have all components in place so now we can try to run it and fix problems until it works.

Here's exchange peer agent code for the curious: https://github.com/killerstorm/BitcoinArmory/blob/color/p2ptrade.py

And web chat used for message exchange: https://github.com/killerstorm/BitcoinArmory/blob/color/app.py

I also made a more flexible version of autotrade, it probably even works.

Code: https://github.com/killerstorm/BitcoinArmory/blob/color/autotrade.py

https://github.com/killerstorm/BitcoinArmory/blob/color/extras/autotrade-test.py

But I think now that we can complete p2p exchange we don't really need autotrade much.

LOL. I didn't expect anything different from MPOE-PR, and it is probably a good thing that you're commenting on p2p markets (it's a sign that you're afraid of them, which means...)

But I think you do not understand how it is supposed to work.

We can decouple asset ownership tracking from exchanges from listings/ratings.

Which means you can create more centralized solutions on top of low level p2p market infrastructure. Say, you can create MPOE-P2P which would be exactly like MPEx except that it would accept ECDSA signatures instead of PGP signatures.

So p2p markets are simply more flexible: they can mimic and interoperate with centralized solutions, but they also offer a number of interesting options.


If you want a shitty analogy, p2p market is more like WWW: you can get both textbook and wikipedia content over HTTP. It can handle both. Choice is up to you. Students often use wikipedia in addition to their textbooks.


Of all people, you're the most informed about how they will work. LOL.


How much does Mircea pay you for your writing, Hannah? Reminds me of Matt Taibbi a bit. But try even more vitriol next time.


Right, if somebody makes such listing p2p market will just collapse. Because if you add one bit of information per ticker (shoddy/non-shoddy) it would somehow ruin everything.


You forget that technology, in theory, would allow you to invest in each of these million of securities. Perhaps some 3rd party rating agency will provide trustworthiness score for each issuer. Just use trustworthiness as weight when you buy them.

When you liquidate, you'll get good deals on some of these bonds and shitty deals on other ones. This, likely, averages to something sensible.

So it is statistically liquid. Not in the same way as one big security, but quite likely it would be acceptable.


Only if you assume linear utility function. Don't forget that people send a lot of money to Satoshi Dice, this means that for real people utility function is very different from what you think it is.

Dunning–Kruger at its finest.

Yes, sufficiently complete specification IS code. And incomplete specification is incomplete code, apparently.

So in the end you always need human judgement, it's just that you can spare human a need to inspect boring and trivial parts.


If there is at least some inspection and there is some compensation for loss, it is already much better than nothing.

Financing development of more secure software would be a good thing.

The problem is that business types usually want to claim that service they offer is absolutely unbreakable and that they will cover all losses if shit happens. But all they want to spend on development is 100 BTC. LOL.

Some pieces of code written in high-level programming languages can be formally verified. This doesn't mean that you can be sure that code does what you think it should do, but at least you can be sure that it won't fail in stupid and unpredictable way, so you can focus on high level logic.

However, there is a problem: proof is done on language semantics level, but problem can exist on compiler level, or on runtime library level. I guess verifying Haskell compiler would cost you a lot of $$$$$.

Then, program's correctness generally depends on OS correctness, and operating systems are typically implemented using rather messy C code.

So no one can be sure and no one can check everything.

But still, program written in Haskell, thoroughly verified and running on, say, OpenBSD is far less likely to fail than some piece of shit written in PHP and running on Ubuntu.

So if I read this correctly, there is now a demand for Bitcoin software written in type-safe functional languages? LOL.

The problem with this idea is that most likely it will be run by assclowns who are totally detached from realities of commercial software development. I mean like MPOE-PR.

It's obvious that the plan is to blame everything on developers, making them scapegoats.

I wouldn't recommend any programmer who cares about his good name to join such insurance business.

So I guess only people who do not mind being paid to be scapegoats will work for you.

Good luck.

I've implemented coloring for zero-confirmations transactions in
 Armory, so now effect is seen immediately, and there are no weird
 problems with disappearing coins which Ron reported.
 At the same time I've fixed a bug with lack of coloring of
 double-spend transaction after blockchain reorg.

Also there are some minor improvements in GUI:

• uncolored is now default
• you cannot send coins in 'all colors' mode
• sum in 'select wallet' dialog is now in units

New build: http://killerstorm.xen.prgmr.com/alex/ArmoryX-0.2.4.zip

Is there a need for Linux builds? I guess that Debian/Ubuntu users
 should have no problems building it themselves because it is easy to
 install all dependencies.
 So I think there is no need.

This severely underestimates complexity of code verification.

It is kinda a spectrum. If you just look through the code, line by line, all you can say "I haven't found obvious flaws, yet", only idiot will say that it is "safe to run".

There is a reason why people write unit tests. If they want to make sure that it works, each line, each statement should be covered by a test. And quite often test suite is large than code base itself.

See here: http://www.sqlite.org/testing.html


And even that doesn't give you 100% guarantee.

Also see here: http://www.fastcompany.com/28121/they-write-right-stuff
Writing software with very few defects is incredibly costly. Running software with no defects at all is likely impossible.

OK, even if we rule out things which aren't feasible, there is still a lot of restrictions. I would give you any kind of assurance about for code written in dynamic programming language (JS, Python, PHP) or unsafe programming language (C/C++). It is simply a minefield: compiler performs almost no checks, so it is hard to make sure that it doesn't fail in a weird and unexpected way.

This leaves us with Java (it has many flaws, but at least it isn't as bad as things mentioned above), Ada, functional programming languages like *ML and Haskell.

So what I'm saying, if properly done it would be too restrictive for a startup business.

And if it not done properly it won't be a good service. It's basically an insurance business: you know that some system WILL fail because your code verification isn't exhaustive. You just do pre-screening to rule out obvious losses. Otherwise, it is a matter of luck, essentially risk pooling.

Thus you don't really need first-class programmers, I think.

If I understand correctly, profits can be capped only if settlement price is so far from previous clearing price that it can eat through required initial margin.

I don't know how much is "too far", but probably it is related to price range.

Although it looks like it is possible to bit through price range: (1/11.952-1/14.608)*10= 0.152, but initial margin is only 0.1141. But it's kinda unlikely scenario.

So, well, unless something extraordinary happens on mtgox and if people will be arbitraging on ICBIT to prevent huge price swings there should be no problem.

It doesn't need a reload button, bug which wipes your orders should be fixed instead.

Sure: http://www.bitcoinx.org/donate/

I think we'll also make an option to fund specific sub-project so people can vote with their money.

It's now in a stage where you can actually play with it.

General description: https://bitcointalk.org/index.php?topic=106373.0

Windows client and some basic instructions: https://bitcointalk.org/index.php?topic=106373.msg1386370#msg1386370

Windows binaries available: http://killerstorm.xen.prgmr.com/alex/ArmoryCC-0.2.3.zip

The purpose of this release is to allow people to play with colored coins and identify possible problems. However, it's nearly fully functional. But I recommend to be cautious. (See below.)

To run it you need to be running Bitcoin-Qt or bitcoind. You need to complete synchronization before you launch Armory.

Simply unpack it and launch. It requires about 1 GB of RAM in addition to what you need to run Bitcoin-Qt. Also it takes ~10 minutes to launch since it performs full blockchain scan. (Twice!)

There are two differences from normal Armory client: drop down which lets you to choose color and 'Hallucinate' menu section. Also some functions were disabled.

It comes with color definition TESTcc. But obviously you have no coins.

You can issue your own: send some coins to wallet you've created in armory, then go to menu Hallucinate -> Issue colored coins. Enter name, change parameters if you want and it will create coins for you.

Before you send those coins to other you need them to install this color definition (and obviously they should be using color-aware client), otherwise coins will be lost.

Simplest way to install color definition is to fetch it by ColorID from a color definition registry. So you can simply note ColorID of your freshly issued coins, then post it to forum/blog/IRC channel, like

.

Then people who are interested in these bonds can download color definition (Hallucinate -> Download color definition -> enter color ID) and accept them from you.

Alternatively you can get color definition file (~/.armory/colordefs/c03e572bc2c8520112194a95a29b24c7e99fc87e.colordef) and host in on your server. Then people can download it via URL, say http://example.com/c03e572bc2c8520112194a95a29b24c7e99fc87e.colordef

In that case you do not depend on color definition registry server availability. (For the record, I manage color definition registry which is used by this build of client, code is available here: https://github.com/killerstorm/colored-coin-tools/tree/master/web )

Currently you can trade colored coins OTC, e.g. #colored-coins-otc channel on freenode.

 But auto-trade (which would allow to buy/sell coins automatically) is almost ready, and we are making progress on p2p exchange.

Warning:

• All colors mode is dangerous, you will lose your precious colored coins if you send coins from it. I'll likely disable it in next release
• Only functionality which is tested is plain and simple sending/accepting coins. Fancy stuff like offline transactions and payment URIs is not tested and might not work
• Be careful with units, check twice
• Global ledger is somewhat broken, but it gives you a general idea
• You need 1 confirmation to see colored coins, so coins can 'disappear' when you've made a transaction, that's OK

New version correctly displays units in most places. E.g. when you issue a coin where one unit is 10 satoshi, 123 satoshi will be displayed as 12.3, not as 0.00000123.

There are many places where currency amounts are displayed and I was not able to convert all of them. However, all places which actually matter likely display units correctly.

• when you change color via dropdown it changes units being used
• if it says 'units', it is in units (likely)
• if it says 'BTC', it is in BTC (likely), no matter what is selected in dropdown
• if it doesn't say anything, it is likely in units, particularly:
• global ledger table and wallet balance is in units
• but if you view a concrete transaction it is in BTC (because there are both colored and uncolored inputs we cannot display everything with units)

Also global ledger table often displays bullshit transaction value, do not trust values it shows.

Have you tried reading this?: http://devtome.com/doku.php?id=devcoin

Devcoin is more like a "benefit corporation" rather than simply a currency. Essentially it is an organization which created its own currency for accounting purposes.

Your sense of self-entitlement is frightening.

I should note I'm in no way affiliated with devcoin, I'm simply trying to explain obvious facts.

You do not need to have any hashrate specifically for devcoin thanks to merged mining, and network/CPU resources related to transaction verification are tiny.

Any while we are here, miners aren't in any sense noble. At start ordinary users were miners, so network was directly democratic. Then people started mining it for profit... Of course there is nothing wrong with it and it was anticipated, but need to understand that miners simply provide hashrate... You know, like utilities which provide you electricity. Your hashrate secures network, but it removes control from users. So you're like mercenaries, there is nothing nothing noble about it.

You aren't supposed to think about ethical questions, you simply get money for your hashrate and that's all. If certain network pays you less than what you could get elsewhere, then simply switch to highest paying network.

Of course there are miners who do not mine for profit, but those do not care whether they get 10% or 100% of a pie.

Um, hello? Miners do not need to do anything at all, they simply get free coins for tiny amounts of work.


Not to keep network alive, but to prevent double-spends. I doubt that anybody wants to attack devcoin, so even 10% is probably too much.

Developers create demand for devcoins, they make it valuable, and miners get profit of that.

In other words, without developers DVC would be yet another worthless Bitcoin fork. You can as well mine testnet.

Mathematically, suppose X is value of 50,000 DVC in USD. Miners earn X * 0.1 for each block.

Suppose developer ABC creates something which adds additional demand for devcoins, thus driving exchange rate to X+x. Now miners get (X+x)*0.1 USD, thus they got x*0.1 of ABC's work per each block. Suppose this effect lasts for 10000 blocks, thus it makes sense to give ABC a bounty of at most 10000*x*0.1.

I'm fairly sure you do not understand economics of mining. In theory, miners are strictly profit-motivated, thus giving bigger share to miners would give network better security, and that's all. You get what you pay for, miners are not shafted.

However, merged mining essentially makes it a free ride.

Thanks. I actually read this stuff on devtome.com before asking question, I just wanted to clarify whether those are current rules.

 The eligibility rules are here:
http://www.devtome.com/doku.php?id=devcoin#developer


Then I guess "colored bitcoins" project qualifies since it is essentially a Bitcoin client with extra features which would allow users to issue their own private currencies/stocks/bonds/whatever and trade them on p2p exchange, all on top of Bitcoin protocol. There are no users yet, however, since software isn't finished yet. However a lot of people are interested.

So... Does it qualify as is, or should we wait until people start using it, or...?


OK, I understand why you're doing this, but you should note that people might see it as unfair. A trivial app might require at least 40 hours of development time, but one could write like 40 articles in 40 hours, no?

So developers are at huge disadvantage compared to writers.

Also you didn't mention shares people get for DVC-related development, like for DVC software, projects which generate DVC revenue and so on. What's the policy about such projects? Is Devtome the only for-profit project allowed to exist or it's just that there are no other proposals?

New version of client includes these things:

• manage color definitions
• issue new colored coins
• import color definitions via colorid

It's currently available via github, but you need to build if yourself. If you want Windows build please PM me.

New feature use examples:

There is new "Hallucinate" menu item.

1. Download color definition:
You can enter color id, for example

c03e572bc2c8520112194a95a29b24c7e99fc87e

and it will download and install color definition from server.
Presumably these ids can be posted on forum etc.
E.g. if you want my FooCoins you install my definition with id above.
After installing definition you need to restart client.

2. Manage color definitions:
Allows you to check colorid for definitions you have (e.g. you can get
it there and share it), see balance (it is displayed correctly here,
in units), publish definitions on server, delete them. (Restart is
required.)

3. Issue colored coins:
Enter name and modify parameters as you need. It can be automatically
published on server.
Color id will be displayed so you can use it to refer to others to your coins.

(Obviously you need enough uncolored coins in this wallet.)