Yes, there are lots of simple things we could do to make script processing stateful.  The hard part is going to be convincing everyone that stateful scripts are a good thing.  That is going to be rough going, since pretty much everyone prefers stateless.

This particular scheme doesn't actually add any security at all, and could actually cause people to lose coins.  It is actually an argument against state, not for.

Nope.  The script system is extremely limited in inputs.  It doesn't know anything about the output (or much else, for that matter).

There is no mechanism to restrict what address you can send to, and such a "feature" will almost certainly never be added.  Note that this would require a protocol change.  You could modify your client easily enough, but that doesn't really help you at all.

Even if such a thing were made, and the network was willing to enforce it, it would just move the problem to the recipient wallet.

The design of p2pool actually makes it impossible for you to get less than your fair share, over an infinite timeframe.  Your variance will grow as your hashrate shrinks in relation to the rest of the pool, but the sum will always work out.

The short answer is no.

The address encoding scheme includes a version byte which forces the first byte to take on a specific value (or one of two values, depending on the byte).  For it to be a bitcoin address, it must be 0 or 5, giving a leading character of 1 or 3.

See here, but note that the list is both incomplete (in the sense that there are many other address systems not listed, and new ones showing up every day), and far too long (in the sense that only a couple of them are actually valid for bitcoin).

As to the length, there isn't much to be done there.  The length is fixed by the size of the hash and the encoding system.  Some hashes lead to (very slightly) shorter addresses.  Key compression does not help here (because the hash of the compressed key is used, and that hash is the same size as the hash of the uncompressed key).

There are other schemes that are capable of generating short-ish addresses.  See Casascius's mini format, for an eample.

No, the payment details are needed for verification.

You sign by putting (private key, message) into the signing function, and you get back a signature.  You verify by putting (public key, signature, message) into the verification function, and you get back a boolean.

Inside both of those functions, the message is hashed, and the hash is used internally.*

The idea is that the merchant can say "I will ship item X to you, if Y bitcoins show up at address Z".  They then sign that message (which involves hashing the message and then, ahem, "multiplying"** the hash by their private key) and then they send you (public key [in certificate form], signature, message).

You then stuff (public key, signature, message) into the verification function, and it will hash the message, then "multiply" the message hash by the public key, and then check to see if the product it calculated bears the proper relationship to the signature**.  It then returns TRUE or FALSE.

At this point, if the verification returned TRUE, you know with certainty that the message in question was signed by the private key that corresponds to the public key you are looking at.

Note that you explicitly do not know who signed the message yet.  This is where PKI comes in.  I wrote a longer post about PKI earlier, and I won't rehash it all.  But basically, you repeat the signature verification process, but this time the message to be checked is the certificate presented by the merchant, and the public key used for verification is from a certificate provided by someone that you explicitly (or implicitly) trust to only sign certificates that bear verifiable contact information tying the certificate to a real world entity (someone you can sue, basically).

When that is done, you now know that the message was actually signed by a real world entity which has been validated by the CA that you trust for such things.  The last step is to compare the entity information from the certificate against the entity information you were expecting to deal with.  Without this step, an attacker could potentially get a perfectly valid and verified certificate for "Bob's Malware Farm, LLC." and present it to you after hijacking your attempt to log in to your bank's website.  Hopefully, you'll notice that the certificate presented wasn't the "Global Megabank Savings and Theft" certificate that you were expecting and you won't give the attacker your account info.

* The hash function forces the input to the actual signing function to be a known size, which is very useful to the signing function.  Hash functions aren't perfect, but the structure of the message makes it impossible to find working pre-images.  This is a subtle point, but all of our structured signatures would remain safe, even if the hashing function in the signing function were found to be generally insecure. 

** I'm doing a lot of handwaving here.  The signing function isn't really multiply, and I'm not going into detail on how signatures are verified in reality.  This is something you can look up if you want to, for the purposes of this discussion, we can just assume that these functions exist and work correctly.

On the other hand, I'm not aware of any "secure" chips that have stood up to inspection by FIB.  Search for Tarnovsky on youtube for details.  All "security features" so far are annoyances and speedbumps rather than roadblocks.

I'm not sure if a move to the main die will help or not.  I think that amateurs are mostly working on small run, old fab, large feature chips.  Does anyone know for sure that Intel-sized features are fundamentally beyond the reach of a FIB?

Totally agreed that the real threat will be on the software side though.  For one thing, good system design should be able to prevent "Break Once, Run Everywhere" attacks, so the theoretical capability to extract keys from a TPM isn't a big deal, particularly not for distributed/networked agents.

I'm not sure about the main client, but here is some ghetto PHP code that works.  I've used it to create a bunch of multisig p2sh addresses.

Satoshi is exactly right about alternate implementations.  They are hard to do right, and can cause a hell of a mess when done wrong.

But, it comes down to which of the two bad options do we like least.  Virtually no one currently active on the project wants a monoculture.  We are willing to take on the challenges and risks of multiple implementations because we feel that the risks of having just a single client are even worse.

Perhaps he'll turn out to have been right about this too, in the long run.  We should be able to answer that question fairly well in another 10 or 20 years.

By definition, the https certificate and private key must be on the front line.  Keeping that private key secure is a gigantic pain in the ass, and pretty much no one bothers doing it right.  They are pretty much disposable.

The invoice key, however, can sit safely on a hardened back end box, well insulated from the outside world.  Depending on the implementation, you can also store it encrypted with the encryption key stored only in non-swapped memory.  (You can do the encryption thing on a webserver too, but no one ever does.*  Think load balancers and cloud servers starting up without human intervention.)

So, while the two offer little difference in security, it is still a "best practice" to do things right, when possible.

* For certain values of "no one".  I used to work in a datacenter, and one of our customers had their webserver configured for security.  We had to physically key in the decryption key for the certificate's private key every time the server rebooted.  Everyone hated that box, I think including the customer.

My GPUs are still running strong.  They find a share every few days and earn a little dust.

No, in DSA systems, the signature is verified with the public key, but created with the private key.  This way, only the private key holder can create a signature, but anyone can verify it.  The certificate is a jumble of stuff, but at heart it is a carrier for the public key and information related to the public key.

This is really the whole point of digital signatures, and the reason why DSA is always done with public key cryptosystems.


I'd like to point out that this is not an expert level discussion, not even close.  This is basic stuff, "Introduction to Cryptography 101" level.  In short, this is stuff that you should already know to participate in discussions in Dev & Tech.

I don't say that to be insulting.  I don't want to drive anyone away.  I don't want to discourage anyone from learning.  I don't want to prevent anyone from contributing to the conversation.  Quite the opposite on all counts, actually.  I have very little time to devote to bitcoin, but most of the time that I do have is spent helping and teaching others, at the expense of time I'd rather be spending on my own projects.

But if someone comes in here and their understanding is not sufficient to making meaningful contributions, they really should spend a lot of time reading silently, or asking very polite questions and reading the answers with great care.  What they should not be doing is repeating nonsense they heard elsewhere or arguing with the dismissive answers they get when they do.

Now let me explain why I'm so hostile to piotr_n.  For the last year or two, there has been a deluge of FUD.  Virtually all changes that have come to public discussion have come under relentless attack, typically by people "asking questions" and spreading misinformation.  Piotr is a good example of this.  Go read his post history and you'll find a fairly complete catalog of recent changes to the bitcoin system.  He is opposed to every single one of them, he thinks that Gavin is the puppet of the Illuminati, and when pressed, he doesn't know a fucking thing about anything he's ever talked about.

But he isn't alone.  Dozens of him have come and gone.  I don't like to assume malice while incompetence is still a viable option, but after a while even the least paranoid among us starts to wonder exactly who wants to undermine the development team and process, and why.

So, again, I apologize to anyone* that has ever been dismissed or answered less than politely.  But no one here is here to educate you, particularly not about the basics, and if you show up saying the sorts of crap that we've been dealing with nonstop for the last year or so, the odds really aren't in your favor.

* With a few exceptions.

If you go ask a cardiac surgeon to explain how a multiple bypass surgery works, and every time he starts to answer you interrupt him by asking how that step helps to balance the humors, or some other pseudomedical nonsense, he's pretty likely to quickly become exasperated.  If you are the twelfth guy this week to pull that stunt, he may not be entirely polite when he tells you to come back when you have a better grasp on medicine.

I'm sorry that the devs didn't have time to spoonfeed "How the Internet Works, Volume 7: SSL" to you.  But this is the age of Google.  It is within your own capability to educate yourself enough to ask meaningful questions.

The point of the signature itself is that it is now impossible to change the signed data without invalidating the signature.  Things that are important need to be included in the signed portion.  It would be pointless to sign a transaction request message that didn't include the Request Details in the signature, as the details could then be changed by anyone, at any time.

The certificate, and the CA's signature on the certificate, is to connect that certificate (and by extension, signatures made by the corresponding private key) with a real world identity.  In theory, the CA will not sign any random certificate they see, but will only sign the ones that appear to come from the entity named in the certificate.

Anyone can be a CA and sign whatever certificates we want.  But no one will trust your CA's signatures (and by extension, the certificates signed by you) unless you are a serious organization committed to only signing valid certificates.  The nominal reason why browser vendors charge thousands of dollars for including a certificate in their browser is because the browser vendor needs to audit (or hire an audit of) the alleged CA's policies and practices to ensure that certs signed by the CA will be trustworthy.

Ahh.  The problem then is that you don't know how SSL PKI works.

The CA generates a private key, and a matching public key.  The pubkey is packaged into a certificate, which is then signed by the privkey (which is funny, because it is a self-signature, but it still provides some assurances).  They then publish that certificate.

The merchant generates their own private key and the matching pubkey.  They package that into a certificate with some identifying information, which is sent to the CA.  The CA signs the merchant certificate with their private key and sends it back.

The merchant then generates a payment request, hashes it, and signs the hash with their private key.

You get the request, the signature and the certificate.  Your software verifies that the attached certificate does indeed correspond to the signature.

To verify that the certificate you are looking at does indeed belong to the vendor you think it belongs to, your client checks that the certificate it received has been signed by a trusted CA.  In this simple example, the CA's published pubkey has been included in the client through some out-of-band mechanism (hardcoded into the source maybe).

You will notice that at no time during your transaction is anything sent to the CA.  The CA isn't signing your specific message, they already signed the merchant's certificate, and the merchant's private key is used to sign the request.

There are two wrinkles that can be added to the simple example.  The first is when the CA doesn't sign your certificate directly.  In that case, the merchant sends a certificate chain.  Your client then follows the chain backwards, making sure that the merchant's cert has been signed by X, and that X was signed by Y, and so on until certificate Z was signed by the CA.

The second is OCSP.  In OCSP, your client can look in the merchant certificate for a field specifying the OCSP server.  Your client can then ask the OCSP server if the certificate it is looking at is still valid.  If the certificate was signed in error, or if the private key for it was stolen from a compromised server, you can find that out in real time using OCSP, and potentially reject the transaction despite having valid signatures.

(There is also a variation of OCSP called OCSP stapling where the server, rather than the client, requests proof of validity from the OCSP server and attaches it to the certificate.  This is better for privacy, since your client doesn't then need to tell the CA that someone from IP address X is checking on the certificate issued to Y.  OCSP already has a timestamp and a validity window, and are signed, so it doesn't really matter who asks for it or which servers it passes through in transit.)

I've read your posts several times, and I still can't figure out why you think that anything is being sent to the CA.  Digital signing involves hashing the message, and OCSP involves sending the hash of the certificate issuer's DN and pubkey, but it doesn't follow that OCSP is going to throw every hash it sees into the OCSPrequest.

Links?  I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.

Go educate yourself.

Even better, according to Gavin on IRC just now, OCSP is not currently scheduled for implementation.  So, just to be absolutely clear to anyone reading this thread, at this time, there will be absolutely zero communication with any CA done by the bitcoind client.

At some point, some form of OCSP probably will be implemented, because it is a very useful security feature.  When that time comes, everything I said above about OCSP not leaking the transaction details will still apply, and several billion people will have the opportunity to verify on their own that the code isn't doing anything sneaky.

You know, if you would just learn to use google, you'd make a hell of a lot less incoherent emo posts, and probably do a fair bit less cutting.

Please read the RFCs for OCSP (2560, 5019, etc).  OCSP involves asking the OCSP server for the current revocation status of the certificate.  There is no provision for sending your transaction to the OCSP server for tracking.  Very close to 100% of OCSP traffic is used for validating SSL certs.  If it was leaking data, it would have already leaked all of your SSL session keys (since 1999!).

If OCSP is enabled in bitcoind, the OCSP server might be able to figure out that you are looking at a signed payment request from entity X, which they probably already knew because your browser checked the exact same certificate a few seconds earlier.

It is entirely possible that I'm being unfair in my estimation that you are a giant fucking troll*, in which case I would owe you an apology.  But you are clearly aware of the existence of OCSP (since your questions make no sense in any other context), but you have either intentionally refused to educate yourself about it, or you know perfectly well what it does and does not do, but want to spread misinformation.

* Not like we don't all know about you from your insane rants in other threads.

Just FYI, most bitcoins that exist are not currently available for sale on any market.

If you pumped enough money in, you could clear most of the sell orders in one shot.  That would push the price up and lure more coins in, but the second round would be more expensive, etc.  The result would probably be a few hundred thousand coins, and the market price would probably end up north of $1000 per BTC.