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

[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

[1714174626]

1714174626

[1714174626]

1714174626

[1714174626]

1714174626

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