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

If you don't want to choose your UTXO, then you have to accumulate everything on one UTXO. Because transaction fees depend on transaction size, people have incentive to use as small number of UTXO's as possible. There are coins like Ethereum where everything is account-based and all amounts are automatically accumulated, but that's the same level of privacy than using single UTXO in Bitcoin. If you have more splitted funds, you have better privacy, but you can always send coins to yourself and have just one UTXO if you really want.

While it's good alternative, it could be costly if OP doesn't pay attention about transaction fee or the wallet has poor UTXO selection.

I think that you didn't pay attention to DannyHamilton's post, which was a wonderful read by the way.

You probably haven't understood that this electronic payment method is a currency. Note that it's significant and completely different from payment processors. When you're using your credit card to buy something, you become in debt of this purchase in fiat. When, your Netflix sweeps you money from your bank account for the monthly payment, it debts you in fiat. Unless you pay someone in cash, you're getting constantly in debt for your purchases.

Your credit card and your bank account aren't currencies; they manage to debt you in a currency, which is fiat. In Bitcoin, if you make a purchase, you aren't in debt of anything; the confirmed transaction is a proof that you paid your dues. I don't know if you understand this, but it's significantly different.

If you wanted from Bitcoin to have a “freeze” option you should deposit it on a third party and they'll freeze your money (which is no longer yours) whenever you told them to.

In my ideal scheme that I have proposed (who knows if it is actually feasible/reasonable to expect devs to ever consider), the utxos are all turned on and off together like lightbulbs on a christmass tree. no need to worry about which ones to freeze and unfreeze in order to construct your transaction.

---

i always feel stupid when i come up with some complicated scheme and then someone introduces me to something that already exists and does the same exact thing 

your idea is pretty close to the same end effect but the method is not the same. the only thing i would argue here is the funds in a 2of2 multisig, their utxos are not in any type of frozen state. with my idea which i know is crazy, the utxos have a state. the state must be changed before they can be spent. how that state gets changed should be cheaper than having to combine alot of utxos and send them to somewhere else to be spent.

[moderator's note: consecutive posts merged]

True, but taproot would keep the multisig transactions as small as possible, and if he does pay attention to his UTXOs then he could potentially save money over "unfreezing" unnecessary UTXOs only to have to "freeze" them again. Seems like the simplest solution to what he wants to achieve.

Then just use a multi-sig cold storage set up combined with a standard single-sig wallet. The single-sig wallet can be a hot wallet for portability and convenience, or can be a hardware wallet or cold storage itself for added security.

Think of your coins in the multi-sig as "frozen". No one can access them without gaining access to 2 (or more) private keys, just like someone wanting to use your credit card needs to gain access to 2 factors - your credit card itself and your online account. When you want to "unfreeze" the coins, send them from this multi-sig address to your single-sig address and make as many transaction from this single-sig as you like. When you want to "freeze" them again, send them back to the multi-sig cold storage.

The bonus of this set up is you do not need to "unfreeze" your entire stack, and can choose to only "unfreeze" as many coins as you want to at the time.

to unfreeze and spend you would need both but once it is unfrozen, they can do as many single sig transactions as they want to which is more convenient to the end user. Once they are done they can lock it up again by signging once with their private key. that's the theory of it anyway.


I get that totally 

What you describe is just a complicated and more expensive version of 2-of-2 multi sig. in order to spend the coin, you need the private keys for address x and address F.

As Danny mentioned above, your coin should not be thought of as an account, but rather as cash.

As I mentioned above, “freezing” your credit card is a loss prevention feature to prevent losses for your bank, not you. With credit cards, you are generally not liable for unauthorized transactions.

got you boss.


i'll definitely check that out boss. and just for my own enjoyment I hope you wouldn't mind if I assign a uuid to this thread so that I can use it for reference purposes. the entire thread i mean.

61842BEE-940A-40E5-9896-00B427E85790

Then you need to stop worrying about some incredibly unlikely scenario in which someone breaks in to your house to physically access your computer to steal your coins, and start instead worrying about the fact that you are storing your seed phrase on an internet connected device. The latter is far more likely to result in your coins being stolen. This is like worrying about your seat belt being too loose while ignoring the fact that your brake pedal doesn't work.

When setting up a 2FA Electrum wallet, you are still provided a seed phrase which will provide you with all the information necessary to sign a transaction on your own. Should TrustedCoin go out of business, you can simply restore a full wallet from your seed phrase and access your coins.

Yeah I'm not sure all cards have that feature but mine does. I don't even have to enter any pin # or password or anything. I just click the 
"freeze" button at the top of the webpage once I am logged in and it's that simple. Then the button says "Unfreeze". These actions take place immediately. From my experience.


My proposal makes the utxos inactive, unable to be spent until a certain action is performed first. Sweeping the address would just kick the can down the road in the sense that the utxos are basically still active and able to be spent but they just belong to a different address. That's not what "freezing" is all about.

Additionally, if someone had an address that had a large number of utxos it could be quite costly to transfer them all to a new address. With my proposal, they wouldn't have to do that. Because they are frozen in place. And the transaction that freezes them would be tiny. Thus costing as little as possible. And removing the real risk that they enter the destination address incorrectly and lose all their funds or they get some malware that changes their address and they lose everything. With my solution the bitcoins are never touched or moved anywhere.




Not at all the same. My proposal could easily be extended to offer multiple states in which even greater functionality would be possible. Say you had an address that had 10 bitcoins in it and you were worrried that someone might hack your private key and drain the funds in one fell swoop. Well, just put your address into a state which says they can only spend 0.01 bitcoin every 144 blocks (everyday). Since you don't usually spend more than that much in a single purchase, it won't affect you. But it would take a hacker quite a long time to drain all your funds. And you would probably notice it long before they got anything substantial from it. Since you check your balance at least once a week.

[moderator's note: consecutive posts merged]

I don't have such a feature on my cards so I am not exactly sure how it works. I assume all you need to do to freeze/unfreeze your account is log in to your online banking account, enter your password or maybe a PIN and that's it. Although it's a good security feature, it isn't exactly high-tech. If someone stole your PIN/password/whatever you use to freeze/unfreeze your credit card, they could do it as well.

If you are concerned about someone being able to spend your digital assets by discovering your seed, why not extend it with a passphrase? No one would be able to steal your coins unless they have the passphrase as well. You can compare that seed extension to the password you use to freeze your credit card with.   

It can be easier than you think. No coin can be spent twice, so the only thing you need to "freeze" funds is just spending them. You can send coins to yourself, in this way the old address is "frozen", because coins can no longer be spent, but that second address can control freezing and unfreezing, because all you need to unfreeze your coins is just sending them back to the same address. Of course address reuse is a bad idea, so you can use fresh address from some HD wallet every time.

To control freezing and unfreezing you don't have to store private keys online. You can have some signed transactions prepared upfront and just broadcast them when you need.

Exactly, it would be the same.

I have 2FA set up with paypal, but it's a real pain in the ass. Everytime I login I have to go to my authenticator and get a 6 digit code. But I do it because someone actually logged into my paypal account once and tried to transfer alot of money straight out of my bank account to another country.



I trust coinbase with the $3 i earn here and there. nothing more. in general, i dont place too high a premium on exchanges. they are useful for getting crytpo but i like to get it the helll out of there asap.

---

Yeah that's a good point. So what you're saying is we don't want the freeze/unfreeze feature to be solely dependant upon knowing the particular bitcoin addresse's private key. I think I see what you're saying. Now the question is, how are we going to implement it then ?

---

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

2) This new address F will control the state of address X.

3) When the user wants to freeze address X, they send a transaction to address X using a special opcode.

4) The first time a user freezes their address X using address F, miners will create a record in a special database that lists address X along with its related controlling address F. A flag field will be toggled to "1" which will represent the frozen state.

5) If a transaction is ever attempted from address X in the frozen state, miners will reject it because they will first consult their database and see that address X is in the frozen state. Assuming no other reasons for which the transaction would be invalid, they can provide an error code indicating the address is frozen and thus the transaction cannot be completed.

6) When the user wants to unfreeze address X, they just send a transaction to address X from address F using the same opcode.

7) Miners will update their database and update the record for address X by toggling its flag field to "0" which will represent the unfrozen state.

If a transaction is ever attempted from address X in the unfrozen state, miners will first consult their database and see that address X is in the unfrozen state and then continue to process the transaction as normal. If it passes all the other consensus rules then it will be accepted.

Do you guys think this would work? I spent the better part of a day coming up with it so I sure hope so! Let's turn this baby in to a BIP.
 













[moderator's note: consecutive posts merged]

Wouldn't transferring balances to and from that wallet/key be effectively the same thing?

I'm not sure how freezing would work without a higher authority, which would no longer be bitcoin.

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.

You are thinking of Bitcoin as an electronic payment system instead of as a currency.

If you have cash in your wallet in your back pocket, there is no way to "freeze" that.  If anyone get's their hands on your wallet, they can spend the cash that is in it.  The way you protect your cash from being spent is to do one of two things. You either make sure that the cash is always under your control (that nobody else has physical access to it), or you find a trusted third party (such as a bank) and you give it to them, trusting that they will make sure that the cash is always under THEIR control (using economy of scale, they can implement more expensive vaults, guards, security systems, and insurance than you can).

IF you choose to trust someone else (such as a bank) to maintain control of your funds, THEN they can provide a method for you to "lock" your account with them so that no transactions can occur until you perform some "unlocking" action.  Of course, if the thief can figure out out to perform the unlocking action, then they'll still be able to access the account.

This is exactly how Bitcoin works.

If you use your own wallet, and you have control of your private keys, then it is up to you to secure those private keys so that nobody else can access them. This is like cash in your back pocket, or in a small safe in your house, or hidden in a drawer somewhere in your house, etc.

If you choose to use a custodial service, then you can turn over complete control of your bitcoins to that service. That service can then make transactions on your behalf whenever you ask them to. You'll have to trust that they'll do a good job of securing the bitcoins that they are holding for you against both outside attackers and internal fraud. It would be easy for such a service to provide a "locking" method where they would refuse to create any transactions on your behalf until you perform an "unlocking" action. This is like depositing your cash into a service (such as a bank).

Coinbase already offers something like this with their 2FA system.  You can "lock" your Coinbase account with 2FA, and then they will refuse to send any transactions on your behalf unless you provide the appropriate 2FA value to "unlock" your account for that single transaction.

It sounds like you could achieve the kind of set up you are looking for with a 2FA wallet. It's not exactly the same as freezing an address, but it would achieve a very similar outcome:

With your credit card, someone can steal your credit card or steal your credit card number, and not be able to spend your money unless they can also break in to your credit card account and hit the "unfreeze" button.

With a 2FA account, someone can steal your wallet file or steal your private key, and not be able to spend your coins unless they can also break in to your phone and access the 2FA code.

The downsides to this approach are that Electrum's 2FA charges an additional fee, but you could get around this by using a manual multi-sig set up. You also need your wallet and 2FA app (or both wallets if doing it yourself) to be on different devices, so the compromise of one device doesn't lead to the compromise of both factors/private keys needed to sign a transaction.

So basically you want to prevent people who have private key of your Bitcoin address can't steal your Bitcoin while it's frozen. But on protocol level, how do you freeze the address and how node can verify that you're the owner the address? The only answer i can think is by creating cryptography signature from your private key.

 I mean after all that's how it works with my credit card. I lost it once and someone found it but since it was frozen, they couldn't use it AT ALL. Not only that but I didn't lose any money either. My credit line transferred over to the new card the credit card company issued me. And guess what? It was not the same card number as the old one, if that's any help. Dave in card services was really helpful. I told him i felt like an idiot for losing my card and he said no problem they understand and it happens don't worry about it.


Well, I can't really answer that about bitcoin but I know how it works with my credit card if that would help. they have a big database and in the tables, there's a field that can be marked with F for frozen or U for unfrozen. Everytime a transaction comes in, they pull up that record in the database for my card and check if the field is F or U. If it is F then it won't approve.



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