Bitcoin feature suggestion - Address Rule

[btcKaboom]

Hi guys
I have a suggestion for a new bitcoin feature
Since we can store the wallet balance in the chain, what about some address rule?

This would mean you can setup things like:

• Maximum Amount to send per day/month etc
• Specific time of day which transaction is allowed to occur
• Whitelist of address to send to
• Charity donation address for each transaction

Transaction would be rejected if it broke the rules

Think of any more? I think these would help with bitcoin security, stops people zapping your coins to nowhere
So I could have my long term storage address, can only send to my daily expense address, max .5 per day.

This would require separate verification than just the private key to modify.

What do you think

EDIT
here is how i think it could work:

Create a new address
Send a special type of transaction - Rule Transaction
The rule transaction is stored in the blockchain
The client is given a rule key to write down and isn't stored digitally
Then miners look up rules of the address before confirming transactions

To change/remove rules, you do another transaction to remove the rule.
When you put on a new rules, a new rule key is generated and you discard the old one.

[Relnarien]

Hi guys
I have a suggestion for a new bitcoin feature
Since we can store the wallet balance in the chain, what about some wallet settings?

This would mean you can setup things like:

• Maximum Amount to send per day/month etc
• Specific time of day which transaction is allowed to occur
• Whitelist of address to send to
• Charity donation address for each transaction

Transaction would be rejected if it broke the rules

Think of any more? I think these would help with bitcoin security, stops people zapping your coins to nowhere
So I could have my long term storage address, can only send to my daily expense address, max .5 per day.

This would require separate verification than just the private key to modify.

What do you think

Seems more like unnecessary redundancy to me. The Bitcoin client can't do anything with your wallet.dat file as long as you encrypt it. If you have a keylogger or any other malware on your terminal, then none of those security features would matter since malware can just as easily take your wallet.dat file along with your password. The only security issue that your suggested features could potentially help with is against malware that replaces your clipboard with a malicious entity's own Bitcoin address, which one can detect easily if one pays careful attention to what he/she is doing. But like I said, malwares usually steal the wallet.dat files themselves, which means all of those features would just be unnecessary bloat in the code.

[btcKaboom]

well the thing is you would not change the settings very often, or ever,
maybe the settings are set when the address is created, cannot be changed
even if there was a password of some sort you wouldn't need it on your computer

i think security and redundancy go together quite well

besides the security, i think there are heaps of cool things you can do with that

edit - i for one would like to be less reliant on cold storage, it just makes things inconvenient.
this is like a middle ground between cold storage

[Rocket Launcher]

yes agree to secure of wallet with about biggest fraud of commpany or hacker attack
as we know a lot of hacker can do anything they want .

[Relnarien]

well the thing is you would not change the settings very often, or ever,
maybe the settings are set when the address is created, cannot be changed
even if there was a password of some sort you wouldn't need it on your computer

i think security and redundancy go together quite well

besides the security, i think there are heaps of cool things you can do with that

edit - i for one would like to be less reliant on cold storage, it just makes things inconvenient.
this is like a middle ground between cold storage

You seem to be missing the point. Once your wallet.dat file is compromised, then your attacker can just load it in one of the many existing Bitcoin clients. And you can't hardcode those suggested "features" into the wallet.dat file itself without making it incompatible with other Bitcoin clients. Hackers can hack both wallet.dat files and Bitcoin clients. Those are 2 different things.

[btcKaboom]

You seem to be missing the point. Once your wallet.dat file is compromised, then your attacker can just load it in one of the many existing Bitcoin clients. And you can't hardcode those suggested "features" into the wallet.dat file itself without making it incompatible with other Bitcoin clients. Hackers can hack both wallet.dat files and Bitcoin clients. Those are 2 different things.

i meant put the settings in the block chain somehow, just like the balance is stored on the chain not in wallet file.
the miners look at the rules for an address before they do the transaction

it could work like this

create a new address with your rules, you get given a rule key and private key
rule key you write down its not stored on the computer
so, its a little bit like cold storage, but still usable in a convenient way
so even your wallet got compromised by a hacker, they can only steal what your rule allows

so then you wanna change your rules, create a new address and use the rule key to unlock the address and transfer to the new one

[R2D221]

Since we can store the wallet balance in the chain [...]

First of all, wallet balance is NOT stored on the blockchain. “Balance” is calculated by adding all the inputs and subtracting all the outputs.

This would mean you can setup things like:

• Maximum Amount to send per day/month etc
• Specific time of day which transaction is allowed to occur
• Whitelist of address to send to
• Charity donation address for each transaction

Transaction would be rejected if it broke the rules
[...]
This would require separate verification than just the private key to modify.

This could only be useful for self control (so you don't spend your life savings), or for parental control in case your kids use your computer too often. The reason this can't work against a hacker stealing your coins is that if those features are at the wallet level, then you just need to get the private keys and load them in another wallet, and then spend them. For this to be effective, it would have to be done at the protocol level (which I think it's too complex to include, but maybe someone knows better).

[Envrin]

These types of things would be up to the client and/or web wallet service you're using, and not so much the bitcoin protocol.

[Relnarien]

i meant put the settings in the block chain somehow, just like the balance is stored on the chain not in wallet file.
the miners look at the rules for an address before they do the transaction

it could work like this

create a new address with your rules, you get given a rule key and private key
rule key you write down its not stored on the computer
so, its a little bit like cold storage, but still usable in a convenient way
so even your wallet got compromised by a hacker, they can only steal what your rule allows

so then you wanna change your rules, create a new address and use the rule key to unlock the address and transfer to the new one

The blockchain functions more like a ledger than a spreadsheet database. To put it simply, if you wanted to transcribe it to human-readable form, it would read something akin to "Jan 1, 2014, 00:00:00, Generated 50 BTC, 1BitcoinAddress001 sent 10 BTC to 1BitcoinAddress002". Clearly, you believe that the blockchain contains a collection of all generated Bitcoin addresses, which is simply not the case. That is why your proposed idea will not work at the protocol level.

You can always tweak the code of any Bitcoin client on your own to satisfy your need for extra security. However, a smart hacker would just bypass your client and steal your wallet directly.

Stick to using a cold storage solution. Even if they somehow work, clients with fancy features are still only as secure as the person using them.

If you're concerned about hackers you could use a multisig address (maybe 2-of-2 or 2-of-3) and have each address on different computers. You could also send a transaction with an nLockTime parameter and make those coins unspendable until a certain point in the future (If I understand that correctly).

Please quote the post that you are replying to, not just the last one on the thread because it's easier to get to. If you don't, then you look like a spambot scanning the last post for keywords and posting randomly generated replies. Although, judging from your post history, this recent post does seem highly suspect.

[btcKaboom]

Clearly, you believe that the blockchain contains a collection of all generated Bitcoin addresses, which is simply not the case. That is why your proposed idea will not work at the protocol level.

Well, bitcoin already implements something like a rule, which is that someone can't spend more than the balance of an address.
I assume it does this by having a list of all transactions and calculating the balance.

So, the bitcoin client can send a special transaction which contains the rule, rather than an amount to spend.
Then that transaction can be seen by the miners when they confirm new transactions from that address.

[MechaLeary]

Please quote the post that you are replying to, not just the last one on the thread because it's easier to get to. If you don't, then you look like a spambot scanning the last post for keywords and posting randomly generated replies. Although, judging from your post history, this recent post does seem highly suspect.

Sorry about that, you're right I probably should've quoted directly in response to the title post rather yours; my mistake.

[R2D221]

So, the bitcoin client can send a special transaction which contains the rule, rather than an amount to spend.
Then that transaction can be seen by the miners when they confirm new transactions from that address.

I think Ethereum, with its Turing-complete scripting, will be capable of doing this kind of transactions.

[justusranvier]

Since we can store the wallet balance in the chain

We don't and we can't, so the rest of your suggestion is invalid.

[cr1776]

Since we can store the wallet balance in the chain

We don't and we can't, so the rest of your suggestion is invalid.

True. 

Likewise, if I understand what you are suggesting, I do not believe this adds anything in terms of security that could not be done at the application level vs the protocol level.  In either case (creating/changing your rules with your private key etc) vs bitcoin as it is now, if someone has your private key, you are screwed because they'll just change your rules and then transfer your coins.  A root cause of insecurity is protecting your private keys and adding these rules doesn't help with that. 

[btcKaboom]

Since we can store the wallet balance in the chain

We don't and we can't, so the rest of your suggestion is invalid.

True. 

Likewise, if I understand what you are suggesting, I do not believe this adds anything in terms of security that could not be done at the application level vs the protocol level.  In either case (creating/changing your rules with your private key etc) vs bitcoin as it is now, if someone has your private key, you are screwed because they'll just change your rules and then transfer your coins.  A root cause of insecurity is protecting your private keys and adding these rules doesn't help with that. 

I must be missing something - explain to me how bitcoin stops people spending more than the balance of their address.

The rule key is required to remove a rule.
The rule key is more secure than a private key, because you dont need to use it all the time, and it only ever gets used once - to remove a rule.

[cr1776]

Since we can store the wallet balance in the chain

We don't and we can't, so the rest of your suggestion is invalid.

True. 

Likewise, if I understand what you are suggesting, I do not believe this adds anything in terms of security that could not be done at the application level vs the protocol level.  In either case (creating/changing your rules with your private key etc) vs bitcoin as it is now, if someone has your private key, you are screwed because they'll just change your rules and then transfer your coins.  A root cause of insecurity is protecting your private keys and adding these rules doesn't help with that. 

I must be missing something - explain to me how bitcoin stops people spending more than the balance of their address.

The rule key is required to remove a rule.
The rule key is more secure than a private key, because you dont need to use it all the time, and it only ever gets used once - to remove a rule.

1. You are missing something.  The nature of the protocol ensures no one can spend more than the balance that an address contains. If you could overdraw an address bitcoin would be worthless. (Using the concept of balances at addresses as shorthand.). If you are talking about something you didn't say, the total balances at any address for which you control the private keys, your client can enforce whatever rule you want, but the protocol does not.

2. By default Bitcoin Core doesn't reuse addresses and consequently private keys either.  Hence change addresses, new addresses for each transaction etc. Reusing addresses can cause security issues such as the android PRNG issue for reused addresses so it is already not recommended.  If that is the concern, a rule disallowing address reuse might be considered (I don't think it is a good idea either, it too could be enforced client side).

Anyway, if your computer is compromised you are screwed either way.  The difference in security between having a second layer at that point is de minimis.

As an aside, the odds of this being adopted by everyone are infitesimal when you can accomplish the same thing (or more) with good security on the client side. It is like adding email at the tcp/ip layer vs on top of it with SMTP.  You want the lower layers to be simple so they are easier to debug and here it is even more important since if you lose an email it can be resent, vs potentially billions of dollars at stake with bitcoin. 

You can always implement what you suggest and then see how many people will adopt it.

[btcKaboom]

Since we can store the wallet balance in the chain

We don't and we can't, so the rest of your suggestion is invalid.

True. 

Likewise, if I understand what you are suggesting, I do not believe this adds anything in terms of security that could not be done at the application level vs the protocol level.  In either case (creating/changing your rules with your private key etc) vs bitcoin as it is now, if someone has your private key, you are screwed because they'll just change your rules and then transfer your coins.  A root cause of insecurity is protecting your private keys and adding these rules doesn't help with that. 

I must be missing something - explain to me how bitcoin stops people spending more than the balance of their address.

The rule key is required to remove a rule.
The rule key is more secure than a private key, because you dont need to use it all the time, and it only ever gets used once - to remove a rule.

1. You are missing something.  The nature of the protocol ensures no one can spend more than the balance that an address contains. If you could overdraw an address bitcoin would be worthless. (Using the concept of balances at addresses as shorthand.). If you are talking about something you didn't say, the total balances at any address for which you control the private keys, your client can enforce whatever rule you want, but the protocol does not.

2. By default Bitcoin Core doesn't reuse addresses and consequently private keys either.  Hence change addresses, new addresses for each transaction etc. Reusing addresses can cause security issues such as the android PRNG issue for reused addresses so it is already not recommended.  If that is the concern, a rule disallowing address reuse might be considered (I don't think it is a good idea either, it too could be enforced client side).

Anyway, if your computer is compromised you are screwed either way.  The difference in security between having a second layer at that point is de minimis.

As an aside, the odds of this being adopted by everyone are infitesimal when you can accomplish the same thing (or more) with good security on the client side. It is like adding email at the tcp/ip layer vs on top of it with SMTP.  You want the lower layers to be simple so they are easier to debug and here it is even more important since if you lose an email it can be resent, vs potentially billions of dollars at stake with bitcoin. 

You can always implement what you suggest and then see how many people will adopt it.

stop being so negative

[R2D221]

stop being so negative

Stop trying to be so positive about something you don't understand how it works.