Topic: Why doesn't bitcoin have a "freeze" function? - page 4. (Read 1645 times)

I had assumed we were talking about wallets and collections of addresses rather than individual addresses. It is reasonable (even if not practical/possible) to want to freeze an address which is storing your life savings on it (or a portion thereof, since it is good practice to split large holdings across multiple different wallets), unfreeeze it to spend some portion of the coins on it, and then send the remainder to a different but also frozen change address. Alternatively to have some system which allows you to generate and freeze say 20 addresses at once, so you always have pre-frozen receiving and change addresses.

Incidentally, this all happens automatically when you use a multi-sig wallet, with every new receiving and new change address that you generated automatically protected by at least 2 different private keys.

Well it's like someone said, you start with a public key that is 256 bits. You can't get anymore entropy out of the address space than that. That's why using sha512 would be a waste of resources.


I'm surprised that all the way throughout this whole thread not a single person has raised the objection that "this isn't how bitcoin addresses are supposed to be used, they are only supposed to be used one time. You're not even supposed to use a btc address more than once so there's no need to freeze and unfreeze it because once you use it for the first time, you're done with it forever!"


Now I'm sure everyone is going to use that as an argument why a freeze/unfreeze feature should not be part of bitcoin! The reality is though that people do use the same address over and over.

As I said above, the 96 bits aren't lost or unused. But even if you assumed they were, these bits being lost or unused would not change the fact that bitcoin has 2¹²⁸ bits of security.

You need to decide whether you are trying to protect against someone brute forcing your private key (which will never happen) or discovering a back up of your private key.

It does practically provide more security, but this only really becomes relevant when considering quantum computers in the relatively distant future.

And why not SHA512? That'd be 2²⁵⁶ times securer than RIPEMD256! You said this yourself; to shorten the addresses, to shorten the chain size.

That's true for the addresses that have revealed their public key, which means those that have spent outputs. If an address has never spent funds, then you only know its RIPEMD160 hash. This theoretically provides more security.

Yeah I didn't think about that. But I guess it's true. So if the security of 160 bit addresses is only 128 bits then I guess the address space is not the weakest point. I'll have to go back to the drawing board.

That's a question you would have to ask Satoshi. But at the very least maybe he could have used RIPEMD256 in which case there be a 256bit address space thus more security. I suspect the reason he used 160 is to shorten bitcoin addresses up a bit.

First of, he changed the 94 to 96. Secondly, the security of secp256k1 isn't 256 bits, but 128. It's just the compressed public key (excluding the prefix) that is 256 bits.

Alright, here's a co-argument:  Why not replacing the RIPEMD160 (the one before the address' encoding) with SHA256? That way, there wouldn't be unused entropy.

Answer:  Just because a percentage of the entropy is lost (specifically 96 bits), it doesn't mean that the system becomes insecure. No one ever successfully found a private key by brute forcing unless it wasn't properly generated. As for the freezing feature, I explained you why it doesn't make sense.

All of the addresses end up to be just an encoding of 160 bits. (except P2WSH multisig)

Say, for example, the scope of private keys is between 0 and 99, and each of those private keys will map to a public key that are associated with addresses a - z. The way that bitcoin addresses are calculated, each of the private keys associated with address "q" for example are (for all intents and purposes) randomly distributed.

There are plenty of private keys that have been brute-forced. There are even thread about brute-forcing private keys. Other examples of private keys being brute-forced include when wallets intentionally use weak RNG, and an attacker is able to search private keys from a much smaller scope of private keys than the total scope of possible private keys. The attacker checks all the private keys from the reduced space, and steals coin accordingly, using the same private keys the user generated.

Generating a private key that is associated with an address that is associated with another private key someone else has generated associated with the same address is essentially zero. Further, if you have generated a private key associated with an address, you do not have any additional information that will make it easier to generate another private key that is associated with the same address.

Well, except for the fact that there is a many to one relationship between private keys and bitcoin addresses. Just saying that it might be possible to have a way to implement the freeze feature so that not all of those "many" private keys would be able to perform the "freeze/unfreeze" operation. Wouldn't that be an increase in security? Not a huge increase but still some.

I'm not aware of people that ever got their bitcoin private key brute forced. it might have happened but the chances are that the hacker found a private key different than theirs but it still resolved to the same address.

94/256 equals about 36%. So what that means is the security of bitcoin was reduced by that percentage. Not saying it's still not reasonable secure but it did get reduced by 36%. Now if there was a way to recover some of that lost security and use it in the context of my freezing/unfreezing idea that's what I was thinking might be a compromise between people who thinking having a separate freezing key is too much of a pain in the ass. Why not just use the private key you have and some of it's unused 36% entropy. That way every bitcoin user could take advantage of it to further protect the funds on their address that begins with 1. Without having to do anything like create a multisig wallet.

I was about to write that you can achieve almost the same thing like freezing simply with two wallets with distinct security level (e.g. one with several encryption levels on a non-connected device / hardware wallet and one on pc/smartphone for everyday transactions) but then I saw that the core of this idea was already brought up by @vjudeu and @o_e_l_e_o.


The proposal you made in this post would probably work if the devs added the "additional check" for miners in the protocol. It could surely be programmed into a token, be it Bitcoin-based (e.g. via Counterparty or Omni) or an altcoin with expressive scripting language. Maybe you could try to make first a "token prototype" if you want this feature really to be tested.

However, its only advantage to the "two-wallet-solution" seems to be that transaction fees would be lower for the freeze/unfreeze transactions. In reality, only the "freeze" transaction would have a significant advantage, because in the "unfreeze" transaction we have only one UTXO to move.

An ideal solution of course would include Lightning, so we can get rid of the fees almost completely. I however don't know if this is possible in a really safe way. A very rough idea would be to create a "channel factory" (multi-party channel) with 3 nodes, where you control two of the nodes and a counterparty (which acts as your "connection" to the rest of the network) another one. You can then set up different credentials for both of your nodes (one with a higher security level, i.e. by multiple encryption), and when you want to freeze your coins, you simply transfer all your Lightning balance to the more secure one.

I disagree a little bit with DannyHamilton's post, while he obviousy is right about what he writes, I think trusting a third party in this particular case isn't really the point, the point being more to have two different "security levels" to switch between, like with the two-wallet-solution that o_e_l_e_o wrote or garlonicon's multisig idea.

That:

We continuously try to justify why it makes no sense practically to implement this freezing feature while larry_vw_1955 believes that it'd be an improvement for Bitcoin. But, besides that, it doesn't hold water theoretically too. Freezing can't happen on your cash, only on IOUs. Bitcoin, can't operate in a creditable manner, because as said by its definition, it is a peer-to-peer electronic cash system.

Bitcoins aren't credit; if my transaction becomes confirmed, there's no debt from any parties. A confirmed transaction is a proof that both of them paid up.

You mean 1 address is valid for 2^96 private keys.

In your theoretical set up, you still need two pieces of information - your private key and your "unfreezing" key, code, password, or whatever it is. What difference does it make if you swap that second piece of information for a second private key? In both set ups you need to back up and use two pieces of information to spend your coins.

The other 96 bits are still used, despite the address space being smaller. You can't cut the last 96 bits off of a private key and still derive the same addresses.

At this point, we're in loop.

---

The extra 94 96 bits usually seen as minor security weakness since 1 private key address is valid for 2^96 address private key (ignoring different public key representation, different address format, etc.).

If you want to use the same private key to both "unfreeze" your coin and to spend your coin, your proposal is worthless. As has been noted above, if someone compromises your private key, they can both unfreeze and spend your coin. If your private key will not get compromised, there is no point in "freezing' your coin.

I was not referring to using a third party to freeze/unfreeze your coin. I was referring to using a second private key to freeze and unfreeze your coin. The end-user would control both private keys, but may employ different levels of security for each key.

In banking there's an equivalent term for that, it's called "block card". Once a card is blocked, it can't be unblocked (AFAIK).

It wouldn't make sense to add a freeze feature that you can unfreeze, because chances are the person with the private key will simply unfreeze it themselves. You need something to permanently freeze balance that you suspect is stolen, and unspendable transactions with OP_RETURN is what you're looking for.

It would be a better solution for exchanges and governments seizing laundered money instead of auctioning it away, it would also solve most of the AML drama since burned bitcoins cannot be sent to an exchange.

I honestly don't like the concept of needing 2 different private keys. I wish there was just a way to use a single private key. And still have the "freezing/unfreezing" feature. It's my understanding that even though private keys are 256 bits long, the address space is only 160 bits long. So Satoshi didn't use all 256 bits, he left 94 of them for us to be able to think up some super duper amazing thing to use them for to add extra security! The problem is how? It's not as easy as I thought.


i guess not. maybe they'd run their own node and try and spam invalid transaction to it first to see if it worked. but if they could look up an address and see that it was frozen then they wouldn't even bother doing that.

Well obviously, if they had access to the "freezing key" as well then the funds would be gone and I could easily see that on the blockchain. The more interesting question is how would they know they had the freezing key? If they didn't get it from me then where did they get it?


That would be a disaster. But I guess that's one of the drawbacks of this method vs 2 of 2 multisignature. which doesn't have this problem. It's like your funds forever being held hostage. Kind of like someone that used "Call me Ishmael" as their brain wallet because they were reading moby dick.

So go back and use the multi-sig set up I suggested earlier in this thread. If someone steals one of your private keys, they can't do anything with it. You need at least two private keys to "unfreeze" the funds, and they can't wait for you to unfreeze and then attempt to steal your coins without having the second private key.

Either a transaction is valid and will be accepted by a node, or it is invalid and will be rejected and not broadcast to the network. Since you have no idea which node an attacker might try to send their transaction to first, you have no way of monitoring for invalid transactions. And any half intelligent attacker would not spam invalid transactions in the first place.