Topic: Keys with withdrawal limit (Read 1758 times)

I really like the 2FA aspect of using a 3rd party co-signing service and it wouldn't need to be coupled with withdrawal limits (which users can do on their own, anyway, as per my example earlier).

Support for advanced things like CoinJoin would be an added bonus to the 2FA aspect.

I proposed that upthread.  The service actually wouldn't want to give you their private key to the user as they lose deniability in the event something adverse happens.  The user could "overspend" and then claim they were hacked and the service failed to stop it.  Service can't prove they didn't sign the tx, brand and reputation suffers.  This concept goes beyond just this example, only one entity should have access to a single active private key.

However there is an easy work around with no loss of functionlaity.  Just make it a 2 of 4 key multi-sig and use two override keys.
Generate Kepair 1 & 2, print them out, put them in a safe.  This is your "override" key(s).
Generate keypair for your wallet.
Service will generate a keypair but send you only the public key.

Generate multi-sig address which requires 2 of the 4 keys to sign and the entities produce four unique key pairs (SERVICE, WALLET, OVERRIDE1, OVERRIDE2).

Combinations used:
WALLET + SERVICE = normal operation
OVERRIDE1 + OVERRIDE2 = override the service (lost wallet and/or service goes rouge)

The service can not only provide a spending limit but they also can provide a form of 2FA.  User receives a text message from service on a cellphone or other device (not same device as wallet) from the service to authorize a signing.  If wallet is compromised, user can decline and attacker can't spend even a single satoshi.  When overlimit the service would refuse to sign and notify user on the same device.

Normal Use:
User creates and partially signs tx.
Partially signed tx is sent to service.
Service Requests approval from user via 2FA device.
User approves.
Device adds signature and broadcasts.

Overlimit:
User creates and partially signs tx.
Partially signed tx is sent to service.
Service deletes partially signed tx as invalid.
Service notifies user of over limit rejection via 2FA device.

Compromised wallet:
User creates and partially signs tx.
Partially signed tx is sent to service.
Service Requests approval from user via 2FA device.
User declined.  (Also possible here for an option for user to report wallet compromised which will auto-reject all requests).
Service deletes partially signed tx as invalid.

Override:
User removes paper wallet with two override keys.
User generates a tx spending all funds from this address.
User signs with both keys.
User broadcasts to network.



Why do we need an override key?
In case either the wallet is destroyed or the service becomes malicious (freezes funds refusing to sign any transactions) either for personal gain or possible under threat of violence by a nation state.

Why two override keys?
Technically you could just have one override key and also use wallet key but if your wallet is lost/destroyed without backup you would be unable to spend funds.  Initially I said this can be accomplished by having ie be (wallet AND service) OR (override) but it is easier done by requiring any two keys and have two override keys.  The two override keys could be printed on the same sheet of paper (simply key 1 & key 2).

Why not share the same key between service and override?
Deniability.  There is no way to know WHO authorized the override is keys are shared.  By using separate keys the blockchain becomes irrefutable proof of which entity or entities authorized the transaction.

This seem like a lot just for a single address.  Any way to extend it to multiple addresses?
Very easily using HD wallets.  Instead of a single key pair for each four keys (wallet, service, override1, override2) they would be HD public and private seeds.  The user and service would share the public seeds, keep their private seeds secure and could deterministically generate as many P2SH addresses as needed.

What -could- be done is this:
An online service advertises a "daily limit" service. You register an account on that service, you fix your allowance, and they send you a private-public key pair.

You print the private key, and keep it locked.

You generate another private-public key pair, for use with your own hot wallet. (you also print a copy and keep it locked too)

Now you send all your funds to a multisig address which must be signed by both your key, and the service's key.

Form now on, when you want to spend coins, your wallet generates a transaction, signs it, forwards it to the "daily limit" service. The service inspects the transaction, verifies the amount transferred, and it it is below your daily quota, signs it and broadcasts it. It will confirm after a few minutes.

Now, if:
1. Your wallet is compromised, an attacker cannot spend more that your daily limit. After that the daily limit service refuses to sign.
2. If the service is compromised, the attacker cannot spend your funds because he doesn't know your private key.
3. Only if both your wallet AND the service is compromised then the attacker can steal all your funds.

Now, if your wallet is compromised, or if the service goes down, or in any case you want to move more money that what your daily limit allows, not a problem! You have all the necessary private keys to initiate any transaction locked in a safe place; you can retrieve them.

Thinking about it, the apparent wishes of the OP can be fulfilled using nLockTime in the manner described below (specifically the second proposal).

Call it the Allowance Proposal:

Step 1: Create a number of inputs of size equal to the daily allowance. The keys to these inputs are considered "cold", i.e. contained in a cold wallet (possibly controlled by the Master of Money, aka MOM).

Step 2: Create one transaction for each of these inputs (and sign with appropriate cold keys) with the outputs set to "hot" keys and an nLockTime corresponding to the allowance release rate (e.g. [currentBlockNumber + 144*n] for a daily allowance).

The effect thus far would be a controlled release of funds from the cold wallet to the hot wallet.

To avoid the risk of these nLockTime-in-the-future transactions being refused by miners and funds thus not being (reliably) made available in the hot wallet, the transactions could simply be stored by you yourself and only released to the network for confirmation when the allowance is needed.

Extending to a more proper Fixed Daily Limit Proposal would simply require purging pending transactions from the previous day. The device holding your hot wallet and charged with purging would not even have to be online (offline device producing QR code for transaction to be read by an online device, such as your phone).

It's worth noting that regardless of whether the transactions with future nLockTimes were sent to the network (naughty kid tries to spend a whole year's worth of allowance), the cold keys could simply be used to make a new transaction for immediate execution for the allowance outputs (MOM revokes allowance).

From a philosophical perspective I hate that banks claim they are protecting me by cutting me off from my own money. This is not to protect me, it's to protect their weak security from losing all your money. And to keep you from withdrawing your money in the event the bank needs it.
During the 2008 collapse I took all my money out of the bank. They argued with me for 30mins. about why it was unnecessary.  Now that the story has been told I know that the U.S. was within HOURS of shutting down the ATM network. They feared a run as people realize that their money is not going to be available. I did not trust them then, and I certainly don't now.
No bank is going to provide better security than I can. I have never lost a Satoshi, yet I just got my new credit card to replace the account stolen from Target. Thanks but no thanks, I do not want my security provided by someone else.

It should be possible to prepare the unspent outputs to the correct size (which would just require another transaction beforehand).

but i dont really like that idea (i dont like it that my bank does the same). wouldnt it be better to just split your bitcoin holdings to different addresses and put them in coldstorage.

whenever you need money you just pick one key from there

The bitcoin protocol requires that a previous unspent output be spent in its entirety when it is used to supply value to a transaction.  So if there is an unspent output for 100 BTC that is being used to fund a transaction that will be sending 0.001 BTC to someone, the entire 100 BTC is "spent", with 0.001 BTC being sent to the "someone" and 99.999 BTC being sent to a brand new unspent output that the spender's wallet has the private key for.

If you are going to implement a protocol that somehow implements a "spending limit", then you are going to have to find a way to only spend a portion of the previously unspent input.  If that is your plan, then you need to explain how you will solve the double-spending problem that bitcoin solves in a decentralized way.

Note that in bitcoin, the receiver of the bitcoins does not get to decide what the requirements are for sepnding the bitcoins.  Those requirements are created by the sender.  If I send you 1 BTC.  Then what my wallet does is create a transaction that states that the 1 BTC in value that it is placing in an output can only be spent when an ECDSA signature (using the Secp256k1 curve) is provided using the ECDSA private key for the specific "address" that I've placed in the output.  This is why you can "receive" bitcoin even when your wallet isn't running (or even if your "wallet" has never been more than a piece of paper).

Explain exactly how the sender that sends you your cryptocurrency will place the dual nature signatures on the transaction in a way that will allow a specific "spending limit"?  Will the sender choose for you what your spending limit will be? Will there be a fixed "spending limit" per-defined by the protocol for everyone regardless of the exchange rate of crypto-currency?

Just randomly saying "I want a new protocol that will implement a user selected spending limit at the protocol level" does nothing to provide a workable solution on how to do that.  For decades people wanted a "protocol that will solve the double-spending problem for cryptocurrencies in a decentralized way". A solution was finally presented in 2009.  If your desired protocol could be created, it very well may take many decades to find an appropriate solution that is also decentralized, and even then it will only happen if a significant number of "experts" all consider the effort worth the research effort.

If all you have is a hammer, every problem looks like a nail.

This is applicable in that bitcoin and fiat/banking are very different in nature, so trying to replicate the exact behavior of one in the other is likely to be suboptimal.

Regardless, the "fixed daily withdrawal limit" could probably be implemented without requiring changes to the bitcoin protocol (although there might be some transaction relay / mempool issues, that would need sorting out).

nLockTime would seem like a good place to start.

You are right, but it still seems pretty inconvenient to have to rely on other parties to simulate a withdrawal limit. It should be enforced by simple math so that no one except the owner of the coins needs to be involved in the transactions. It's not like 3rd parties are going to do it for free.

Bitcoin is insanely complex at a protocol level, so is http but users won't operate at the protocol level.

It could be a simple as I spend some coins, I get a text on my phone asking me to confirm, it goes through.  I tried to spend too much I get a text advising me the security service has blocked the transaction.  The service can't hijack my phones, or act against my interest (court order to freeze the funds) as I can always override the action by using the override key.

To make it that seemless will require a lot of good software.  That is often the heart of any good software development making something complex seem incredibly simple.

That is still way more complicated than it should be and it doesn't completely overcome the issues mentioned by conroe64.

What bitcoin needs is some type of script functionality where you can have "partially spent" or "partially solved" outputs instead of just spent and unspent outputs. Users should have the ability to create scripts which limit the speed at which coins can be spent. Maybe something like that can be done with the script system, but I doubt it.

The mini-blockchain wiki has a page related to this topic.
A method for allowing custom user-defined withdrawal limits:
http://bitfreak.info/mbc-wiki/index.php?title=Withdrawal_limit

But there's no way something like that could work with the current bitcoin protocol.

Multi-sig is a lot more powerful than that.  You can arrange constructs like A and (B or C or D) for example.  If you have key A then you need only one of your three friends to "co-sign" but even all three together can't steal your funds.   Using a reverse arrangement you could have an override key (A AND B) OR C.  You have key A, and your two factor security company has B but you don't trust them completely so in a secure location you have an encrypted copy of key C which can be used to transfer without the need for a second party.

The key is making all this easy to use, functionality, and seamless to the end user.  That is where a lot of work needs to be done.  However multi-sig is no substitute for common sense.  You say multiple wallets is too much of a hassle.  Do you think someone like Warren Buffet would want to walk around with $28 billion in cash on his person even if he could?  There is absolutely no reason to have one wallet for everything.   You don't do that right now.  I am pretty sure 100% of your liquid wealth isn't sitting in you physical wallet.  I mean security starts with compartmentalizing risk.  Banks even do it.  The teller will only have so much cash, the cash safe on the floor will have more, the vault has even more but there it is broken into different locked cash containers.   A major bank that may have $20M in cash just doesn't have $20M in cash stuffed into the teller drawers because it would be a pain to use multiple wallets. 


Still I think I see a problem in your response.  You said keys to unlock a wallet.  There is no such thing.  There is one private key per address (or multiple for multi-sig P2SH).   Wallets have hundreds or thousands of keys.  Wallets are protected by passphrases and encryption but that has nothing to with the bitcoin protocol.  If you are thinking otherwise this may be why your "issue" and proposed solution doesn't seem to make any sense to anyone else.

I'm kind of confused by these replies. In case this isn't understood, I'm proposing a change to the bitcoin protocol. That is why I have to "invent my own protocol", it's so I can communicate these ideas. Maybe I didn't explain in enough detail the issues that I see with bitcoin, even with multi signature addresses. I tried to give an explanation as to the problem I see with bitcoin in the first paragraph of my very first post.

As far as the proposed solutions, I didn't see any that seemed satisfactory to me. Using multiple wallets would involve constantly reaching into the cold storage wallet anytime new funds are needed. It would be like having a vault that your constantly opening and closing every few days. Logistically, this would be a nightmare.

In addition, using multi signature addresses gives third parties much more control over your funds than is desirable. If their key is needed to unlock the wallet, a third party can withhold it, and freeze your funds. If enough third parties hold keys to unlock your wallet, they can collude together to steal your funds.

The idea I thought of, having different types of keys with different privileges, should solve these issues and provide much more security than can be achieved right now. I thought it was a novel idea, which is why shared it. I apologize if, in your opinion, it is not.

conroe64 it seems to me what you are suggesting is multiple wallets. A hot wallet that holds small amounts and a cold wallet that has the rest. The cold wallet could be a multisig implementation where multiple people hold the private keys and all or most of them have to cooperate to sign a spend transaction.

Listen to kjj and wheatstone.

This is often known as an xy problem
http://meta.stackoverflow.com/questions/66377/what-is-the-xy-problem

Proposing solutions for a system you don't understand is almost never successful.

conroe64,

It's unclear what what exact problem you are trying to solve with these very convoluted solution proposals. You premises seem flawed and the issues you present don't really reflect the way bitcoin works.

Try to very clearly formulate the problem, cutting it to the bone. Forget EVERYTHING about how bitcoin works and focus purely on the problem. After you've established the problem, I'm sure any number of people (myself included) would be more than happy to discuss solutions.

You have some basic research to do.  Bitcoin does not work at all like you think it does.  Your questions are not answerable, and inventing your own terminology is not a winning strategy when you are asking for help.

Is it easier, then, to create a one time use key? With a set of one time use keys, that had a time restriction, you could produce a set of 3650 keys for the next year (365 days x 10 keys per day). Each one of these keys could have a limit of say $30 worth of bitcoin, and only work on a given day. So you'd have 10 $30 keys that would work on January 1st, 2015, 10 more on January 2nd, 2015, etc.

On another note, I don't like the idea of using a standard multi-sig and having a bank as a trusted party, because what if the bank decides to freeze you out? They don't get to spend your funds, but they can still stop you from spending it.

With a master key and a bunch of companion keys, this wouldn't be an issue, because you could give out companion keys to many "trusted" third parties (who you may not trust too much), who are all independent of each other. So for example, you could set up the address so 1 master key and 1 companion key would unlock the funds, but 2 companion keys could not and hand out companion keys to a USA institution, one in Japan, a trusted relative, etc.

conroe64,

Bitcoin doesn't work the way you appear to believe it does. (And neither does the bank.)

In fact, bitcoin is much safer than the bank in this scenario, although added security can be set up with banks to increase the difficulty of retrieving funds (adding steps, including extended verification).

In any event, the robber in your example will be able to look up the bitcoin amount associated with each key. Even if it were possible to construct a script with limited fund access (which doesn't make sense, regardless, since the entire input is spent regardless of how much is transferred where), the robber would know that you had given him the "limited access key" and would simply proceed to force the master key out of you.

The simplest solution in the case of bitcoin would be to have multiple wallets, each with a limited amount of funds. Unlike with credit cards or checks, it is not possible to get more out of a bitcoin input than the funds available. Since there is no way for the robber to know how many wallets you have, he would have no idea if you were holding back (although any sufficiently motivated robber might just continue to use the $5 wrench until you are dead, regardless of whether your wealth is in bitcoins, dollars, gold, or whatever).

Scripts do not have access to amounts and addresses, so currently this can be done. It can be simulated with multisig and a trusted party. Banks could offer this service if they wanted. Experimentation with this would be a good first step before deciding to extend the scripting system.