Why doesn't bitcoin have a "freeze" function?

[PrimeNumber7]

This is off-topic in this thread, however even if you are encrypting a message to someone, for most people on this forum, you are trusting that the administrator has not changed the displayed encryption key of the person you are interacting with.

This includes that the keys have been transacted within this forum's private messaging system. The parties can communicate outside of the forum and exchange their keys there.

You are correct, but I believe the practice you describe is rare for people communicating on this forum, which is why I said "for most people on this forum".

Do nothing until I need to unfreeze them and spend something. then freeze them back.

I think that you haven't understood something very important. The system works autonomously. The nodes have to somehow verify that you're indeed the owner of a certain address whether you want to spend from that address or “freeze” it. So, you'd still have to provide a digital signature for each “freezing” action you made. Thus, “freezing” wouldn't differ from spending outputs.

That's why it can't be implemented with the way you want. A third party is always required.

In theory, a second key could be used to "freeze" and "unfreeze" outputs, which is separate from the key used to sign said inputs.

I don't see any reason why something like this would ever be implemented because it would result in additional transactions that are freezing and unfreezing outputs, and it would make keeping track of the UTXO set more complicated, both without any meaningful benefit.

[1714774566]

1714774566

[1714774566]

1714774566

[1714774566]

1714774566

[1714774566]

1714774566

[1714774566]

1714774566

[BlackHatCoiner]

You are correct, but I believe the practice you describe is rare for people communicating on this forum, which is why I said "for most people on this forum".

If they believe they have something to hide, they will. Encrypting messages isn't compulsory, but with your consent, you can choose not to trust the specific third party. You can even transact the keys via USB and trust none.

In theory, a second key could be used to "freeze" and "unfreeze" outputs, which is separate from the key used to sign said inputs.

But, if it was somehow compromised, it could still be unfreezed by someone else. It wouldn't differ from the classic private key way that spends outputs and thus, it wouldn't have any reason of existence.

[PrimeNumber7]

In theory, a second key could be used to "freeze" and "unfreeze" outputs, which is separate from the key used to sign said inputs.

But, if it was somehow compromised, it could still be unfreezed by someone else. It wouldn't differ from the classic private key way that spends outputs and thus, it wouldn't have any reason of existence.

You could make the same argument about the OP's online banking credentials. Although, in theory, one might take additional steps to secure a "freezing" key to reduce the chances a malicious actor would be able to "unfreeze" coin.

I do agree that the OPs proposal is not something that would improve bitcoin. All of my coin is in a perpetual "frozen" state until I sign a transaction that moves my coin to another address with my cryptographic keys securing my coin. If anyone tries to move my coin without the required signature(s), all nodes, including the miners will reject this transaction as invalid. I was merely playing devils-advocate in giving a technical alternative to what others were proposing. 

[BlackHatCoiner]

What I'm saying is that there are no reasons to be the third party who would freeze/unfreeze your funds, since you essentially already do that with your private keys. Freezing is a “feature” that comes when the funds are under someone else's custody and they allow you to take actions with them in an extent. You don't own the funds, this is why you may get frozen until you provide a legitimate element which may be enough for them to unfreeze you.

Freezing funds is a condition where the trusted third party requires information from their client. Implementing what we've been discussing is like being able for a bank to freeze their own money.

[larry_vw_1955]

Freezing funds is a condition where the trusted third party requires information from their client. Implementing what we've been discussing is like being able for a bank to freeze their own money.

That's why banks have die packs so that they can make their own money unusable when someone try and steal it. Same idea boss. Someone got my private key but I freeze the address, well, they can't do anything. But that does bring up a good question. How would I know if someone had my private key? Because they might just be waiting until I unfroze the address to try and do a transaction. I better make sure I unfreeze quickly and broadcast a transaction with big fee right? I guess it would be nice to have some way of knowing failed transaction attempts using my private key. You know how credit cards can send you alerts when someone tries to use your card fraudulently? That might be asking for too much though.

[BlackHatCoiner]

That's why banks have die packs so that they can make their own money unusable when someone try and steal it.

I think that the known phrase “be your own bank” has made you think of Bitcoin falsely. A bank has customers. If we assume that every bank needs customers to operate, then you're not your own bank with Bitcoin; you just have 100% control over your funds.

Someone got my private key but I freeze the address, well, they can't do anything.

How did they gain access to your private key? If they gained access to it, what makes you think that they don't have the “freezing key” as well?

I better make sure I unfreeze quickly and broadcast a transaction with big fee right?

If they want to rip you off, they'll find a way. The easiest way that just came up to me is to run a node. Once you broadcasted your unfreezing state which would end up in the mempool, they'd instantly recognize it and broadcast their fraudulent transaction.

[o_e_l_e_o]

How would I know if someone had my private key? Because they might just be waiting until I unfroze the address to try and do a transaction.

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.

I guess it would be nice to have some way of knowing failed transaction attempts using my 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.

[larry_vw_1955]

How did they gain access to your private key? If they gained access to it, what makes you think that they don't have the “freezing key” as well?

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?

If they want to rip you off, they'll find a way. The easiest way that just came up to me is to run a node. Once you broadcasted your unfreezing state which would end up in the mempool, they'd instantly recognize it and broadcast their fraudulent transaction.

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.

[larry_vw_1955]

How would I know if someone had my private key? Because they might just be waiting until I unfroze the address to try and do a transaction.

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.

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.

And any half intelligent attacker would not spam invalid transactions in the first place.

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.

[NotATether]

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.

[PrimeNumber7]

How would I know if someone had my private key? Because they might just be waiting until I unfroze the address to try and do a transaction.

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.

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.

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.

What I'm saying is that there are no reasons to be the third party who would freeze/unfreeze your funds, since you essentially already do that with your private keys. Freezing is a “feature” that comes when the funds are under someone else's custody and they allow you to take actions with them in an extent. You don't own the funds, this is why you may get frozen until you provide a legitimate element which may be enough for them to unfreeze you.

Freezing funds is a condition where the trusted third party requires information from their client. Implementing what we've been discussing is like being able for a bank to freeze their own money.

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.

[ABCbits]

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.

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.

At this point, we're in loop.

The only answer i can think is by creating cryptography signature from your private key.

OK. So it really can work is what you're saying?

What i say it won't work if you use private key for freeze/unfreeze address and spend your Bitcoin. The hacker who have your private key will simply unfreeze and spend your Bitcoin.

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.

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

[o_e_l_e_o]

I honestly don't like the concept of needing 2 different 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.

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

[j2002ba2]

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

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

[BlackHatCoiner]

That:

At this point, we're in loop.

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.

[d5000]

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.

1) Bitcoin address X wants to add the freeze feature. So it generates a special bitcoin address F.
[etc.]

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.

[larry_vw_1955]

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

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.

[larry_vw_1955]

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.

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.

[PrimeNumber7]

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.

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.

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.

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.

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.

[BlackHatCoiner]

94/256 equals about 36%. So what that means is the security of bitcoin was reduced by that percentage.

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.

Why not just use the private key you have and some of it's unused 36% entropy.

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.

That way every bitcoin user could take advantage of it to further protect the funds on their address that begins with 1.

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