Hiding your bitcoin behind a timelock AND "m of n keys" at the same time?

[coastermonger]

As much as I want to run it, the bitcoin-qt client currently has lax security in my opinion. Protecting any amount of coin with a only a simple passphrase risks many kinds of unauthorized withdrawal attacks, mainly from keylogging malware.    
As this discussion has evolved, it has become more about the security issues with private keys themselves and how to fix them.  Don't get me wrong, the Bitcoin-Qt client is a fantastic wallet that I would love to run on my computer, but I honestly feel like keeping my BTC behind a layer of 2-factor authentication is safer.

One of the biggest fears any bitcoin holder has is that an unauthorized program will clean out their wallet.  It's unfortunate that thieves who are successful at it are very likely to do it again.  There is absolutely no recourse for the vitcim to get their coins back, and currently no punishment awaiting those who perpetrate the crime.  Is it ever totally the victim's fault? It's a moot question.  You can point fingers and play the blame game all you want but the reality is in these kinds of circumstances, thieves will absolutely try to steal coins any way they can and it's BAD FOR BITCOIN.

How can we fix it and especially protect the most vulnerable users?  Cold storage, Paper wallets, hardware wallets, and multi-sig are a start, but believe me when I say they're not enough, they shouldn't be the only options, and many users actually don't have the wherewithal to set them up.  My rule is if you can't trust your bitcoins with grandma, it's not easy enough yet.  Each user should be able to run their own digital trustless BTC vault

What's an easy way to beef up security without trusting other people to hold your coins?  The answer is simple, and built right into bitcoin: time.  Time can be measured two ways, by the computers clock or by the network itself in terms of confirmations.  If we can use scripts to prevent our coins from even being sent out until a specified time or number of confirmations have been made after our request, it will greatly help decrease the chances that our coins are spent without our approval, it will also solve other problems propagated by human error.  

I have five simple suggestions for potentially improving the security of coins kept on any wallet, but especially the bitcoin-qt

• give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time (or number of confirmations) must pass before it is sent out and the request can be cancelled anytime before that.  Even more importantly, many methods of notification should be available to say that a withdrawal request has been made.
• allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.
• allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.
• allow users a kind of "total lockup" mode, specifying a period of time in which no coins can be transferred to a new address in any way shape or form until a period of time or a specified number of confirmations has passed.  Personally I believe this should have a maximum to prevent coins from being locked up for years by accident or malicious intent.
  
• a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

Pros: thieves attempting to drain a wallet of funds will find their attempts hampered.  Even if they know the password (or private key) and attempt to withdraw, they must wait a specified time period and the wallet owner is simultaneously notified with the option to cancel.  Thieves may also find that the wallet is unable to process a request to send the funds to their address, i.e. theirs is not on a list of trusted forwarding addresses.

I think the parameters should be as flexible as possible, and of course optional.  Users should be able to specify whether they want a weeks delay or a 5 minute delay, a 2 BTC daily withdrawal limit or a 100 BTC daily withdrawal limit.  Many other different kinds of rules for addresses can be imagined, but of course users could always choose to generate a normal address, and protected from accepting a transaction with these kinds of extra-restrictive output scripts.  A failsafe should always be in effect as well, meaning that the user pre-defines a trusted address that could accept the BTC instantly.  Thieves would have to hack this as well if they wish to spend the coins instantly, and another still if a chain were set up...ad nauseum.

Cons: Users will have the option of enabling these extra security layers, but may find their coins less accessible if they are not careful.  Caution should be exercised so that coins with ultra-constrictive security options are not created.  

I'm very interest in any comments on this.  Thank you!

EDIT 1: To much skepticism, I have further elaborated how this may be possible to do below in the responses. It essentially involves creating transactions that have more constricting output scripts, some of which may require changes to the bitcoin protocol. Jump to: https://bitcointalk.org/index.php?topic=209409.msg2213559#msg2213559

[1715598935]

1715598935

[1715598935]

1715598935

[Terk]

I have four simple suggestions for potentially improving the security of coins kept on any wallet, but especially the bitcoin-qt

• give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time must pass before it is sent out and it can be cancelled anytime before that.  Even more importantly, many methods of notification could be available to say that a withdrawal request has been made
• allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.  Changing this option takes a significant amount of time to re-set
• allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.  Again, changing this parameter takes time to reset.
• a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

The methods suggested above will prevent your co-worker from sending your coins if you leave your computer and wallet unlocked and go for a lunch break (which you shouldn't do anyway). But none of this will save your coins if you have your computer compromised. Once your wallet is unencrypted, your private keys can be read by any malicious software that is running in your system. All these limitations will affect only a user who will try to use Bitcoin-qt interface, but the malicious software having access to your private keys could spend all your coins regardless of these interface-based limits.

[coastermonger]

The methods suggested above will prevent your co-worker from sending your coins if you leave your computer and wallet unlocked and go for a lunch break (which you shouldn't do anyway). But none of this will save your coins if you have your computer compromised. Once your wallet is unencrypted, your private keys can be read by any malicious software that is running in your system. All these limitations will affect only a user who will try to use Bitcoin-qt interface, but the malicious software having access to your private keys could spend all your coins regardless of these interface-based limits.

I get that part of it is an interface and deep down, the real need for protection is at the level of private keys.  But work with me here: I think I'd really like the option to shield my coins through time and/or number of confirmations somehow.  If unencrypting the wallet is difficult and done through the interface, could one also just put a kind of time delay that must pass before the wallet could even allow itself to be unencrypted?

i.e. let's assume that a malicious program has my password.  Then they have the ability to unencrypt my wallet. But previously when I set up the wallet I configured it to only unencrypt and show my private key after a specified amount of time and/or confirmations.  So the malicious program *can* try to do so, but that period of time must pass, I will get a notification for it, and I will be given the option to cancel such an action.

[Terk]

i.e. let's assume that a malicious program has my password.  Then they have the ability to unencrypt my wallet. But previously when I set up the wallet I configured it to only unencrypt and show my private key after a specified amount of time and/or confirmations.  So the malicious program *can* try to do so, but that period of time must pass, I will get a notification for it, and I will be given the option to cancel such an action.

It doesn't work this way. The malicious software just runs in the background and waits until you unlock your wallet. Do you have a time lock? Fine, the software has all the time in the world. Once your wallet is actually unlocked (by you), they have your keys and can spend you coins. They don't really care about your password.

[coastermonger]

I really appreciate your comments on this.

So given that private keys will always allow instantaneous transfer of coins (unless bitcoin itself is entirely patched) this is the crux of the problem;

We have a situation where unlocked wallets (however briefly so) are vulnerable and able to be attacked by malicious programs.  Yet at the same time the wallet needs to be unlocked and unencrypted in order to spend the coins.  

Is a dedicated hardware wallet really one of the most foolproof ways to go then?

Or is there a way to set up a wallet so that despite being "unencrypted" the private keys still can't be read?  

OR is there a way to show the private key on the computer without it being the actual private key, but it becomes something that a person sitting at the computer could understand as the private key?

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

[grue]

you clearly have no idea how bitcoin operates.

give users the option to specify time delays for withdrawals.  When a request is made to send money, a specified period of time (or number of confirmations) must pass before it is sent out and the request can be cancelled anytime before that.  Even more importantly, many methods of notification should be available to say that a withdrawal request has been made.

how can this be enforced at the protocol level? the wallet contains private keys, how can you reliably delay the transaction?

allow users the option to lock-in the next destination addresses of their coins.  For instance if a user wants to keep coins in their wallet but make sure they're not transferred anywhere else but their next hotwallet they can do so.  They may even choose to set up a list of trusted addresses.  Changing this option takes a significant amount of time to re-set

impossible. the only way is by sending the coins to the said address.

allow users to specify a maximum amount of BTC that can be transferred out in a given timeframe.  Again, changing this parameter takes time to reset.

impossible to enforce at protocol level

a password is not enough, allow the wallet to use any kind of 2nd factor authentication if possible, please!

lol

[DannyHamilton]

I really appreciate your comments on this.

So given that private keys will always allow instantaneous transfer of coins (unless bitcoin itself is entirely patched) this is the crux of the problem;

We have a situation where unlocked wallets (however briefly so) are vulnerable and able to be attacked by malicious programs.  Yet at the same time the wallet needs to be unlocked and unencrypted in order to spend the coins.  

- snip -

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

There are 3 possibilities that show a lot of promise for protecting private keys and making it much more difficult for a thief/hacker to access your bitcoins.

Hardware wallets.
Multi-signature transactions
Offline signatures (such as Armory provides).

[Foxpup]

Or is there a way to set up a wallet so that despite being "unencrypted" the private keys still can't be read?  

OR is there a way to show the private key on the computer without it being the actual private key, but it becomes something that a person sitting at the computer could understand as the private key?

The private keys must be readable by the software. It can't send transactions otherwise. Encryption is the only way to ensure that the private keys can be read by the software that needs to read them, and only when it needs to read them, while preventing the private keys from being read by anyone else. Though even that won't work if you've got a keylogger.

I'm just trying to brainstorm a way that will attempt to thwart thieves at any level, despite them knowing your password and infecting the system. The key difference is that they are not you and they are not sitting at your computer.  

It's not possible. If someone a) can decrypt your private keys (ie, they know your password) and b) has access to your system, they can steal you coins. The only solutions are to a) keep keyloggers off your system, and/or b) make it completely impossible for anyone to access your system at all (cold storage).

Bottom line, if someone or some program has access to your computer, they can do anything that you can do, including access your private keys and use them to steal your coins (using their own software, if your software has "safeguards" which don't actually provide any real protection). No lock is safe from someone who has the key.

[Terk]

There are 3 possibilities that show a lot of promise for protecting private keys and making it much more difficult for a thief/hacker to access your bitcoins.

Hardware wallets.
Multi-signature transactions
Offline signatures (such as Armory provides).

This.

And of course there is this fourth method which always helps and it's called the common sense.

You don't need to and you shouldn't keep all your wealth in Bitcoin-Qt. Just like you don't walk around the streets every day with your wallet filled with every dollar you have. With fiat money you're aware that it's easy to lose wallet, it's easy to get pickpocketed or get robbed, and you don't carry hundreds of thousands of dollars every day, but you rather have most of your wealth stored somewhere secure (that includes banks). You need to apply the same logic to bitcoin.

Read about cold wallets and put most of your bitcoins into a secure cold wallet. Or better split into multiple wallets. If you have 1000 BTC but only spend 15 BTC every month on average, leave 20 BTC in your Bitcoin-Qt and put the rest into cold wallets. Create 10 cold wallets with 20 BTC each and simply use them to reload your Bitcoin-Qt wallet roughly every month. The rest 780 BTC put into a long term cold wallet which you don't intend to touch until you spend all your short term cold wallets (or again, split it into five separate cold wallets). Put multiple copies of the long term cold wallet in some very secure places (don't rely on having only one copy as things like fires happen).

Just because something is being done on a computer doesn't mean the usual common sense doesn't apply. Your Bitcoin-Qt wallet is only as secure as your fiat money wallet kept in your back pocket. You need to be aware of dangers and be careful, because there are people waiting for the chance to steal from you. Just don't stash everything you have in your back pants pocket.

[coastermonger]

I can't even respond to Grue because he's just one of those guys that tells you that "you don't know anything."  Not helpful.

DannyHamilton reiterates some good points. Hardware wallets and offline signatures are two relatively secure ways to deal with BTC without someone having remote access to your computer.  I'm interested to see where multi-sig transactions will lead, but it effectively just makes more private keys necessary to steal before the coins can be stolen.  It's a useful trick but it doesn't solve the problem that private keys need to be so very well hidden.  

As Foxpup points out: No lock is safe from someone who has the key.  If that's the case then I would contend we need a better key.  What's so special about a key?  Anyone can use it, but how we make it changes how the key behaves in the lock.  Perhaps we can exploit this last property to our liking.

Terk I honestly appreciate your feedback and comments here, but what you're describing as common sense is actually describing some of the flaws with bitcoin.  It's a fantastic system, but if we work at it we can help make it idiot proof.

I'm still fixated on the crux of the issue: in that once a thief knows your private key the coins can be instantly transferred to any other address with no chargeback.  This is a fundamental feature of the bitcoin protocol itself, a great strength but also a huge weakness.  Surely isn't there a way to tweak the protocol?  I'm going to try to use a very simple example:

A.) Normally the private key that is paired with an address represents the way to transfer the value. Knowing the key gives a user the power to spend/steal the coins there instantly.  These can be thought of as "fast" coins.  Even if coins are in cold storage, knowing their private key makes them instantly spendable on the network.  So the private key is currently the weak point.  It must be hidden to all but the owner.

B.) But what if the system were capable of creating a new address with a different kind of private key by command.  One that would still be recognized as a valid, but this key has a different property that sets it apart.  Maybe it has an extra character, or a specific sequence of characters within it, just something that makes it so that the protocol knows its different and categorically "handles" it differently.  

C.) The protocol sees these coins with a different private key and knows that it will be subjected to a different set of instructions.  What instructions could those be?  Go crazy with ideas, but it might allow for some pretty powerful security features to be put into place.  So much so that you could feel comfortable sharing the private key itself.  The coins at that address could be sent as normal but they may have extra constraints on their behavior that any wallet client would recognize.  I.e. a time delay, a maximum per time period limit, a committed and locked forwarding address etc. These might be thought of as "slow" coins that have been temporarily been made to have these different properties as long as they reside at this address.  Sending them to a new address without instructions to modify the private key to be "different" again would revert them to their normal "fast" state.

Please understand I'm not talking about just changing the behavior of a wallet here, but changing the behavior of all wallets and a bit of the protocol itself.  I understand this is weird and foreign to many people who have worked with bitcoin for a long time, but this is coming from a deep desire to help further bitcoin and prevent theft.  

What it would look like in practice? Say Bob has 20 BTC that he just received.  He wants to further protect his BTC so he instructs his wallet client to generate an address that will have a modified private key.  The address is valid and anyone can send BTC to it, but it might even look a little different when shown.  Once coins are at this address, the blockchain knows to process them differently according to his input when he created it.  In bob's case, he generates an address that will cause the coins here to be locked up in pending for at least 72 confirmations before they are actually sent to an outbound address.  He sends the coins to this new address and they remain there.   The next day he pays a friend 2 BTC.  The blockchain processes this transaction and for the next 72 confirmations the blockchain does not actually send the coins, they are still within Bob's wallet at his modified address.  This is NOT a chargeback, it's priming to send.  Once the coins are sent Bob cannot get them back as usual in bitcoin.  About 12 hours later Bob's friend Alice notification that the coins are now in her wallet.  Since Alice is using a normal address, the coins behave as normal "fast" BTC, they can be spent instantaneously and have none of the properties that Bob gave them.  That night when Bob sleeps, someone who infected Bob's computer with malware attempts to import the modified private key from bob's wallet.  They're trying to steal all his remaining 18 BTC.  They copied it when his wallet was briefly unencrypted during his transaction with Alice. Bob wakes up the next morning and sees a notification that the coins sitting at that address have a pending withdrawal request that he did not authorize.  He cancels it, and the blockchain never sends it to the thief's address. Now in possession of his coins and aware that his computer is compromised, Bob takes the necessary steps to protect his investments.  This is a hypothetical case where the bitcoin protocol and wallets have been modified slightly so that even though a thief knew Bob's modified private key, the blockchain knew to process the BTC according to Bob's input at the time the address was created, and the thief could not steal it.

TL;DR - Currently, Private keys are not safe.  We should work to allow users to create safer, craftier, modified private keys

Also, I am aware that there is some complexity here I do not understand, such as multiple valid private keys per address for instance.  I wonder how this would affect it.

[wumpus]

You should be careful about the amount of BTCs you store on any online device. The specific client is least of your worries. Wallet encryption helps a bit, but if your PC or phone is really compromised it won't stop a determined attacker, certainly not one with root privileges (and direct memory access), from stealing them while you send coins.

There is no way that software can protect against such attacks.

If you have a large stash of BTCs please use an offline or paper wallet. And backup it very carefully. And there's companies working on hardware wallets, that would be an interesting space to watch too.

[Jobe7]

Dear OP,

You can already make hardware wallets, or you can (and should) store the majority of your wealth (Bitcoins) in cold storage, on multiple devices. If you're not sure on how to do either you can pm me or google it.

The only absolute way I can think of to address what you're saying is to have a 3rd Party hold your wallet (an escrow of some kind) and require you to provide your password and whatever other ID requirements you've set for them to require before they spend your funds on whatever item/person you wanted.

But then thats defeating the purpose of 'be your own bank', but let's be honest, there's definitely going to be people out there who don't trust themselves with all their wealth and would prefer a 3rd person holding a chunk of their wealth for certain spending procedures.

There you go OP, business venture idea right there, "a trusted 3rd party for when those encrypted wallets just don't feel safe enough!". The 3rd party would be faced with similar issues, but maybe they'd sign a clause with the person. And there we go, the start of a purely online Bitcoin bank It's gonna happen or later, I betcha.

[grue]

I can't even respond to Grue because he's just one of those guys that tells you that "you don't know anything."  Not helpful.

is your attention span 10 seconds? because I responded to every single suggestion you made. all you're doing is making vague suggestions with no way to implement with the current protocol. for example, the "delayed addresses" suggestion. how exactly is that going to be enforced? even if it could, how would it help if your computer was infected? the attacker can simply wait a few days until the funds are available.

come to think of it, what's wrong with the systems currently available? we have multisig transactions, as well as printable cold wallets.

you're the one making the suggestions. half baked ideas are dime a dozen, what we need are ideas with implementation details.

[coastermonger]

is your attention span 10 seconds? because I responded to every single suggestion you made.

Your responses were: "how?, impossible, impossible, and lol." I'm sorry if you actually meant to inspire some discussion, I must have taken it  the wrong way.  It's fine, I'm going to refrain from ad hominem here and assume you didn't read the entirety of this response: https://bitcointalk.org/index.php?topic=209409.msg2198370#msg2198370 (as it really was too long)

I'll take pretty much everything I said in that reply and condense it down to a few lines:

• Private keys currently represent a problem in that once they are shown the BTC can be stolen immediately, to anywhere.
• But what if we could sometimes create addresses for ourselves that purposefully had a certain kind of private key.
• Imagine if the protocol itself were tweaked to recognize certain private keys as different.  (crazy simple example: any private key starting with "E9" has property X)
• It means any coins at that address will be handled differently by the blockchain itself, a universal property that everyone has agreed on.
• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.      
• In effect a malware program could view a private key, attempt to steal the coins, but the blockchain would handle those coins differently coming from that address and the user would get the option to cancel the pending transaction before it is actually stolen.
• What properties the coins have depend on how the the bitcoin protocol is coded to handle the modified private keys.  We could imagine any kind of behavior changes for extra security or functionality.  Once a key is made, it makes actually changing the entire protocol to necessary to change how those coins behave.  Once the coins are spent from that address, they no longer have that behavior.  It is truly a temporary, user-initiated property.
  

[DannyHamilton]

• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.       

This would not be possible.  The blockchain and all the peers never get to know what your private key is.  That's why the key is called a "private" key.  It isn't visible to the blockchain. I suspect that what you are looking for is a new transaction output script.  It is the output scripts of the transaction that determine what the requirements are for later spending that output.  The reason that the vast majority of transactions can be spent with a signature from a private key is because the output script when the bitcoin was received specified that the only thing required was a signature from a private key.  If you want a different spending requirement, then you have to convince the person sending you the bitcoins not to simply send to a bitcoin address and instead to use an output script that adds additional spending requirements.  Here are the script programming commands that can be used in an output script.  If you can come up with a good solution from this set of commands, perhaps you can convince others to use a wallet/client that supports your new script requirements:

https://en.bitcoin.it/wiki/Script

If there is a particular command that is missing from the set, perhaps you can get a client created that supports additional commands.

[aaaxn]

is your attention span 10 seconds? because I responded to every single suggestion you made.

Your responses were: "how?, impossible, impossible, and lol." I'm sorry if you actually meant to inspire some discussion, I must have taken it  the wrong way.  It's fine, I'm going to refrain from ad hominem here and assume you didn't read the entirety of this response: https://bitcointalk.org/index.php?topic=209409.msg2198370#msg2198370 (as it really was too long)

I'll take pretty much everything I said in that reply and condense it down to a few lines:

• Private keys currently represent a problem in that once they are shown the BTC can be stolen immediately, to anywhere.
• But what we could sometimes create addresses for ourselves that purposefully had a certain kind of private key.
• Imagine if the protocol itself were tweaked to recognize certain private keys as different.  (crazy simple example: any private key starting with "E9" has property X)
• It means any coins at that address will be handled differently by the blockchain itself, a universal property that everyone has agreed on.
• The blockchain protocol could have been tweaked to recognize any private key starting with 'E' to mean 'delay' and the number behind it to mean a certain number of confirmations.  In this case the user purposefully generated an address with the private key E9 so that the coins there are delayed by 9 confirmations before actually being transferred from one address to another.      
• In effect a malware program could view a private key, attempt to steal the coins, but the blockchain would handle those coins differently coming from that address and the user would get the option to cancel the pending transaction before it is actually stolen.
• What properties the coins have depend on how the the bitcoin protocol is coded to handle the modified private keys.  We could imagine any kind of behavior changes for extra security or functionality.  Once a key is made, it makes actually changing the entire protocol to necessary to change how those coins behave.  Once the coins are spent from that address, they no longer have that behavior.  It is truly a temporary, user-initiated property.
  

It all can be easily done when we replace output/input script with account ledger, which just keep an balance attached to an address. With this design you could easily make account type which has withdraw limit defined or which has two keys. One limited and one allowed to spent without limit. It would also fix many other problems of bitcoin(eg. dust output, ever growing blockchain, ...)
Some ideas can be found here:
https://bitcointalk.org/index.php?topic=195275.40

I don't think you will find support for your ideas in bitcoin supporters. Everybody seems to be in love with current bitcoin design no matter how complicated and inefficient it is.

[wumpus]

I don't think you will find support for your ideas in bitcoin supporters. Everybody seems to be in love with current bitcoin design no matter how complicated and inefficient it is.

It's certainly interesting, but it's more the domain of altcoins than bitcoin. I wonder why all the current altcoins are literal copies of bitcoin, and no one is experimenting with more wildly different ideas like that.

[coastermonger]

To DannyHamilton: I appreciate your insight and for bringing up the topic of output scripts.  You seem like a really knowledgeable guy.  I am sorry that my terminology might not be up to par.  So the blockchain itself does not see or store private keys, got it.  But the wallet does correct?  What I am trying to do is introduce the idea that sometimes the private keys themselves could be generated to have some specific function like an output script.  It would have to be a universal quality that any wallet would recognize.  What would technically need to happen to make this change?  Be as grandiose as you like, it's just brainstorming.

To aaaxn: I'm curious about your idea of replacing input/output script with account ledger.  One of the main problems I'm trying to solve is that sharing a private key always allows instantaneous theft/transfer of a coins.  I want to give users the options to sometimes not make this the case, to be able to store their coins in addresses that have private keys which modify the behavior of how their coins can be spent.    (the protocol itself would have to be modified to accomodate this behavior) Under your example, could I still immediately steal all of your coins if I discovered the private key of your address?  Why or why not?  I'll also make sure to check out the other idea thread.

And to John Smith: I realize that this might be more the domain of alt coins if the changes to bitcoin are too complicated or too far gone to implement.  I just kind of hate the idea of introducing another alt coin.  I'm ultimately curious if these are changes that can be introduced because they would keep the current functionality of the bitcoin protocol intact, but also change it for those who want the option to.

[wumpus]

And to John Smith: I realize that this might be more the domain of alt coins if the changes to bitcoin are too complicated or too far gone to implement.  I just kind of hate the idea of introducing another alt coin.  I'm ultimately curious if these are changes that can be introduced because they would keep the current functionality of the bitcoin protocol intact, but also change it for those who want the option to.

The way to do it would be to first experiment with it on an alt chain. Once it turns out to be workable, and the alleged advantages really hold up, it could be implemented in Bitcoin. In principle it's possible to change a lot of the internal workings using a hardfork (see also https://en.bitcoin.it/wiki/Hardfork_Wishlist) but it has to be proven first.

[skull88]

Not a programmer, nor a security specialist but isn't it possible to build in the client something that allows you to besides encrypting the wallet with a password you can also encrypt it with something like a yubikey, so that you actually need something physical to decrypt it? So if a computer is infected they still can't send any coins because you also need the usb device.

OP has a point, I have the knowledge to keep my coins secure. But no way my mother could do this, sticking something like a usb key in the computer is even for her a nobrainer.

[DannyHamilton]

To DannyHamilton: I appreciate your insight and for bringing up the topic of output scripts.  You seem like a really knowledgeable guy.  I am sorry that my terminology might not be up to par.  So the blockchain itself does not see or store private keys, got it.  But the wallet does correct?  What I am trying to do is introduce the idea that sometimes the private keys themselves could be generated to have some specific function like an output script.  It would have to be a universal quality that any wallet would recognize.  What would technically need to happen to make this change?  Be as grandiose as you like, it's just brainstorming.

This is a futile effort.  You can't force the attacker to use the wallet you want him to use.  He'll just create his own wallet software that ignores the restrictions you are trying to put on the private key.  Since no other wallets/clients can see the private key, they won't know about the restriction, they'll have to assume that the wallet that sent the transaction followed the proper rules enforcing the "private key restrictions".  If you want the network to enforce something, then you have to use criteria that the entire network can see.  The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

[aaaxn]

To aaaxn: I'm curious about your idea of replacing input/output script with account ledger.  One of the main problems I'm trying to solve is that sharing a private key always allows instantaneous theft/transfer of a coins.  I want to give users the options to sometimes not make this the case, to be able to store their coins in addresses that have private keys which modify the behavior of how their coins can be spent.    (the protocol itself would have to be modified to accomodate this behavior) Under your example, could I still immediately steal all of your coins if I discovered the private key of your address?  Why or why not?  I'll also make sure to check out the other idea thread.

Well with account ledger we can define different account types. It's possible to define account with two keys. One master key which can set account limits/unlimited spending and other with spending limit attached (eg. max 1 BTC per day). You use second key for day to day transactions and if attacker gets it he can only spend max 1 BTC per day and you have time to react.

[grue]

Your responses were: "how?, impossible, impossible, and lol."

confirmed for 10 second attention span



Also, you have no idea what ad hominem means. All you're doing is randomly spewing out buzzwords. Let's recall:

An ad hominem (Latin for "to the man" or "to the person"[1]), short for argumentum ad hominem, is an argument made personally against an opponent instead of against their argument

I raised questions about each one of your suggestions. Instead of providing clear implementation details, you called me out for attacking you.

You're the one proposing a change/feature. Therefore, you should be able to provide implementation details to overcome the problems that others raise. I'll reiterate again: half-baked ideas are worthless.

[coastermonger]

This is a futile effort.  You can't force the attacker to use the wallet you want him to use.  He'll just create his own wallet software that ignores the restrictions you are trying to put on the private key.  Since no other wallets/clients can see the private key, they won't know about the restriction, they'll have to assume that the wallet that sent the transaction followed the proper rules enforcing the "private key restrictions".  If you want the network to enforce something, then you have to use criteria that the entire network can see.  The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

To DannyHamilton: Okay, so private keys must remain as they are since they are only dealt with by wallets.  But here's an idea: aren't attackers also forced to send the coins from our address?  Can the blockchain protocol be changed so that it will recognize some addresses as special case?  If so then any kind of feature imaginable could be put into the protocol to deal with certain coins a certain way.

Here's what it might look like:

• I instruct my wallet to make a "vanity" address for me that will start with the prefix "1d144"
• This is not difficult, there are a plethora of such addresses and it may take a few seconds to minutes to generate it depending on processor power. So I receive some coins at that address.
• When the coins go to be spent, the blockchain has been changed to recognize that the d144 prefix means to delay the sending of those coins for 144 confirmations.  I could be importing a private key or initiating a send transaction with a wallet.  Doesn't matter, the blockchain still knows that the coins are coming from a "d144" address.
• Meanwhile later a thief obtains my private key by some means.  He goes to import the private key (and my coins) to his wallet.  
  
• Yet the blockchain can still recognize that they are coming from this delayed address that I set up.  This address can be imbued with all kinds of properties that are to my advantage and not the thief's.  Say the thief does indeed initiate a withdraw transaction, it will still not actually send the coins out of my wallet until 144 blocks later.  Say we added a failsafe that in the meantime can immediately return the bitcoins to another address I control.  It makes the job of hacking one wallet the job of hacking multiples.
• So even if my private key is stolen and a thief is attempting to spend my coins I am able to cancel this unauthorized transaction through my wallet and since the coins are still mine.  Depending on the rules I set up with this address, other options may be available to me.
  

I want to make sure the underlying part is clear first: the blockchain should be able to be programmed to recognize certain addresses as different, and then be able to apply special rules to those addresses no?  

The way to do it would be to first experiment with it on an alt chain. Once it turns out to be workable, and the alleged advantages really hold up, it could be implemented in Bitcoin. In principle it's possible to change a lot of the internal workings using a hardfork (see also https://en.bitcoin.it/wiki/Hardfork_Wishlist) but it has to be proven first.

To John Smith: I appreciate the insight, but unfortunately I have very little experience with programming.  My only hope is to try to stir up ideas and hopefully someone with much more skill than me will be able to build off of them.

The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

 

So just out of curiosity, could these output scripts themselves be made to change the spending behavior of the coins if the bitcoin protocol was changed?  My only concern is that this is a power given to the sender, not the receiver.  Meaning someone could send bitcoin but try to defraud the person receiving it.  Perhaps allowing modified addresses is more useful because the rules attached to it only concern the owner of that address.

[DannyHamilton]

This is a futile effort.  You can't force the attacker to use the wallet you want him to use.  He'll just create his own wallet software that ignores the restrictions you are trying to put on the private key.  Since no other wallets/clients can see the private key, they won't know about the restriction, they'll have to assume that the wallet that sent the transaction followed the proper rules enforcing the "private key restrictions".  If you want the network to enforce something, then you have to use criteria that the entire network can see.  The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

To DannyHamilton: Okay, so private keys must remain as they are since they are only dealt with by wallets.  But here's an idea: aren't attackers also forced to send the coins from our address?

No.  They are not forced to send the coins "from your address".  The are forced to spend the unspent transaction outputs in the blockchain that have a script that requires an ECDSA signature from the private key that is mathematically associated with your address.

I think the problem you are running into here is you are trying to make random guesses at ways to change what bitcoin does without any understanding yet of what it is actually doing, why it is doing it, and what decades old problems it solves by doing it the way it does things.  It might help you come up with good ideas if you first take some time to learn about what is happening in the first place and why.

Can the blockchain protocol be changed so that it will recognize some addresses as special case?

An address is just a short-hand for a script.  We humans use addresses as a way of communicating a concept that is represented in the blockchain by way of output scripts.  The output scripts determine what the requirements are for spending the output.  As such when we say "send the bitcoins to address 1MyBitcoinAddress", that is "human-speak" shorthand for a particular type of output script.  What you are actually saying is: "Create an output script that requires the future spender of the output to supply both a public key that hashes to address 1MyBitcoinAddress and an ECDSA signature proving that they have access to the private key associated with that public key".

If someone wanted to, they could instead "send bitcoins to" an output that requires that a user supply a string of characters that hashes to a particular value.  This output wouldn't have an "address" at all.  The only person who could spend the output would be the person who knew what string would hash to the value indicated.

Here's what it might look like:

• When the coins go to be spent, the blockchain has been changed to recognize that the d144 prefix means to delay the sending of those coins for 144 confirmations.  I could be importing a private key or initiating a send transaction with a wallet.  Doesn't matter, the blockchain still knows that the coins are coming from a "d144" address.

The blockchain is just data.  If doesn't recognize anything, it doesn't know anything. It isn't a program.  It is just a list of transactions.  I assume that you mean that you'll convince every user to run this new special wallet/client protocol so that they will refuse to recognize the new output as spendable until it has 144 confirmations if one or more of the inputs to the transaction were previously outputs sent to an address that started with d144?  They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.  That doesn't seem like it would work, by the time it has just a few confirmations, it is already embedded in the blockchain.  Since blocks committed to the blockchain can't be modified, how would you "unspend" the transaction?  It seems like you'd be increasing the size of the UTXO list (since you'd need to know not only the unspent transaction outputs, but also all the outputs used as inputs to any transaction that currently has a UTXO)?

• In the meantime I am able to cancel this unauthorized transaction through my wallet and since the coins are still mine.  
  

How is your wallet going to rewrite the blockchain without re-mining all the blocks since the transaction got its first confirmation?

What would happen then is interesting, because the coins are in my wallet and there exist two people in the world with the keys them, each apparently with the power to cancel each other's transactions.  I've worked out a few potential solutions to this problem but I want to make sure the underlying part is clear first: the blockchain should be able to be programmed to recognize certain addresses as different, and then be able to apply special rules to those addresses no?

No.  As already stated, the "blockchain" isn't programmed at all.  It is just data, a list of transactions and attributes and requirements.  It doesn't "recognize" or "do" anything.  So I'm sticking with the assumption that you are saying that all the wallets/clients/miners should update their software to refuse to recognize such transactions as re-spendable until they have 144 confirmations.  I still can't figure out how such a concept would help, but for the sake of discussion I'll go along with such a concept temporarily.

The way to do it would be to first experiment with it on an alt chain. Once it turns out to be workable, and the alleged advantages really hold up, it could be implemented in Bitcoin.

That sounds like a great idea.  I'll be interested to hear if you can get it working.  It doesn't seem to be well thought out yet.  As an analogy, it sounds a bit like someone saying "If we could just reverse time, and gravity, there are some really cool things we could do.  I think we should try some tests, and if it works, we should implement it".  Or perhaps, "If we could just build a machine that generates more energy than it uses, we could solve some major problems in the world.  I think someone should run some "perpetual motion" and "over-unity" tests, and once it turns out to be workable, and the alleged advantages really hold up, it could be implemented."

In principle it's possible to change a lot of the internal workings using a hardfork (see also https://en.bitcoin.it/wiki/Hardfork_Wishlist) but it has to be proven first.

And at the moment, not only hasn't this idea been proven, but it doesn't even seem to consider any of what bitcoins does, nor the issues it solves.

To John Smith: I appreciate the insight, but unfortunately I have very little experience with programming.  My only hope is to try to stir up ideas and hopefully someone much more skill than me will be able to build off of them.

Spouting random ideas with no understanding of the technology behind bitcoin is far more likely to result in a knowledgeable person spending a lot of time trying to help you understand why the idea doesn't make sense than to result in anything anyone can build off of.  The only good thing that is likely to come of it is that you at least might gain a better understanding of bitcoins inner workings.  However, there are much more productive and easier ways of accomplishing that goal than by asking others to chase down ideas that pop into your head.

The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

 

So just out of curiosity, could these output scripts themselves be made to change the spending behavior of the coins if the bitcoin protocol was changed?

No need to change the protocol.  These output scrips can already be used to change the spending behavior of the coins.  This is why things such as multi-sig work/exist.

My only concern is that this is a power given to the sender, not the receiver.  Meaning someone could send bitcoin but try to defraud the person receiving it.

Yes.  This is the design of bitcoin.  You ask someone to provide you with a way to have exclusive control over some value that they currently have exclusive control over.  They create an output script that you recognize as providing you exclusive control over that value.  Once you confirm that their output script gives you exclusive control, you consider the transaction complete.  If the transaction does not give you exclusive control over the value, you tell the sender that you haven't received it.  The current output script that we humans call a "bitcoin address" is simply a script that we all agree provides exclusive control over the value.  You feel comfortable telling someone to "send to an address" because you trust that that phrase means the exact same type of script to everyone, and everyone recognizes such a script as providing exclusive control over the coins by nature of the way ECDSA signatures work.

If you want to create a new type of output script, you'll want to be very certain that:

• Everybody (or everybody's wallet/client) knows exactly how such a script should be created
• Such a script reliably gives the "receiver" control to "spend" the value
• Such a script reliably prevents anybody else from having control to "spend" the value

Then you convince everyone to upgrade their wallet/client/miners to new software that can recognize this new output script, and that can validate it well enough to be certain that the sender can't create an altered script that defrauds the receiver.

[mandros]

The blockchain is just data.  If doesn't recognize anything, it doesn't know anything. It isn't a program.  It is just a list of transactions.  I assume that you mean that you'll convince every user to run this new special wallet/client protocol so that they will refuse to recognize the new output as spendable until it has 144 confirmations if one or more of the inputs to the transaction were previously outputs sent to an address that started with d144?  They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.

If the majority of the clients knew and enforced this rule a block which included a transaction to spend those coins before 144 confirmations would be considered an invalid block and would be rejected. Just like trying to spend coins without the correct private key or doing a double spend, it breaks a rule so it's an invalid mined block.

The only transaction allowed before those 144 confirmations would be a transaction where the amount where identical and the source and destination addresses where reversed (source -> destination and destination -> source). That would "unspend" the coins.

[jmw74]

Wow, nobody's mentioned this yet? https://en.bitcoin.it/wiki/Contracts

I think it solves the problem that OP wants to solve, but is much better designed and solves a lot of other problems too.

[Dabs]

Let's pretend the bitcoin protocol gets modified the way OP wants it.

1. coastermonger has 100 BTC in his "slow" wallet.
2. hacker compromises computer/wallet and gets private key.
3. hacker sends 100 BTC to another wallet.
4. coins are in "waiting" period for 72 hours.
5. coastermonger is alerted, cancels the transaction.
6. hacker notices that the transaction has been cancelled.
7. hacker sends 100 BTC to another wallet again, with a different transaction.
8. coins are in "waiting" period for 72 hours.
9. coastermonger is alerted, cancels the transaction.
10. hacker notices that the transaction has been cancelled.
11. hacker sends 100 BTC to another wallet again, with a different transaction.
12. coins are in "waiting" period for 72 hours.
13. coastermonger is alerted, cancels the transaction.
14. hacker notices that the transaction has been cancelled.
15. hacker sends 100 BTC to another wallet again, with a different transaction.
16. coins are in "waiting" period for 72 hours.
17. coastermonger is on a vacation, 72 hours pass, all his coins are stolen.

Or

1. coastermonger is alerted, cancels the transaction.
2. coastermonger sends his 100 BTC to another wallet.
3. coins are in "waiting" period for 72 hours.
4. hacker is alerted, cancels the transaction.
5. hacker sends 100 BTC to another wallet.

[DannyHamilton]

The blockchain is just data.  If doesn't recognize anything, it doesn't know anything. It isn't a program.  It is just a list of transactions.  I assume that you mean that you'll convince every user to run this new special wallet/client protocol so that they will refuse to recognize the new output as spendable until it has 144 confirmations if one or more of the inputs to the transaction were previously outputs sent to an address that started with d144?  They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.

If the majority of the clients knew and enforced this rule a block which included a transaction to spend those coins before 144 confirmations would be considered an invalid block and would be rejected. Just like trying to spend coins without the correct private key or doing a double spend, it breaks a rule so it's an invalid mined block.

The only transaction allowed before those 144 confirmations would be a transaction where the amount where identical and the source and destination addresses where reversed (source -> destination and destination -> source). That would "unspend" the coins.

So you are creating a situation where transactions are reversible for 144 blocks?  So I can pay you for merchandise, and almost a day later I can send those bitcoins back to myself even though I don't know your private key?  And this sounds like a good idea to you?

If someone wanted to create havoc in bitcoin, they could create software that would watch the blockchain for transactions from addresses that start with d144, and 20 blocks later they could just randomly reverse some of them?  They could essentially keep your bitcoins locked in your d144 address forever, because every time you try to spend them, they's just be reversed back?

And if the transaction has 2 inputs, and only one of the inputs is from the d144 address?  Then what happens to the bitcoins?

[jl2012]

Your suggestions require total protocol change, not just bitcoin-qt. (if you think bitcoin-qt = bitcoin network, that's completely wrong), and that will provide only very limited improvement in security.

Without a protocol change, your grandma can still use bitcoin at a safety level comparable to cash and credit card. The solution is temper-proof hardware wallet. I think we will have one very soon.

[mandros]

The blockchain is just data.  If doesn't recognize anything, it doesn't know anything. It isn't a program.  It is just a list of transactions.  I assume that you mean that you'll convince every user to run this new special wallet/client protocol so that they will refuse to recognize the new output as spendable until it has 144 confirmations if one or more of the inputs to the transaction were previously outputs sent to an address that started with d144?  They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.

If the majority of the clients knew and enforced this rule a block which included a transaction to spend those coins before 144 confirmations would be considered an invalid block and would be rejected. Just like trying to spend coins without the correct private key or doing a double spend, it breaks a rule so it's an invalid mined block.

The only transaction allowed before those 144 confirmations would be a transaction where the amount where identical and the source and destination addresses where reversed (source -> destination and destination -> source). That would "unspend" the coins.

So you are creating a situation where transactions are reversible for 144 blocks?  So I can pay you for merchandise, and almost a day later I can send those bitcoins back to myself even though I don't know your private key?  And this sounds like a good idea to you?

If someone wanted to create havoc in bitcoin, they could create software that would watch the blockchain for transactions from addresses that start with d144, and 20 blocks later they could just randomly reverse some of them?  They could essentially keep your bitcoins locked in your d144 address forever, because every time you try to spend them, they's just be reversed back?

And if the transaction has 2 inputs, and only one of the inputs is from the d144 address?  Then what happens to the bitcoins?

I was not defending the idea, just pointing out that the blockchain is not just data, it's data and a majority of clients who enforce a set of rules.

A rule to allow chargebacks for about 144 blocks is technically possible, I'm not saying it's a good idea or it can not be exploited by evil attackers, just that the bitcoin network has the capability to enforce those kind of rules if it must.

[coastermonger]

To Danny Hamilton: Your patience is commendable.  I hope you realize how dead-set I am on understanding this.  Indeed my suggestions might sound a little ludicrous at this point, but hopefully I can get to where I able to describe them in terms that are understandable.  Also, if you want to post an address I'll tip you for your time.

What you've explained so far is interesting.  

They [users and thieves] are forced to spend the unspent transaction outputs in the blockchain that have a script that requires an ECDSA signature from the private key that is mathematically associated with your address.

I understand that Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied.

AND

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins.  

AND usually,

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key

I know that multi-sig transactions  encumber the output with additional constraints (like m of n private keys needed to spend)

I think it's significant that users as well as thieves are forced to use these same constraints. In effect it means a user might encumber his own coins in a way that is to his advantage.

So before we think about designing constraints, What basic properties are we focused on here?
1.) The coins can be spent, but the pending transaction is broadcast and a specified amount of time (or confirmations) must pass before the coins actually leave your wallet.
2.) Sending the transaction again overrides the first, and again renews the pending withdrawal time.
3.) A failsafe address is added that allows the coins to immediately be spent to it.  (very important)

I would find such constraints useful for several reasons:
Transaction mistakes happen all the time by human-error.  This allows users a window of time to change something before it becomes irreversible if they messed up a detail (like the amount, miner fee, or destination)
If a thief obtains the private key to an address and attempts to import/spend the coins, they too are subject to the same constraints that make withdrawals pending for the amount of time the owner originally specified.  Any attempt to spend the coins will notify the owner, and by scripting design he can send to a failsafe address (which should be set up to have a private key stored elsewhere).  A whole chain of such addresses set up so that the job of hacking 1 wallet becomes the job of hacking many.  
Unlike multi-sig, which just makes hacking many private keys necessary, "pending withdrawals + failsafe" allows the owner to be notified that his private key has been obtained if the thief ever attempts to spend his coins.  The coins are still his, and he can act accordingly.

It's literally like saying to a thief: "You can steal the key to my vault, but if you try to spend the money there I will know about it and can cancel it.  Also, I can immediately send all the money to another vault I control that you don't have the key to"  

Some similar (but not identical) functionalities already exist in the protocol like time locking contracts.  The difference is that time locking just specifies a time until the coins become spendable in advance.  Whereas we want to specify a time that the coins must wait to become spendable the moment that they are spent, in advance.

They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.  That doesn't seem like it would work, by the time it has just a few confirmations, it is already embedded in the blockchain.  

Well I admit that's where it gets murky to me.  The problem is that we have to convince other nodes to reject a transaction that prematurely tries to send the full amount. That's what a thief with a modified wallet would try to do.  But the thief can't change the output scripts because they're already set up.  So we need script that's very smartly designed to begin with, we could try to design it so that it can't prematurely send the full amount, it needs to wait in a wallet first.  The scripting should be flexible so that a variety of time frames can be inputted during creation.  (I'm using 144 as an arbitrary number).

Perhaps the coins with these scripts would broadcast a kind of "intention to send" or "transaction start" in blockchain record.  The intention then sticks with each successive block as pending until the requirements are met and it can finally be confirmed as sent.  This kind of transaction first has to plant its foot somewhere, because the script requires:

• if the "intention to send" is > 144 blocks prior in the blockchain.  Send = true  and the coins will relay a transaction
• If it can't find its "intention to send" (never existed), or if it is < 144 blocks prior (still pending) then send = false and it creates a new point to start over again.

Because nodes have an awareness of which block they are currently viewing, it should surely be possible to create a script which is able to find a previous starting point in the blockchain and compare it to the number of blocks that have passed since, either sending or pending the transaction based on the result.  (For these purposes, I mean to say pending = the coins stay in the wallet, waiting to be sent)

Ideally if we set it up correctly, attempting to spend the transaction again to a different address or different amount would broadcast another intention, overriding the first.  

How is your wallet going to rewrite the blockchain without re-mining all the blocks since the transaction got its first confirmation?

We shouldn't have to re-write the blockchain.  Starting a delayed wtihdrawal transaction keeps the coins in your wallet, but it absolutely has to broadcast a kind of transaction.  Some solutions are more elegant than others.  

• Maybe it sends a tiny amount first, (I don't think this is feasible)
• maybe the output scripts specify that it first must send the coins to another kind of intermediary address that you also control, and then it will either spend the coins to the ultimate destination or return them to an address you control based on which script has been satisfied.
• maybe the blocks are changed to be capable of storing these kinds of "intention to send" reference points that must exist before coins can ultimately be spent based on the requirements of these output scripts.
• maybe the transaction has outputs that specify that it simply must confirm much more slowly, able to become purposefully double-spent in the meantime (I also do not like this idea)
  
• or maybe its a case where all miners/clients/wallets update after a hard fork to be capable of recognizing/relaying/accepting these kinds of transactions which broadcast an intention first and a confirmation later.

Dabs
brings up the point of what happens when both a user and hacker control coins and can cancel each others transactions

1. coastermonger has 100 BTC in his "slow" wallet.
2. hacker compromises computer/wallet and gets private key.
3. hacker sends 100 BTC to another wallet.
4. coins are in "waiting" period for 72 hours.
5. coastermonger is alerted, cancels the transaction.
6. hacker notices that the transaction has been cancelled.
7. hacker sends 100 BTC to another wallet again, with a different transaction.
8. coins are in "waiting" period for 72 hours.
9. coastermonger is alerted, cancels the transaction.
...

That's what the failsafe address is for.  We need a script that will say [require all these delays OR allow them to be sent to X address immediately and make sure the owner can provide the ECDSA with the private key] The failsafe address is another that is under the control of the owner and should be elsewhere so that the thief has to hack THAT failsafe address as well to get at the coins.  A whole chain of such addresses could be set up.  The thief would have to hack or know the private key for not just for "m of n," but for each and every one in reverse order so that they can attempt to irreversibly spend the coins without notifying you.  That's the apparent magnitude of this idea.  As of now when your bitcoins are stolen, the first time you learn about it is when it's too late.  This changes it so that you're notified if your coins are stolen and you have the opportunity to act.

So you are creating a situation where transactions are reversible for 144 blocks?  So I can pay you for merchandise, and almost a day later I can send those bitcoins back to myself even though I don't know your private key?  And this sounds like a good idea to you?

Absolutely not. Indeed it sounds like a terrible idea, I don't think transactions should be reversible.  I'm trying to create a situation where everyone's node basically understands that my transaction can't be sent until a specified amount of time has passed since its origin.  Properly implemented, these scripts would not allow double spending because each new request replaces the last.  It would not allow chargebacks because once the pending transaction is finalized it cannot be re-spent or refunded.  The blockchain would record the coins as having a new owner.

There is another matter to address, in that no one should be able to send Bitcoins with these kind of constraints to an unwitting victim.  Transactions that attempt to create coins with these encumbrances should be rejected by default for most every user.  They should only be accepted willingly, most likely under a circumstance when a person is turning their own coins into "delayed withdrawal coins" for themselves.

So just a quick recap: I'm imagining a scenario where sometimes we can send coins which require extra output scripts to satisfy.  These kinds of encumbrances are similar to but different than existing ones used in contracts.  Why would they be useful?  Because in the case that your private key is compromised, what would normally become a catastrophic loss becomes a case where the thief cannot spend your coins without notifying you, the coins take time to leave your wallet, and you (and the thief) are able to immediately transfer the coins to another wallet under your control.  This may also be a voluntary encumbrance that users enact to protect themselves from sending a transaction with human errors like: the wrong amount, the wrong miner fee, the wrong destination.  

The irreversible nature of of bitcoin transactions is an absolutely huge advantage over other currencies, but we should also have the option to sometimes say "not just yet"

[Birdy]

I had a similar idea, so I will post it in this thread.
Maybe this approach would solve some of the problems:

Create a second type of adress that acts like a normal adress, but with those exceptions:
- When you create the adress, you get a third safety key.
- The safe adress starts with e.g. 7 to distinguish it from normal adresses.
- The safe adress will transfer the money like a normal adress, but after a certain delay (2 days?1 week?), if you have private key to this adress you can freeze the adress and stop the transaction whenever you want. Miners can see that the transaction is from an adress with a starting 7, so it should be possible to implement.
- If an adress is frozen, you are able to release all Bitcoins from the safe adress with the third safety key to a new adress.


It may be some extra work, but it would add a new layer of safety for those who want it.
So if your PC is compromised later in the process your coins wouldn't be gone in an instant anymore.
It would be easy to set up an app that would alarm you in case the money is spent from your safe adress.

[coastermonger]

I had a similar idea, so I will post it in this thread.
Maybe this approach would solve some of the problems:

Create a second type of adress that acts like a normal adress, but with those exceptions:
- When you create the adress, you get a third safety key.
- The safe adress starts with e.g. 7 to distinguish it from normal adresses.
- The safe adress will transfer the money like a normal adress, but after a certain delay (2 days?1 week?), if you have private key to this adress you can freeze the address and stop the transaction whenever you want. Miners can see that the transaction is from an address with a starting 7, so it should be possible to implement.
- If an address is frozen, you are able to release all Bitcoins from the safe address with the third safety key to a new address.

As I read this its interesting, but let me see if I understand you correctly.
- You want to allow your wallet to create an address which by nature can send coins but only after a delay following the withdrawal request.
-Creating the address allows two keys to be created, one which can freeze the coins during the delay period and one which can release the bitcoins back to a new address (presumably one you also control)
- If a thief has access to just your private key, they can only spend your coins (with a delay) or freeze them.  They need both your private and this release key to truly liberate the coins to an address of their choosing.

Yet how do you propose reliably generating these 2 keys so that they are not viewable on the same system?  I could be misunderstanding you, I'm just interested in how you see it working.  Usually if a thief has gained access to your private key, he has access to everything else.  

I've tried to solve that problem by making knowledge of the private key independent of the ability to spend coins.  Perhaps a transaction could be created with output scripts that would require both a delay OR a transfer back to a failsafe address you control (no extra key required)  

Making it so that the miners recognize a transaction is pending is another topic entirely, which may or may not necessitate the need for vanity addresses.

[Birdy]

Yet how do you propose reliably generating these 2 keys so that they are not viewable on the same system?  Usually if a thief has gained access to your private key, he has access to everything else.  

The danger is only at the time you are creating the new adress, not when you use it to spend coins.
At the moment you also have this danger when using an adress to spend coins, because you have to use the private key to do this.
Obviously the third key should only be on a piece of paper or offline hardware.

You don't have to use the third key unless malware got your wallet, except for the waiting time there wouldn't be other drawbacks.

[coastermonger]

The danger is only at the time you are creating the new adress, not when you use it to spend coins.
At the moment you also have this danger when using an adress to spend coins, because you have to use the private key to do this.
Obviously the third key should only be on a piece of paper or offline hardware.

You don't have to use the third key unless malware got your wallet, except for the waiting time there wouldn't be other drawbacks.

So let's assume that I malware got my wallet and has my private key.  I've used the private key to freeze my coins so they are stuck in a pending state.  Let's ignore for a moment how the network and other nodes (not just my wallet) will know the coins are in a pending state.  We've set it up so that a 3rd key can unlock the frozen coins and send them out to a fail-safe address.  This key would have to be mathematically associated with my address so that it provides an ECDSA signature when used.  But unfortunately let's assume that I forgot to literally write down the key on paper.  Are my coins gone forever?  Is there anything that will be able to show me what that 3rd key is supposed to be?

I guess the point I'm trying to make is that it might be possible to pre-specify an exact failsafe address without the need for an extra key at all, such that the private key can still send to it instantly. This means the thief can only see their transaction frozen, or sent back to you.

[Birdy]

So let's assume that I malware got my wallet and has my private key.  I've used the private key to freeze my coins so they are stuck in a pending state.  Let's ignore for a moment how the network and other nodes (not just my wallet) will know the coins are in a pending state.  We've set it up so that a 3rd key can unlock the frozen coins and send them out to a fail-safe address.  This key would have to be mathematically associated with my address so that it provides an ECDSA signature when used.  But unfortunately let's assume that I forgot to literally write down the key on paper.  Are my coins gone forever?  Is there anything that will be able to show me what that 3rd key is supposed to be?

Of course not, it's like the private key to public adress, so the coins are gone.
If you fail to write down/print the third key, it's your own fault. Just like failing to write down the private key when you make a paper wallet.

I guess the point I'm trying to make is that it might be possible to pre-specify an exact failsafe address without the need for an extra key at all, such that the private key can still send to it instantly. This means the thief can only see their transaction frozen, or sent back to you.

So you kinda want the miners to store user data like those fail safe adresses, don't you?
Because you cannot setup constraints client-sided, they are useless.

[coastermonger]

So you kinda want the miners to store user data like those fail safe addresses, don't you?
Because you cannot setup constraints client-sided, they are useless.

Client side constraints are absolutely worthless, exactly.  They're too easy to bypass just by using a different client.  In this case it's more accurate to say we want the miners to process our instructions (whatever they may be) and include them as output scripts for the coins at our address in the blockchain.  Thus everyone will be at consensus over what those instructions are, and the coins at that address will forever be obliged to follow the rules of those output scripts if someone wishes to spend them, even a thief.

So if we predefine an output script to just give the coins the capability to either:
1.) Send with delay or
2.) be sent to a specific failsafe address we specify at creation

Then there's no need to generate this third key on the same machine.  We could have used a different machine entirely to set up this failsafe address, I see some advantage in that.  

Even more importantly though, how would we use scripting to both broadcast a kind of transaction to the network and tell all the other clients to delay its completion until a certain point at a later time?  It would have to be a kind of delay that is only initiated once the withdrawal request is made, again not client side, already existing within the output script.  I kind of took a stab at such logic up there, but I'm curious what other people might come up with.

[DannyHamilton]

So to summarize:

We started with the idea of a "special" private key to delay access to spending bitcoins.  However, since Bitcoin relies on all the peers to enforce the rules, and the peers don't have access to the private key, we quickly realized we need to use information that is publicly available.

Next we considered the idea of a "special" address that would delay access to spending bitcoins.  Since the bitcoin address is public information, this would seem to address the concern that we need to use something publicly known.  However, we can't control the spending at the point of transaction creation since an attacker could create their own tool for spending the bitcoins at the address.

If we use the address to enforce the delay at the peer level, the only "timestamp" that the peers have access to is the time they first hear of the transaction.  The peers could delay relaying it, but this doesn't seem to solve the problem.  The attacker could connect directly to miners/pools and the "true owner" of the bitcoins wouldn't even hear bout the transaction until it was too late.

We've now arrived at the idea that since the output scripts were specifically designed for the ourpose of controlling access to spending the output, perhaps the output script is the best place to create the delay.  This means that you would have to rely on the sender to use the output script you desire, but this could potentially be dealt with by immediately sending any bitcoins received with a "typical" output script to this new output script as soon as we receive it.

So after gaining an understanding of the issues with the other suggestions, we're now ready to talk about what can and can't currently be accomplished with output scripts.

Unfortunately, as far as I know, the current script commands do not provide a method of determining block height.  Now, if we are talking about forking changes, changes to the protocol, and/or changes to what is recognized as a valid transaction, then perhaps it would be worth considering modifying the script command set to allow scripts some way of referencing information about the block where the transaction is confirmed as well as the block where the transaction output is spent.

Since we are talking about peoples money here, and any changes we make to the protocol and transaction validation could potentially have unintended consequences, we should be extremely careful about making any such changes.  Perhaps it is a worthwhile effort to see if we can get the security we desire with the current command set even if we don't get the specific functionality we are considering.

I'm not against modifying the command set if it is well tested and can be demonstrated that a significant value will be gained while careful analysis and testing determine that the new command set presents minimal risks.

Right now I'm still hearing very "pie in the sky" ideas.  The details would have to be thought out carefully to see if such an idea is even feasible and to determine if it opens new lines of attack.

I'll have to think on this for a while.  I've tried to come up with how such a script would look, and how it would be satisfied.  It is clear that if you wish to include some sort of requirement that an "intent to spend" transaction be created, and then later an actual spending transaction, along with some delay between those two transaction as indicated in the original output, that some significant changes would need to be made to the protocol.

If I can come up with a way such a script could be structured, I'll come back to this thread and let you know.  If I can't then I'll try to let you know what the stumbling block are.  Regardless, any discussion about future scrips beyond the simple script we all think of as "send to address" is a welcome discussion.

Some comments on specific things that have been said by various people in this thread in the past 18 hours:

Your suggestions require total protocol change, not just bitcoin-qt. (if you think bitcoin-qt = bitcoin network, that's completely wrong) . . .

Seeing as Bitcoin-Qt is the "reference client", what are you suggesting.  Is there some other protocol definition beyond the rules enforced by bitcoin-qt?

I was not defending the idea, just pointing out that the blockchain is not just data, it's data and a majority of clients who enforce a set of rules.

I'm pretty sure "the blockchain" is just data.  It is just a "chain" of data "blocks" that have been appended to each other.  The clients enforcing the rules are not "the block chain", they are the clients.  Clients store a copy of the blockchain, but the blockchain
doesn't enforce the rules, the clients do.

A rule to allow chargebacks for about 144 blocks is technically possible, I'm not saying it's a good idea or it can not be exploited by evil attackers, just that the bitcoin network has the capability to enforce those kind of rules if it must.

Perhaps.  Even so, the tricky part about any significant change is that if you don't want to fork bitcoin into two competing currencies, it requires that everyone agree to update their software to the new way of doing things.  Convincing everyone to do anything is an extremely difficult thing to accomplish.  I'm still not certain that such a change could occur without some significant unintended consequences, but maybe.  The first concern that comes to mind would be the possibility that attackers would find a way to take advantage of this new output type and use it to defraud others.  Still, it might be worth a look to see what could theoretically be accomplished.

To Danny Hamilton: Your patience is commendable.

Thank you for the compliment.

I hope you realize how dead-set I am on understanding this.

Indeed. One of the reasons that I keep coming back to this thread and responding to the thoughts to yourself and others is because you seem to really want to understand take the time to understand the explanations that are given.  You don't seem to be just trolling and attempting to force others to argue for arguments sake.

Indeed my suggestions might sound a little ludicrous at this point, but hopefully I can get to where I able to describe them in terms that are understandable.

Now that you've begun talking about the output scripts rather than "special private keys" and/or "special addresses", the conversation is beginning to sound much less ludicrous.  I'm still not certain if what you want can be implemented without introducing significant problems, but at least we are reaching a point where those with an open mind can have a discussion.

Also, if you want to post an address I'll tip you for your time.

If you are serious, PM me, and I'll send you an address.  If not, that's ok, I'm enjoying the conversation.

What you've explained so far is interesting.

The design of bitcoin can be surprising when you first learn about the details.

Something to keep in mind is that some truly great mathematicians and crypto-analysts have been trying to come up with a workable crypto-currency for decades.  Most had a "gut feeling" that it "should be possible", and yet for decades any possible solution required a centralized clearing house that could confirm for users that a "coin" hadn't already been spent elsewhere.  This resulted in opportunity for fraud perpetrated by the clearing house as well as central point of attack.

Satoshi isn't a "prophet", Bitcoin isn't a "religion", and Satoshi's White Paper isn't a "Bible".  Bitcoin has undergone changes over the past 4 years, and it will undergo additional changes in the future.  However, there are certain core features that provide the "solution" that makes a decentralized crypto-currency possible.  If we aren't careful about changing those core features, we begin to run a significant risk of "breaking" bitcoin.

[jl2012]

1.) The coins can be spent, but the pending transaction is broadcast and a specified amount of time (or confirmations) must pass before the coins actually leave your wallet.
2.) Sending the transaction again overrides the first, and again renews the pending withdrawal time.
3.) A failsafe address is added that allows the coins to immediately be spent to it.  (very important)

This may somehow increase the safety, but it just makes you more trouble. Due to the risk of chargeback, no merchant will deliver before your transaction becomes permanent.

To archive reasonable safety, the specified time must not be too short (e.g. the thief may steal your coins when you are sleeping). If the specified time is too long, you cannot spend your coins in a reasonable time. If the specified time is too short (e.g. 30 minutes), the increase in security is very slim and you have to wake up every 30 minutes to monitor your bitcoin balance.

In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.

[jl2012]

Seeing as Bitcoin-Qt is the "reference client", what are you suggesting.  Is there some other protocol definition beyond the rules enforced by bitcoin-qt?

Here: https://bitcointalk.org/index.php?board=37.0

To enforce an incompatible protocol change (aka hard-fork), you need to modify all these alternative clients, not just bitcoind or bitcoin-qt

[Maged]

In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.

And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case.

But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel.

[Terk]

This conversation turned into great direction, many thanks to DannyHamilton.

We've now arrived at the idea that since the output scripts were specifically designed for the ourpose of controlling access to spending the output, perhaps the output script is the best place to create the delay.  This means that you would have to rely on the sender to use the output script you desire, but this could potentially be dealt with by immediately sending any bitcoins received with a "typical" output script to this new output script as soon as we receive it.

Except I don't think this solves OP problem (but I haven't played with scripts yet, just read https://en.bitcoin.it/wiki/Script once to get some idea - so please correct me if I'm wrong).

Let me add a legend to what I wrote below: We have S -> A -> V -> O transactions, where S is some outside sender who sent us coins to the A address. We immediately sent them to our V secure vault address which should give us some kind of time lock protection when sending coins to outside O address.

OP problem is: he'd like to have a secure vault protected with time lock. Spending coins from this vault should be protected/reversible on the peer level within certain time since the spend attempt from the vault. So he wants to add a secure time buffer after V -> O is executed.

As far as I understand how scripts work, once you satisfy output script, you can do whatever you like with coins and it's totally outside previous output script control. We can't have scripts which control scope extends beyond that point. So even if we create some time-lock protected A -> V transaction, its output script could only control after what time since this transaction coins could be send further. After that time has passed, the script would not have any control on the V -> O operation, which could be created using a standard transactions.

So script solution would allow: To have a vault protected with time lock, but spending coins from this vault would be protected on the peer level within certain time since the vault got the coins. So this could only add a delay after A ->V is executed, but after that time has passed, the V -> O couldn't be protected.

Am I right? I am only learning how scripts work and might not be aware of some things yet.

Also, another issue is that since we still have one private key required to satisfy the script, if the attacker steals that key, he has equal control over coins that coins owner have. So time lock or no time lock, the owner has no advantage over the thief.

[Terk]

Also, another issue is that since we still have one private key required to satisfy the script, if the attacker steals that key, he has equal control over coins that coins owner have. So time lock or no time lock, the owner has no advantage over the thief.

And regarding this, I think we already have a solution for a secure vault on the peer level, just don't have client software that supports it in a convenient way. M-of-N transactions are great for creating a secure vault, we just need support from client software. A nice implementation for vault addresses might be:

You run the software on an ever-offline computer (e.g. Ubuntu Live). You choose “create secure 2-factor vault” (let me call it that). What it does is generate two private+public key pairs and combine them into 2-of-2 address using createmultisig command. The software offers to export separately two sets of data: the first containing all three public addresses and one private key - into a txt file ready to import on your main computer. The second containing 2-if-2 public address (for identification) and second private key - as a print with QR code and/or encrypted file for digital backup (which you shouldn't ever decrypt unless you want to spend coins from the vault).

On your main computer, you import the first set of data and you now have the 2-factor address in your wallet as well as one of the private keys required to redeem. You can send your funds to this vault. If your computer is compromised, your coins can't be stolen as both private keys are required to redeem from the 2-of-2 address and you never stored the second key on your online computer.

When you want to send coins from your 2-factor vault, you are asked to provide the second key, which you can scan from QR code or import from encrypted file, etc.

Of course if your computer is infected at the moment when you spend coins from the 2-factor vault and provide the second key, the malicious software could alter your transaction and send your coins elsewhere (or just create a transaction on its own as soon as you provide the key), but there's nothing anyone can do to protect you from that. You can take extra security step and prevent that by launching a fresh Ubuntu Live, importing keys from the first set and providing the second key only on that fresh machine which should be clean. It would then connect to the internet to broadcast your signed transaction transferring coins out of the vault. This would be a relatively safe way to provide the second private key if you're not sure if your main computer is clean (i.e. even if your main computer is infected).

So this would be a quite safe pattern to have a secure, 2-factor vault which would not be accessible for thief even if you had all the malware in the world on your computer.

The need of using a clean machine at the time of sending coins from the vault is a limitation, but no time locks will help if the thief has complete credentials allowing to satisfy output script. If owner has no advantage over thief, as they both hold all required keys, there would be a race of who will act faster. Or if we had some reversible time-lock as the OP suggested, then we would have an (in)finite loop of mutual cancellations (which would in fact turned out to be finite, because the owner would finally let go or skip one iteration, while the thief wouldn't, as he would have it automated).

[coastermonger]

It's super early in the morning here and I really should be in bed, but I did want to mention a few things.  
Many awesome thanks to DannyHamilton for what I found to be a surprisingly concise and accurate summary of what's been discussed so far.  I'll contribute to that part of the discussion later.  

To address Terk's point:

OP's problem is: he'd like to have a secure vault protected with time lock. Spending coins from this vault should be protected/reversible on the peer level within certain time since the spend attempt from the vault. So he wants to add a secure time buffer after V -> O is executed.

As far as I understand how scripts work, once you satisfy output script, you can do whatever you like with coins and it's totally outside previous output script control. We can't have scripts which control scope extends beyond that point. So even if we create some time-lock protected A -> V transaction, its output script could only control after what time since this transaction coins could be send further. After that time has passed, the script would not have any control on the V -> O operation, which could be created using a standard transactions.

So script solution would allow: To have a vault protected with time lock, but spending coins from this vault would be protected on the peer level within certain time since the vault got the coins. So this could only add a delay after A ->V is executed, but after that time has passed, the V -> O couldn't be protected.

A user is basically taking coins he received from S and sending them from A to V himself.    V -> O could be protected by the scripts he attached to it during the A -> V spend, which is not the encumbered transaction, it would appear to happen normally.  But once at V the coins have the scripts which enforce the behavior desired.  I want to add a secure time buffer after A ->V is executed.  Once the coins are sent to O, you're absolutely right, they would not have these special encumbrances anymore.  We're only concerned with how they're getting out of V and the rules we can create when we send from A -> V. We would actually need more than just a time lock, because you're right that a simple delay would not work. (A thief could just wait to spend the coins like us) We need the transaction to have the following logical functions:

• Go to pending if it cannot find a previous instance of itself trying to be spent
• Go to pending again if it can find a previous instance of itself in the blockchain that occurred recently enough that its within a time frame we specified.
• Confirm and send the full amount if it can find a previous instance of itself in the blockchain that occurred outside the time frame we specified.
• Have the option to send immediately to a failsafe address we specified

This requires answering several questions.  What would "pending" look like in the blockchain?  How would the transaction know how to look for itself?  It might just have to know exactly where it is in the blockchain, just have an awareness of where it is relative to its original "intention transaction" and an ability to account for the difference between the two.  Maybe it will involve a script where we're telling the coins to become immature and unspendable for X amount of confirmations again. I am not exactly sure,

Also, another issue is that since we still have one private key required to satisfy the script, if the attacker steals that key, he has equal control over coins that coins owner have. So time lock or no time lock, the owner has no advantage over the thief.

One private key is indeed required to satisfy the script.  This is creating a kind of encumbrance where the hacker can try to spend the spend the coins if he has the private key.  But the coins will not spend immediately, in fact ideally they will publicly broadcast that there is an intention to spend first.  This public broadcast could be picked up in a variety of ways by a variety of programs that could ultimately notify the user.  The user could then even access his compromised computer and tell it to send the coins to a predefined failsafe address immediately instead.  He would not have to input the private key of the failsafe address to do so.  So the thief is left with 2 options: Either try to spend the coins with a public broadcast and waiting period, or send the coins back to another wallet that the user controls.  This is the owner's advantage.  He's set up his coins with these constraints that thief must abide by.  

Now, one could also argue that the thief may already hacked the fail safe address too, which in this case I would conclude that the user is indeed screwed for having the private keys for 2 different wallets on 2 different devices hacked simultaneously.  Designing a reliable fail safe is important, but the correct one may be something else.  I haven't thought of any elegant solutions for multi-private-key-hacking other than possibly having the ability to set up a whole chain of failsafe addresses, or allowing the failsafe itself to split up the coins.  But that's a topic for another very open-minded conversation, as it would basically require

Also for jl2012's comments

This may somehow increase the safety, but it just makes you more trouble. Due to the risk of chargeback, no merchant will deliver before your transaction becomes permanent.

I agree that no merchant should deliver before the transaction becomes permanent.  If a smart implementation can be found, the coins will not actually show up in the merchants address until a final confirmation.  The "intention to send" transaction will have no utility to anyone other than the owner.  This isn't an idea that allows users to send their coins to other wallets and then revoke them, this is an idea that makes it so their coins don't leave the wallet until a predefined period of time passes.

To achieve reasonable safety, the specified time must not be too short (e.g. the thief may steal your coins when you are sleeping).

Exactly, allowing users to specify how long they want the delay to be when they create the script is crucial so anyone would have control over this according to their needs.  Too short is fairly useless. Keep in mind however, that the blockchain is broadcast as public data.  One could have a 3rd party program to monitor that address for them and report any activity for that address via email, text, etc.

If the specified time is too long, you cannot spend your coins in a reasonable time.  

This is not technically true, I mentioned that a failsafe address is important because it allows the coins to always be able to be transferred to it instantly.  If a user deems that they need their coins right now They always have this option.  The thief would necessarily have to know the private key of both addresses to spend the coins instantly too.  Case in point, it's easier to hide multiple private keys versus just one.  Doesn't mult-sig do this? Yes, but multi-sig doesn't notify you if a thief attempts to spend your coins.

In conclusion, your idea is either providing slim improvement to security, or extremely inconvenient, or both

This is a pretty raw idea, a lot can be changed at this point.  A good amount of forethought can prevent it from becoming inconvenient.  What this requires is a thorough understanding of what can and can't be changed, as well as potentially unintended consequences.  DannyHamilton is right, we should be extremely cautious about allowing anything in the protocol that might break bitcoin itself.  

[jl2012]

This is not technically true, I mentioned that a failsafe address is important because it allows the coins to always be able to be transferred to it instantly.  If a user deems that they need their coins right now They always have this option.  The thief would necessarily have to know the private key of both addresses to spend the coins instantly too.  Case in point, it's easier to hide multiple private keys versus just one.  Doesn't mult-sig do this? Yes, but multi-sig doesn't notify you if a thief attempts to spend your coins.

So theoretically, the failsafe address should be a cold address or it won't be safe enough. When you need to spend a coin, you need to send the coins to the failsafe address first, then open your cold wallet (e.g. Armory) to send the coin out. So why don't you simply put your coins at the cold failsafe address at the very beginning?

[jl2012]

In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.

And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case.

But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel.

If the customers are happy with a few hours delay, the exchange can simply process withdrawal request manually with a cold wallet. So the only useful scenarios of the proposed system would be fixing mistake and fighting against dishonest staff. I think these risks could be minimized by multisig or other existing solutions.

EDIT: actually the proposed system is not a good measure against dishonest staff, as the staff could work with the hacker, or be the hacker himself. That means you still need another staff / a trusted computer to crosscheck the actions. So why not simply use multisig cold wallet?

[Maged]

In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.

And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case.

But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel.

If the customers are happy with a few hours delay, the exchange can simply process withdrawal request manually with a cold wallet. So the only useful scenarios of the proposed system would be fixing mistake and fighting against dishonest staff. I think these risks could be minimized by multisig or other existing solutions.

EDIT: actually the proposed system is not a good measure against dishonest staff, as the staff could work with the hacker, or be the hacker himself. That means you still need another staff / a trusted computer to crosscheck the actions. So why not simply use multisig cold wallet?

I don't disagree with the idea that this would provide marginal security over what we already have. But, there is added security with this. Basically, this is a way of doing multisig without requiring that one of the private keys ever touch an electronic device unless something bad happens. Theoretically, the CEO of a company could memorize a private key and derive its public key without a computer, reducing the number of people and things that have to be trusted - considerably. You could prove that it is impossible for someone to steal from you even if they hack every electronic device in the world. Is a paper wallet practically better than storing your private keys on a USB drive? No. But it's pretty cool to think about. The same applies to this idea. It would be interesting to see an alt-coin with this, though.

[jl2012]

In conclusion, you idea is either providing slim improvement to security, or extremely inconvenient, or both. So why don't you simply use cold wallet, which is inconvenient but perfectly safe? Soon we will have tamper-proof hardware wallet, which will be convenient and safe.

And that's really what this comes down to: what use cases would an "intent" system have over other solutions that don't require changing the protocol? It's not usable for a hot wallet, so that case is out. It would work well for a warm wallet, but since there are plenty of viable alternatives to preventing theft (using paper wallets, hardware wallets, or 2-factor wallets), I only really see it as a way of fixing mistakes, which is a pretty rare use case.

But... what if you think at the enterprise level? Where this ends up potentially being useful is in the hot wallet of a company that is monitoring their hot wallet 24/7/365. Imagine if an exchange got hacked. No longer would they require expensive "trusted" hardware that verifies that a transaction is valid and signs it. They just need every one of their receiving addresses to be a delayed-transfer address and have an understanding with their customers that they can't get to their money for a few hours. THIS is where an intent system would truly excel.

If the customers are happy with a few hours delay, the exchange can simply process withdrawal request manually with a cold wallet. So the only useful scenarios of the proposed system would be fixing mistake and fighting against dishonest staff. I think these risks could be minimized by multisig or other existing solutions.

EDIT: actually the proposed system is not a good measure against dishonest staff, as the staff could work with the hacker, or be the hacker himself. That means you still need another staff / a trusted computer to crosscheck the actions. So why not simply use multisig cold wallet?

I don't disagree with the idea that this would provide marginal security over what we already have. But, there is added security with this. Basically, this is a way of doing multisig without requiring that one of the private keys ever touch an electronic device unless something bad happens. Theoretically, the CEO of a company could memorize a private key and derive its public key without a computer, reducing the number of people and things that have to be trusted - considerably. You could prove that it is impossible for someone to steal from you even if they hack every electronic device in the world. Is a paper wallet practically better than storing your private keys on a USB drive? No. But it's pretty cool to think about. The same applies to this idea. It would be interesting to see an alt-coin with this, though.

How could you derive the public key without using a computer at all? Doing it by hand? That's too dangerous as any minor mistake in calculation will be fatal.

[Maged]

How could you derive the public key without using a computer at all? Doing it by hand? That's too dangerous as any minor mistake in calculation will be fatal.

Which is why the benefit is theoretical. 

[jl2012]

How could you derive the public key without using a computer at all? Doing it by hand? That's too dangerous as any minor mistake in calculation will be fatal.

Which is why the benefit is theoretical. 

You don't need to do it by hand. Just buy a raspberry pi, never connect it to the internet, calculate the public key of a brain wallet, and throw the pi to incinerator

[coastermonger]

I'm sorry to dig this topic back up.  But a big part of me thinks there's some very real utility in time-locking a transaction (make it wait before it can be sent out.) So I'm curious:  Does anyone think this is possible to do with some kind of auxiliary program/currency that integrates with bitcoin yet doesn't change it's protocol?

The biggest problem I'm interested in is that if someone discovers your private key, then poof your BTC is instantly gone.  I'm hoping the "instant" part of that can be voluntarily changed in some circumstances.

[gmaxwell]

I'm sorry to dig this topic back up.  But a big part of me thinks there's some very real utility in time-locking a transaction (make it wait before it can be sent out.) So I'm curious:  Does anyone think this is possible to do with some kind of auxiliary program/currency that integrates with bitcoin yet doesn't change it's protocol?

It's trivial to do, I'm disappointed to see someone making all these claims that "bitcoin-qt is insecure" (compared to??) doesn't actually understand Bitcoin well enough to answer this for themselves. Search the forum, there was even a thread about locking up coins recently.

The problem is that if the attacker has your private key he can just race you for the coins when they become spendable and get his spend of them mined first. Kinda lame.  Better to use a hardware wallet (coming soon) and not worry about that.

[coastermonger]

Hey Greg, I appreciate your patience with me on this.  I agree that hardware wallets will solve many security issues.  The problem I am trying to solve is about protecting your coins from theft even when their private key is compromised.

The problem is that if the attacker has your private key he can just race you for the coins when they become spendable

This is exactly the crux of the issue I'm talking about.  If this idea were fully developed, an attacker could *not* race you for the coins because the act of spending them initiates the waiting period.  Trying to change the spend destination would re-set the waiting period again.  The correct owner could transfer the bitcoin to a failsafe address instantly, which itself could again require timelocking to spend.

It's a security feature that combines both "m of n" and timelock properties.  I would find it enormously useful, because it means that if a malicious program somehow accessed  even our private keys, they would find it very difficult to steal bitcoin without suffering a waiting period, without notifying us, without convincing the entire blockchain to ignore the rules for this transaction that everyone has agreed upon, and without also finding the private key of a failsafe address which may very likely also contain a timelock.  

I know that the bitcoin network has some functionality to delay the spendability of coins because it does so with the new coinbase coins that are generated.   What I'm trying to envision here is a situation where a thief is hampered from stealing coins even when the private key is known.  

[gmaxwell]

Okay, I see what you're saying there.

It's actually a similar solution I suggested using coincovenants to make fail-safe redemption of coinwittness transcripts resistant to double spends.

The problem I was addressing there is that to redeem a coin from an external system the redeemer provides a transcript that shows they are rightful owner of the coin, but what if they were only the rightful owner at some point in the past and subsequently transferred the coin to someone else and that system has failed so you can't use it to prevent the doublespend?   My suggestion was that the redemption could be constrained to pay to an output which could only be redeemed after a timelock or before the timelock to someone with an even longer transcript (to another timelocked output).  This way it can only ratcht forward and you are guaranteed the rightful owner gets the coins so long as they are paying attention.

One place where the comparison falls down is that I don't see how your bounce race ever ends, you just cycle endlessly moving the coin from lock to lock.  One possibility is that you could require the fees to go up every time, and so if someone rips you off you make a transaction that pays all the coins to fees. This doesn't get you your coins back, but it guarantees that the thief can not make a profit... though perhaps he would still try hoping that you would not be paying attention.

I also get what you're saying about a recovery address but I'm unsure. If you could have your coins locked up with a timelock and have a secure recovery address which you could access within the timelock window— why not just assign your coins to that recovery address to begin with?

[Dabs]

The biggest problem I'm interested in is that if someone discovers your private key, then poof your BTC is instantly gone.  I'm hoping the "instant" part of that can be voluntarily changed in some circumstances.

While we still don't have the solution you want, just do everything you can to protect your private key from ever being discovered. Prevention is better than cure. Keep it offline.

[coastermonger]

Okay, I see what you're saying there.

It's actually a similar solution I suggested using coincovenants to make fail-safe redemption of coinwittness transcripts resistant to double spends.

The problem I was addressing there is that to redeem a coin from an external system the redeemer provides a transcript that shows they are rightful owner of the coin, but what if they were only the rightful owner at some point in the past and subsequently transferred the coin to someone else and that system has failed so you can't use it to prevent the doublespend?   My suggestion was that the redemption could be constrained to pay to an output which could only be redeemed after a timelock or before the timelock to someone with an even longer transcript (to another timelocked output).  This way it can only ratcht forward and you are guaranteed the rightful owner gets the coins so long as they are paying attention.

Your idea for constrained redemptions is pretty genius, it would be neat to see that kind of functionality someday.  

I also get what you're saying about a recovery address but I'm unsure. If you could have your coins locked up with a timelock and have a secure recovery address which you could access within the timelock window— why not just assign your coins to that recovery address to begin with?

The one big utility I see with creating timelock coins + a failsafe backup address is that it lets you have the near equivalent functionality of a hotwallet with cold storage security.  Offline wallets/paper wallets/hardware wallets are awesome, but a little clunky for some users.  They might not be the best security solution for every scenario.  

Ideally I would keep all my timelocked bitcoins running on a hot wallet with bitcoin-qt, and the failsafe would direct into a paper wallet.  I could spend/receive bitcoins into this address as I please.  If someone hacks my computer and tries to initiate a transfer of my coins, I will know about it and can stop it.  The knowledge of being compromised without suffering the consequences is pure gold, and is a far better alternative than discovering the hack all too late.  Imagine how many bitcoiners, exchanges, mining pools, and payment providers could sleep easy at night knowing their bitcoin can't leave their wallets without their timed consent.  Attackers would find that their methods would be exposed without profit.  

Alas, just a pipe dream for now.  I'm hoping that some day I can post a big enough bounty to see this kind of thing realized.  Even better if it can be done with an implementation that doesn't require changing the bitcoin protocol, but that will require some seriously creative thinking!