Old systems were broken suddenly because they sucked.  No one knew they sucked, because no one was looking at them.  Anyone can design a system that they can't break.  Our systems don't suck any more.  They aren't built in the dark.  Everyone looks at them.  In fact, a decent fraction of the intellectual power of the human race is devoted to examining cryptosystems.  The really bad ideas are gone now.

I understand full well that the history of modern cryptography doesn't absolutely preclude the chance of a sudden break, but it certainly relegates it to the domain of extreme long shots.

If you feel strongly enough that the threat is so great that we need to take action now, feel free to do so.  All of the source code is publicly available.  Design and implement something.  Test it out, prove to the world that it works and is safe.  Convince everyone that the risk of changing the system is small enough that it outweighs their estimate of the risk of a catastrophic break.  No one will stop you.  Plenty of us will even help you with design and implementation.

Just don't expect to make any friends by telling people that they must do your work for you.


Dormant keys are protected by dormancy.  Unless in this hypothetical world SHA-256 is broken at the same time as ECDSA.

To keep things in balance, you have to sell the winning asset and take on more of the losing asset.  This is a good way to protect against a sudden drop in one side, but does not seem to be a winning strategy for the long run.

I think that the quest for the perfect mixer has greatly hindered the deployment of imperfect mixers.

What we need is a simple system.  A very simple server that can operate over many protocols (HTTP, telnet, IRC bot, etc.), including tor versions.  A very simple set of scripts that run on the client that interact with it.

When the client connects to the server, the server advertises what sizes it is willing to mix and how many participants it wants.

If the client meets those needs, it sends an address that it wants included in the next batch.

It then checks back from time to time, and when the server has enough participants, it sends back a transaction that pays to the list of participating addresses.

The client sees the address it wants in the output and signs it with SIGHASH_ALL + SIGHASH_ANYONECANPAY and sends it to the server.

When the server gets all of them back, it assembles them into a full transaction and broadcasts.

Lots of things can go wrong.  None of these nodes provides any security because the node can de-anonymize the transaction by providing all of the other inputs and outputs involved.  Batches can fail because any participant fails to sign.  People can attack the system by intentionally signing up and then failing to pay.

But imagine a network with hundreds or thousands of these nodes running.  Literally anyone can set up a node.  Imagine clients constantly churning coins through them.  Each cycle adds between zero and full anonymity, so many cycles should, on average, work pretty well.  People could even build chains through the system, using the output from one cycle to feed the next.

Protection against a potential weakness in ECDSA has been included since day 1.  Don't reuse keys.

Also, in reality, a sudden catastrophic break in ECDSA is pretty much unimaginable.  There have been zero sudden breaks of that magnitude in modern cryptosystems.  What really happens is that they weaken gradually over many years.

Should such a thing happen, the method described in the first post appears, at first look, to allow migration, and the world would implement it or something like it very rapidly.

There may be some value to adding this to the system in advance of the need to use it.  It may even enable some other useful things.  But it would be a fork.

I've never been a big fan of balancing strategies.  They run away from success and towards failure.

Colored coins are unworkable in the real world.  Mastercoin is a scam.

We need a bitcoin-like chain for securities and shares.  We'll get there.  Brokerages will transition to acting as interfaces between the bitcoin chain and the security chain.

There is insecure, and then there is insecure.  Are there any real world attacks that don't require the attacker to be in a position where they could do much worse?

Also, note that the time data used by the bitcoin network is also totally unauthenticated and insecure.  Our pseudoclock is adjusted based on the version message timestamp, which is trivial to modify.  We even potentially reject blocks (which contain a somewhat secure timestamp) based partially on data collected from the totally insecure timestamps reported in the unauthenticated version messages.

Hell, for all we know, the bogus timestamps from these nodes are a real world attack test.

I know that bitcoin doesn't need an accurate clock, but every node on the network has an accurate clock available anyway.

Small transaction management is hard to do in a way that works for everyone, is safe, and doesn't leak privacy.  One or two of those are easy enough, but getting that third one in there is a bear.

It gets much worse when you try to preserve coin age and priority for the free transaction calculation.  Someone with an unhealthy attachment to their old satoshidice in-band notification payments isn't going to be happy if their whole wallet is tied up in new coins when they have to pay a fee for a trivial spend.

Just FYI, I routinely make static-ish builds.  My mining distro is based on Debian, but the bitcoind binary on it is build on an ancient slackware box with wildly different libraries.  Fudging the makefile for a static build gives me a binary that will run just about anywhere.

On the original topic, rather than a fork, why not build options?  This would reduce the maintenance delta to a hopefully manageable level.  It is even something that could be done incrementally.

Why would we need to include NTP?  Is there some OS out there with network support that can run a bitcoin node, but not NTP?

No one should be doing serious work on the internet without a solid clock, and money is about as serious as serious gets.

After a while, this really degenerates into the SSL debate.  SSL sucks.  Why does everyone use it?  Because everything else is worse.  NTP sucks.  Why does everyone use it?  Because everything else (including bitcoind's crappy pseudo-NTP) is worse.

We were smart enough to avoid creating our own PKI in favor of the existing system that is good enough.  Why aren't we smart enough to avoid creating our own clock synchronization system?

P.S.  pool.ntp.org.  The Air Force could probably mess with it if they were willing to crash some planes, but I doubt that anyone else could do much damage.  I know we have some timekeeping enthusiasts around.  Is the NTP pool more vulnerable than I'm aware of?

Edit 2013-10-28 19:32: removed an extra "a"

Imputed data isn't.  Ditto for interpolated.

If your model involves anything resembling regression, cleaning the data in any way will cause your model to vastly overestimate the certainty and accuracy of the output.

This kind of thing is a pain to model.  The spreads between the exchanges distort the price signal that you are looking for, but not totally.

You could use (sign,magnitude) of changes instead of absolute values, which will remove the pure-arbitrage signal from the price signal, but that distorts the price signal.  (sign,log(magnitude)) might help a bit, but that's hard to say too.

Or, you can ignore the arbitrage signal, and just mash the prices together as they really are.  But that will result in a price that is constantly too high by a factor related to the difficulty of moving stuff around.

You are going to hate this, but the most valid way to go is to model each exchange and the relationships between them.  You'll have to give up on the notion of "the bitcoin price" and instead work with "the bitcoin price at locations X,Y and Z".

Oh, and I forgot that the arbitrage issues are not linear.  Your model is going to get screwed every time the real world factors that cause the spreads change.

The ambiguity of the hex forms is one of the reasons for the encoded forms.  Hex is not suitable for interchange, only for internal temporary use.

Avoid ambiguity internal to your program by attaching metadata.

We should have fixed the time nonsense in bitcoin long ago.

Despite the imperfections of NTP, there is no excuse for a p2p network (which runs on the same internet as NTP) to fudge the clock.  If I have a good NTP lock, and I connect to a node with a different time, that node is wrong and should be kicked immediately.  If I don't have a good NTP lock and I connect to a node which does, that node should kick me.

I don't know that making whatever this is fix their clocks will cure anything, but it can't hurt, and we should have done it long ago.

I take a very slight exception to this.  Signing a message, which is all that a transaction is, has a cost.  One, it requires you to publish your public key, and two it requires you to publish a signature.  Publishing your pubkey is a huge hit to the security of the key, as it entirely strips one layer of our elaborate defensive structure (the hash) from that key.  Once the pubkey is widely known, the incremental cost of publishing another signature is slight, but not zero.

These are very tiny, but real, costs to the security of that key.  We believe that our system is secure against key-reuse, but history teaches us that multiply used keys are the first to fall when a system starts to show weaknesses.  The problem is even worse with low quality keys, which I consider all so-called brain wallets to be, and those are the very ones that people are most likely to use to store their largest stashes, and the ones they'll most likely be tempted into weakening in this way.*

A user should not publish their public key until they are ready to stop using it.  Signing a message to prove that you control the key that controls some coins is not the final use of that key and should not be encouraged.

The safe way to prove ownership of a key is to transfer it all funds available to that key to a new key/address with an unpublished pubkey.  This is how gox proved the safety of their stash a while back, and this is how the FBI proved confiscation of DPR's wallet.

* I see proof of address systems mainly used as e-peen comparison tools.  Perhaps I've overlooked some serious usage?

To create a P2SH multisig address, some entity in the process must be in possession of all pubkeys.  Pubkeys are generally considered safe to share, publish, etc.  That's why they are called public keys.

WIF works perfectly well for keys used in multisig.  You can import all of the keys into the client if you want, or you can specify them in the RPC signrawtransaction call, and whatever infrastructure you create to support your system had better be able to read them too.

When redeeming, signatures are also safe to ship around.  Signatures are big, coding them in base58 makes them bigger.  No one is going to be processing them by hand.  Signature problems will just show up as an invalid signature, and they can find the problem and try again.  It isn't like a key or an address where an error can drop coins into a black hole.

Look at BIP 10.  It is about shipping signatures around for multi-party transactions, but it looks like it would work perfectly well for P2SH multisig too.

How much less than full entropy is "good enough"?

If used properly, even a shitty key can be good enough, just as long as it isn't too shitty.

But, key abuse is rampant in bitcoin.  You also can't constrain the future use of the key when you make it.  Since you can't be sure that you won't, some day in the far future, abuse your key, you should endeavor to make your keys as securely as possible.

The only advice I'm ever willing to give people is to pack as much entropy into their keys as they possibly can.  If they want to cut corners, that's on them.

The modulus trick is great.  I don't know how I missed it in my travels through the FIPS manuals.  It seems like a very effective way to blend extra entropy throughout the entire key.  I'm going to steal it for my offline paper wallet generator.  Since I haven't yet made a geiger tube collector, I'm always skeptical of my entropy sources.

There are fewer places to screw up, but still not none.  Again, use a cup, try tossing it the same way each time, don't look at the coin before/during tossing, use a flat tray with a marked border, write down exactly what comes up even if you don't think it looks "random enough", etc.

Uh, actually it is surprisingly easy to fuck up dice rolling for entropy.  Any attempt to extract entropy from gross physical processes that requires human work is prone to failure.  Just ask everyone that tried it during World War II.

Ideally, you should build a machine that shakes the dice in a cup and tips the cup into a flat, level tray.  At the very least, use a cup, try to tip the cup the same way each time, and for the love of god, don't look in the cup while shaking or tossing.  The tray should have a line painted in it about 1.5 die radiuses away from the wall and you should ignore any rolls where any of the dice touch or cross that line.  Also reject any rolls where the dice are touching.  Since dice touching can be somewhat subjective, it is also a good idea to reject any rolls where the dice end up within some objective threshold of each other, 1.5 radiuses perhaps.  Build a gauge block of the appropriate width and taller than the dice and try to slip it between the dice if they are even remotely close.*

Next, all of your dice need to be different and distinct colors, and all faces must be instantly distinguishable (that means you need dots or lines on both 6 and 9, not just one).  You must always assemble the rolls into your number in the same way.  Print a data collection sheet with boxes, and color code the boxes to match the dice so that you don't mess up the ordering.**

And finally, never, ever, ever reject throws for subjective reasons.  You must be extremely vigilant about this.  Your natural tendency will be to reject throws that don't look random enough, or just don't look right in some obscure way.  You must fight these thoughts and write down the data collected, exactly as it comes up, regardless of your personal feelings.

You'll note that most of my advice is in the area of removing your own judgement from the system.  Your brain is a shitty discriminator of entropy, and if you let it interfere with the process, you will get shitty entropy out.  During World War II (and the cold war, for that matter), office staff on all sides of the war were trained to generate encryption codes and pads by using physical systems like dice.  They usually failed (and their codes were cracked, and people died) because they would have unhelpful thoughts like "that's too many 7s to be really random.  I'm going to change a few".  And that was generally after being trained specifically not to do that, and that lives depended on the quality of their work.  Odds are very good that you will do at least as poorly as they did.

* The common theme here is to reject any rolls where the dice might be leaning on the wall or on other dice, which is to say when they might not be completely flat, which is to say when human judgment might possibly come into deciding which face is up.  Setting the margin wide and using objective measures reduces the temptation to occasionally fudge things.

** Again, remove human judgment.  If the die only has 6 or 9 marked, you will occasionally write the wrong number down.  If you don't have a defined order, you will write them down in the order that "looks" most random to you.

No you can't.  The authentication in SSL is ephemeral.  At no point do you ever possess a document signed by their key.

No, it doesn't need to be encrypted.  Encryption protects the privacy of the message.  If the parties wish to keep the communication private, it should be encrypted, but encryption isn't necessary for authentication, which is what DSA does.

Because any change to the message will invalidate the signature, the message has become tamper-proof.  You simply reject any messages that don't have a valid signature, so any messages that aren't rejected are known to have come from the signing key without changes.


That will generally leave a trail.

Also, we have CRLs and OCSP to help us keep track of which certificates are no longer valid, despite having a trusted signature.  CRL is a batched process that involves just downloading the current list from time to time (this is technically communication with the CA, but not of the sort that gets anyone riled up).  OCSP requires communication with the CA, but this can be done by the server instead of the client (stapled OCSP), and at no time involves sending message details to anyone (the protocol allows enough data to identify the certificate, only).


Well, SSL certainly has weaknesses, but in general, SSL really does allow secure (private) communication.  But it turns out that PKI is really, really hard.  Corporate proxies can use wildcard certificates (signed by actual CAs in some cases) to actively MITM all SSL connections passing through.  Governments can do the same thing, and some have speculated that they might use (or have used) their power to, ahem, request that CAs sign bogus certs that look perfectly correct.  If you run into a situation like that, or if you are merely careless and fail to notice that you've been hijacked by a null-suffix certificate, you can end up having a totally secure communication with an attacker instead of whoever you thought you were talking to.

This comes up a lot in debates about how browsers should handle self signed certificates.  How does a user know that a certificate that has been presented is the right one unless a CA has signed it?  Unless the fingerprint has been sent out of band, and then actually checked, they have no way to know.  See here.