Bitcoin Forum

What is a 'frozen' address?
    An address locked for spending (but yet it can receive money)

Why you want to 'freeze' an address?
    To prevent spending in case of stolen / compromised private key

How is that possible?
    Simple. protect it with another key.

How you protect this 'freeze' key?
    Generate offline. Use one key only once (twice, for lock and unlock)

but, turtles all the way down?
    two turtles better than one turtle?  ::)

What is made possible now by this 'freezing'?
    you can use your cool firstbits address forever without worrying about stolen key

Why so much attachment to some random bit, after all it is free?
    may be it is trivial in my case (1vijay), but what about these firstbits 1, 1paypall, 1citi, 1microsoft, 1google, etc.

Is this some kind of planned loophole / backdoor that allows access to .. ?
    no, only who can spend can freeze

How safe is this 'frozen' address ?
    the safest; safer than a paper wallet

Safer than a paper wallet?
    yes, spending is prevented by implementations

The safest, huh?
    yes, hm.. I mean, only as safe as your 'freeze' key

How will this be implemented?
    A team working on this (now, its only me)

I want this to be implemented, what can I do?
    let the world know. participate in the poll of this thread

(to be continued)

You can generate an address offline.

As long as you keep the private key secret, nobody can steal the bitcoin.

Any comments?

DannyHamilton told you how people implement this today.

Yes, I am aware of addresses generated offline, and tools used to generate addresses offline.  But, I tried to import private key to my block chain.info wallet and password protected wallet is backed up to many places. My password is quite strong, but I want to have more security for my wallet / address. Like, if I could externally freeze spending from my addresses, I think that would be great.

Whenever I want to spend btc I can unfreeze specific address for short period of time, and then freeze them again (by signing with different keys every time??).

This way I don't have to worry about my wallet getting stolen, because my addresses were frozen for spending.

All this is for I want to keep my firstbit addresses (1vijay, 1visu) forever. I still can create multi-sign (3xx*) addresses with one of these addresses part of it, but that's entirely different story.

I will try to explain further with detailed examples, implementation and pros/cons later. :)

So how do you freeze your address-sealing keys, to make sure no-one can use them to unfreeze your frozen accounts?

Its turtles all the way down.

-MarkM-

Good question. I am not planning to freeze my second key, instead I will change them as I prefer. I mean I will freeze with third key, and then unfreeze with second key, so now I would need only third key to unfreeze my address. One unfreezed, now I can use my first private key to spend btc. Immediately after spending I will freeze my address again with third or another new key (4th).

If somehow we can implement this to blockchain, then it would really be useful for everyone.

No.  This can't be done.

Transactions in bitcoin simply don't work they way you think they do.  Sorry.

Why you think it is not useful, or can't be done?

I still believe this kind of address freezing is the bestest safest way to store / exchange coins. :)

I will try to explain it further.

but with the ability to change second "unlock" key will be useful in many cases. so the first address remains safe always, and can receive money even when it was locked.

Now something similar to offline addresses mentioned above, can be done using multi-sign addresses, but in this case, new address keep changing, so it is not possible to use single address for receiving funds forever.

Now to answer an important question, when address creation is so cheep why you want to use one address forever? well, I got my firstbit addresses (1vijay and 1visu) and I don't want to loose it. Using one address as main address for all transactions, and protecting with second set of keys for freeze / unfreeze purposes, is preferable in many cases.

when I was reading through bitcoin.it, I found some concepts related to this 'offline / frozen address' do exist with bitcoin eco-syatem; like, nlocktime, exit address and contracts.

You can simply leave the private key of your vanity address in an offline client such as Armory. Locking private key X with private key Y gives you no extra security than 2-of-2 multisig with X and Y

No, I have already imported it to my Blockchain.info wallet. Again, addresses generated offline is not the same as 'frozen' addresses. 'Frozen' addresses only receive, and will not spend funds.

With 2x2 scheme receiving addresses keep changing.

May be I should put less emphasis on addresses, and throw away old addresses, after all it is free. But, I prefer to keep it forever.

Exploring 'script', and checking possibilities to define public address and firstbits-like shorthand notation (say 'secondbits') outside block chain. With this, I can keep one shorthand address notation and associate it with any public addresses.

And, I have to do this in a way that users don't have to trust 'secondbits' provider.

It would require a huge rework of the Bitcoin code, and introduce a hard fork to the blockchain. What you mentioned can be done by using a time-based 2-part signature service, much like TTBit was offering some time ago, but a more practical and secure way would be to generate the address using some offline utility like Vanitygen and print the keys out.

tl;dr: No.

We still offer it. lbaat.net. Although not sure it would satisfy what you are trying to accomplish

I am sure it wouldn't require lots of code changes. With some (lot) effort, I can implement all this myself. Real question is should we implement this, and what benefits it bring to the Bitcoin ecosystem.

And, no, surely it wouldn't require a hard fork, and this 'freeze' transaction is not meant to change already created blocks. It is only for new blocks (of course old addresses already in the block can also be used), it will also include transaction fees.

Simply,

 - an address can be frozen for spending
 - can keep one address without worrying about loss of its primary key
 - first primary key is protected by second primary which can be changed as and when required
 - second primary key is only used for lock / unlock (freeze / unfreeze) first address

It is not the same as m*n key because,

  - with m*n, address keep changing, so cannot use one address for all transactions

The stuff you're saying doesn't make sense.  I simply can't take anything you say seriously if you can't explain it in a way that makes sense.  Either you don't understand how bitcoin works, or I don't understand what you are suggesting. (Maybe both?)

Ok, here's an example,

Let's say you own firstbits address, '1Hamilton'. You spent lot of time, effort and money to generate it and you are happy to use this address for all your transactions.

At some point of time, you doubt your firstbits private key was stolen / compromised. Now only option for you is to stop using it. Would that be OK for you?

How about satoshi loosing his, firstbits '1'?

You got the problem now? :)

Yes, I've understood that you have a sentimental attachment to a random string of letters and numbers that happens to match a particular pattern that you like.  I've also understood that you are concerned about the private key associated with that string of characters being compromised.  This isn't the part that I don't understand.

The part I don't understand is how you think you can "freeze" an address without "lots of code changes" and why you think "surely it wouldn't require a hard fork".  I also don't understand why you think that "address keep changing" with 2-of-2 multisig.

No one else will do it. Not one of the main developers will also do it, when it's as easy as using a brand new or different address. Any address that can receive coins will be able to spend it if you have the private key.

> The part I don't understand is how you think
 > you can "freeze" an address without "lots of
 > code changes"

Frozen or not is just 1 bit detail, I hope this is possible through 'script'ing, so requires zero or minimal change. Just we need to check whether address is frozen before proceeding with sign validation. Yet, I am not very sure.

> why you think "surely it wouldn't require a
> hard fork".

I am suggesting that this can be implemented as specialized freeze/unfreeze transaction, or through a new flag in usual transactions. Either ways, this is going to be a new transaction with a fee. We are not going to redo all the hashing from Genesis block.

> I also don't understand why you think that
> "address keep changing" with 2-of-2
> multisig.

This again for the emotional attachment with the random bits. I want to include compromised address as one of multisig address. Now, I have to let everyone know my new address. When this address gets compromised, or every time I want to use different key to sign, then I have to create another multisig address.

This way also, I cannot use one address forever.

And, don't worry. I am not trying to give someone else the authority to freeze all your addresses. If they can freeze your address, then they also can also spend your money. Means, you need original private key to freeze an address.

This much is now very clear to me.


The "script" that is used in a bitcoin transaction describes what is required to spend the transaction. How can this be used to lock and unlock an address?


Easy to say. As far as I know, impossible to do without a "hard fork". Do you know of a method that would avoid a "hard fork" that you haven't described yet?


Which would require a "hard fork" as far as I know. Do you know of a method that would avoid a "hard fork" that you haven't described yet?


Nobody said anything about hashing from the Genisis block.  Perhaps you don't understand what a "hard fork" is?


Ok, I think I see your concern with multisig, but I still don't see how you are going to fix that problem with you "address freezing" process.

just use Armory, can even be the same wallet (then u have to use Coin Control) ;)

> The "script" that is used in a bitcoin transaction describes
> what is required to spend the transaction. How can
> this be used to lock and unlock an address?

the same way how script spends coins.

verify unlock signature, unlock, verify spend signature, spend

or, something similar to that.

Would like to end this thread, as I figure out implementation further.  :)
your suggestions always welcome.

Yes. Please end this thread.

Your suggestion of:


offers no improvements over multisig.  You would need to provide anyone who sends you bitcoin with the public key of your "unlock keypair" and they would have to create a transaction that includes that in the "script".  This would only lock that transaction, not the entire address, until the "unlock keypair" was compromised.  Then you would have to send out to everyone another unlock public key, and would have to move all your own old coins to a new transaction using the new unlock keypair.

This is essentially a multisig solution that requires giving out a public key instead of an address?

something like this..  ::)

I don't see where the "unfreeze key" is in that example?

thats ok, it is just an idea. an incomplete example.

finally, I got 1 more want in the poll. I am happy as if it is implemented.
I will edit first post for clarity. :)

How to freeze your bitcoins:

1. Print a paper wallet at bitaddress.org
2. Send your bitcoins to the address printed on it
3. There is no step 3

Recover your bitcoins later by creating a throwaway Blockchain.info web wallet, importing the paper wallet, and sending the coins to an address of your choice.  You can avoid leaving any unused coins in the web wallet simply by printing a new paper wallet and sending the balance there.

FTFY  ;)

@casascius, thanks for your post. finally, I think my post got some attention.
you are one of very few members, I can recognize by profile name. :)

now, how would you solve my main problem,

A frozen address with time-activated release would be far more secure than an offline address.

The requirement to 'keep a private key secret' makes security depend on humans, and humans are fallible.  Best to outsource security to the protocol as much as possible.

I can see lots of real world scenarios where a time-locked address would be useful and an offline address isn't good enough:

(1) A large 'bank' or exchange that has billions of dollars worth of bitcoin in cold storage. Even if the bank assigns multiple signatories to spend those bitcoins, they could be kidnapped and forced to disclose the private key.
(2) A famous rich person who is publicly known to own a lot of bitcoins.  Again, the frozen wallet would discourage kidnappers.
(3) A problem gambler who wants to keep his retirement fund safe from himself.
(4) A single parent who has terminal cancer and greedy relatives, and who wants to leave his bitcoins to his 13-year old child.
(5) A bitcoin enthusiast who lives under a tyrannical regime and fears that the authorities might imprison and torture him in order to obtain his bitcoins.

As bitcoin gains in value and maturity, these kinds of examples are going to gain relevance.

No matter how you cut it though, if you have a time-locked address, the bad guy has just as much chance of being the person to get the coins the minute the time runs out as the good guy, possibly even more so if the good guy is in a vulnerable position.

I think, "time-based lock" is different from "frozen".

"time-based lock" is for predefined time, "freezing" is adhoc.

compromised "time-based lock" address, has no protection.
when in doubt, "frozen" addresses can be unlocked, and then locked with new "freeze" key.

You keep saying this.  I give up.

easy for you, I can't do that.  :)

I still have to go a long way to answer questions like,
whether this can be implemented?
can I do this?
will this ever be released?

True. But my idea is to use the time lock as an additional security feature on top of already existing security features, such as offline wallets and multisig.

Instead of using time locks that expire on a fixed date, I would suggest using 'ratchet' time locks where the expiry date can be postponed indefinitely by the owner of the address.

so, someone gets they key can extend the lock and prevent you from spending.

how you could postpone a time lock? through a new transaction?

1. Probably can not be implemented.
2. Probably no easy way to do it yourself without changing the protocol. It could be client dependent.
3. Probably not ever be released.