Exotic Transaction Types with Bitcoin(codinginmysleep.com)
codinginmysleep.com
Exotic Transaction Types with Bitcoin
http://codinginmysleep.com/exotic-transaction-types-with-bitcoin/
3 comments
This is very interesting and I think needs to be more widely known. There is a general perception of Bitcoin as simply a currency useful to criminals. The idea that it is capable of useful things that regular currency can't do helps to legitimise it.
Smart property doesn't work unless the control devices speak bitcoin(and are probably online). Bitcoin, because of its distributed nature, can't keep secrets, so it is impossible to tie the necessarily secret cryptographic credentials used for access control to public transactions.
You end up having to give escrow keys to a third party who well they might agree to be bound by a bitcoin script contract, can't actually be forced to honor such a script any more than they could with a normal loan/contract.
You end up having to give escrow keys to a third party who well they might agree to be bound by a bitcoin script contract, can't actually be forced to honor such a script any more than they could with a normal loan/contract.
By way of a functional example:
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.
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.
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.
The weirdest parts about that one are really:
1) You're placing the lock under the complete unsupervised control of someone you're supposed to be securing against. A car buyer, for example, could replace their entire ignition system with aftermarket parts: no amount of security will prevent that.
2) It doesn't actually need Bitcoin. The same concept can be implemented with regular old key signing.
1) You're placing the lock under the complete unsupervised control of someone you're supposed to be securing against. A car buyer, for example, could replace their entire ignition system with aftermarket parts: no amount of security will prevent that.
2) It doesn't actually need Bitcoin. The same concept can be implemented with regular old key signing.
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.
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.
wrt 1, The car control system and the smart property stuff would all be on a single chip. So, of course, replace enough parts and the car would be unlocked. But those parts might be expensive or complicated enough to replace be an effective lock.
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.
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.
The audio of the talk is awful. Are there any better sources for the original talk?
http://soundcloud.com/david-perry-17/the-future-of-bitcoin-n...
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.
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:
http://www.zynaptiq.com/unveil/
Other interesting conversations about de-reverberation:
http://comments.gmane.org/gmane.comp.audio.music-dsp/775 http://www.gearslutz.com/board/music-computers/60299-convolu...
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:
http://www.zynaptiq.com/unveil/
Other interesting conversations about de-reverberation:
http://comments.gmane.org/gmane.comp.audio.music-dsp/775 http://www.gearslutz.com/board/music-computers/60299-convolu...