Set send limit for particular bitcoin address ?

[streamplus]

Hi,

I want know if someone can integrate a send limit for a particular bitcoin address ?

For example, i set maximum send limit: 0.001 BTC in one transaction under 24 hours !

This will prevent stealing big amount of BTC in a major exchanger and even from owners.

Any idea about this, is it possible to implement it on bitcoin core ?

[Xynerise]

Impossible since there no "from" addresses and also addresses don't exist in bitcoin on a protocol level.

[0xuser]

You DEFINITELY can integrate such functionality for your LOCAL Bitcoin Core Wallet, but it's impossible for today to integrate such functionality to entire Bitcoin Blockchain, because it may break current consensus.

So, you can edit Bitcoin Core https://github.com/bitcoin/bitcoin, implement such functionality and even make pull request.

But these steps will setup sending limits only to your modernized local wallet. And if someone steal your private keys, he/she will be able to send all your coins from his/her ordinary wallet.

[streamplus]

You DEFINITELY can integrate such functionality for your LOCAL Bitcoin Core Wallet, but it's impossible for today to integrate such functionality to entire Bitcoin Blockchain, because it may break current consensus.

So, you can edit Bitcoin Core https://github.com/bitcoin/bitcoin, implement such functionality and even make pull request.

But these steps will setup sending limits only to your modernized local wallet. And if someone steal your private keys, he/she will be able to send all your coins from his/her ordinary wallet.

How it can be done ?

Is it possible for a bitcoin fork for example ? and can be applied for any bitcoin address proving the private key to check if he/she own that address ?

[ranochigo]

How it can be done ?

By modifying the Bitcoin fork. The change will ONLY affect whoever is using that client.

Is it possible for a bitcoin fork for example ? and can be applied for any bitcoin address proving the private key to check if he/she own that address ?

It is possible for any client, literally. None of the clients that I know of currently implement such features. You can always modify the code yourself to do so.  If you want to prove that someone owns a Bitcoin address, you can ask them to sign a message with a message that is agreed upon prior to signing. That could merely proof that they have control of the coin in the address at that point of time.

[HeRetiK]

How it can be done ?

Is it possible for a bitcoin fork for example ? and can be applied for any bitcoin address proving the private key to check if he/she own that address ?

All you could do is make your own hardfork, but then you'd end up with an alt on its own blockchain and not Bitcoin.

If you only write a wallet client that enforces such a limit you would have gained nothing, as you would need to implement such a feature on the protocol level. So while your wallet client would check for such a limit, any adversary that wants to steal coins would simply use a wallet that doesn't enforce it.

Alternatively you could try using timelocked transactions and periodically shuffling coins around on an application level. That would be incredibly kludgy though and not necessarily increase security.

[streamplus]

If new altcoin is able to implement this feature, so everyone can set a limit to spend X ALT in the X time etc. ?

Programmatically is it possible in the blockchain technology ? In the way that each one can set that parameters in decentralized way ?

Is there any altcoin based on bitcoin core implemented this feature ?

[bob123]

If new altcoin is able to implement this feature, so everyone can set a limit to spend X ALT in the X time etc. ?

Theoretically, yes. This can be done.

Programmatically is it possible in the blockchain technology ? In the way that each one can set that parameters in decentralized way ?

'Blockchain' is just a data structure.
But to give you a short anwser: Yes, it is possible to be implemented with an underlying blockchain in a decentralised way.

Is there any altcoin based on bitcoin core implemented this feature ?

Altcoins(here: BTC forks) are based on bitcoin, not 'bitcoin core'.
Bitcoin core is just a client(full node / wallet) to access the bitcoin network.

But, no. I am not aware of an altcoin providing such a 'feature'.
What would be the sense of such a feature? What problem does it solve?

[HeRetiK]

Is there any altcoin based on bitcoin core implemented this feature ?

Altcoins(here: BTC forks) are based on bitcoin, not 'bitcoin core'.
Bitcoin core is just a client(full node / wallet) to access the bitcoin network.

But, no. I am not aware of an altcoin providing such a 'feature'.
What would be the sense of such a feature? What problem does it solve?

It's mentioned in the original post:

This will prevent stealing big amount of BTC in a major exchanger and even from owners.

I'm not sure if such a measure would be all that effective though. Keep in mind that the owner of the coins would be affected by this withdrawal limit as well, which means they would have no way to move their coins to safety should a breach occur -- as the adversary would already have used up the contingent of that daily limit. So while an adversary could not clean out a wallet in one fell swoop, you'd have a daily race between the adversary and the original owner of the coins on who manages to get the daily contingent of coins out first.

Another challenge is the following: How is the limit defined? If it's (a) hard coded as part of the protocol, you have a crippled payment network that depending on the exchange rate supports either only too small denominations or has limits that are too high to make any sense for protection purposes. If it's (b) defined by the address owner, ie. the holder of the private key, the adversary can easily lift the limit up themselves.

[bob123]

What would be the sense of such a feature? What problem does it solve?

It's mentioned in the original post:

This will prevent stealing big amount of BTC in a major exchanger and even from owners.

I somehow completely ignored that  


But this doesn't make sense.

1) Exchanges can create a withdraw limit on appliaction level (e.g. application which checks the current withdrawn balance from their wallet -> allow/refuse)

2) It also doesn't prevent coins from being stolen from a laysman.
If Alice has 10 BTC's 'sitting on address' X. And Bob has been able to get Alice's corresponding private key.
Bob withdraws the maxium amount possible (e.g. 1 BTC / 24 hours). -> 9 BTC remaining.
Now Alice has to wait 24 hours until she can 'save' 1BTC. But Bob is a smart boy and has created a script which will automatically create another transaction after these 23:59:59 hours have passed.

This will require Alice to also code a script which (hopefully) will create the TX (with an extraordinary high fee) before bob's script does create his transaction. Thats basically a race condition.


Additionally:
I wouldn't store my BTC on an address where only (X btc/ Y hours) can be withdrawn from.
I'd rather create multiple addresses which all holding a maximum of X BTC. And i guess the majority of users with X+ BTC would handle it this way too.

This creates more problem than it is going to solve. How to pay for a house? Wait 20 days, paying 1 BTC each day? How shall an exchange utilize a cold wallet? With 10.000+ addresses rotating every Y hours?


IMO, this is a bad approach.
The owner should have full control over his funds. And the security should be handled by the user only (which requires the network to be fully secured itself, of course).

[streamplus]

What would be the sense of such a feature? What problem does it solve?

It's mentioned in the original post:

This will prevent stealing big amount of BTC in a major exchanger and even from owners.

I somehow completely ignored that 


But this doesn't make sense.

1) Exchanges can create a withdraw limit on appliaction level (e.g. application which checks the current withdrawn balance from their wallet -> allow/refuse)

2) It also doesn't prevent coins from being stolen from a laysman.
If Alice has 10 BTC's 'sitting on address' X. And Bob has been able to get Alice's corresponding private key.
Bob withdraws the maxium amount possible (e.g. 1 BTC / 24 hours). -> 9 BTC remaining.
Now Alice has to wait 24 hours until she can 'save' 1BTC. But Bob is a smart boy and has created a script which will automatically create another transaction after these 23:59:59 hours have passed.

This will require Alice to also code a script which (hopefully) will create the TX (with an extraordinary high fee) before bob's script does create his transaction. Thats basically a race condition.


Additionally:
I wouldn't store my BTC on an address where only (X btc/ Y hours) can be withdrawn from.
I'd rather create multiple addresses which all holding a maximum of X BTC. And i guess the majority of users with X+ BTC would handle it this way too.

This creates more problem than it is going to solve. How to pay for a house? Wait 20 days, paying 1 BTC each day? How shall an exchange utilize a cold wallet? With 10.000+ addresses rotating every Y hours?


IMO, this is a bad approach.
The owner should have full control over his funds. And the security should be handled by the user only (which requires the network to be fully secured itself, of course).

So, you will stay have full control of your address since you have just to change the parameter and remove the condition from your private key so you can pay for house etc. Please read my post well to understand more the idea.

If someone get your private key, sure you will lose everything, but this will prevent some attacks like:
- steal everything from JSON RPC api for web services
- if someone have access to your phone or desktop client, he cant send everything

The idea can be developed more to cover more cases.

But  the main question remain, how it is possible programmatically to add this feature.

[HeRetiK]

If someone get your private key, sure you will lose everything, but this will prevent some attacks like:
- steal everything from JSON RPC api for web services

Exchanges should keep everything in cold storage to begin with. If you can empty their wallets using their API they already have fucked up security so badly that no rate limiter will be able to help them.

- if someone have access to your phone or desktop client, he cant send everything

Of course they can, because then they simply increase the withdrawal limit before stealing your coins.

But  the main question remain, how it is possible programmatically to add this feature.

1) Keep track of outgoing transactions within the last 24 hours
2) Whenever a new transaction is made, accumulate the outgoing transaction amount and check against it
3) Publish the new transaction on the blockchain if the outgoing transaction amount is smaller than the withdrawal limit minus the accumulated amount of outgoing transactions within the last 24 hours
4) Otherwise display user message

[streamplus]

If someone get your private key, sure you will lose everything, but this will prevent some attacks like:
- steal everything from JSON RPC api for web services

Exchanges should keep everything in cold storage to begin with. If you can empty their wallets using their API they already have fucked up security so badly that no rate limiter will be able to help them.

- if someone have access to your phone or desktop client, he cant send everything

Of course they can, because then they simply increase the withdrawal limit before stealing your coins.

But  the main question remain, how it is possible programmatically to add this feature.

1) Keep track of outgoing transactions within the last 24 hours
2) Whenever a new transaction is made, accumulate the outgoing transaction amount and check against it
3) Publish the new transaction on the blockchain if the outgoing transaction amount is smaller than the withdrawal limit minus the accumulated amount of outgoing transactions within the last 24 hours
4) Otherwise display user message

Thank you for your time.

They cant since private key is required to set limit for an address.

For json rpc server this will limit the impact of the attack of course, since from json rpc you cant get private key of addresses etc.

If someone bypass send limit ine the client side, what is the appraoch to take ? How the block chain will check that ? How the other clients trust the transaction ?

[HeRetiK]

Thank you for your time.

They cant since private key is required to set limit for an address.

If they can send coins from the wallet, the wallet contains the private key. If the wallet doesn't have access to the private key, it can't send any coins.

If someone bypass send limit ine the client side, what is the appraoch to take ? How the block chain will check that ? How the other clients trust the transaction ?

The Bitcoin blockchain won't check for these limits because it neither knows nor cares about these limits. The other clients won't check for these limits because they as well neither know nor care about these limits. If someone bypasses the send limit on the client side there's nothing you can do about it.

If you really want to have absolute security about the withdrawal limits being enforced, all you can do is create an alt that does so on the protocol level.

[bob123]

If someone get your private key, sure you will lose everything, but this will prevent some attacks like:
- steal everything from JSON RPC api for web services
- if someone have access to your phone or desktop client, he cant send everything

This doesn't make sense. If your mobile/desktop client doesn't contain the private key, it is not a fully functional wallet. Where is the private key stored in your 'concept' ? 

But  the main question remain, how it is possible programmatically to add this feature.

The 'algorithm' itself is trivial. See HeRetiK's pseudo code for an almost-finished implementation.

For json rpc server this will limit the impact of the attack of course, since from json rpc you cant get private key of addresses etc.

How is this related to your 'maximum send limit idea' ? 

[streamplus]

How is this related to your 'maximum send limit idea' ? 

If you set for your address the condition: Only 0.3 ALT for 24 hours, then attacker can only get 0.3 ALT and not your full balance throue the JSON RPC API. Since he can't access to the private key from the API, and then he can't manage to modify the condition since the private key is required for that.

> if someone have access to your phone or desktop client, he cant send everything

This doesn't make sense. If your mobile/desktop client doesn't contain the private key, it is not a fully functional wallet. Where is the private key stored in your 'concept' ?

Of course the private key will be there, but i am speaking about regular user who have access to your phone ... he can't send the full balance from your client ... since he must have knowledge on how to get the private key from the mobile phone etc ... and even for hacker this make the process longer, just the time to recover your phone etc ...

If you really want to have absolute security about the withdrawal limits being enforced, all you can do is create an alt that does so on the protocol level.

I am speaking about a bitcoin fork (Altcoin), how someone can manage to integrate this feature on it ?

Is there any altcoin that integrated similar function ?

Any documentation in this way ?

[simplexum]

how we do it:

separate tx signer into independent node, that periodically connects to the main system to download transaction proposals, sign them and upload signatures. you protect this node to the maximum degree possible. can put it behind TOR so the attacker will have serious difficulties locating it.

make the signer track the spends and enforce money flow limits (in satoshi per second, and in total amount). it refuses to sign transactions that exceed the limits. limits are per-key, and if the key is HD, the limit is enforced for any descendent keys, collectively

for limiting the spending speed, we use (a variation of) an algorithm similar to that is used for network traffic shaping (https://en.wikipedia.org/wiki/Leaky_bucket), but with satoshis instead of bytes