Yes! I think this is a great idea. I think we should invent the concepts of an “I-got-robbed button” and “slow money”.
You could take some of your money and choose to put a “slowing spell” on it. When you cast the slowing spell, you choose the amount of delay imposed, e.g. 30 days. After you cast the slowing spell, then the next time you move that money (send it in a transaction to a new address), the transaction doesn’t finalize for 30 days. During the period that the transaction has been initiated but not finalized, you can hit an “I-got-robbed button” to cancel the transaction.
That’s the basic idea. I’ve thought about it quite a bit and there are a couple of more tweaks we should probably add.
One is that if you hit the I-got-robbed button, the money should be returned not to the original sender (which, after all, probably just had its private spending key stolen), but to a different address. Maybe we could integrate this with hierarchical deterministic keys, to make it easier for people to learn and use. And of course, the slowing-spell should still stay on it in this case!
(Whereas in the other case — if you move the money and the waiting period elapses without anyone hitting the emergency button — then the slowing spell is over, and the new private spending key would have to choose to cast it again if it wanted.)
Another is that if you hit the I-got-robbed button, then maybe you shouldn’t get 100% of the value back, but perhaps 95% or 90% of the value. This would be a disincentive to use the I-got-robbed button to defraud or extort recipients. I’m not sure about the security implications of this tweak.
If the private key is compromized, so that multiple people have access to it, the person who presses the I got robbed button may not be the owner. Instead of transferring the funds to a different address with another delay, the funds need to be frozen indefinitely pending the outcome of an arbitration proceeding which decides the true owner. The arbiter should have been preselected in advance by the owner of the private key before it got compromised. A private key owner should be able to associate one or more approved arbiters with an address in advance, so that if the I got robbed button is pressed, the funds can be frozen pending the outcome of a decision by the arbiters associated with that address. The identity of the arbiters might be hashed to keep them private, only disclosed if necessary.
Adding to my previous reply, it occurs to me that if an address can have a hashed list of arbiters associated with it, it can also have any arbitrary hashed message associated with it, which can be published when an I got robbed button is pressed. The arbitrary message can have the real name and contact info of the key owner, as well as the names of the arbiters, and their public keys. Then it would be very simple for the arbiters to know who owned that key and they can just move the funds to a new address of the owner’s choosing. The arbiters can be paid a fee for this service, deducted from the amount transferred.
Alternatively, the “I-got-robbed” address could be specified by the user at time of casting, so e.g. they could have a luke-warm address in which the slowed funds are stored, and then set up a cold address for fallback. This is equivalent to the caster initially selecting an arbiter, but instead relies on the security of the cold address rather than the benevolence (and presence) of the arbiter.
That would be a decent alternative, but the possibility exists that even the cold address may have been comprimized. If the only thing stored on the blockchain is a hash, which could be of any arbitrary message, there is room for a lot of flexibility to let the user choose different ways to handle an I got robbed button. The choice would be made in the message itself, and would not incur any cost in blochchain storage unless the message gets published. Also, the I got robbed message should be broadcastable by anyone who knows the message, (trusted friends), not just the owner. So long as the message matches the hash, anyone could broadcast it. For instance, when Ross Ulbright had all his servers confiscated, if the message only had his real name, and some arbiters, and could have been broadcast by his friends, then the confiscation of his bitcoin could have been defeated by one of his friends broadcasting an I got robbed message for him, even with him in jail. Presumably he would have chosen arbiters in another country outside of US jurisdiction. Or if somebody was in the hospital and their house was robbed, and the robbers found the printout of the cold storage key too, if the arbiters are known public figures, their reputation would be on the line if they do anything dishonest when somebody trusts them to resolve stolen funds. Thus, a panic button could just make everything public to bring reputation into play. However, the message could allow just moving to another cold storage if the user chooses. Any kind of script could be allowed.
Correct. The simplest way to implement an “I-got-robbed” button would be as some kind of optional P2SH scriptPubKey on the slowed ZEC, such that the button itself would be a pre-signed P2SH payment that could be broadcast by anyone. The P2SH script could pay to the user’s cold address, or to addresses of pre-selected arbiters, or any other script. This is similar to CLTV, except that CLTV would start the timer from the point at which the funds entered the luke-warm slow-addr, whereas we’d want the timer to start from the point that funds were spent from the slow-addr (essentially enforcing CLTV on all spends from the slow-addr except the “I-got-robbed” transaction).
That makes sense. I was unfamiliar with P2SH and CLTV and had to look them up, but now I understand what you were saying. Thank you for the explanation.
I disagree with this. The recipient will know they have received slowed funds and can value them accordingly. It is up to the recipient to guage the risk of fraud and deal with the risk accordingly. Slowed funds would probably be valued at a discount coresponding to how much it would cost to insure the risk of fraud. If a person only has slowed funds and the recipient won’t accept them, the person can trade slowed funds for unslowed funds from one of his friends or somebody who trusts him. There could even be professional dealers who buy slowed funds at a discount.
If somebody intended to commit fraud, and were able to do so profitably while still paying the penalty, then the penalty would still not stop fraud. It would only reduce the proceeds.
Even the presence of a penalty would not cause slowed funds to be valued the same as unslowed funds. The would still be a risk discount.
The penalty might reduce the proceeds for some intentional fraud, but it would certainly hurt honest people who need to use the feature. That would be unjust. If you are okay with such injustice based on the logic that the person should have taken more care with their keys, and therefore there should be a penalty to deter carelessness with keys, then there is no difference in principle with letting the person lose all their money. They should have taken better care of their keys, right? So 100% loss is fine too based on that logic, and provides an even better deterrent against carelessness. May as well not have the feature at all if you want to deter carelessness with keys. If you care about justice, then justice needs to be 100%, not 95% or 90%.
Who would recieve the proceeds of some honest person’s mistake or misfortune? The miner of the block? The founders? I do not think miners or founders should get a boon from somebody else’s mistake or misfortune. The transaction will have a fee. That should be good enough.
Insurance markets can solve this problem. Insurers can gauge the risks associated with both parties and price transaction insurance accordingly. Anybody who abuses insurance gets charged higher premiums or can’t buy insurance. If anyone has a problem with an insured transaction, the insurer would settle the dispute rather than an arbiter.
Transaction fees to miners are an issue with slowed funds if a transaction is invalidated with an I got robbed button. Does the miner get to keep the transaction fee on the invalidated transaction? If no, then miners will be reluctant to include slow fund transactions in a block, because they might not get to keep the transaction fee. If yes, and an account hack is malicious, the hacker could just give all the account funds to miners since the miner fees can’t be reversed. There are some possible solutions I can think of. One is to hard code some global limit to how much of a fee the miner can keep on a revoked transaction. So if the fee was within what is commonly accepted as normal, the miner could keep it, but if the miner fee went beyond some limit, the miner would give back everything beyond the limit. Another possibility is that when funds are slowed, an upper limit on the miner fee for transactions with the slowed funds can be specified as one of the parameters.
What is the significance of that transaction? I see it has a lot of addresses and uses a lot of bytes, but aside from that what causes you to consider it important?
but look at the transaction cost as a percentage of the transaction value, 0.2% isn’t insane for ANY type of transaction. I don’t think that that is unreasonable at all, especially compared to other payment methods. the tx fee on a credit card transaction is typically around 10 times that, for instance.
I dunno, I think that that is a totally reasonable fee, especially with all the congestion of unconfirmed transactions right now. And it only looks big for a blockchain tx fee as an absolute value, not as a %, too.
Hi folks. I moved this convo to a new thread since it was cluttering AMA thread. Please be mindful to create new threads when discussions divert from original topic.
