Well, one should send coins to a different wallet after mixing, ideally on a different online wallet service.


Once server have queued up enough tickets it will send a message "broadcast within a minute starting from T".

Participant picks a point in time within that minute at random and broadcasts his unblinded ticket at that point.

There are some difficulties in this, for example, user needs to be able to switch to an unrelated IP address between time he obtained ticket and redeemed it. But otherwise speed is limited by demand for such service, i.e. time it takes to queue up enough participants.


Not if it is integrated with some popular wallet software


I don't see how, properly executed mixing is exactly as untraceable as Chaumian cash.

Basically, the only difference is who signs the transaction, and I don't think it is substantial.

To elaborate on this... I was involved in development of ArmoryX, an Armory modification which can do colored coins.

What I noticed is that it is fairly easy to implement plugins for Armory in Python. Perhaps etotheipi will add this to Armory mainline...

Anyway, it can look like this: you grab normal Armory binaries, then install some plugin in form of Python code (of course, you need to check that it doesn't steal your coins =) ), then you basically have "mix my coins" button.

It is fairly easy to implement this. p2ptrade I've implemented for ArmoryX does something very similar, so-called atomic coin swapping between two parties. (I.e. two parties construct a transaction and sign their parts of it after they check that transaction is right.)

It is probably possible to implement an add-on for bitcoind which would use RPC API.

Finally if somebody uses a client which doesn't have this plugin/add-on, he might run a standalone mixer program. Basically this program will give you an address, you send coins to that address, and some time later get them back.

So feasibility isn't a problem at all. I wonder whether this scheme is secure, and whether there is interest in mixing like this.

Well, it might be sort of a plugin for one of clients...


Not necessary. If a lot of people use mixing, one round can be done in less than a minute.


Isn't it obvious? You can keep your bitcoins securely in your wallet. Service simply helps to negotiate a transaction which sends Bitcoins from your wallet to your wallet. There is no risk whatsoever.

"Simply selling people Chaumian cash" would require people to trust that server, develop a way to pay with them etc.

In which sense it is simpler than running a "mix my coins" plugin for your wallet?


Sure, there is no reason to have just one server.


I would need to trust you to not run away with my money. Also I cannot estimate mixing quality you provide.

http://178.33.22.12:3333/json/tx/8f6c8751f39357cd42af97a67301127d497597ae699ad0670b4f649bd9e39abf

Format is obvious, I think. Server code: https://github.com/domtancredi/bitcoinjs-color

It is serving data for testnet, and that's for a reason.


Well, here's a test (for testnet): https://github.com/vbuterin/BitcoinArmory/blob/color/txcolortest.py

But I don't have color definitions it's based on, I'll ask Vitalik...

You forget that inputs have scripts of different lengths.

For example, in case with P2SH output script is short, but input script is long.

Change you're proposing will subsidize multi-signature P2SH transactions.

What if I want to use 10 signatures for one input? Who cares, inputs are free!

Blind signatures used by mixing service are entirely orthogonal to Bitcoin cryptography.

From what I see RSA should be used for blind signatures, but perhaps there is a way to make other digital signature protocols to work with it too.

I wouldn't formulate it like that. A simple mixer service can trivially run away with your money, or it can log everything and sell it to interested parties. So it is 100% honor based, and quite likely you rely on service being altruistic.

On the other hand, it is kinda hard for a blind signature-based mixer to attack someone. Moreover, such attack can be easily detected by users.

So it isn't about trust. It is like "does somebody want to pull off a sophisticated attack at his own expense to reveal my identity?"

We should try to improve it further, but even as is it is way ahead of simple mixers in terms of security.

Unless I'm missing something UTXO tree can be used by miners only if it is mined in the main chain, not merged-mined.

And we want it to be used by miners because otherwise miners have to download whole blockchain at start.

If UTXO tree is maintained via merged mining which has only 1/1000 of hashing power, attack on such lightweight miners will cost only 1/1000 of hashing power. And it has potential to ruin SPV.

UTXO tree has a great potential, but it needs to be implemented properly.

Well, if they use bitcoind 0.8, while they still full blockchain on disk, working set depends on UTXO set.

Performance difference is probably too small to be considered, but still, UTXO set has effect on performance.

I've been thinking about this for quite some time (IIRC I posted a message about use of multiple chains for scalability ~2 years ago), and I think there is somewhat better solution: split blocks into two parts, permanent and temporary.

People can move their normal Bitcoins into temporary chain via a special transaction, and they can move it back too. That's the difference from your approach.

Obviously, we can expect temporary part to be more microtransaction-friendly as keeping transactions forever no longer bothers miners.

Some miners can choose to follow only permanent Bitcoins. It is possible because they can see that transfers is balanced.

Say, you send your 1 Bitcoin into temporary chain by sending it to yourself with SPLIT flag. Now you cannot spend it on the permanent chain without doing MERGE transaction.

Only miners who follow both permanent and temporary parts can check whether MERGE transaction was valid. However, miners who follow only permanent chain do not care about it because they can confirm that transaction does not increase number of Bitcoins in existence without following both parts.

Frankly, this is too radical for Bitcoin, perhaps some alt-chain will try it first.

Doing it in small batches is OK, it's probably even preferable for other reasons: faster and less disruptions.

It is possible to do mixing in a p2p fashion without blind signatures: by mixing coins of two users at once. But if some users are compromised (e.g. are NSA agents), entropy gain per round is small, and so large number of rounds is required. Blockchain bloat will be too large...

Doing it in batches where more than two users are involved would drastically speed up entropy gain. Even, say, 32 inputs per transaction is very good.

You still probably want many rounds (ideally on different services), but not thousands of rounds. If rounds are fast, it's not a problem.

For the sake of completeness, I previously considered two-party mixing rounds with subsequent compaction: i.e. these two party transactions won't be submitted into blockchain, but instead somebody would make a large transaction out of all of them and people will then sign this large transaction. It is possible and can compress thousands of small mixing rounds into one tx, but is very vulnerable to DoS attack: if there is an asshole who refuses to sign, people will have to re-do mixing pretty much from scratch.

Yes, considered this combination, but I don't see where it can be really useful (i.e. interest in it), and I don't have resources to implement things at random.

However, recently a different thing came to my mind: namecoin can be used simply to associate a public key with some name, while colored coins will exist on Bitcoin chain. In theory it is possible to verify this association without downloading whole namecoin blockchain.

If this is true, namecoin can be used to register ticker, colordef and whatnot, but we'll still trade on bitcoin chain.

I think that would be cool, but it's fairly complex software-wise.

Have you seen "the best way to implement coloring on a server" discussion on bitcoinX mailing list? It might be  relevant to what you're doing.

I've reposted it here: http://wiki.bitcoinx.org/index.php/ServerImplementationDiscussion

Also "development priorities" thread is kinda relevant too.


Coloring itself is described here: https://github.com/bitcoinx/colored-coin-tools/blob/master/colors.md

It isn't a complete spec, but I think it's good enough for the start...

It doesn't cover color definitions, but I'd say code which "does" color definition IS the spec for now: https://github.com/bitcoinx/colored-coin-tools/blob/master/colordefs.py

p2ptrade protocol isn't documented anywhere, but general overview was posted several times on bitcoinX mailing list, I can dig it up if you want.


Well, you can either send me your spec for review, or outline parts which you think might be problematic and we will try to improve specs.

Fairly easy to implement, if I'm not missing something:

Suppose there is a mixer service.

First of all, user needs to prepare outpoints for mixing: they should have exactly the bitcoin amount service requests, say, 1 BTC.

User submits a pair: outpoint he wants to mix and a blinded hash of receiving address. He also needs to pay a small fee. Server responds with a blind signature of an address. (I'm sorry if I'm using terminology incorrectly: I've just read blind signature algo description.)

Some time later user submits his address together with unblinded signature. Service can confirm validity of signature, thus it knows that this address is linked to some outpoint, but it cannot know with which one.

After enough users have submitted their outpoints for mixing, service will create a mixing transaction: it will include all outpoints and all addresses. Since addresses appear in a different order, it isn't possible to tell which outpoints are linked to which addresses.

Users then sign their outpoints after confirming that their addresses are included in transaction's outputs.

There are two possible problems:

1. User refuses to sign his input. It's easy to deal with it: asshole's outpoint is banned, everybody else re-submits their blinded and non-blinded addresses. Thus this DoS attack costs asshole money. Also service might require minimal age of 1 day for outpoints. It would mean that to sabotage signing 100 times per day asshole needs at least 100 BTC.

2. NSA submits their own outpoints for mixing, subtracts them from transaction and thus reduces mixing entropy. I don't see it is a big problem because mixing entropy is always log2 N where N is number of honest participants who will never reveal their (outpoint, address) pairs. So NSA can only instill a sense of false security if number of honest participants is low. And it will cost NSA some money...

In an ideal case commonly used Bitcoin clients should do mixing from time to time, even if users doesn't really need it. This will make sure that number of honest participants is quite large. Then Bitcoin will be statistically anonymous.

EDIT: Oh, the third possible problem: mixer service is run by NSA and they will make sure that your coins are not mixed with coins of honest people. This problem needs to be addressed, but I think solution is fairly simple: it is possible to check quality of mixing externally. Say, if have some sort of web of trust, WoT members can sign messages like "my coins were mixed in transaction xxx". If you see that enough WoT members sign certain transaction you can make sure that some mixing entropy exists. (As long as you trust WoT, that is.)

Note that ArmoryX development is sort of discontinued, we are currently focusing on thin clients.

There might be maintenance release if there is demand for it.

This is p2ptrade GUI: https://i.imgur.com/qPaXcpS.png

The rest is fairly boring: combo which selects current color (after you select one you can see balance and send them as usual), and a menu to issue new coins/view existing definitions/download new ones.

Ну вообще Satoshi начал с того, что выложил свою статью, которая объясняет почему безопасности биткоина можно верить. А уж потом занялся GUI.

RealSolid, судя по его поведению, просто клоун. Очень низка вероятность того, что такой клоун способен разработать свою систему, которая сможет конкурировать с bitcoin в плане безопасности.

Но если статья выйдет, можно будет обсудить. Без этого это просто клоунада и развод на бабки.

А вообще, насколько мне известно, любая криптовалюта сводится к распределённому консенсусу. Отличается только способ подавления Sybil attack.

В bitcoin Sybil атаки устраняются спомощью proof of work: Sybil атака дорого обходится в вычислительном плане.

В ppcoin спомощью proof of stake (хотя есть другие варианты PoS): Sybil атака дорого обходится в плане денег.

В ripple.com предлагается просто выбрать набор заведомо реальных узлов и доверять ему. Такой же вариант предлагает Ben Laurie, к примеру узлами могут управлять какие-то общественные организации или коммерческие компании. Вероятность того, что они все сговорятся очень низка.

И, наконец, есть Qubic, в котором узлы привязываются к сетевым адресам, и для Sybil атаки нужно много IP адресов и большая пропускная способность.

В общем, если RealSolid не изобрёл чего-то принципиально неизвестное науке, то скорее всего речь идёт о системе построенной на доверии заведомо известным узлам. Что, в общем-то, не особо интересно при том, что уже есть ripple.com. Хотя можно было сделать платёжную систему с семантикой биткоина.

Можно просто закоментировать LogStackTrace, это просто отладочный вывод.

По-видимому backtrace() недоступен в FreeBSD.

Oh, I thought you meant profitable within a single trading session.

Still it might be somewhat problematic for people who use futures to hedge their positions (e.g. if one sells goods for BTC but needs to pay supplier in USD), but I guess they have to live with it.

Have you thought about making futures with guaranteed profit? Maybe via insurance (higher fees) or something like that.

Well, the idea is that profit on one account isn't limited but loss on another is. Suppose I fund each account with 1 BTC.

If market moves in one direction over several days (and it is often the case with Bitcoin), my loss is ~1 BTC, but my profit might be 2 BTC.

Effectively it is a bet on high volatility.


How so?


Well, Fireball is either dishonest or he doesn't understand how futures work. (LOL!) And neither do you.

Suppose I bought at 40. Then next day futures price went to 35. Then back to 40. My P&L over two days should be 0, right?

Wrong!

It turns out that when price moves from 35 to 40 my position is "profitable" and so it might be forcibly closed "at a very good price", which won't cover my previous loss.

Thus on ICBIT it is possible to suffer loss due to counterparty risk.

It is even possible to have a loss when you should have had profit.


It works only as long as collateral covers price movements.