Anyone have contact info for MinghuaQu ?

Congrats on the round

What I'm offering to implement is a strict superset of what you propose. I think the added functionality is important, today. We have a difference of opinion on priorities, and we'll have to leave it at that.

That's about 243MB.

Block chain pruning is very well understood, and can be done safely. The reference client already does this (the data is kept around but the index used for validation is pruned). Search the forum and dev mailing list: we won't rehash it here.

Peter, RSA blind signatures are dead simple. All cryptographic libraries support the required primitive operations, albeit sometimes under different names. And the math itself is simple: you could even implement it in a few lines of Python (not recommended, however, as it'd be super slow):


The difficulty in implementing CoinJoin is the standard software engineering problems of any distributed protocol, and not the cryptography itself. The crypto is remarkably simple. OpenSSL supports blind-signing directly, but even so I specifically chose RSA over other blind signature schemes because it is so straightforward to implement - multiplying large integers - even though it's quite a bit slower than more esoteric schemes. So yes, I take implementation complexity very seriously.


I think you've misinterpreted my proposal. The work I've done so far specifies what those messages will look like, not the networks on which they are transmitted. It is a network protocol that can be run over any broadcast + point-to-point medium for which anonymous connections can be made. There is absolutely nothing tying this proposal to bitmessage, it is simply one of many possible implementation routes.

However the initial implementation will run over bitmessage because that is the simplist and fastest way to get started. I imagine that if/when this eventually gets adopted into Bitcoin-Qt and other wallets, it'll probably run over a modified version of the bitcoin p2p protocol, using Tor or I2P for the anonymous connections.


You are very focused on mixing, but that is only one application. There is also every category of group transactions from matched donations to group buys to auction bids, where 2 parties is only an edge case. There is also the possibility for an online facilitator (who gets paid) when the parties are not online often enough to arrange joins directly. And there is every other transaction with multiple inputs and multiple outputs, which desires a crowd to hide in. A multi-party Chaum blinding solution achieves that, whereas a 2-party mixer merely solves a single problem.


A toolkit for constructing group transactions is what I'm making.

And as a meta-point, I don't believe that bounties are the right tool for this job. If you donate to this campaign, you know what you're getting: X hours of my time to implement the spirit of this proposal, while understanding that I retain the right to make technical changes when it becomes necessary for reasons now unforeseen. Bounties, on the other hand, have too much variance, arbitrariness, and general risk for someone such as myself who makes his living off of it.

No, there's no relation between a pubkey and a pubkey-hash. Once the pubkey is known, hash160 isn't relevant at all. Coinbase transactions in the pre-pool days were simply the public key and OP_CHECKSIG. "All" you have to spend this is find a way to generate a signature from the public key only. No hash preimage is required.

It's not streamed reads, but random reads over a multi-gigabyte dataset. Spinning metal disks are notoriously bad at that.

Thank you justusranvier. Your generous support over the last few months is what has kept me going to hit this milestone after the funding would have run out at the end of August. In case people missed it, here's the ReDonate campaign:

http://redonate.net/dashboard/bitcoin-developer-maaku

I don't even know how to respond to that. Quantum physics is governed by a wave equation. Quantum computers are just a neat arrangement of coherent waves and barriers that has computationally interesting properties. You simulate it by solving the wave equation, which is just math. How do you think Bell came up with his inequality? He solved a 'simulation' by hand, with pencil and paper. If someone actually has money on the line, then maybe you are misinterpreting what the challenge is?

Anyway, we're wandering deeply offtopic.

Christian's math doesn't work out:

http://arxiv.org/abs/1109.0535

You can certainly simulate a quantum computer, just as you can simulate the core of a neutron star without actually creating one. There's nothing magical about a quantum computer. It's just capable of running an amazing number of calculations in parallel - literally in parallel if you subscribe to MWI. You can simulate that by running the calculations in series on a classical computer. Of course for the kinds of problems people usually want a quantum computer for, that simulation would take longer than the lifetime of the universe. But you could do it, in principle. There's nothing magical about quantum computation.


It's in the FAQ that I linked to, but in summary you run a quantum computation requiring a wave function collapse forward and reversibly measure the result. If the wave function collapse is real then it would be resolved to a single state. When you run it in reverse the wave function maintains that single state. If, on the other hand, the MWI meta-theory is correct then the reversibility keeps the wave function coherent and it 'collapses' again as you reverse the operation possibly ending up in a different state. Of course there is no collapse, it's just an artifact of us ending up in one of many previously coherent worlds.

Um, for credentials I'm a physicist, my undergraduate adviser does his research in quantum computing and I've actually done laboratory experiments demonstrating entanglement and (so-called) non-locality. Is that sufficient?

Joy Christian is of that category of people that looks at the data and says 'that can't be right!' and willfully ignores it. You can verify that something apparently spooky is going on with relatively simple experiments that have been replicated many, many times. It's like rejecting Einstein because the twin paradox is just too weird a concept. It doesn't stop the atom bomb from being possible.

Anyway I only bring up many worlds interpretation (MWI) because it's a simpler meta-theory that explains all observed quantum phenominon without resorting to the wave function collapse (and therefore without the EPR paradox of non-locality), or the privileged observer frame of reference. It still has all that quantum weirdness, but with very simple, easy to understand (albeit mind-blowing) explanation. The best long-winded introduction to MWI is this FAQ. In a couple of decades when we have atomic-scale reversible computers we'll be able to do actual experiments that will tell once and for all if the wave collapse is real or merely a belief resulting from our anthropic bias.

Regarding quantum computation, you can simulate it on a classical computer, sure. But then you only get a simulated “speedup”. It would definitely not be any faster than classical computation.

Bell's argument doesn't apply to the many worlds interpretation, which also conveniently resolves all the spooky-action “paradoxes”. But regardless, under no consistent quantum theory is quantum computing with classical parts possible. Joy Christian is a crank.

The point is that the OP was not maxing out his bandwidth. It is possible to use your full bandwidth to download the blockchain, if you're selective about what peers you connect to, no matter where in the world you are connecting from. In 0.9 this manual tweaking should no longer be needed.

Actually your original posts didn't make it clear that it'd be a one-time burst of transactions. So long as you stay well within those limits on average, it doesn't matter if you do them all at once. Except, as already mentioned, the performance issue which minconf=1 solves. Of course setting minconf=1 has other implications:

(1) If you exhaust the list of confirmed outputs, your sends will fail (because there are no unspent outputs to fund the transaction with). In that case just try again later after some confirmations. A good strategy would be to use -blocknotify to call a script which processes transactions until you exhaust your pool of outputs, then exit and wait for the next block.

(2) If your list of unspent outputs shrinks, as it will from time to time, you may unexpectedly limit yourself. If you have just two unspent outputs, you are limited to no more than 2 transactions per 10 minute block with minconf=1. The solution here is split your largest outputs into a couple of smaller ones (by calling 'getnewaddress' a few times and doing a 'sendmany'), so you once again have a large enough list of outputs available.

(3) You can minimize both these problems by batching all the little transactions you want to do into a single transaction, one per block, if your use case allows it.

As for the 0.51btc: unexpected, but thank-you!

The entire network is limited to approximately 7 transactions per second, assuming you're using the smallest transaction possible. That comes from the maximum size of 1 megabyte of transaction data per block, 1 block per 10 minutes. That's not 7 per user, that's 7 transactions total, including everyone else in the entire bitcoin network.

But assuming you keep within these limits, minconf=1 should do it.

EDIT: This is not a permanent cap, but is something that will be fixed in time. However there are technical problems that need to be solved before the bitcoin network can scale to higher capacity.

I've had success killing and restarting bitcoind until I'm syncing from a fast peer (maxing out my bandwidth). I know others have had success using -connect using an IP in a known-to-be-fast range (e.g, if you're bootstrapping on AWS, dig the DNS seed until you find a peer with an AWS IP). Sync time goes down to less than a day even with a spinning metal disk.

Let me help you read between the lines of gmaxwell's answer: what you're trying to do is going to result in flooding the bitcoin network with more transactions than could ever possibly be confirmed. Either you will die a quick death from transaction fees, or you won't provide enough fees and your transactions will never be relayed let alone confirmed. So what you're doing won't work for reasons unrelated to this performance 'issue' you've identified.

I would suggest rethinking whatever it is you are trying to do.