Bitcoin Forum

I had an idea to increase the security of the bitcoin-qt wallet so that it's protected by more than a single passphrase.  it has a few advantages beyond multi-sig.  Comments and critique are welcome.

https://i.imgur.com/BLW4FMr.jpg

Your illustration is very attractive, but it's still not clear to me what it's accomplishing.

If you are not using multisig how exactly is this two-phase transaction being completed? What specific technical mechanism prevents the desktop or the mobile device from unilaterally forming a transaction?

Contrary to your claim, multisignature would let you know an attempt was made and would allow you to reject it if it's not performing the requested actions.

Why do you not just send the transaction to the mobile device directly, since it is a necessary step in the process in any case? What purpose does the "precursor" network serve?

How do you protect this public network from being abused for bulk file transfer or other applications, especially since the data is encrypted?

Nitpick: The password protected QT wallet is itself two factors:  You must have the private keys on the computer (wallet file), as well as the decryption key. Adding the requirement for keying material stored/entered via the phone is a third factor— and a good idea. But this is what multisig was implemented for.

Great questions Greg.  I'm interested to know your thoughts because there may be more than one way to accomplish this.

Q: If you are not using multisig how exactly is this two-phase transaction being completed?  
A: There are two types of wallets being used here. Neither one has the ability to spend funds by itself.

• The first is a "blind" wallet which looks and feels pretty much exactly like bitcoin-qt, but is incapable of fully decrypting itself.  Instead, it can communicate intentions to spend.  Entering the 1st password correctly doesn't form a transaction which can be accepted by the bitcoin network, but it does form a sort of primitive bundle that can be relayed around a precursor network.  This tells everyone in the precursor network what the intended spend destination/amount/fee etc. is. But otherwise the information is useless until it's been fully decrypted by the second half of the password in a "spend" wallet.
• The spend wallet takes a precursor transaction, and uses the 2nd half of the password to fully decrypt it into a form that can be relayed within the bitcoin blockchain.

Q: What specific technical mechanism prevents the desktop or the mobile device from unilaterally forming a transaction?
A: Nothing prevents this.  A user could in theory install both wallets on the same device, creating a precursor first and fully decrypting it second.  It just wouldn't be a very good idea and would increase their risk of becoming compromised due to malware.  The advantage here is that they never have to enter their full password on the same device

A: Contrary to your claim, multisignature would let you know an attempt was made and would allow you to reject it if it's not performing the requested actions.
Q: Sorry, I didn't realize this.  Can you show an example of what it looks like when a multi-sig transaction is only partially completed in the blockchain?  I'd love to see this side of bitcoin developed further to a point where it's easy for the average user to set up in the native client. Multi-sig usage isn't very widespread at the moment.

Q: Why do you not just send the transaction to the mobile device directly, since it is a necessary step in the process in any case?
A: It's necessary, but may not be sufficient for the purposes of stopping theft.  Publicly broadcasting the precursor transaction helps ensure that a number of parties are agreeing that the transaction is valid and fits the appropriate criteria to be relayed.  Trying to relay it directly would expose the 2nd wallet into signing off on something that the owner wouldn't have authorized. MITM attacks for instance.

Q: How do you protect this public network from being abused for bulk file transfer or other applications, especially since the data is encrypted?
A: Set criteria for what a precursor transaction needs to look like before it can be relayed by participating nodes.  A permanent memory would not be required for the precursor network, and it could drop spend attempts after a period of inaction if they are not picked up.  If I'm misunderstanding what you mean by bulk file transfer, please let me know.

In practice, my blind wallet is able to set up as many single addresses as needed and create intents to spend bitcoin associated with them.  My spend wallet on another device has no ability to move coins by itself, but can recognize attempts by the former and sign off on them.  Multi-sig transactions are useful but only show up in your balance if all of the associated private keys are already in that wallet.  This allows users to split up the control of their coins not by breaking them up into multiple different bitcoin addresses, but breaking up the password over multiple devices.

Side note: I was referencing this thread from multi-sig research.  If there have been developments since that time, I will gladly stand corrected: https://bitcointalk.org/index.php?topic=287063.0

Sorry, you're describing desired behavior here, not an actual mechanism. Without multisignature I don't believe what you're describing is actually possible, which is why I asked for the mechanism.   "incapable of fully decrypting" and "primitive bundle" and "fully decrypt" are not meaningful to me in the context of the cryptosystem the bitcoin uses.

Sorry. That wasn't my question. I certainly understand the advantage of additional factors. Assume the mobile and desktop devices exist. What prevents one from completing the transaction entirely without the aid of the other (esp. including a second transaction with the same keys as the first)?

They can't go into the blockchain half completed. You sign on one device, and then it's half completed, and sign on the second device— assuming the second device agrees-, which fully completes the transaction. This is precisely what multisignature is for.

Why would the second wallet sign something the owner didn't authorize? Why would it sign a transaction which is not valid?  How can an anonymous public network decrease exposure to MITM than directly connecting the devices?

You're misunderstanding what multisign is for. It is specifically intended for cases where the keys are not on a single device. It is pointless, other than for softwaretesting, to put the keys on a single device.

Please describe a specific mechanism where (two device threshold signing, with dual verification of the content being signed) can be accomplished without using multisignature.

A solution for checking balance of a multisig address exists in the very thread you linked: https://bitcointalk.org/index.php?topic=287063.msg3435441#msg3435441

Sorry, I'm very aware of this. The point of this post is to simply describe an end-goal: transactions that are required to be  signed on multiple devices before they're relayed, also allowing users to see attempts to spend in the process.

Why is this worth talking about? Because multi-sig is still too obscure for the average user to create, theft is rampant within the bitcoin community, and it's difficult to tell when part of your security is compromised before it's too late.  Hopefully the idea sparks enough interest and discussion so that it can lead to better security on the basic client.  If you're going to press me for exact mechanisms, then I'm afraid we won't be speaking the same language.  There may be more than one way to accomplish this type of behavior and I was hoping to introduce the general concept first so that multiple different strategies could be theorized to adopt it.  If you think multi-sig is the best way to go, great.  I still have reservations that it may not bring all the desired functionality to the table.

Upon setting up the blind wallet for the very first time, the user is prompted to enter two passwords.  Each will encrypt the private keys in the wallet with rounds of AES-256-CBC, for example.  The blind wallet will never again ask for the second password.

This means that upon entering password 1 with your blind wallet, you form a partially decrypted transaction that still requires password 2 to fully decrypt. Why are we doing this?  So that the user never has to enter their full decryption information on a single device again.  They may even set up x-of-y passwords.  Assuming a thief obtains all the information they possibly can from one device, they'll still end up with a partially encrypted wallet.

Each wallet by itself is still incapable of forming completed transactions.  
The blind wallet isn't asking for the 2nd password
The spend wallet doesn't even have the private keys to initiate the process, it only acts as an input for confirmation.

Okay...let's assume that a thief discovers 1 of 2 private keys needed for a multi-signature transaction.  Can he or she initiate a spend attempt using only one of the keys?  If it's not going into the blockchain, how does the owner of both keys see this and realize that one is compromised?

If you're ultimately asking about why a secondary network is necessary at all, it seemed very obvious to me that the bitcoin network itself would be incapable of transmitting partially decrypted transactions, and it would be a fruitless argument to try to convince anyone that it should do so.  If the blind wallet has to communicate some portion of data to the spend wallet, then choose whatever method you think is best that wouldn't rely on a central authority.  A decentralized network seemed more ideal because it would allow an owner to monitor the spend attempts from their wallet, anywhere in the world, without that information having to touch the bitcoin blockchain.  

What this is ultimately trying to accomplish:
1) Creates an environment in which the user never has to enter their full password on a single device
2) Splits up the necessary password so that by design, it can be entered on multiple different devices
3) Allows the owner to see any attempt to move or spend the bitcoin at a single address before it completes, assuming all passwords have not been compromised

And it's trying to do all this without requiring any changes to the bitcoin protocol itself.

It's not too obscure anymore :). I've already explained that in another post (https://bitcointalk.org/index.php?topic=490372.msg5545238#msg5545238) - give it a read and tell me what you think.

What does this model achieve that ECDH doesn't already do?

I have no qualms about what you're doing, and wish you the best of success.  But users are still navigating to a central source (namely your website) to set these up.  I want them to have the ability to do it at home without having to go to a 3rd party website.

It allows for owners to see when an attempt is being made to move their coins, before they're actually moved irreversibly. I have still have not seen a convincing method that will allow an owner to verify when X of their multi-sig keys has been compromised, before the outputs are actually spent.  A multi-sig transaction can't be recorded in the blockchain before it's complete, so how would I know that someone has compromised one or more of the keys required?

To put it simply, this would allow a thief to freely compromise a key and attempt to move the coins without consequence.  Think of it like a tripwire or what you will.

I understand your intent however I don't think your model brings any new mechanics to what we currently have. Whether it is with your model, multisig or ECDH, the transactions has to go through all the relevant signers before it is valid and can be broadcasted.

If all the factors are compromised, the attacker can create a valid transaction and the coins will moved, regardless of the signing method.

Also, both multisig and ECDH behave like your system: they require some sort of non blockchain synchronization channel for all the factors to complete the valid transaction. In this cases, as it is with your model, every relevant signer is made aware of the transaction and has full disclosure of the transaction. The added security of multi factor signature scheme is that every signer can fully audit the transaction, which is what you pretend you do in essence, and is no different for the other models.

As for the crypto, I assume neither of the 2 signers in your model have the full private key. Ima also assume signatures are passed from one signer to the other without any signer being able to recreate the secret of the other one. And lastly, each signer has the full public key to be able to build the wallet's balance and initiate transactions. In the case of a 2-of-2 scheme, this sounds like ECDH to me.

Again, your alternate network to share partial signatures can be used just as well to share multisig or ECDH attempts. What you are truly proposing is a decentralized synchronization network, which in itself is interesting. Add support for other "out of blockchain" message types and you have something.

https://i.imgur.com/aWoL6Mj.png

I'm aware that multi-sig creates a special type of address that needs multiple private keys to spend, but how can I protect an entire local wallet in general with more than one password?

I'm not sure if the question is rhetorical or if you are truly asking how to do such a thing. Multiple factors are desirable precisely because the potential of a local secret security model (as in single factor protection) is exhausted too quickly.

The problem with your presentation is that you have yet to analyze it from a cryptographic standpoint. Once you get through that step you'll see that the most sensible solution for multi factor signature is multi-sig. Your scenario is simple enough that it could be implemented with ECDH too.

You didn't review your "password" model enough. Multiple factors retain their security because no single factor at any point in the process is in possession of the full secret. To encrypt a private key with several layers of encryptions has 2 major flaws:

1) The signature process can only be performed from the top layer down. If the first password was set on your mobile and the second one your PC, you have to start signing with the PC.

2) The biggest flaw: The last signer will have full disclosure of the secret.

Once you realize that, you'll see the existing solutions under another light.