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

[larry_vw_1955]

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.

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.

[1714866953]

1714866953

[1714866953]

1714866953

[1714866953]

1714866953

[larry_vw_1955]

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.

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.

[BlackHatCoiner]

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.

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.

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

[o_e_l_e_o]

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.

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.

This theoretically provides more security.

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

[larry_vw_1955]

And why not SHA512? That'd be 2²⁵⁶ times securer than RIPEMD256!

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.

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.

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.

[o_e_l_e_o]

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

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.

[BlackHatCoiner]

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.

Fair point, but I was assuming we used a curve to avoid that waste of resources (like secp521r1). Anyway, my point was clear; there's no reason to increase the security that much. It becomes extravagant and makes the chain heavier.

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.

I wouldn't say so, unless you do it on purpose. HD non-custodial wallets like electrum are made in a way to avoid reusing the same addresses. Once you spend money from one of your receiving addresses, the changes end up to a change address that was never used before. Once you spend from that change address, same thing happens. Even on custodial wallets like Coinbase, they never show you a previously generated address for deposit.

[larry_vw_1955]

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.

what kind of multisig wallet software are you talking about? because i actually created one by hand once but i couldn't find any software to use it with lol.

[BlackHatCoiner]

what kind of multisig wallet software are you talking about? because i actually created one by hand once but i couldn't find any software to use it with lol.

What do you mean that you created by hand? If you've used multi-sig in the past, how did you manage to do it so? Probably, the most known non-custodial multi-sig wallet out there is Electrum.

The example o_e_l_e_o gave you, correctly answers on what you want. You'll have to create a 2-of-2 multi-sig wallet, which means that for each address, it is required to provide two signatures to spend an output (not just one). Theoretically, you can consider one of them to be the freezing key and the other to be the private key that is used to spend outputs. Whoever gets access to your private key can't steal your funds unless they also gain access to the freezing key.

[o_e_l_e_o]

what kind of multisig wallet software are you talking about? because i actually created one by hand once but i couldn't find any software to use it with lol.

Yeah, as BlackHatCoiner has said, I would probably use Electrum to achieve what you are looking to achieve. If you want to be able to spend bitcoin on the go as you would with a credit card, but then "freeze" it when you are not planning to use it, then this is what I would do:

• Create a 2-of-2 multi-sig Electrum wallet using Electrum on your phone as one wallet and Electrum on an airgapped computer stored safely in your house as the second wallet. (Obviously using verified downloads, backing up the seed phrases on paper, and all the other usual security precautions.) Send your coins to this wallet.
• Create a standard Electrum wallet on your phone, which will be used as your daily hot wallet.
• When you want to unfreeze some of your coins, send a portion of them from the multi-sig wallet to the hot wallet. This will require signing a transaction from both your phone (which can be thought of as analogous to your credit card in this case), and your airgapped computer (which can be thought of as analogous to your credit card's freezing function). Return any coins you don't want to unfreeze as change to a new address in the multi-sig wallet.
• The coins you just unfroze by sending to your standard mobile wallet can be spent normally, as and when you desire.
• If you want to freeze them again, you can send them back to a new address in the multi-sig wallet. Since you are using your phone for both wallets, you can easily obtain a fresh multi-sig address while on the go.

The only downside I can see here is that you can only unfreeze coins when you are at home. You could work around this by replacing the airgapped computer with hardware wallet you can carry with you.

[garlonicon]

The only downside I can see here is that you can only unfreeze coins when you are at home.

To solve that, you can prepare some signed transactions upfront, in this way you can broadcast them without accessing your "freeze/unfreeze key", if you have 1 BTC, you can have some transactions spending for example 0.01, 0.02, 0.05 and 0.10 BTC, in this way the rest of your funds are safe, because all such transactions will unfreeze only a part of your funds, sending the rest to some fresh multisig address.

[o_e_l_e_o]

The only downside I can see here is that you can only unfreeze coins when you are at home.

To solve that, you can prepare some signed transactions upfront, in this way you can broadcast them without accessing your "freeze/unfreeze key", if you have 1 BTC, you can have some transactions spending for example 0.01, 0.02, 0.05 and 0.10 BTC, in this way the rest of your funds are safe, because all such transactions will unfreeze only a part of your funds, sending the rest to some fresh multisig address.

It's a good idea, but those coins in the pre-signed transactions do lose some security by doing this.

If I am carrying around pre-signed transactions moving multi-sig funds to my hot wallet, then those coins are really only as secure as those funds which are already in my hot wallet. If someone is going to compromise either me or my phone and steal the coins in my hot wallet, then they can probably steal the coins in these pre-signed transactions (which are presumably saved on my phone) as well. I suppose if you encrypted the transactions them then it does give you plausible deniability against a physical attack.

It's definitely still preferable to carrying a hardware wallet which can be wrench attacked to empty your entire multi-sig wallet, though.

[PrimeNumber7]

The only downside I can see here is that you can only unfreeze coins when you are at home.

There is also the issue of cost. Tx fees are cheap now, but they will not always be this way. If you want to unfreeze some of your coin, it will typically be because you want to spend it, thus it will probably not make sense to pay a fee that results in it taking days (or longer) to confirm when unfreezing your coin. Similarly, when freezing your coin, if you pay a fee lower than next block confirmation, while your tx remains unconfirmed, there is the potential for it to be double-spent by someone who has access to the private keys on the phone wallet (in your example).

[larry_vw_1955]

What do you mean that you created by hand? If you've used multi-sig in the past, how did you manage to do it so? Probably, the most known non-custodial multi-sig wallet out there is Electrum.

I mean I took 3 private keys and created a multisig address using a script that requires 3 of 3. Since I did everything from a script, there was no wallet software or anything. So I wasn't sure if I could import those private keys into some wallet software to let it help me do transactions. That's the problem. Not sure if electrum would help me with that problem, since I know it lets you create multisig wallets but if you already have existing one I dont know.

Oh, also I don't know if this is true but I read somewhere that you can actually use the redeemscript as your btc address instead of the p2sh address. Damn that would be cool. On the one hand, you're giving away your public keys but on the other hand, you can bypass the p2sh collission issue ... I know it's probably not reasonable to be using a redeemscript as an address but someone said you could. don't know how that would work! Hey joe, here's my btc address, you'll notice it's kind of long!

[larry_vw_1955]

Yeah, as BlackHatCoiner has said, I would probably use Electrum to achieve what you are looking to achieve. If you want to be able to spend bitcoin on the go as you would with a credit card, but then "freeze" it when you are not planning to use it, then this is what I would do:

[/list]

Solid advice, thanks. I wish I would have set it up that way to begin with. But I used a script to create a 3 of 3. I didn't stop to consider how hard it might be to actually spend from it. But I'll definitely try your idea in the future, seems like the way to go.

[BlackHatCoiner]

On the one hand, you're giving away your public keys but on the other hand, you can bypass the p2sh collission issue

I think you're somehow missing the point if a collision were to ever happen. I don't know exactly what's is written in the Bitcoin's source code, but just because you revealed the public keys doesn't mean that you get away the collision issue. In P2SH, the nodes firstly verify that the hash of the public keys gives you, indeed, the HASH160 you gave them at first, when you later want to spend from that multi-sig address.

But, if another set of public keys gives you the same hash once is hashed, both are considered correct during the verification part. The nodes won't realize that this multi-sig address with these public keys can't spend just because another person had spent in the past from one with the same hash, but with different keys.

If you want to get rid of the collision issue, just use P2WSH multisig. There are a total of ~2²⁵⁶ private keys you can use which is a smaller number than the total addresses you can create (2²⁵⁶). (Of course, there are still cases with collisions, but much less)

You can observe they're more supposedly secure in a brute force than the others from their length:

Code:

tb1q7hqy8sfea6nr5gfghjtl6emxfas9mv5rqragxppcfgxhwqdsu7psluzu2e (testnet)

[larry_vw_1955]

I think you're somehow missing the point if a collision were to ever happen.

I was talking about instead of hashing the redeemscript to get a p2sh address, you just use the redeemscript itself as the address. I never heard of that but someone said you can do that. not sure if it is true. But I took a redeemscript and pasted it into a block explorer and it said it wasn't a valid btc address. so either block explorers don't understand some addresses or that information was just wrong. i'm betting on the latter 

[o_e_l_e_o]

There is also the issue of cost.

In OP's initial proposal, he was suggesting having a second address which would control the frozen state of the primary address by way of sending special transactions to and from this second address. Given that, then the fees he would pay in my system are not significantly higher, and once taproot shrinks multi-sig transactions, won't be higher at all.

But I used a script to create a 3 of 3. I didn't stop to consider how hard it might be to actually spend from it.

What script? Generating all the keys for a multi-sig wallet on the same device at the same time negates a large portion of the additional security that a multi-sig brings. Also, please tell me you didn't send all your coins to an unfamiliar wallet before first testing you knew how to spend from said wallet?

[PrimeNumber7]

There is also the issue of cost.

In OP's initial proposal, he was suggesting having a second address which would control the frozen state of the primary address by way of sending special transactions to and from this second address. Given that, then the fees he would pay in my system are not significantly higher, and once taproot shrinks multi-sig transactions, won't be higher at all.

I wasn't even referring to the added cost of using multisig (although that is also a temporary issue), I was referring to the cost of moving your coin back and forth between your hot wallet and what is basically cold storage unnecessarily, and due to the nature of the goal of the setup, almost always having to pay 'next block' level transaction fees.

If you are not comfortable having a certain amount of coin in your hot wallet all the time, it is probably not a good idea to be moving that amount of coin to your hot wallet on any kind of a regular basis. If your hot wallet keys are compromised unknowingly, the attacker does not need to immediately spend coin from that hot wallet, and they probably won't if they know that a large amount of coin is regularly sent to said hot wallet.

IMO the proposed setup involves poor security practices, even if it meets the OP's (misguided) stated goals.

[larry_vw_1955]

What script? Generating all the keys for a multi-sig wallet on the same device at the same time negates a large portion of the additional security that a multi-sig brings. Also, please tell me you didn't send all your coins to an unfamiliar wallet before first testing you knew how to spend from said wallet?

Just a little script. Well that's the problem there is no wallet. When I made the address I guess I thought there has to be a way to import it into a wallet and then just spend from it but no! And yes you right that I didn't generate the 3 address on 3 different computers. probably not the best idea.