What are thoughts on this possible fix for the issues of having an exchange safely operate in a low hash rate system. Centralize the block chain around the exchange.

The exchange can broadcast a message, signed by a private key, that contains the latest checkpoint that the exchange wants to lock in. It broadcasts this message whenever it confirms a deposit (ie. a deposit reaches the number of confirmation blocks the exchange requires).  Nodes then automatically get updated with the block chain the exchange is using and refuse reorganizations beyond this check point.

95 from the looks of it.

It is source but there is a .zip file included that contains windows binaries.

What commit id was it forked from sacarlson/multicoin-exp originally? If I clone multicoin-exp and overlay the source from Tenebrix-daemon-exp then the diff I get shows it wasn't the master. For example multicoin-exp includes auxpow merged mining changes in src/db.cpp but Tenebrix-daemon-exp doesn't.

Yeah it's very hard to see what bitcoin fixes are missing. The keystore thing shows at least one is. I see sacarlson/multicoin-exp doesn't have that fix either.

There is a bug in keystore.cpp, AddKey. A 'return true' should be there. I assume this is missing from a bitcoin merge or some commit not pulled into whatever history the original fairbrix source came from. This is the bitcoin commit where it was fixed.

What's the ancestry of the code? ie. What commits was it forked from in bitcoin or multicoin? It makes it hard to audit what changes were made when the history is broken.

I notice you accept namecoins. What version of the namecoin client are you running? I'm just checking to see if you are running the latest client which switches on merged mining at block 19,200 to ensure you don't end up on the wrong side of a chain fork.

How are you handling the issue whereby namecoin has a small hash rate and an attacker with >51% of the network can effectively deposit namecoins, trade for bitcoins, withdraw the bitcoins, then reverse the deposit?

This doesn't work in the presence of a >51% attacker either. This is one example of how an attack works:

1) Start mining from the current block but don't publish the blocks to the network.
2) Make a deposit.
3) Don't include your deposit transaction in the fork you are mining in (1) but include all others.
4) When the deposit clears trade for bitcoins.
5) Withdraw bitcoins.
6) When the bitcoin withdraw succeeds, publish your forked chain.
7) Since the new fork doesn't include your deposit you can repeat from (1) re-using the coins in the transaction you didn't include in the fork.

It doesn't matter how long I delay the withdrawal in (5) since they can wait as long as needed before doing (6). The only thing that upsets their plans is if the network hash rate increases and their fork is no longer the winning fork. But that's still no loss to them since they still have the bitcoins. They can buy more alternate coins and repeat until they succeed. This attack can easily be automated.

This is difficult to spot for exchanges unless they're monitoring chain reorg's and then check all transactions in the new chain. Even then it's too late and the bitcoins are gone and can't be recovered. If the exchange doesn't notice then at some point they run out of bitcoins and wonder why. The I0Coin exchange was monitoring chain reorg's but unfortunately I didn't catch on to what was happening until the 4th attempt or so due to me traveling and not being able to analyze it in detail.

Tying an exchange user to a verified identity would help since then the exchange user has to come up with verified identities to keep cheating the system, assuming the exchange bans accounts when it notices missing transactions after a chain reorg.

Something like https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

Yes, this is the issue with IP banning. I used to IP ban people with suspicious activity but they just moved to TOR. The people who did the double spend used TOR.

This won't work if someone has the majority of hash power. They can always rewrite the chain, they just need to wait. The higher confirmation just makes it harder for someone with less than 50% of the hash rate. i0/ixcoin make it even easier due to the time travel exploit not being fixed and the lack of an active developer/maintainer to set checkpoints regularly.


This would be a significant manual effort and not something I want to do. It'll also raise complaints if I refuse a withdraw due to suspicious activity and then get hammered for it on the forums.

I didn't want to close the exchange. But I had to given the existing situation. What i0/ixcoin needs for exchanges to safely operate are:

* More hash power
* An active maintainer of the software
* Fix the time travel exploit
* Regular checkpoints added to the software

I provided information on why it's closing down. I provided information about the double spend attempts on the i0coin block chain. The ixcoin chain has the same problems - it has a low hash rate and has no one maintaining the chain software to provide fixes. The risk is to great for the exchange to operate in this environment. If you want the chain to succeed and exchanges to open then you need to do something about encouraging more people mining and more usage of the coin.  

Others in the forum here have indicated that other exchanges may open to facilitate trade in these coins. You may not be holding worthless coins you may just have to wait for another exchange. You could even operate one yourself or do 'over the counter' trades in forums and IRC. If you're worried that your coins are worthless do something about it and make them worth something.

I have not asked or imposed on anyone to cover my losses. The withdrawal fee has always been there. Users of the exchange were able to see the fee and choose to deposit or not knowing that there's a fee to withdraw. That fee is solely there to cover the network transaction fee for sending and receiving coins. Knowing a fee exists the risk is upon the user that if circumstances require them to withdraw they need to pay that fee.

In a previous comment you raise an analogy of early termination charges on insurance policies. The withdrawal fee here is not an 'early termination' fee. It's a fee to cover what the bitcoin network charges for transferring money and has been charged always - whether 'terminating early' or not.

You are making it sound like I'm charging a fee to recoup losses. This is not the case.

The balance of the accounts within the exchange are stored in a database, not the block chain. So when a double spend occurs, the other end of the trade still gets the BTC updated in the database. The exchange itself is short the money but the trader is not. I have made good on the losses. The exchange was structured to minimize any loss (compared to the entire BTC balance the exchange held) knowing that I'd be covering it.

Bitcoin is vulnerable to attacks involving a majority of computing power, yes. So is every other bitcoin-based chain. SolidCoin 2 claims to have solved it but there's no details on what they've done on that chain.

I'm aware of this. Why do you think I'm not? There's nothing that can be done to avoid attacks by someone with greater than 50% hashrate (with current coin designs) since they can re-write the chain at will - all they need is time.

Right, none had the time warp issue fixed. That definitely needs to be fixed on new chains to make it harder for >51% exploits. Such an attacker can still do whatever they want though, it just takes longer. Merged mining helps if it means that large number of users will start mining, making it more difficult for someone to get >51%. Or finding a trusted pool to 'centralize' things for a while until growth happens. I agree that multiple chains are still a good thing and I still hope to work on pools/exchanges as the technology improves.

I don't think people should just delete their ix/i0 coin wallets. It's possible someone could fix the isues, re-release a client and the coins remain valid. It just requires a committed and interested developer to push things forward.

Withdrawals seem to be working - what do you mean they are locked up? The exchange still has to pay a withdrawal fee, especially as the wallet gets low on funds and hits fragmented addresses, so it doesn't make sense for it to turn it off and to incur an even greater loss than it already has.

I agree. Without a trusted miner/pool giving a huge amount of hash power all new chains are exploitable in this regard. Would having the coin reject attempts to do a block reorganization  further back than a certain number of confirmations be enough? Exchanges can then have their deposit limits set sometime beyond that limit. What are the downsides to that?