Why does it bother you?


Perhaps you should make two chains: one with bitcoin-compatible transactions and another with incompatible. Let's see which one wins!

I find it strange that nobody did it.

Perhaps difficulty is the main barrier. I doubt that revolt would work unless difficulty is reset OR major mining pool joins revolt.

Also people are probably too loyal to bitcoin, which is spooky. (Cryptocurrency should work even if majority isn't loyal, right?)

Heh, if people are so altruistic that they don't even bother to attack than PoS-based coins like PPC can work too.

No, you are supposed to open another command window and run commands in it. E.g. devcoind <command> will send that command to a running server instance (which occupies your first console).

Why not simply use utxo owner's resources for upkeep as I proposed here? It isn't particularly complex and likely is as implementable as mechanism to associate colored outputs with uncolored?

It can work like this:

To connect transaction inputs we look up outputs in unspent transaction output database.

Instead of performing this lookup locally we will first lookup it in local cache, and (if it is not found) perform a lookup in DHT. ("Cloud database".)

However we will have to check results we got from DHT, and to do this we will pull additional proving information and check whether it is consistent with current state we got via blockchain.

So now unspent transaction outputs can be stored in DHT (they are in the cloud now,  ), and we only have to store enough information to confirm results we get from DHT locally.

Of course, DHT is unreliable, but people who want to keep their utxos alive will save a local copy, and later they can populate DHT or act as DHT nodes to make sure transaction they made passes validation.

What's interesting it requires no changes to protocol as all of this can be done in a separate layer. I.e. nodes which wish to save on local storage (at expense of network traffic) will populating DHT and will start maintaining local check state.

I can help with Windows build. I never built Bitcoin for Windows, but I've built a lot of other software. For example, recently I've made BitcoinArmory binaries via mingw on Windows.

Let's clarify:

Cross-compilation isn't a hard requirement, building on Windows is fine, right?

Do you prefer bitcoind, Bitcoin-Qt or both?

From wiki:


BTW I wonder how that happened, wiki documents sharp rise in capitalization: 300 BTC in January 2012, 3,809 BTC August 18, 2012.

So who buys devcoins?

Wiki says:


What are the largest contributors? devtome.org?

I really want to know more about economics of this...

Bitcoin users want stability, and they will likely object to making Bitcoin merge-mine-able since it gives no benefits, only potential problems. Bitcoin developers will do what users want.

So if you mine devcoin as a primary chain, you're mining without bitcoin. And it's just impractical.

If the problem is that you want devcoin p2pool, maybe there is a way to p2pool it in mm setup? Is this really a fundamental limitation, or it would just make software more complex?

Perhaps I can answer... Generally, rationality is understood as following some utility function, which is not always monetary profit based. But it is opposite to doing things on a whim.

Forget about profit, you secure blockchain via mining. If you go from bitcoin+devcoin+... via merged mining to devcoin+..., you choose to not secure bitcoin. WHY? What value do you see in NOT securing bitcoin? Or is there some opportunity cost?

The only possibility I see here is pissing match incorporated into utility function. OR you're irrational.

If this is the case, other people simply would not want to fund your pissing match and your irrationality, they are simply not interested.

It doesn't make people undemocractic, it's just that both doing something and NOT doing something needs some reason.

OK, but what's about revenue? There is no revenue besides mining and share purchases, right? Or...?

There is a market, for example: litecoinglobal.com

You cannot buy groceries there, sure, but financial market is still market. It helps to stabilize the exchange rate.

For example, ESECURITY_SA bond must convert USD to LTC to pay dividends. So this bond adds to continuous demand for litecoins.

Also people might buy litecoins as a hedge... Since it is using different hashing algo, most likely attack on Bitcoin won't affect Litecoin, and it is easy to adapt any tools made for bitcoin...

While we are here, it's even harder to understand what DVB does.

After reading forum I understood that it is like mining bonds or stocks which pay dividends from some merged mining farm, with BTC converted to DVC. But mining bonds usually say what hash rate one share represents, I'm completely puzzled here.

Also it looks like DVB pays some bounties for something, but I do not understand how, why, and what it gets out of it. Description sounds like a description of devcoin itself. Or is it a "devcoin" on top of devcoin?

I've heard about devcoin a while ago, but started looking closer only now. It looks really interesting, but I find it hard to find up-to-date and coherent information, as wiki articles are often self-contradictory.

If I understand correctly, current policy is this:


But is it actually the case? From what Unthinkingbit posts it looks like things are funded on case-to-cases basis.

Is there, like, a summary of what is currently funded? Like, 70% goes to such and such project.

I know there are some csv files, but it's kinda hard to "parse" them and figure out what goes where.

What's about current eligibility criteria?

Let's say I work on colored coins p2p exchange, is related to bitcoin. Can I get some devcoin generation share for this?

What's about projects which generate devcoin revenue, is there a list of bounties, or simply anything relevant is funded?

Please don't take it as criticism, but just as a friendly recommendation from an outsider who has a fresh look on things:

Make one page with basic information and summary, like:

• brief description of concept and mission
• what currently gets funded (summary, break down, examples)
• capitalization, how much it money it generates
• eligibility, current bounties

And specifically WITHOUT old and too detailed information.

I think only a very dedicated person would read 50 pages of forums to learn how it actually works, majority would simply ignore it if it's too vague.

So one good no-bullshit page might seriously help with devcoin popularity.

As I understand, wiki maintenance is one of major devcoin projects, so it shouldn't be a problem to find people to maintain just one page with up-to-date information.

We have at least two implementations: bitpaint.py and my fork of Armory. I think both kinda work, but have rough corners and are not thoroughly tested.

I'm going to make ColoredBitcoin Armory a bit more usable this week. Also I'm not far from making p2p exchange.

You aren't attentive. Fireball did not manipulate the price, he did clearing after price changed. Margin calls were postponed and positions were not forcibly closed.

You're again trying to mis-represent the facts.

And, obviously, if he could simply manipulate the price he wouldn't have needed that additional clearing.

I didn't ignore it, I described it in all details.

As you're dense, I can repeat: my involvement is limited to:

1. Being a customer, I played with ICBIT a bit since last Friday. With sum less than 5 BTC.
2. I had a discussion with Fireball more than 1 year ago, in summer of 2011. We have considered making futures exchange together. But I abandoned this idea, and we were not communicating up to last Friday.

That's all, there is no other involvement. I've answered your question, please mark it in your notebook, you seem to be forgetful.

Just because you want to uncover scam it doesn't mean scam exists, OK?


Same is true for ICBIT: it's customer's job to get his order to ICBIT. There is no evidence that smickles coped with it, all we know that he clicked some button in his browser, but that's not enough. There is no tcpdump log.


It looks like you have very vague ideas about network and software engineering.

ALL sorts of problem are always theoretically possible, and moreover they happen all the time, even with very important servers.

If MPEx is not made out of pixie dust it might be vulnerable too. Denying this just shows your ignorance.

Here's an example of network problem which can happen: http://mina.naguib.ca/blog/2012/10/22/the-little-ssh-that-sometimes-couldnt.html

There was a problem with one of routers several hops away to a data center. Connections which were routed via it predictably failed. But even if you repeatably try to connect, sometimes it works. And, of course, if you're connecting from a different location there is no problem.

So it is an undeniable fact that site might be down for some people, and not down for others. Moreover, problem might be stochastic, i.e. one out of 100 connections fail. Moreover, problem might be somewhere between customer's ISP and your ISP, usually there are many hops.

These are basics, if you understand it you know nothing.

And exactly same kind of unpredictability can happen on server side. I won't bother explaining it to you in all details, but it is very well possible that overloaded server will drop some connections while processing other. E.g. check SPECweb2005 benchmark, as you see there is such thing as "tolerable error level", even when people run it in controlled environment and can retry as many times as they want: http://www.spec.org/web2005/results/res2009q2/web2005-20090520-00138.html


I agree that people should demand more transparency from ICBIT, but that does not mean that MPEx is made out of pixie dust, OK?

Do not make bold statements like "we can never fail", they simply show your incompetence, and that's all.


I was simply replying to your statements that MPEx cannot fail. It can. It doesn't mean that it DOES fail, I never claimed that. I simply outlined how it is possible, so your statement is provably false.

You do not understand how technology works and you are boasting and making invalid statements. I'm trying to correct you. This is totally unrelated to ICBIT being a scamsite.


Yet another bullshit statement from you. It is possible to implement a scam site which would give PGP-signed receipts.

It is not a slightly misleading statement, you're implying that if if PGP receipts are given then site is definitely not scam, which can mislead people into believing to scam sites which use crypto.

It is only secure when it is done via blockchain.


That's a good idea, actually.

I believe STAT wouldn't be aware of packets which are in flight but haven't yet reached servers.

But this is largely a theoretical problem since you can simply wait a bit to make sure that all data in flight either arrived or died peacefully.

Also I hope that if MPex sees two identical orders it would ignore duplicate, so even if you submit twice it is not a problem.(?)

See my reply to MPOE-PR. Use of simple HTTP requests is a bit too fragile: any network congestion can leave order in a dangling state where it can arrive to server at any time. And checking that won't help you, as you're checking current state, but you cannot remove packets which are already in flight.


Colored coin exchange will be based on "atomic coin swap" transactions. Double-spend can only cancel such transaction if it is included into blockchain faster, but it won't be possible to steal anybody's coins.

There is a lot of other useful traits:

• after you've got counter-party's signatures you'll be able to demonstrate that he isn't trustworthy if he double-spends
• transaction is either included into a block or it is not, there is no dangling state
• you can chain several transactions together, if one fails due to double-spend dependent transactions will get canceled automatically

Um, what? GPG is simply a digital signature/encryption software. Bitcoin transactions are also digitally signed, but they are also included into blockchain to ensure there are no double-spends. It's an extra protection on top of what GPG can provide.

I'm rather bored with this discussion. You are dense. I'll try to spell it out for you one more time, but this is the last time...

OK, let's consider it from user's perspective. User tries to submit order to MPex. His user agent "hangs". User doesn't know whether his order was accepted. He waits for some time, let's say 30 seconds, then clicks "stop" button and tries to check whether order was accepted by other means.

Let's say order was not accepted, then user will try to re-submit it.

Suppose it was time sensitive like it was with smickles order. How is MPex going to explain why order wasn't accepted immediately? Most likely response is "oh maybe the connection failed we'll investigate": connection failure is indeed the most likely cause, but it is a good idea to check server logs.

If user was running Wireshark, or maybe just in-browser debugger like firebug, he would know more about this failure, but let's just say a typical user doesn't run Wireshark so it doesn't matter.

Now let's consider a bit more complex case: suppose that packet which was carrying request body was buffered at some router between user's computer and MPex server and was "in flight" for some considerable time, e.g. 1 minute. It's possible in case of congestion, packet loss/retransmission, routing problems etc.

In that case we can a situation like this: 1) user clicks "stop" button in browser, but it doesn't stop packets which are already in flight; 2) user checks state, it says that order is not accepted; 3) now those packets which are in flight arrive to server and it actually accepts the offer. Whoopsie.

It isn't simply theoretically possible, this actually happens. Say, when I use ssh sometimes it freezes and I see what I typed after a significant delay.

So... How is this different on ICBIT? I don't know. As I understand, there is no progress indicator, but it is not a fundamental flaw, it can be trivially added. Otherwise, situation is identical.

It is completely independent from transparency issues, I agree that use of PGP signatures and full transaction log are desired features.

But that wouldn't have helped smickles. On the other hand, Wireshark could: he could see whether he got SYN-ACK and whether server ACKnowledged that it received POST body. Having that log he could prove that problem is indeed at ICBIT's side. (Sort of, ACK isn't signed... But it would be a good evidence.) Unless ICBIT blocked him via IP address on firewall (iptables TARPIT). Then he would need to use pathping to collect evidence...

Anyway, you need to learn a bit more about how networking works (just knowing about SYN-ACK isn't enough), and how to consider concurrency problems (i.e. you need to consider all possible event orderings for all participants). Also you have serious problems with logic. ("MPex uses PGP signatures, and thus ICBIT sucks". Really?)

Evidence he collected so far isn't enough, IMHO.


Well, if he wants to continue with accusations, he probably needs to dump more money.

But I was commenting on your "moral compass" comment. Clearly it is not about moral compass, it is about risk. You just didn't know how it works, did you?


Well, I have ~4 BTC balance on ICBIT now. Also I discussed futures exchanges with Fireball is summer of 2011. That's all.

Oh, I see. So punishing "the manipulator" OR scammy exchange operator is against MP's moral. I knew it.

Maybe I'm missing something, but to prove his point MP just needs to up the ante. If ICBIT is a bucket shop it would be out of business (or MP will be out of his money, hehe).

Or did you mean that MP is a pussy who cannot put money where his mouth is, and that is his moral compass?

Girl, please stop trying painting MP as a saint. He got some evidence against ICBIT, we get that. Pushing it further just doesn't look good. You don't seem to understand all intricacies of the business, and cheap propaganda just doesn't work.