Sorry, those links don't explain anything. Explain to me how you would transfer a private key to me using DRM in a way that completely ensures that you no longer have access to that same private key.
Ok, so you want a model of how to transfer the private key of a DRM coin. Well, before we start let's clarify what a DRM coin would be in this hypothetical model so we can agree on what we're talking about:
Basically it is the public/private key pair of a wallet address that is stored cryptographically on just one computer at a time. The public key is still publicly available knowledge and can be viewed arbitrarily (eg: someone may access the public address in order to look it up on the block chain to check its balance). However the private key can only be accessed once, once it has been retrieved the coin itself is destroyed so it cannot be transferred again. The coin should also store the balance that was transferred to the address when it was created (Note: someone may add more money into it after creation because the public address is known. It would be a strange thing to do though. So the balance is technically the minimum amount that it contains-- if someone adds extra money the coin itself doesn't know about this. Only the initally creation balance is known by the coin.)
Now for the model: (Note: this is just a simple hypothetical model- in reality it would be more detailed than this). The model has three different parts, 1)coin creation, 2) coin transfer and 3)reveal private key.
Let's use the following example to explain how it the first two parts work:
Sender Sally has atleast 50 BTC on-chain in her wallet. Receiver Ross is coming to collect the 50BTC she owes him, but Ross will only accept DRM coin because he doesn't want to wait around 20min-90min for 3 confirmations to prove that he has received the coin. So sally has to 1) create a coin holding 50 BTC before Ross comes and 2) transfer it to Ross when he arrives.
1) Coin creation:
a)Firstly, Sally secure boots her computer. This procedure puts the hardware into a precisely defined state and prohibits all non-signed pre-OS binaries to run (eg: the OS boot loader will only be run if it's signature matches that stored on chip). This prevents low-level pre-OS attacks such as rootkits.. see:
http://en.wikipedia.org/wiki/Uefi#Secure_bootb)Once the OS is up and running then Sally runs the program and selects the "make-DRM-coin" option. This software checks before it does anything that it is running on a securely-booted machine in a secure state.
c)Once the software knows that it is safe, it creates a the private/public key pair address and makes a standard on-chain transaciton to load the address with 50BTC. The software doesn't reveal the private key to Sally.
d)Once the transaction has been confirmed (the number of confirmations can be arbitrarily decided by the user.) the software puts this key pair plus a record of the amount into sealed storage. see:
http://en.wikipedia.org/wiki/Trusted_Computing#Sealed_storageThe coin has now been successfully created
2) Coin Exchange:
a)Both Sally and Ross secure boot their computers.
b)They both run the software and Sally chooses the "transfer-DRM-coin" option. Like the before the first thing the program does is establish that it is running in a safe, secure environment.
c)The software establishes a secure connection between the two computers. Let's just say it is SSL over a direct computer-computer WiFi connection for this case.
d)Once the connection is established, the two computers both remote attest to the other that it is running an untampered version of the "make-DRM-coin" software on a secure computer. see:
http://en.wikipedia.org/wiki/Trusted_Computing#Remote_attestation and
http://en.wikipedia.org/wiki/Direct_anonymous_attestation3)Sally's computer retrieves the coin from secure storage and tranfers it to Ross's machine. Sally's machine deletes its copy. On receipt Ross's machine places it into sealed storage. (This transfer would actually be a little tricky because of the need for confirmation of the transfer before Sally has her coin deleted. Computer protocols for this sort of thing already exist.)
Voila! The coin has been transferred.
For the last part: Let's assume the Ross for some reason or other wants to transfer some amount of the coin on-chain within the Bitcoin network:
3)Reveal Private Key:
a)Ross secure boots his computer
b)He runs the program and chooses the "reveal-private-key" option. Similarly to the other options, the software only continues only if it being run securely.
c)The software retrieves the coin form sealed storage, informs ross of the private key and destroys the coin. He can now perform standard on-chain transactions.
There you go. A simple protocol of a secure private key exchange.
Please note though: In real life you wouldn't make a new DRM coin each time for a specific transaction. Rather you would make a lot of them preemptively at commonly used demoninations (eg: if you had 1000BTC make 9x100BTC coin, 9x10BTCcoin, 9x1BTC, 9x0.1BTC, 10x0.001BTC) and would exchange the required number of each demonination to make up the amount required. eg: to transfer 156BTC transfer 1x100BTC, 5x10BTC, 6x1BTC.
Also note: the software can reveal the public key and amount of the coin at any time-- this can be used to increase the confidence of the person receiving the coin that the DRM hardware/software protection mechanisms haven't been defeated since they can check that the address still has atleast the amount stated before accepting it. It can also be used to check the number of confirmations of the coin.