LOL, no doubt.  And while there have been instances of CAs behaving badly, SSL is still used and generally trusted for transactions and communications of low to moderate importance.

For example: you're using it right now.

The people on this forum are all of the people you know?  Stop strawmanning and think of all the people you know, your parents, your dentist, the grocery checkout clerk.  How many of them have heard of PGP or can describe its proper use?  But they know the "little lock thing" on the browser means things are at least trying to be secure, and commerce may proceed.  Would I use this for transactions valued in the BTC equivalent of millions of dollars?  Probably not-- that sort of thing requires a stronger trust model than SSL achieves.

PGP might be a more "correct" way to approach this, but I'm looking for something that will work right now in the real world, and have real benefits even if it ain't perfect.  If implemented, this will improve the trust and security of almost every Bitcoin merchant transaction.  And for bonus points, it's trivially easy to implement.

I was a huge fan of PGP ten or so years ago, to the point where I gave a presentation on the subject to a local ColdFusion (the programming language) user group meeting.  I sill do conference sessions from time to time about how public key encryption, SSL, and PGP work.  People are always startled to discover that the top of the SSL trust layer isn't at the CA layer, it's the browser manufacturers, who choose which CAs to include.

Unfortunately, my attempts to get my circle of nerd friends to embrace PGP fizzled every time.  Today I see it used pretty much daily for encryption during B2B document exchange, but key signing is nonexistent and the public key exchange is done in a depressingly insecure way.

That being said, it'd be fairly easy to optionally replace "sigdomain" with "sigkey" (or perhaps "sigpgp") and attach a key ID (or perhaps fingerprint, but I'm trying to keep it short) and PGP sig hash instead.  But I'm trying to get an idea off the ground that could work with the whole world today.

For all of the complaints about SSL, and I'll be the first to agree that many are valid, it's still way better than nothing.  And it's time to do better than nothing.

> PGP is a better solution, and can be made sure that a company/person generated the address.

I like PGP as well as the next person, but the SSL trust network is far better established than PGP's, and either of them can verify that a company/person generated the address.

PGP might be a better solution *in theory*, but in practice SSL is actually used by ~100% of people on the Internet.  What percentage of all of the people you know have actually signed or encrypted a message using PGP?

One problem I see with Bitcoin URIs is that it's impossible, as a customer, to prove ex-post-facto that you made a payment (a) to a specific entity or (b) for a specific purpose.  While you may trust that a Bitcoin address/URI belongs to a vendor based on the fact it was presented via SSL on that vendor's page, once you've made payment you have no mechanism to prove that (a) you saw that URI on the vendor's page, (b) you made payment for any specific purpose, or (c) you paid the amount in full.  In short, there's nothing to enforce non-repudiation of a vendor's Bitcoin URI invoice once payment is made.  In other words, it's easy to create an invoice, but how can a customer show a receipt that's provably from the invoice?

It occurs to me that we already have infrastructure in place to address this-- SSL.  (SSL ain't perfect, but it's way better than nothing.)

Since the URI for a Bitcoin payment (BIP 0021) is intended to be extended, I propose this:

The vendor MAY append two (or three*) fields to the end of a URI: "sigdomain", and "sig".  "sigdomain" indicates the DNS name where the SSL public key can be retrieved that verifies the signature of the transaction, and "sig" is the Base-64 encoded SHA1RSA signature of the URI up to and including the "=" sign after "sig".  ("sig" MUST be the last field of the URI.)  If "sig" is used, then "sigdomain" MUST also be included.

Example:

bitcoin:1NYTSZeZ6axJhnR41AfxxB4ks5fEgkjDQ8?sigdomain=darylb.net&sig=b9FUOZOmvlIYAMD6FH4mTw9fipCLi8WSnN9laSg%2BlRagU5EwHe9VFN0NlX1B%2FKKNtcKlbqBel1C4WOh9bH2uibg5eNKBwDXUWenLk%2BT3i5G5iUn0uG5SNtz69zOYAloFRn5E8CAFXElqoBFj24XcU6tgRJuFv7EwFMGiNhenaauHaohB8sYr8HNKqoeLC5zMbG9sB%2FCy%2F8N3Vj7QSFYh4bQt4W%2FJI%2Fai8Fq4E7U%2FEUHR%2BHINb%2FX%2FSwUxXMva6LuDRQq%2FzhhNUFmbtd1ahne%2FF%2FADm8UQMM1LPj%2FZMtbpE6EUEW5%2BVkFYiaK2tOIBauQb%2FbrstOcIkxZgS7VdC3%2BQgw%3D%3D

Or:

This address has been signed using the private key corresponding to the public key that's available by connecting to "https://darylb.net".  The client SHOULD store the public key cert along with the invoice, so that signature verification is replayable even if the server's key is replaced.

Granted, this makes for a rather dense QR code, but with a 4.2k hard limit for alphanumeric QR codes, it's not approaching the maximum.

Clients unaware of Bitcoin Invoice Signatures (BIS) will simply ignore the added data; but clients that are aware of BIS can present (a) all of the fields included, and (b) the value of sigdomain (or optionally the Distinguished Name that the cert was issued to) and (c) the fact that the vendor has signed the transaction AND that the client has validated that signature.

In the case of a payment dispute, the customer can present the original Bitcoin Invoice URI, and prove that their payment was made through the public blockchain.  The URI in this case becomes both the invoice /and/ the receipt.

*Expiration: to limit the valid time for invoice's payment, a vendor MAY add a field labelled "sigexpiration" can be added before the "sig" field, which will be yyyymmddHHmmss encoded, and in the UTC time zone.  (HH is using a 24-hour clock.)  Clients SHOULD translate that time to the time zone of the user, and MUST NOT allow payment to be submitted after that cutoff.  (Payments confirmed after the cutoff become a dispute outside the scope of this proposal.)

I'm aware of BIP 0070, but this is far more lightweight, is usable offline, can be implemented in a relatively short period of time, and won't break existing Bitcoin clients.

Java source code for this:  https://github.com/dbanttari/bitcoin-invoice

Did it not ship with its own power supply?

Edit: Grats!

Thanks for the clarification.

In what way does this make sense?

I'm afraid "temporary" has had a really long run, so far.  I suppose it depends on your timescale, or just semantic issues of denotation vs. connotation.

I don't consider anything that's "unlikely to change in my lifetime" to be temporary, because from my mortal perspective, it's permanent.

If people were truly so unhappy with the status quo, there'd be less of it. ;-)

Must have been really slow, I still haven't gotten any notification.

Ooooo, that wouldn't be smurfy at all.  :-/

You're only allowed to buy vowels, not whole words, silly.

Indeed it does.  The people who were notified of the closure quickly bought BTC and got the hell out of there.  Not clear to me why he didn't halt trading the moment he started notifying people.  I had a sell order in for an unreasonably high price at the time, but someone who got notified bought through it, and now I'm stuck with a bunch of USD the banks won't let me touch.

I wouldn't be upset if there hadn't been "favored customer" notification.

Can we stop the devolution into pedantry?

Yes, they are technically shipping.

No, they're still not shipping in any meaningful volume, and that's annoying.

Next point?

I suppose it could be argued that anyone holding Bitcoin is shorting fiat

Wow, this thread devolved quickly.

But if I might probe an assumption of the OP- why do people need to be involved in mining in order to participate in a cryptocurrency system?

I don't think gravy belongs on fries.

Sorry, that's still more hypothetical.

I like waffles.

Incidentally, "We are still waiting to hear back from the bank regarding our remaining account balance" suggests to me that they may have received the check, but that it was for an amount less than they were expecting.

From the moment we let the money out of our direct control, there's been a very real possibility of not getting it back.  The only question is that of probabilities.  And speaking objectively, the longer it's being held by Bitfloor, the worse that probability gets.  Roman's reputation is the only reason most of us have any hope at all.

n.b. This includes fiat in bank accounts we "control."  Ask people in Cyprus about that.  Haircuts are probably not coming to the US anytime soon, but when it comes to any country, they won't announce it in advance, because that would defeat the whole purpose.  (It can be argued that there is no greater Ponzi scheme than our fractional reserve banking system.)

Hell, even if you stuff your mattress with cash, its "value" is being silently leeched away via inflation.

What I don't understand is how they managed to make the holding (um, "hoarding") of gold illegal in 1933 without a widespread backlash.  The hubris of even considering the action shocks me.  But then, it was the middle of the Great Depression, so I presume most people had better things to worry about, like food and shelter.

...Sometimes I wish I'd never heard of Bitcoin, because what I've learned since is a whole big series of very uncomfortable truths.

Clearly, you missed the shift into the hypothetical.  I like to talk about ideas, not people.

Ditto.  I was mildly shocked but happy when my sell filled, but now that I know why, I'm far less happy.