Former Verifone employee here: While it's technically true that pay-by-reference is a thing most payment processors offer it's not supported by most payment processing software and most processors treat it like a premium service. The vast majority of recurring credit card payments are sadly still done by storing an encrypted card number and decrypting it every time payment is made.
Adding insult to injury, most payment processing software also only conforms to the bare minimum encryption requirement meaning your credit card information is only encrypted using 3DES, keying 3 (meaning a whopping 56 bit key). You can attribute this poor security to laziness since that's the same encryption mechanism PINpads use so the CC co devs already had that code laying around to repurpose.
Of course I have no idea what software Dish uses, who their processor is and what those two things allow/support. Dish may actually be using proper pay-by-reference transactions or they may not, I have no idea.
None of this changes the fact that a payment system where you must reveal your secret key (cc#) in order to spend is inherently flawed, poorly designed and will be frequently compromised at every link in the chain. It's just a bad security design from the ground up.
The price chart looks a lot like the transaction volume chart, which is usually how I make my guesses as to whether we're in a bubble or not - increase in price without similar increase in usage = bubble. That said, it's anyone's call.
The site's been up less than a day and it's still very early beta. I've been informed that the shipping estimates being provided at checkout are not even close to correct for non-U.S. customers and that's something they're working hard to fix. Give them time :)
It's not really looking like that's an option too many folks care about anyway, given the survey results so far.
As for the concerns:
1) The original audio did mention that there would be difficulties on the hardware side of that fence - leasing a car may have been a poor example, but it was just an idea of one kind of transaction a "smart property" system would be capable of.
2) There is actually one big benefit of adding Bitcoin to that mix: You gain the benefits of a publicly published block chain that's not reliant on any centralized source as is the case with traditional key signing. A bank could implement this for their loans right now, but it would be reliant on some centralized source to enforce the payment schema. With the bank as that source it would be a very lop-sided relationship with one central point of failure. With the Bitcoin protocol as the source of contract enforcement the balance of power between you and the bank is even and your single point of failure is now a distributed transaction network with tens of thousands of nodes.
That's the best I could do - I'm not exactly an audio engineer but I can remove noise and normalize at least. Not much I can do about the echo, but if someone else knows a way, downloads are enabled so feel free.
It's theoretically possible with deconvolution, but I don't know that anyone's had much success there without a bunch of MATLAB coding and a perfect impulse of the room.
There's a newish plugin called Zynaptiq Unveil that claims to do "blind" reverb removal, that is, without having an impulse response. I haven't tried it, but there's a demo version:
I have a lock, it knows it has a unique ID of 123.
I have a keypair A, the lock is programmed to trust messages signed by keypair A.
My friend has a keypair B. I encode a message in the block chain signed by A that says something equivalent to "lock 123, you may open for whoever controls public key B"
When either I or my friend come to the door and scan at the lock, we send it our public key. If the public key matches one that the lock has been told to trust, it sends back some random data. We sign that random data with private key A or B, thus proving that we actually own that keypair, and the lock opens.
If someone else sends a message to lock 123 that isn't signed in an appropriate way by some key the lock has been told to trust it ignores the encoded message. If someone sends it a public key that it doesn't trust, it ignores that too.
I need to give access to my wife, who holds keypair C. I send another message to the lock saying "allow access for keypair C but also make keypair C an administrator so she can grant access to others too"
All of this happens transparently in milliseconds with a simple application that could run on your smartphone.
If that works, it works without bitcoin. I can send that messaged, signed, with or with out bitcoin. Conversely, no bitcoin script can force me to sign that message since no bitcoin script can contain that private key. Just because a systems uses public key crypto , doesn't mean its works with bitcoin.
In the sense that it works securely. It clearly works for giving someone authorization.
It should be noted that this is similar to the way SSL works for encrypting HTTPS browser sessions - there is a root authority that has the right to sign other peoples' keys. Some of those keys can sign other keys and so on - if the string of signatures doesn't authenticate all the way back to a root authority, your browser warns you that something is wrong.
Sure it is. If the devices speak Bitcoin I can say "only open the door if someone has a key that I (and only I) have sent this kind of transaction to" - when I sign the transaction I prove that I am the holder of the "root key" that lock is programmed to trust and I'm certifying permissions to the holder of a second key. They can then use sign some random arbitrary data the entry system sends to them (handshake) to prove that they control a key I've signed off on. Bitcoin is distributed by nature but it's based around split-key cryptography and using ECDSA to prove the ownership of keys. You're not using secret data encoded in the key to open the door, you're using the key itself and a signed transaction to establish trust.
That works, but it works without bitcoin. The idea the article was putting forth is that you could use bitcoin scripts to change property ownership
The point is you can't, as the article proposes, create a bitcoin scripted loan where if I default on the loan, authorization message/transaction gets sent (because that message must be signed with a private key that the network does not have) .
What you could do, in a world where bitcoin script is far more powerful, is give your bank a transaction that says this transaction is only valid if I didn't pay loan x(where x is some bitcoin contract loan) and if it is valid, then the bank has access to my car.
When this transaction validates according to network consensus, the car would hand over control. This requires,however, that the car can make the validity judgment. Which means the car has to understand the bitcoin protocol and probably have access to the transaction records/blocks.
Adding insult to injury, most payment processing software also only conforms to the bare minimum encryption requirement meaning your credit card information is only encrypted using 3DES, keying 3 (meaning a whopping 56 bit key). You can attribute this poor security to laziness since that's the same encryption mechanism PINpads use so the CC co devs already had that code laying around to repurpose.
Of course I have no idea what software Dish uses, who their processor is and what those two things allow/support. Dish may actually be using proper pay-by-reference transactions or they may not, I have no idea.
None of this changes the fact that a payment system where you must reveal your secret key (cc#) in order to spend is inherently flawed, poorly designed and will be frequently compromised at every link in the chain. It's just a bad security design from the ground up.