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

[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.