Pages:
Author

Topic: Proposing new feature in Bitcoin protocol to reduce the number of thefts - page 3. (Read 6957 times)

legendary
Activity: 1176
Merit: 1018
One problem with depending upon "lock_time" for security is that it will tie up the funds from the owner when for his own security he may need to access his funds sooner than anticipated.

Tying up, or encumbering one's own funds is and would always be a personal choice.  With freedom comes the freedom to make bad decisions.  It would be up the owner to weigh the pros and cons of trying up the funds.  It sounds to me like you are saying the 'problem' would be people making a choice, and then later regretting it.  Or am I missing something?
hero member
Activity: 658
Merit: 501
One problem with depending upon "lock_time" for security is that it will tie up the funds from the owner when for his own security he may need to access his funds sooner than anticipated.

This service could also be handled off the block with mutisig with a service like copay where the other party or oracle locks the transaction for a certain time period.
legendary
Activity: 4060
Merit: 1303
If flood is a problem, lock and unlock can be charged as any other transaction.

Just go ahead and implement it and do a pull request. That will give everyone time to evaluate the proposal in reality and determine whether this hard fork is justified. 

legendary
Activity: 3416
Merit: 4658
So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.
Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?

And that "addresses" are not spent, "outputs" are.

And that transactions don't have timestamps?

And that the timestamp on a block is unreliable as an indication of current real-world calendar time?

And that the change you are proposing would require so much modification to the way the protocol works that it would likely destroy the consensus system and the fungible nature of bitcoins?
legendary
Activity: 1400
Merit: 1009
So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.
Are you aware that Bitcoin addresses do not exist on the blockchain or in the protocol?
legendary
Activity: 1176
Merit: 1018
I proposed almost the exact same thing in this thread: https://bitcointalk.org/index.php?topic=511881.0;all
At first I titled the thread Transaction reversability would be a good thing, but I some point I realized people were not even reading the original post, and they were just attacking the idea on the title.  That's when I changed it to Transaction reversability would be a BAD thing.
full member
Activity: 224
Merit: 100
You lock the funds. The thief cannot access them and you will become aware if your funds are in danger. You can postpone the transfer as much as you want until the police can locate the thief. If you cannot locate the thief, you can destroy the funds.

Why destroy the funds? It is the same as death penalty in real life: will deter other people to repeat the crime.
IMO, most bitcoin related thefts are done behind TOR and VPNs that do not keep logs, therefore most thefts are not traceable.

Another issue is that this would lead to additional "transactions" needing to be done by the miners without compensation. In order for this to work properly, both "lock" and "unlock" transactions would need to be confirmed by the miners otherwise the network would not know for sure which one is "correct".

This would also make it much easier to launch what would essentially be double spend attacks against merchants that accept 0/unconfirmed TXs. The attack would work like this: You send a TX to a node that a merchant is connected to, and send a "lock" command to a well connected node a few seconds later. If the "lock" command would have a higher priority then a TX (it would have to in order to be effective) then the "lock" command would take precedent over the TX and the merchant would never receive their funds (having the same effect as a double spend). You would then issue an "unlock" command after the 0/unconfirmed TX is "forgotten" by the nodes

Another issue is that this would make it very easy to attack the network. Someone could easily create thousands of BTC addresses, send a very small amount BTC to each of these addresses and then send "lock" and "unlock" commands for each of these addresses. This would likely overwhelm both the miners and the nodes, making it difficult to even get a TX propagated, or if it is propagated to get it confirmed. 
member
Activity: 85
Merit: 10
I've considered that, it is not the same.

Can you explain the difference?
member
Activity: 85
Merit: 10
A 2-of-2 multisignature address would cover your needs, I think.
hero member
Activity: 532
Merit: 500
Dear Bitcoin Developers,

We would like to propose a feature in Bitcoin protocol in order to reduce the number of Bitcoin thefts.

Real world scenario: attacker installs a trojan into your computer, downloads the Bitcoin wallet and keylogs your computer to get the password. The attacker can and will spend all your money and there's nothing you can do about it.

So, we would like to propose this feature to be added to Bitcoin protocol:

A "Time Lock" command for Bitcoin addresses.

    This will function in the same way as a safe does: The owner of the address will announce the network that he/she wishes to lock this address and will require X amount of minutes/days to be unlocked.
     This would mean that the Bitcoin network will require the user to issue the unlock command and wait for the timer to expire before allowing him/her to spend the money from that address. The GUI client must announce the owner that his address has been unlocked and display a countdown timer so he has a chance to take action.

     There's a problem with the above scenario: as the hacker has access to the keys, the owner still cannot stop spending because he/she can lock the money again but the attacker can unlock them, triggering a race that leads only to a draw (permanent lock of the funds) or the attacker to win (as the hackers are dedicated to make software that will trigger their transaction faster or will spend higher commissions to get the transaction processed quicker etc).

Here is the solution to this problem:

    Lock command will also require an emergency backup address. A 2nd lock command issued will not allow to change the emergency backup address. If the attacker triggers the unlock command and the real owner wants the money back, he/she can issue an emergency recover command and the network will send the money to the emergency address (that was set-up when the first lock command was issued).  It is important that transfer will be completed only after the lock timeout expires and the new address will be locked again for the original timeout. This is required in order to give a chance to the real owner to issue the last and final command (if the hacker had managed to get access to the 2nd address as well).
    The last and final command that can be issued by the real owner of the new address will be to destroy the funds. The funds will be destroyed, not sent to the miners. This is important in order to deter the hackers to develop any other techniques to steal the money (for example few days ago I read that they hacked 6 ISPs and redirected the whole hashing power towards themselves). If we do not destroy the funds, we are inviting them to hack our hashing power.


To summarize:

   lock(address, delay, emergency address)
      note: a new lock command, issued while the lock is active, will not accept to change the emergency address or the delay.
   unlock(address, where_to_spend);
      note: a new unlock command will refresh the timer to the original lock command. If a previous unlock command was issued with no address to spend, there will not be accepted any new addresses
   issue_emergency(address);
       will cancel any unlock commands and send the money to the emergency address set with original lock(). emergency address will be locked for the same amount of time as issued by original lock(). No further unlock commands are accepted.
   destroy(emergency_address);
       can be issued only on emergency addresses that are locked. it is important that this transaction to be signed by emergency_address only as we do not want the hacker that has access to our original address to be able to destroy our saved funds.

   

Regards!
Pages:
Jump to: