Topic: Split private keys (Read 17350 times)
This method mame "publick key halving".
I would like to see if it is possible to resurrect this discussion to understand more about how split keys can be generated and used.
I have been working on a project called SEEDCARD - a bitcoin physical key card that is generated using partial private keys.
As i am not a coder, i have written a proposal that explains how the keys could be generated and used - heres a link to the website: https://seedcard.github.io/website/index.html and there you will find a link to the Code Brief page.
The ideas that were being discussed in this thread so many years ago have inspired me to search for a way to create something that was mentioned in the Satoshi's whitepaper. I believe that there could be a decentralised way to create wallets. These wallets could be used like cash to make off-chain transactions that solve the scaling problem.
Curious to see what happens!
I have been working on a project called SEEDCARD - a bitcoin physical key card that is generated using partial private keys.
As i am not a coder, i have written a proposal that explains how the keys could be generated and used - heres a link to the website: https://seedcard.github.io/website/index.html and there you will find a link to the Code Brief page.
The ideas that were being discussed in this thread so many years ago have inspired me to search for a way to create something that was mentioned in the Satoshi's whitepaper. I believe that there could be a decentralised way to create wallets. These wallets could be used like cash to make off-chain transactions that solve the scaling problem.
Curious to see what happens!
Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key.
This is the part I'm fixating on right now. I assume this is done by Device 2 in order to obfuscate it's private key from Device 1. Can someone provide an example of an equation that would do this?
EDIT: Gavin, I also assume you made a typo at the end of your sentence and meant Device 1's private key instead of public key.
Yes, but my intent is different, so I just wanted to verify this specific part of the equation. Can Computer A and Computer B generate a shared public key with their respective private keys, without compromising the shared private key? Is the main security problem only when the shared private key actually needs to be used?
You're obviously already beyond my skill level. I'm sorry, but I can't help more. But I don't believe that this particular idea ever got much traction.
Yes, but my intent is different, so I just wanted to verify this specific part of the equation. Can Computer A and Computer B generate a shared public key with their respective private keys, without compromising the shared private key? Is the main security problem only when the shared private key actually needs to be used?
Um, no not quite. What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works. Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being. But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own.
Actually, that's not quite right. What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device. Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone. When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone. This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen. 'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree. This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time. But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS. Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped. Either device could be backed up as well.
Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct?
Um, no not quite. What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works. Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being. But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own.
Actually, that's not quite right. What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device. Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone. When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone. This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen. 'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree. This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time. But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS. Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped. Either device could be backed up as well.
Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct?
Um, no not quite. What Gavin was talking about here is a form of two factor authentication, as applied to how the bitcoin system works. Roughly what is being suggested is that one device is creating the transaction according to what it knows about the spender's wallet.dat file, less the private keys that go with the addresses that contain value; and the second device's job is simply to securely hold the private keys, and sign the transaction with the correct keys when presented with a verifiable transaction and proper authorizasion from a human being. But the second device does not have access to the transaction inputs in the wallet.dat file, and therefore couldn't create a valid transaction on it's own.
Actually, that's not quite right. What I've described above is a split wallet.dat system, which can be done now; but what Gavin is suggesting is the development of a new kind of address that, even if the second device is compromised and the private keys stolen, the funds cannot be moved without access to the first device. Currently, a split wallet.dat system is employed by a couple of light android clients (such as Mycelium) to permit a server to hold the wallet.dat while the actual private keys are kept on the android phone. When the user, from the android phone, initiates a transaction; the server creates the transaction and then sends it to the device for signing by the user's phone. This protects the user's funds both from a hacker tricking the server into thinking that they are the user's phone and from similar server ended theft/fraud, but the user's funds are still at risk if the phone is stolen. 'Split addresses' would permit two factor transaction signing, requiring both access to the user's phone, and another of the user's devices; so that the attacker would require both devices to agree. This may not be useful for most people, since if someone is mugged of their phone they are likely mugged of any devices that they possess at the time. But the second device could be as simple as a bluetooth only device that must be within range of the cell phone, with a keypad to enter a code upon POS. Or it could be the user's home pc, that can be set to remain open (within limits, say a max BTC per day rule) for a full day or week, so that if the user's phone is stolen, the amount at risk is limited to what can be taken before the home PC client can be stopped. Either device could be backed up as well.
Bringing this back from the dead for something slightly related I am brain-storming. If I understand this correctly, two separate devices can generate a ECDSA public key without ever knowing the full private key. The security problem arises when one needs to actually utilize the private key, correct?
So I've been thinking a lot about wallet security; Matt's password patch is a good first step, but maybe we can at least build in some infrastructure for a better solution.
We really need a solution where transactions are generated on one device and then verified on a second device, so malware must compromise both devices (e.g. computer and mobile phone, or web wallet and mobile phone) to steal coins.
gmaxwell from IRC thinks it can be done without multiple signatures (just with the standard transaction we have now), and staring at the ECDSA math on this wikipedia page I think he's right. I believe he was inspired by ByteCoin's observation that you can create a vanity public key generating service that is secure-- the service can generate the public key but not know the private key.
I'm mostly writing this to convince myself it could work and to give ByteCoin and Hal and gmaxwell and anybody else who knows a whole lot more crypto than me a chance to poke holes in it. And then point me to a FIPS standard that has it all figured out already...
So: generating an ECDSA keypair means choosing a private key dA, then calculating the public key QA = dAG (where G is a fixed point on the elliptic curve).
The key generation can be split; have device 1 choose dA1 and device 2 choose dA2. Device 1 then sends QA1 to Device 2, and it can calculate QA1dA2 = QA1*A2. Or in english, Device 1 finds a public key on the curve. Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key.
So great, neither Device 1 or 2 needs to ever have both parts of the private key on them to generate the shared public key.
Now lets say Device 1 wants to spend a TxOut that is one of these split keys. The key bit of the signature generation algorithm (see the Wikipedia page: http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm ) is:
...
4. Calculate s = k-1(z+rdA)(mod n)
...
That can be rewritten as:
Calculate s = k-1(z+rdA1dA2)(mod n)
And now I'm stuck. Can that equation be refactored so that Device 1 can compute part of the signature, send its partial result to Device 2, and have Device 2 complete the signature (without Device 2 being able to figure out 1's part of the private key?)?
We really need a solution where transactions are generated on one device and then verified on a second device, so malware must compromise both devices (e.g. computer and mobile phone, or web wallet and mobile phone) to steal coins.
gmaxwell from IRC thinks it can be done without multiple signatures (just with the standard transaction we have now), and staring at the ECDSA math on this wikipedia page I think he's right. I believe he was inspired by ByteCoin's observation that you can create a vanity public key generating service that is secure-- the service can generate the public key but not know the private key.
I'm mostly writing this to convince myself it could work and to give ByteCoin and Hal and gmaxwell and anybody else who knows a whole lot more crypto than me a chance to poke holes in it. And then point me to a FIPS standard that has it all figured out already...
So: generating an ECDSA keypair means choosing a private key dA, then calculating the public key QA = dAG (where G is a fixed point on the elliptic curve).
The key generation can be split; have device 1 choose dA1 and device 2 choose dA2. Device 1 then sends QA1 to Device 2, and it can calculate QA1dA2 = QA1*A2. Or in english, Device 1 finds a public key on the curve. Then Device 2 uses its part of the private key to do a bunch more elliptic curve multiplies to find the composite public key without ever knowing Device 1's public key.
So great, neither Device 1 or 2 needs to ever have both parts of the private key on them to generate the shared public key.
Now lets say Device 1 wants to spend a TxOut that is one of these split keys. The key bit of the signature generation algorithm (see the Wikipedia page: http://en.wikipedia.org/wiki/Elliptic_Curve_DSA#Signature_generation_algorithm ) is:
...
4. Calculate s = k-1(z+rdA)(mod n)
...
That can be rewritten as:
Calculate s = k-1(z+rdA1dA2)(mod n)
And now I'm stuck. Can that equation be refactored so that Device 1 can compute part of the signature, send its partial result to Device 2, and have Device 2 complete the signature (without Device 2 being able to figure out 1's part of the private key?)?
If the device does all of the wallet stuff itself, you can take it on the road.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
If I remember correctly, ArtForz is already working on a secure key storage and signing device. I'll see if I can find a chat log.
Found it: http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/05/05/20#l485685
Sounds like he and I came to the same conclusions, he just beat me by a month or two.
I really need to start hanging out on IRC.
If the device does all of the wallet stuff itself, you can take it on the road.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
If I remember correctly, ArtForz is already working on a secure key storage and signing device. I'll see if I can find a chat log.
Found it: http://bitcoinstats.com/irc/bitcoin-dev/logs/2011/05/05/20#l485685
That's a BitBank more or less, and unfortunately I doubt you could avoid being regulated as a money services business because you'd still be a "money transmitter". You probably could avoid being regulated as a fully blown bank though.
Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.
Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.
This is definitely a topic for lawyers, but you don't really have to transmit anything. Customer wants to pay $100 electric bill. His client generates an unsigned transaction and sends to vault service. Vault service partially signs transaction and sends back to client. Client has secure device complete the signature and client broadcasts fully signed transaction to the network. I guess the only thing the regulators could say here is that the service has the ability to block transactions, so it should be required to do so under AML regulations.
Another thing is there's no need to open this kind of service in the US. There's a much smaller degree of trust required than a regular bank, and it might be a lot harder for the US to strong-arm other countries into regulating this. I definitely wouldn't call it anything with the word "Bank" in it. In some countries it's even illegal to call a company a bank if it's not regulated as a bank.
Just as an example, some definitions in the Michigan Money Transmission Services Act:
Quote
(b) "Money" means a medium of exchange authorized or adopted by the United States or a foreign government as a part of its currency that is customarily used and accepted as a medium of exchange in the country of issuance. The term includes a monetary unit of account established by an intergovernmental organization or by agreement between 2 or more governments.
Seems not to include bitcoin.
Quote
(c) "Money transmission services" means selling or issuing payment instruments or stored value devices or receiving money or monetary value for transmission. The term does not include the provision solely of delivery, online, or telecommunications services or network access.
No selling or issuing of any payment instruments is done by the security service. It's possible you could mangle the meaning of "issuing payment instruments", but see below.
Quote
(e) "Payment instrument" means any electronic or written check, draft, money order, travelers check, or other wire, electronic, or written instrument or order for the transmission or payment of money, sold or issued to 1 or more persons, whether or not the instrument is negotiable. The term includes any stored value device or facsimile. The term does not include any credit card voucher, letter of credit, or tangible object redeemable by the issuer in goods or services.
"transmission or payment of money" -- according to (b), bitcoin may not be defined as money, and therefore no payment instruments could ensue.
That's a BitBank more or less, and unfortunately I doubt you could avoid being regulated as a money services business because you'd still be a "money transmitter". You probably could avoid being regulated as a fully blown bank though.
Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.
Being regulates as a money transmitter means following AML regulations, basically, doing KYC in order to open an account and trying to report "suspicious transactions". There are some other rules in there as well.
OK. For a lightweight client, check out BitCoinJ which implements this mode already. There's no need to duplicate work.
Is this regarding the discussion about saving previous relevant transactions on the secure device? If so, it's a good point
As for the hardware design, I'm starting to think this is the wrong place to get into it. People can hack their own MP3 players and do cool DIY projects, but if we're talking about something that's intended for mainstream use I think you'd need to form a real company to get this moving.
Imagine starting a company that implements Gavin's idea. The company doesn't have ownership over your bitcoins, but helps regular people transact securely on a day-to-day basis. This company would bring in hardware engineers, talk to smart card manufacturers, and negotiate bulk pricing for them. To open an account, you'd ask for a couple of devices or smart cards to be sent to you in the mail. Eventually, you'd be able to buy them at Walmart and 7-eleven. Once you have your devices, you put one away in a safe deposit box and forget about it, and use the other one to do secure payments. The company could make a lot of money on a monthly or annual storage fee. Since the company has to know the bitcoin addresses it's securing, it could just look in the block chain to see how much you've got in them, and take a small cut.
It's cool because it's like opening a bank but without the regulatory bs, and you're not really responsible for everybody's money. Advanced users probably won't need the service at all, and the company can sell them the hardware to secure their coins themselves.
OK. For a lightweight client, check out BitCoinJ which implements this mode already. There's no need to duplicate work.
I've investigated smartcards before. Finding cards that can do ECDSA is difficult. Also, readers that have a display and pinpad can be quite expensive (reusing the ones banks issue isn't as easy as I'd hoped).
Ideally the smartcard reader device is smart enough to do internet connectivity (perhaps tunnelled through the host), because - again - Bitcoin addresses/pubkeys are opaque. You need assurance that the address you see is owned by the counterparty you think it's owned by. We covered this before. Having a display isn't enough. The display needs to display something human readable. In my proposal, the BitBank provided another service beyond hosting keys: verifying that the public key in question was really owned by some human readable string like a business name or email address. In a pure card based design there's no such external trusted observer. Instead I suppose you could try to re-use the existing SSL PKI and have the reader understand how to verify a signature over a new pubkey using the organizational pubkey embedded into a SSL cert.
I think the right tradeoff is not to have the card sign the transactions (this requires a powerful and expensive card) but rather, have the card hold the keys and release them in the clear to a device that can provide the correct PIN. The device itself then takes an unsigned transaction created by the host, fills out the scriptSigs and hands the signed transaction back.
So there'd be three levels of trust: the untrusted host device knows your balance and can build transactions. The dedicated device signs them. The card holds the keys.
There would need to also be an ability to export an encrypted backup because people probably won't want to store all their value in a card that can easily break, be lost, be stolen, etc.
I've investigated smartcards before. Finding cards that can do ECDSA is difficult. Also, readers that have a display and pinpad can be quite expensive (reusing the ones banks issue isn't as easy as I'd hoped).
Ideally the smartcard reader device is smart enough to do internet connectivity (perhaps tunnelled through the host), because - again - Bitcoin addresses/pubkeys are opaque. You need assurance that the address you see is owned by the counterparty you think it's owned by. We covered this before. Having a display isn't enough. The display needs to display something human readable. In my proposal, the BitBank provided another service beyond hosting keys: verifying that the public key in question was really owned by some human readable string like a business name or email address. In a pure card based design there's no such external trusted observer. Instead I suppose you could try to re-use the existing SSL PKI and have the reader understand how to verify a signature over a new pubkey using the organizational pubkey embedded into a SSL cert.
I think the right tradeoff is not to have the card sign the transactions (this requires a powerful and expensive card) but rather, have the card hold the keys and release them in the clear to a device that can provide the correct PIN. The device itself then takes an unsigned transaction created by the host, fills out the scriptSigs and hands the signed transaction back.
So there'd be three levels of trust: the untrusted host device knows your balance and can build transactions. The dedicated device signs them. The card holds the keys.
There would need to also be an ability to export an encrypted backup because people probably won't want to store all their value in a card that can easily break, be lost, be stolen, etc.
listening.
I don't think this is correct.
- You have the following 4 items: the private key (A), the public key (B), its associated hash (C) and finally the associated bitcoin address (D), which is base58encode( hash (C) + checksum). (D) is only invented so that the hash (C) is human friendly.
- If you know (C), you can calculate (D) and vice-versa. But is it not possible to calculate the public key (B) from (C) or (D).
- Initially to receive coins, you reveal your bitcoin address (D).
- If you send coins to it, a standard transaction is made to (C) (Humans do not really need to read the raw blockchain). Output from it can be claimed if you can sign the transaction.
Yeah, those are very good points. The compromised computer can already know that the bitcoin addresses you're sending from belong to the same account and that they belong to you (if the computer has any additional information about you). This could be an issue, and should probably be addressed by any scheme that purports to be secure. The only added amount of data it could glean from you requesting previous transactions for bitcoin addresses is that it could infer that you own bitcoin addresses that you may not end up using in the send transactions.
The only reason I can think of that you wouldn't want an untrusted client preparing the unsigned transaction for you is that you don't want to divulge any of your public keys that are holding money. But that means that if you receive money away from your trusted machine, you won't be able to spend that money. I think a combination makes sense. You can download a cache of your current transactions at home. When on the road, if these transactions can cover the bill, you don't need to divulge any public keys. Otherwise you have the choice of divulging public keys to the client to check for new incoming transactions until you can cover the bill.
I don't think this is correct.
- You have the following 4 items: the private key (A), the public key (B), its associated hash (C) and finally the associated bitcoin address (D), which is base58encode( hash (C) + checksum). (D) is only invented so that the hash (C) is human friendly.
- If you know (C), you can calculate (D) and vice-versa. But is it not possible to calculate the public key (B) from (C) or (D).
- Initially to receive coins, you reveal your bitcoin address (D).
- If you send coins to it, a standard transaction is made to (C) (Humans do not really need to read the raw blockchain). Output from it can be claimed if you can sign the transaction.
So up to the point where you only receive coins, you never have to reveal your public key (B).
But if you want to spend any of them, you will have to reveal your public key to everybody. Otherwise is it not possible for anyone to check to see if your signature is correct.
That is why 2 checks are made when you claim a transaction: first the supplied public key is checked that it hashes to (C) (so that you cannot claim the coins using another public key), and afterwards the signature is checked using the supplied public key.
In fact, revealing your public key shouldn't make things more insecure. But it was probably added as an extra security layer: once you have to reveal the public key (=to spend some coins), you can spend all coins of that bitcoin address and send the change to a new bitcoin address with unrevealed public key. To get to your bitcoins, one must first find a public key that hashes to your bitcoin address (quite impossible already) and then use that to find the associated private key (again at the moment quite impossible).
Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.
If the device does all of the wallet stuff itself, you can take it on the road.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
The only reason I can think of that you wouldn't want an untrusted client preparing the unsigned transaction for you is that you don't want to divulge any of your public keys that are holding money. But that means that if you receive money away from your trusted machine, you won't be able to spend that money. I think a combination makes sense. You can download a cache of your current transactions at home. When on the road, if these transactions can cover the bill, you don't need to divulge any public keys. Otherwise you have the choice of divulging public keys to the client to check for new incoming transactions until you can cover the bill.
I'll release the link to my website as soon as the lightweight client is ready for testing.
Looking forward to it
I've been reading this topic with great interest, as I already proposed something similar a few months ago (a smartcard-like device to use as payment in stores instead of a full bitcoin client on some fancy smartphone).
I've been working on this idea and this is what I have in mind:
It can support a variety of configurations like the secure storage of wallet keys (like the discussion in this topic) or paying at your favourite store, just to name two.
Still need to develop a lot (only part A partially done), but because of this discussion, I'll release the "lightweight" client very soon (still working out some final details, then it's ready for first release/test), so that perhaps other people can build on top of that.
Why a lightweight client ?
Everybody talks about "in the future people won't be using a full bitcoin client", and I agree with that: the full client is only useful for people actively supporting the p2p network (mining, big bitcoin user, ...). "Normal" people only need a (very) small part of the blockchain to be able to use bitcoins.
So the client I'm developping will connect to the bitcoin network (at the moment only to one node) to do only 1 thing: download the blockchain, inspect it and store only relevant data. In "private" or "extra-light" mode, it will only store open transactions of a (small) list of bitcoin addresses (=the few user's bitcoin addresses). In "store" or "light" mode, it will story all open transactions (to be used by a store/website that will accept payments in bitcoin, or some power-users wanting to have all relevant data of the blockchain).
It stores this data in a database (I choose MySql) so that any other program/script/web page can easily access this data. In extra-light mode, as only a few transactions need to be stored, a much easier storage (like plain text or CSV format) can be used (so it could be compiled for smartphone platforms more easily).
The GUI software (C) will act as the interface between the smartcard and the client (A): it will manage the smartcard and will send unsigned transactions to the smartcard and signed transaction to the client. (C) could be a small program running on a PC/checkout desk at the local store where a customer can insert his smartcard into a reader to pay for some goods. But it could also be a webpage of an online store.
In a bigger store, the actual implementation could be: 1 server hosts the lightweight client (A) + database and at each checkout software (C) is installed and used to process payments (which will query the database on the server, and send transactions to (A)).
The smartcard (B) is the key part making everything secure: it has a fixed software on it (you can't hack into it and install some other software to read out the RAM containing the private keys) that can generate/load keypairs and sign a transaction sent to it (so it never needs to reveal the private keys when inserted into a unknown PC/terminal).
As said elsewhere, we cannot trust that what we actually see on the display of the checkout terminal/PC is that what is asked to sign, so it will have to have a display and one or more buttons to confirm/cancel the transaction (or loading of new keypairs, ...). This will also prevent abuse of the smartcard when the PC of a local user is infected.
I'll release the link to my website as soon as the lightweight client is ready for testing.
I've been working on this idea and this is what I have in mind:
- a lightweight client (A);
- a smartcard device (B) with display and button(s);
- a GUI software (C).
It can support a variety of configurations like the secure storage of wallet keys (like the discussion in this topic) or paying at your favourite store, just to name two.
Still need to develop a lot (only part A partially done), but because of this discussion, I'll release the "lightweight" client very soon (still working out some final details, then it's ready for first release/test), so that perhaps other people can build on top of that.
Why a lightweight client ?
Everybody talks about "in the future people won't be using a full bitcoin client", and I agree with that: the full client is only useful for people actively supporting the p2p network (mining, big bitcoin user, ...). "Normal" people only need a (very) small part of the blockchain to be able to use bitcoins.
So the client I'm developping will connect to the bitcoin network (at the moment only to one node) to do only 1 thing: download the blockchain, inspect it and store only relevant data. In "private" or "extra-light" mode, it will only store open transactions of a (small) list of bitcoin addresses (=the few user's bitcoin addresses). In "store" or "light" mode, it will story all open transactions (to be used by a store/website that will accept payments in bitcoin, or some power-users wanting to have all relevant data of the blockchain).
It stores this data in a database (I choose MySql) so that any other program/script/web page can easily access this data. In extra-light mode, as only a few transactions need to be stored, a much easier storage (like plain text or CSV format) can be used (so it could be compiled for smartphone platforms more easily).
The GUI software (C) will act as the interface between the smartcard and the client (A): it will manage the smartcard and will send unsigned transactions to the smartcard and signed transaction to the client. (C) could be a small program running on a PC/checkout desk at the local store where a customer can insert his smartcard into a reader to pay for some goods. But it could also be a webpage of an online store.
In a bigger store, the actual implementation could be: 1 server hosts the lightweight client (A) + database and at each checkout software (C) is installed and used to process payments (which will query the database on the server, and send transactions to (A)).
The smartcard (B) is the key part making everything secure: it has a fixed software on it (you can't hack into it and install some other software to read out the RAM containing the private keys) that can generate/load keypairs and sign a transaction sent to it (so it never needs to reveal the private keys when inserted into a unknown PC/terminal).
As said elsewhere, we cannot trust that what we actually see on the display of the checkout terminal/PC is that what is asked to sign, so it will have to have a display and one or more buttons to confirm/cancel the transaction (or loading of new keypairs, ...). This will also prevent abuse of the smartcard when the PC of a local user is infected.
I'll release the link to my website as soon as the lightweight client is ready for testing.
Your real wallet is in the device. The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it. When you want to pay, it sends the destination address and the amount, only. The device then creates the transaction all by itself, using transaction records it already knows.
Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.
If the device does all of the wallet stuff itself, you can take it on the road.
I want this thing to be my wallet. Not a glorified dongle that allows me access to the wallet stored on my PC.
Your real wallet is in the device. The PC on your desk can keep a copy of the public keys so that it can show you your current balance as a convenience, but that's it. When you want to pay, it sends the destination address and the amount, only. The device then creates the transaction all by itself, using transaction records it already knows.
Yes, the private keys are stored only on the secure device, but that wasn't my question. My question was, if the client can create the required unsigned transaction, which requires nothing more than knowledge of the public block chain, why does the secure device need any more data than just that unsigned transaction, which it then signs. Everything but the actual transaction signature is public knowledge, the only thing the device needs is the transaction itself, so that it can properly sign it. It does not need to know all other unrelated transactions that I've done in the past, and it has no way of knowing whether to trust them anyway.
Jump to: