So here's how I read it. 

Guy A trashes the apartment.
Guy B says "you gotta pay for that"
Guy A says "I'm broke cause I used my money to buy weed"
Guy B says "you're not broke, you've got all that Bitcoin crap."
Guy A says "I'm holding on to that."
Guy B says "You gotta sell it and pay for the repairs."

... and it escalates from there. 

Of course it could also start with guy B wanting to buy drugs or something with Guy A's money.

We don't know what went on just from the article.

The problem is that we are using the current version of SSL (whatever's on the system/linked) to check the validity of blocks that were accepted with past versions of SSL.  

This is why the makefile for bitcoind specified static linking in the first place.

I am ... upset.  We should be using current versions of SSL for communications, because SSL gets valuable security upgrades.  But we should be using it for protocol only, because checking past blocks with a version that was not the version which governed their acceptance  risks exactly this sort of divergence.  Our need for SSL as a communications protocol does not affect the validity of data already transmitted.  

SSL will continue to change, and those changes cannot be allowed to affect data already transmitted and received, nor our software's opinion about whether that already-accepted data is valid.  Neither our stored blockchain data nor our ability to check our stored data should have anything to do with it.

Our need for cryptographic functions once a block is accepted are different, and absolutely NOT subject to revision.  That is, whatever's required to CHECK blockchain validity absolutely must not be something that can be altered by any change in a system library.  

I presume that SSL will continue to "tighten" its spec - that is, whatever is acceptable to future versions will also be acceptable to past versions. Therefore using routines from a three-year-old version of SSL to check data transmitted and received using the current version of SSL ought never fail, and using the current version for communications should get us the benefit of security fixes.  Updated routines can be compiled into the client NO SOONER THAN they are known to work with the entire current blockchain.


Cryddit

Because the Babylonians counted in base 60.  No joke.  They were there first in astronomy, and they divided the heavens with units denominated in base-60. 

For them, this *WAS* the metric system.

You're talking about things that protect against semantic mistakes, which are good.  But cryptographic code has requirements that are not considered in semantic models; we have to avoid creating information leaks.

I'm in favor of using more advanced languages, if we can find an implementation of them that promises to do no copying, no relocating variables, never allocates its own buffers over areas that might still contain private values, doesn't "optimize away" writes to variables when future values don't mean anything or at least lets us order it not to, lets us know when register spills write things to memory, etc. 

I really LIKE nice languages that have good protections against semantic mistakes, and use them for nearly every non-crypto project.  But I have never found a language that both has good protections against semantic mistakes of the kind you're talking about *AND* sufficient control over low-level side channel leaks that it can be used for crypto code. 

If I have to do without one or the other, I'll do without the one that I can at least possibly make up for with sufficient care and testing.

In other news, someone has sent me a private message with a link I'd like to share with y'all:  It turns out we're not the first people to have this conversation.

https://cryptocoding.net/index.php/Coding_rules

Good point.  The filesystem standard says /usr/local is for stuff installed on the machine that isn't part of the "standard equipment" for the system, and in this case that's true of the bitcoin stuff because it's not known to the package management system. 

I put it under /usr because I was unthinkingly re-creating the system as it would have been had it been properly installed from a .deb package in the standard distribution.

Heh.  I have actually had a manager come to me with push-back on code I wrote because it could not reach 100% coverage.  On investigation it turned out that the code the fuzz tester could not reach was pretty uniformly of the type,

IE, it was code the fuzz tester *SHOULDN'T* ever be able to reach.  Eventually we settled for modifying the DEBUGPRINT macro to have #ifdef DEBUG blocks, so he could get his 100% coverage on the production build but I could still have it write a message and crash instantly on detecting an error in the debug build.

By the way, "Write a message and crash instantly" is, by far, the easiest thing to debug.  Throwing exceptions that get handled far from detecting the error is NEVER a good idea.

It's signed to make it easier to check for the results of a subtraction being less than zero. 

Today I built bitcoin (from sid sources) on my desktop box which runs on Debian "Jessie".  

I wrote a blog post that lists, and explains, all the commands needed, in order.  

Comments are welcome.  So is criticism, as long as it comes with a good suggestion as to making the instructions clearer.

http://dillingers.com/blog/2014/12/02/a-short-guide-to-building-bitcoind-and-bitcoin-qt-on-debian-jessie/

It occurs to me that the craft of designing and writing cryptographc software so that it doesn't leak sensitive information is, at best, a
black art, and most of the necessary techniques aren't widely known, documented, or shared.

I bet there are a thousand tips and tricks that most of us have never written down because they are grotty details that aren't very
interesting mathematically.  I would love to hear the coding techniques that others have developed to control side channels and write software that is both reliable and doesn't leak information.

Here are a few of mine.

First, I write unit tests for everything.  Often even before writing the things.  It's astonishing how often crypto code can look like it's
doing the right thing while it's actually doing something very subtly different that you'd probably never notice was different. Like having the wrong period for your implementation of some LFSG-based thing like the Mersenne Twister - get it wrong by one bit, and the output still looks good, but it'll be insecure and have a period way shorter than you expected, giving your software  an exploitable bug.  Or checking for certificate revocation, then accepting a certificate that's been revoked anyway.

Or getting encrypt-decrypt that reproduces the plaintext, but doesn't produce the same output on test vectors as the standard implementation you're trying to be compatible with (and if it's not producing the same output, very likely that's the standard implementation that's more secure than yours....)  Or finding the key server unavailable and then falling back to accepting a certificate without displaying the error it was supposed to display about not knowing whether the certificate is good.  Anyway, write lots of unit tests.  Not only will they make sure you know what your routines are doing, they'll also tell you when you break something.

The debug build calls the unit tests, and they  write a file of test results. The test results file, rather than the executable, is the usual
makefile target, and the makefile instructions for building test results end with 'cat results.txt' which appends the test result output (ie, a blank line followed by listings of any unit test errors) directly to the compile output, just like any other errors that need fixing.

If I get any choice about it, I try to do all the crypto in a single-threaded, dedicated executable that does very little else.  It's
much easier to analyze and debug a single-threaded application.

Know your compiler options.  Use the diagnostic and standard-enforcing ones heavily.  Use those that enable security extensions peculiar to that particular compiler if it helps (such as stack canaries or an option to zero all memory allocated to your program on exit)  but do your best to write code that does not rely for its security solely on those extensions, because sooner or later someone will need to compile it on a different compiler.  Eschew any standard-breaking extensions that won't work (especially if they will also cause errors) in different environments.

I write in C using the standard libraries and the GMP bignum library. GMP has some not-very-widely known primitives that are specifically for cryptographic use and leave nothing on the stack  or in buffers. They're a little slower than the "normal" set of calls, but that's okay. The C standard libraries can mostly be trusted to do exactly what they say and nothing more.  This is kind of a shame because other languages have nice facilities, less "undefined" behavior, and considerably more protection from programmer mistakes, but there is no way to get around it because AFAIK no other language allows me to absolutely control when and whether copies are made, when and whether writes to variables actually happen, etc, as well. Which isn't high praise for C, because it's still hard and grotty and error prone.  But at least it's possible.

The runtimes, templates, and libraries that come with most languages (and here I include C++) can be trusted to do what they say, but without going over a million lines of difficult, heavily #ifdef'd template code with a fine toothed comb I can't trust that they do nothing more. Therefore I don't know how to write secure software in those languages and be certain that it won't leak information. They accomplish their semantic goals well, but do so while leaving copies, and fragments of copies, of everything they touch in their objects, in unused areas of their allocated buffers until those buffers are actually used for something else, and on the stack.

A lot of crypto software makes extensive use of global variables for sensitive values.  They are fast, never get deallocated or (accidentally) copied during runtime, new values always overwrite previous values instead of landing at new places in memory possibly leaving copies of the old values somewhere, and they avoid indirections that might leave pointers to them lying around.  The only thing even a little bit subtle is making sure that they get erased as soon as the program doesn't need them anymore, and again before the program exits, and that's not hard. A pattern emerges with a dedicated 'eraser' routine that sets them all to bytes read from /dev/random before program exit. The read from /dev/random can't be elided by the compiler because it is a system-level side effect.  But if you read from /dev/random into a buffer and then copy from the buffer to the sensitive variables, the compiler can elide that because those are writes to dead variables. What's necessary is to read bytes from /dev/random *directly* into the global variables, one at a time if necessary.  It helps if you define a singleton record type that holds them all; that way you can just overwrite the record instead of doing one at a time.

That pattern is fine for globals that you clear once or twice per program run and again on program exit, but I/O, even from /dev/random, is too slow for using on return from every subroutine that handles sensitive variables. I kind of don't like using global variables. I don't like the idea that every part of the program has access to them. But I have certainly used them.

C also gives you variables with 'file' scope, which is another way to have something that you can't deallocate or lose track of and allows you to limit access to the sensitive variables to JUST the routines defined in one file.  That's probably a better pattern than globals.

I use the 'volatile' keyword a lot, to designate local variables so that writes to those variables will never be skipped, even if writing to them is the last thing that happens before the procedure they're allocated in returns. I know of no other language besides C that allows that. 'volatile' allows me to easily use local variables and avoid leaving anything sensitive on the stack, but do not use it for anything that's not sensitive.  For example if you use a volatile variable to index a loop, the loop will run slow because the code has to write that variable to cache every iteration rather than just mapping it to a register. It's better to just have a regular auto variable that you use for that.

A very good solution to the problem is to allocate a large 'security' buffer as a local variable in main(), and have the program manage its own stack for sensitive variables.  The way that works is that when main() calls anything, it gives it a pointer into the security buffer, and the size of the buffer. A called routine checks that the buffer is large enough and uses as much of the buffer as it needs for its own sensitive locals by casting the pointer at the buffer into a pointer at a record type that contains its sensitive locals.  If it calls anything else that has sensitive local variables, it does so with a pointer just past the end of its record, and the size it got for the security buffer minus the size of its own sensitive-locals record.   As with globals, before program exit you call an 'eraser' that overwrites the entire buffer with bytes from /dev/random.

The benefit of this is that main() retains control of the buffer.  It doesn't make the system slower the way 'volatile' does.  And if multiple routines both read and write in the buffer, the compiler can never elide writes into it - so the routines can easily and reliably clear any sensitive vars that they *aren't* passing back to their caller before they return.  It's probably safer than using 'volatile' local variables, because it's possible to forget to clear a sensitive 'volatile' before returning but it is NEVER possible to forget to clear the security buffer before exiting - that would definitely break your unit tests. The downside of this is that handling the buffer tends to be a pain in the @$$, which is why I tend to use 'volatile' instead.  I do use a designated buffer for VERY sensitive variables, such as passwords. Absolutely no routine, anywhere, gets to make its own copy of a password that lives outside the buffer, and main() writes over that as soon as the key is set up.

I've seen crypto software where sensitive locals were allocated using the 'static' keyword to ensure that local variables with sensitive
information are not deallocated when the function returns.  This prevents leaks during runtime, and with static variables, the compiler can't USUALLY elide writes, so the called subroutine can usually clear the values of its sensitive locals before returning. But it's  not a technique I trust, because compilers are ALLOWED to elide final writes to static variables if it can prove that the initial values of the static variables don't matter to the routine whose scope they're in, and static locals are strictly worse than globals for leak prevention because main() has no way to overwrite all those before it exits. Every one of them gets released when the program exits, and you just don't know what's going to be the next program to allocate the block of memory where they were contained.

I always use unsigned integers.  In fact this is something I learned rather recently, due to an issue raised on the cryptography list.  The basic mathematical operators (addition, subtraction, multiplication) can overflow, and overflow on signed integers (with the usual wraparound semantics that can give a negative result of adding two positive numbers) is undefined behavior.  If you must use signed integers and check afterward for overflow/wraparound, you must add them as though they were unsigned integers, like this:

(unsigned int)z = (unsigned int)x + (unsigned int)y;

because overflow on unsigned integers *is* defined behavior.

You can't even check to see if undefined behavior has happened, because the compiler will go, "oh, that couldn't happen except for undefined behavior, and I can do whatever I want with undefined behavior.  I want to ignore it."

It will then cut the checks and everything that depends on them out of your program as 'dead code'.  So you can have an integer that is in fact negative because of a wraparound that occurred while adding two positive numbers, and the program will jump straight past a check for a negative value without triggering it.

Crypto coding has taught me to use a few other unusual bits of coding style. In crypto, we tend to allocate buffers, permutations, etc that are 'round' numbers like 0x100 bytes or 0x10000 16-bit values.  Because we're using unsigned integers anyway, indexing into these buffers using uint8_t or uint16_t variables gives us an automatic range safety check.  But it is hard to write 'for' loops that exit if we're iterating over the whole buffer, so instead of 'for' loops I tend to use do/while loops.  If I want to do something like initializing a permutation with every value of a uint16_t for example, my usual idiom is to write something like

count = 0; do {
  permutation[count] = count;
}while (++count != 0);

This is also an example of a habit that suits me when in full-on paranoia mode to never leave any local variable (such as count) with a nonzero value if I can help it, whether *I* think that variable is sensitive or not. If I leave something with a nonzero value on routine exit, I try to leave the same constant value in it on every exit.

So that's a few bits about writing non-leaking crypto code.  I've been more concerned with preventing memory-based data leaks, obviously, than controlling other side channels like timing or power use.

Would anybody else here like to share some of the techniques they use?

The problem with that is that it's a one-way peg.  Energy has been converted into Bitcoin, but bitcoin can't be converted back into energy.  Therefore people with bitcoin holdings cannot sell the energy back on the open market if this bitcoin thing doesn't work out.

So, yeah, it's based on energy consumed.  But energy once it has been consumed (and can't be consumed again) has no market value.

No fair citing a study carried out on people who were victims of malnutrition during formative years and mostly have no education to teach them how to take such tests.

Stay far far far away from Paypal or any other organization that has a well-publicized, enforced policy of forbidding and reversing bitcoin trades.  They will hand money back to people because you specifically did what their terms of service forbade you to do when you used them to trade for bitcoin.

This isn't a security "risk".  This is their security, working as designed. 

True so far.  Probably not true for very many decades more.  This is either terrifying or reassuring, depending on your degree of pessimism.

Eh.  The world is big enough to hold people who disagree with me.  That's okay.

Even good things can be taken too far when you take them as absolutes.  I don't like it when individual people get less than they create, but I'll tolerate some of that if it means that people as a whole manage to create more.  I don't like it when the current generation gets less than they create, but I'll tolerate it if the alternative is impoverishing the next generation.

So, yes, I believe in taking some of what people produce (including what I produce) and plowing it into education and infrastructure so that most, rather than just a tiny few, of the next generation, the poor, and etc,  can become better-trained productive people who  produce more.  Woo, basic economics.   Yes, that means I sacrifice to some extent for benefits that won't show up in my own generation. I'm okay with that.  yes, that means some of my money will go to poor people who *won't* become productive, because there's no way to tell in advance which will and won't.  I'm okay with that too; historically the odds favor the strategy in the long run.   Got a college bond?  Here, take my tax money.  Supporting families so people have *time* to go to school instead of needing to be in some near-slavery job from dawn to dusk just to survive?  Yeah, that's part of it too.  

I also believe that if the cheapest way to keep people from doing desperate things such as ripping down your power lines to sell the copper on the black market is to give them welfare, (where the alternatives are expensive things like tripling the number of police and quintupling the prison populations) then the right thing to do is give them welfare - cheaper for the people paying, less disruptive to production, more dignified for everyone, and leaves more possibilities of more people finding better ways to make a living.  Does it mean taxing the people who own the power lines (and the factories that need power, et al)?  Yes, yes it does.  But -- and this is the important point -- they're getting their money's worth.  If every other solution would be more expensive for them or make them less productive, then paying the taxes is the right thing for them to do.  

Taxation is one of those burdens where we do better - ie, we have a competitive advantage - if we can pay less than our neighbors.  But if, as a whole, *EVERYBODY* doesn't pay enough, then all of us lose the benefits of living in civilization.  That doesn't even leave anybody with enough power to enforce those contracts that the Anarcho-Capitalists would prefer were the whole of the law, let alone providing for the productivity and infrastructure needed by a next generation.  

If one is wealthy enough to be an employer, wages are the same sort of expense; we can realize a competitive advantage if we pay less than other employers, but if *ALL* the employers pay too much less, then nobody has enough money to buy the goods we're employing people to create. Also, in the long run there won't be enough people with the training we need to fill our most productive jobs.  The benefit of wages paid go to the employers who produce the goods people buy, and the benefit of education paid for goes as much to the eventual employer as the student.  So in the long run employers get their moneys worth for paying people enough to buy goods and get an education, even when they can't 'capture' all the money they personally pay out.  The point is that all employers are better off if most people do have enough money to buy their produced goods and most of the kids can afford to get an education.  This is true even if *individually* they'd be better off if they could be the one employer who doesn't pay wages that allow that while all the other employers do.  

There is absolutely no idealism involved in Chinese minimum wage laws.

The Chinese government mandates a minimum wage solely because it is clear that if they leave the employers to pay whatever the labor market will bear in the short run, there will be bloody revolution as it turns out to be less than the labor market will bear in the long run.   The same is true in the US; we're just a bit further away from it for the moment.

People in the San Francisco area who would like to meet in person and buy or sell bitcoins for actual cash can PM me. 

Yeah, this is something I never agreed with the 'pillars of the community' here about; Heck, even Hal thought Ayn Rand was somehow not a psycho.  I'm okay with disagreeing about that.

Let's just say there are limits to how far you want to push any ideology.  If the word 'absolute' appears in your political agenda, whether it's on the left, right, top, or bottom of the political spectrum, I kind of don't want to live wherever you're in charge.

I'm optimistic that we'll find a good way to do things and that a lot of what now seem to be intractable problems of human nature will be diminished by progress just as what had seemed to be intractable problems of human nature have been diminished by progress in the past.  I'm confident that neither absolute Laissez-faire capitalism as espoused by the wealthy elite, nor absolute revolutionary socialism as espoused by the ignorant and oppressed, nor absolute anything else, is the right answer.   

I think we probably need a lot less complexity in our legal system, because the question today is more 'whom do you want to prosecute?' rather than 'who has broken the law?'  Laws so numerous and complex that you must choose which to enforce and in what cases are merely tools for extortion and bribe-seeking rather than a solid basis for a rule of law.  But that would be true no matter in what political direction we wanted to reform our laws.

Laugh.  Yes, that would work for the backstory of a good yarn.  And I might even be able to sell that one.  Maybe I ought to write it, it would promote Bitcoin awareness anyway.

Exercise due caution.  Places that advertise good rates are a bit more common than places that trade them.

For what it's worth, paypal is a massive problem with bitcoin transactions.

The immediate issue is that trade in a non-tangible good (which category includes bitcoin) is against their terms of service.  If they find out your account is being used for bitcoin trades they will shut it down hard.  If they can identify a particular trade that was for bitcoin they will perform a chargeback. 

Seriously, just don't use them for Bitcoin anything.  They don't like it, and they take steps to make sure you won't either.