How expensive do you think it would be for the United States National Security Agency (or a comparable organization from another national government) to crack a Bitcoin store, given that we know that some Bitcoin caches have already been cracked?
This would be a reasonable 1~2 weeks project for a pentester with less than one year of professional experience, so I'd put a rough upper bound on that at $20k. i.e. it is trivially within the capability of governments, organized crime, and any intermediate Rails programmer who wants a fun side project.
If you 10X the numbers I would not bet against the outcome "Achieve a systemic compromise of the bitcoin client." (Bitcoin, by design, fans transactions out to every client on the network. The transactions contain executable instructions in a language which is interpreted by C code. Do I need to paint a very detailed picture of the risk here?)
It's a simple sequence of opcodes: https://en.bitcoin.it/wiki/Script The code has been thoroughly audited by many people with substantial experience. Finding an important flaw in Bitcoin would be a major feather in any Whitehat's cap, and a major skull on the mantle for any blackhat.
Script adds extreme flexibility to Bitcoin, allowing the complete decentralization of services which would otherwise require trusted servers like escrow. It is statically validated and purposefully not turing complete. For extra conservativeness scripts not matching a set of standard forms are ignored by the unmodified reference software until transactions show up in blocks.
This is important because its what makes it possible to build other safe distributed transaction systems on top of Bitcoin... it's also what will allow Bitcoin to backwards compatibly upgrade its signing primitives if ECDSA begins looking weak.
You're no doubt aware that HTTP servers routinely did buffer overflows leading to arbitrary code execution early in the development of the Internet, and it is only years of work by thousands of people which makes them safe to use currently, right? HTTP servers are also diverse, old/battle-tested, and do not fan out every HTTP request to every HTTP server. Bitcoin is theoretically a protocol but in practice is a client monoculture (so much so that a bug in a point release of the official client forked the transaction chain), has probably less development hours total than Apache has spent on auditing parsing HTTP headers alone, and does fan out every transaction to every node on the network.
Transactions most certainly do not "contain executable instructions".
We're now arguing about the definition of the word "is."
Not even an hour ago you were claiming how the embedded scripting language added extreme flexibility to Bitcoin implementations. Having thought that through, you now claim the very same embedded scripting language is so crippled it, come to think of it, might not even count as executable instructions at all.
The technical reality of Bitcoin has not changed in the past hour. It still allows transactions to include arbitrary content. They still embed executable code. They are still executed, by design, network-wide on an implementation monoculture.
To paraphrase a tptacek comment: I hope to make the starburst of points which immediately follow this by implication as opposed to having to state them explicitly.
I'm not contradicting myself: In the same comment I wrote "It is statically validated and purposefully not turing complete".
There is no contradiction between between being very limited and also allowing extreme flexibility. I don't think many people here would agree that CSS is "executable code", and yet CSS is turing complete and substantially more complicated than Bitcoin's script. This is why I said it depends on what you mean by "executable code". There is nothing that is jumped to, no looping, the processor never jumps to and runs anything fed in off the network, etc. Just a simple set of operations for manipulating a stack and doing comparisons. But, even though the implementation is simple the results are powerful.
There are several implementations of script evaluation— I can think of at least 6— now though the reference is by far the norm on full nodes.
Comments
How expensive do you think it would be for the United States National Security Agency (or a comparable organization from another national government) to crack a Bitcoin store, given that we know that some Bitcoin caches have already been cracked?
This would be a reasonable 1~2 weeks project for a pentester with less than one year of professional experience, so I'd put a rough upper bound on that at $20k. i.e. it is trivially within the capability of governments, organized crime, and any intermediate Rails programmer who wants a fun side project.
If you 10X the numbers I would not bet against the outcome "Achieve a systemic compromise of the bitcoin client." (Bitcoin, by design, fans transactions out to every client on the network. The transactions contain executable instructions in a language which is interpreted by C code. Do I need to paint a very detailed picture of the risk here?)
It's a simple sequence of opcodes: https://en.bitcoin.it/wiki/Script The code has been thoroughly audited by many people with substantial experience. Finding an important flaw in Bitcoin would be a major feather in any Whitehat's cap, and a major skull on the mantle for any blackhat.
Script adds extreme flexibility to Bitcoin, allowing the complete decentralization of services which would otherwise require trusted servers like escrow. It is statically validated and purposefully not turing complete. For extra conservativeness scripts not matching a set of standard forms are ignored by the unmodified reference software until transactions show up in blocks.
This is important because its what makes it possible to build other safe distributed transaction systems on top of Bitcoin... it's also what will allow Bitcoin to backwards compatibly upgrade its signing primitives if ECDSA begins looking weak.
> If you 10X the numbers I would not bet against the outcome "Achieve a systemic compromise of the bitcoin client."
Does that mean you'll take the other side of that bet?
> I'd put a rough upper bound on that at $20k
Um, what? There are public addresses with thousands of Bitcoins. Why aren't they getting looted?
Bitcoin consuming web applications, such as stores/exchanges, are routinely being looted.
you were implying that arbitrary public addresses could be cracked with a 20k budget, and i am saying that it is not the case.
[deleted]
You're no doubt aware that HTTP servers routinely did buffer overflows leading to arbitrary code execution early in the development of the Internet, and it is only years of work by thousands of people which makes them safe to use currently, right? HTTP servers are also diverse, old/battle-tested, and do not fan out every HTTP request to every HTTP server. Bitcoin is theoretically a protocol but in practice is a client monoculture (so much so that a bug in a point release of the official client forked the transaction chain), has probably less development hours total than Apache has spent on auditing parsing HTTP headers alone, and does fan out every transaction to every node on the network.
Transactions most certainly do not "contain executable instructions".
This is contrary to technical fact. https://en.bitcoin.it/wiki/Script
It depends on how you're defining "executable instructions".
There is a small set of operators and a single conditional. No looping, etc. It's strictly less powerful than CSS, for example.
The implementation is a very simple loop over a switch with a simple 'stack'. The size of a script has a hard maximum of 10kbytes.
We're now arguing about the definition of the word "is."
Not even an hour ago you were claiming how the embedded scripting language added extreme flexibility to Bitcoin implementations. Having thought that through, you now claim the very same embedded scripting language is so crippled it, come to think of it, might not even count as executable instructions at all.
The technical reality of Bitcoin has not changed in the past hour. It still allows transactions to include arbitrary content. They still embed executable code. They are still executed, by design, network-wide on an implementation monoculture.
To paraphrase a tptacek comment: I hope to make the starburst of points which immediately follow this by implication as opposed to having to state them explicitly.
I'm not contradicting myself: In the same comment I wrote "It is statically validated and purposefully not turing complete".
There is no contradiction between between being very limited and also allowing extreme flexibility. I don't think many people here would agree that CSS is "executable code", and yet CSS is turing complete and substantially more complicated than Bitcoin's script. This is why I said it depends on what you mean by "executable code". There is nothing that is jumped to, no looping, the processor never jumps to and runs anything fed in off the network, etc. Just a simple set of operations for manipulating a stack and doing comparisons. But, even though the implementation is simple the results are powerful.
There are several implementations of script evaluation— I can think of at least 6— now though the reference is by far the norm on full nodes.