But if the message-holding party knows p and q, then she can construct the entire private key and sign messages herself. Basically the problem is that only the message-holding party knows the public key that is being signed with, and as long as any of a, b, c or d is secret, she is welcome to lie about this, and she can use this lie to trick the blindsigner into signing something he doesn't want to.

I agree it seems close. But it's not It's a worthwhile exercise spending a few days trying to extend oleganza's scheme to do something other than his specific blind-escrow scenario. You will see that the security breaks every time you get it to do something interesting.


No, that is not at all what DeathAndTaxes is saying, and this kind of complete lack of understanding is exactly why I opened with my "don't roll your own crypto" article.

I added a 'Where do I go from here?' section to alts.pdf (and blocked in some ideas for what I want to talk about in the "stupid shit" sections). If you actually want to do cryptography you should go read that.

You can tell the blindsigner what a and b are, but he can't guarantee that you're not lying to him without also knowing c and d.

Also, there is another problem with using oleganza's scheme as an ordinary split-key scheme: it is not publically verifiable. That is, without revealing enough parameters to expose the private key, you cannot prove to others that the blind signer was actually involved in creating the signature.

There are many people unaffiliated with the core Bitcoin developers who watch the git repo carefully, so such a heist would be impossible to pull off undetectably. Not to mention that the developers themselves form a geographically and politically diverse group (to the best of my knowledge none of them identify as thieves though ). You are welcome and encouraged to read the pull requests and commits. Every bit of oversight helps, even if you are not religious about it.

But of course, a third-party test suite would be a great thing to have. If you want to spearhead such a project I think that'd be a welcome contribution.

Now, having said that, what happened to Mt. Gox has nothing to do with anybody else's code, because Mt. Gox was running their own unpublished in-house code, and it was this code that had their fatal bugs.

That's a neat idea, to use oleganza's scheme as a threshold signature. However, you can't simply execute this scheme unblindedly. If the blindsigner knows all of a, b, c and d then he can determine the entire private key and create signatures all on his own. But if he doesn't know all of those, there is no way that he can be sure of what he is signing (or even of the public key that he is signing with). So this is a threshold signature in some sense... but a very unnatural sense.

It is important to realize that in cryptography, arguments by authority have no validity. There have been cryptosystems created by experts, with mathematical proof of security and decades of use, which eventually failed nonetheless. To develop cryptosystems, it is important to have a deep understanding of the underlying primitives and the contexts in which they can be safely used. This in itself is a gargantuan task which will likely take you years of research, even without attempting to develop your own primitives. (And as I explained in my article, it is never necessary or wise to use home-baked primitives, though it is good practice to develop and break them in private.)

Further, Gavin and Mike's conception of oracles may not correspond to your own conception. In all areas of research there are massive concepts hidden behind small words, and cryptography is no exception.


I apologize for my terse tone. The fact is that this forum has thousands of users with more enthusiasm than understanding, and it can be overwhelming at times. I have only so much time in the day, and sadly I am not paid to post here (though I am paid to do cryptographic research). In fact I have been part of the bitcoin community for several years, and have been quite active in its research community for a good part of that.

My low post count and short replies reflect this situation. To compensate I have been developing several articles to correct and explain common misconceptions, including the one that I posted for you, which as you noticed is not yet finished. I'm glad that you took the time to read it and I hope that it provided some perspective about the nature of Bitcoin-related work.

If you'd like to learn more about modern cryptography, I encourage you to check out Matthew Green's blog (as a starting point, read every single post and reference), as well as some classic papers such as "Probablistic Encryption" by Goldwasser and Micali.

You are playing with fire and for the sake of the community I strongly encourage you to stop.

Please read this document:
https://download.wpsoftware.net/bitcoin/alts.pdf

No. The new laptop has no awareness of what's going on with the old one, so it is fine to move wallet.dat like this. (Though if you use the same wallet.dat on multiple computers at the same time, you will not have fun. Don't do this.)

There is no notion of "accounts" the way you are thinking. The wallet.dat file stores some key material and your transaction history, and the rest of the network is happily oblivious to what exactly is in there.

My guess is that if you copied wallet.dat before shutting down Bitcoin on the old system, the file you copied was not in a finalized state, hence the crash. If you shut down Bitcoin on the old laptop then re-copy the file, things might work for you. If not, this may be a bug with the Bitcoin client.

sx is a utility written by genjix which does a whole bunch of things.

If you are asking for the math behind stealth addresses, see Peter Todd's mailing list post
http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03613.html

IIRC there is a followup by Jeremy Spilman which explains it in a slightly different way, since PT's notation is a bit awkward, so that's worth reading too.

Andrew

dserrano5, I have fixed the autotools files in git HEAD. It should build now without any hackery.

Peter Todd, very good advice. I'll bug you on IRC if I have any trouble with this, and see if I can find my way into the wot.

Edit:
For web-of-trust purposes, here is a signed PGP statement:
It is also available on my website here: https://www.wpsoftware.net/andrew/pgp-statement.asc

I will tag the latest cj-client HEAD with this signature shortly.

Edit2: On github there should now be a tag "v0.1" which matches the commit in which I fixed the autotools stuff.

Thanks dserrano5, I see the error too on my old computer. I'll look into it, it's silly to require new dev tools for something this simple.

In the meantime you can find the line
in configure.ac and comment it out by prefixing with #.

Really? Immediately above the definition of this function there is the comment


which tells you that this function is horribly misnamed and actually does not do what the OP asked for.

Bitcoin transactions do not contain enough information to determine a sender address. There is therefore no way to obtain this information through the RPC interface.

1. Yes, if you are constantly generating new addresses you'll have to make frequent backups. Though you can set the keypool size past 100 if this is a concern.
2. Yes, only wallet.dat.
3. I do this a lot because I forget that bitcoind is running, and it appears to work fine (knock on wood). But no, as long as bitcoind is running the wallet database is opened and may be in a weird state.
4. Yeah, just drop wallet.dat into the right place. (Don't do this while bitcoind is running!)

There are no accounts in bitcoin. Every transaction uses the full value of its inputs.

I guess you mean he's studying CS at the undergraduate level.

Here is a quick brain dump of some interesting CS-y bitcoin stuff:

There are a bunch of network-simulation problems that might be fun to do. For example Aviv Zohar's paper http://eprint.iacr.org/2013/881 still has not been simulated to the best of my knowledge. It would also be neat to study the network consequences of selfish mining, block size changes, propagation of invalid blocks or transactions, etc. These are not really open problems, just things that people have not studied in great depth, so your friend would have some support here.

There is also some cool data structure work to do with blockchain pruning and utxo management. Peter Todd has an idea for using Merkle Mountain Ranges to store the utxo set, then requiring transactions to provide cryptographic proof of the MMR updates. This has a practical problem in that the proofs are huge compared to ordinary transactions, but it's still something neat to study. I'm sure others will jump in with data structures problems; this is not really my thing.

Then on the crypto side there are much cooler problems, but perhaps not so accessible on the undergraduate level. For some bitcoin side projects it would be neat to have ed25519 blind signatures. Learning the background then implementing this is probably roughly the right amount of work for an undergrad honours thesis. Check out ed25519 signatures and Matt Green's note on blind signatures. You might also want to track down David Chaum's untraceable cash paper for a cool application of blind signatures. (If it's behind a paywall I can get it for you.) In the same category would be one-way aggregatable signatures, which are cool in their own right. According to that paper, which I still haven't read, they have some sort of applicability to bitcoin.

There are tons of neat proposals for using bitcoin's secure global timestamping mechanism to solve cryptographic problems. Tons of these are posted here (though I don't have any links offhand). Another exciting example is secure multiparty computation in Bitcoin.

Another cool idea would be to use pairing-based crypto to implement Identity-Based encryption. That paper has a quick overview of pairing-based crypto, which essentially means you have a magic bilinear mapping between groups. This is "moon math" in the sense that the security assumptions are much less studied than, say, discrete log for elliptic curve groups. There are some neat applications for IBE, eg Adam Back's non-interactive forward secrecy scheme. If bilinear mappings are not weird or theoretical enough, there are extensions of this which give you multilinear mappings. (I haven't bumped into one, but gmaxwell says papers exist.) Pairing crypto uses bilinear maps, which can be used for a noninteractive 3-party shared secret, similarly to how EC-Diffie-Hellman gives you a 2-party shared secret -- an (n-1)-linear mapping would give you an n-party shared secret. Peter Todd had some use for such things recently, hence the interest in multilinear mappings.

Veering further into moon math, and probably also past the undergraduate level, there has been a lot of interest in the bitcoin community in efficiently verifiable zero-knowledge computations. In particular, a recent paper on SNARKs (succinct noninteractive arguments for knowledge) has drawn some excitement. Again there are practical problems with the computational time required, but not abhorrent. A more serious problem is that the security proof is in the CRS common reference string model. When a cryptosystem requires all parties to have access to a common reference string, in Real Life this reference string is generated by one party who has access to some secret key -- and with this key, forged proofs can be constructed. Imagine if bitcoin depended on SNARKs and nobody could prove that satoshi was not using (or did not have) such a key. Solving this efficiently is a big open problem. This is cool to investigate (and the linked paper has a -ton- of references) but probably even doing a book report on that paper would be beyond an undergraduate thesis.

A list of alt ideas (some of which I've mentioned above) is here: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas . Your friend may also want to idle on #bitcoin-wizards and see what floats by.

I should probably add a link to the original thread in which gmaxwell explains the justification and technical details of coinjoin: https://bitcointalk.org/index.php?topic=279249.0

Note that the centralization here is of a fairly benign sort: by being the server operator I know the original input transactions and can in principle publish these to undo the privacy-enhancing effects of the join. But then you are reduced to the position you were in just by using ordinary transactions. So there is no harm. (Also you have my word that I will not publish any of the original transactions I have access to.) In particular, my server never sees any private keys or anything, and has no ability to steal money.

Further, the client does many checks for funny business on the part of the server or other participants, and refuses to sign any transaction which spends money it is not authorized to. So not only is the server unable to spend your money, it is unable to trick you into doing so.

I hope this alleviates some of the concerns and confusion I have seen about this on IRC.

This will be the only time that I bump my thread. If people are not interested I suppose they are not interested.

Hey everybody,

Preamble
I have written a simple coinjoin client which does peer-discovery via a central server (my own) and speaks with bitcoin-qt/bitcoind over RPC to construct transactions. The server opens a join session as soon as it receives an unsigned transaction. Then over the next 20 minutes it accepts more unsigned transactions, then closes the join session. At that point all the transactions are merged, the merged transaction is passed back to the clients, and they submit signatures. When all the signatures are in, the merged transaction is submitted to the network.

(If you don't use bitcoin-qt, it is possible to give txids and privkeys directly to the client, so our brainwallet-using friends are supported.)

Downloads
The download links are:
Source: https://github.com/apoelstra/cj-client
Windows binary: https://wpsoftware.net/coinjoin/dload/cj-windows.zip

More information, as well as a link to the web interface (for those who would rather deal with raw transactions than use a point-and-click client) is available at https://wpsoftware.net/coinjoin/client.php

When do the joins happen?

You can use the joiner any time. However, to get people on the same page during these early days of few users, we will have scheduled joins starting at 7PM PST and 7PM GMT on Monday, Thursday and Saturday. The recommended output size for these scheduled joins will be 0.5 BTC.

How do I use it?

First, start bitcoin-qt with the -server option. I think on Windows you can do this by Right-clicking on the program icon and going into `Properties'.

Even if you do not use bitcoin-qt, you will need bitcoin-qt or bitcoind to be running in other to do the transaction construction. I'm sorry for the inconvenience.

Next, start the joiner. It will communicate with bitcoin-qt to get a list of your coins. Choose the ones you want to join, and a target output size. When you are satisfied, click "View Transaction" to see the transaction that will get joined. You will see the inputs you selected, and several output addresses. These are new output addresses given to the joiner by bitcoin-qt.

(If you'd rather specify output addresses manually, click Advanced->Add Outputs... and type them in.)

If you are happy with this transaction, click 'Submit Transaction'. After a minute or so, the client will ask for your wallet passphrase. This is needed so that the client can sign the joined transaction. (The passphrase will not be sent over the network under any circumstances.)

That's it! Leave the client running, and when the session ends, it will sign a merged transaction and submit it to the network.
Good luck!

Coinjoin does not need nonstandard transactions, nor should it use them -- it is NP-hard to determine whether an ordinary bitcoin transaction might be a coinjoin.

I asked gmaxwell about the possibility of sybilling (e.g. showing different empty trees to each lender), and he said that the threat model he is dealing with here consists of people who show up on -otc, do a bunch of small, simple trades for a year or so to build up reputation, then finally borrow huge sums of money and disappear. This is a real thing that happens today.

So to coinrevo: the problem this solves is a real one, even though it doesn't solve the "real" problems around lending.

To Mike: re "this protocol is incomplete", it's presumed that you'd attach your tree to your -otc rep, so every fake account would require a new reputation-building phase.

As discussed in the CoinJoin thread, there is a (conceptually) simple and safe way to merge Bitcoin transactions, which can give participants improved privacy by befuddling blockchain analyses.

There are a few people working on cool clients which do CoinJoins automatically and invisibly, but until these are ready the current way to do it is basically:
1. Collect raw transactions from people.
2. Join these all together with whatever stitching method you have (probably some bitcoind/sx hack script).
3. Get signatures from each party, one after the other, until you have them all.
4. Submit the transaction.

The worst step is #3, this takes forever if you have several parties and creates asymmetries in who knows what about the transaction. There is no reason everyone shouldn't sign at once, it's just that bitcoind can't merge the resultant transactions.

So, I've written a tool which does this, and set it up here: https://www.wpsoftware.net/coinjoin/

Now the steps (for every participant) are:
1. Submit your raw transaction.
2. After some time (right now 20 minutes later, it will tell you when), receive a joined transaction to sign.
3. Sign and submit this.

Please do not post TL;DR or ``I don't understand this'' or ``too complicated, nobody will use this''. The point of this joiner is to deal with the technical parts of manual coin joins, not to make coinjoining trivial and easy to do. (These are great goals, just not ones I have time to pursue.)

Anyway, I'm throwing it out here for you guys to play with. Detailed instructions are on the page.

For those willing to futz around with raw transactions, I have a simple centralized coinjoiner available here:

https://www.wpsoftware.net/coinjoin/

Basically, once you submit a transaction this opens a 15-minute window for others to submit a transaction. After the 15 minutes are up, the transactions are merged and everybody signs the merged transaction. Once all the signatures are received, the joiner submits the transaction.

Thanks very much to my testers, in particular gmaxwell and midnightmagic, for their excellent suggestions and bug-finding.