Topic: Hiding your bitcoin behind a timelock AND "m of n keys" at the same time? (Read 6800 times)

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


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!  

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.

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?

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.


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.  

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.

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.

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

Which is why the benefit is theoretical. 

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.

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.

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?

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?

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:


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,


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


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.


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.


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.


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.  

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

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


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.

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.

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

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.

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:


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


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.


Thank you for the compliment.


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.


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.


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


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.

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.