Transaction reversability would be a BAD thing

[BADecker]

With a few tweaks, couldn't escrow be made friendly, right inside the client? And wouldn't that be just about the same thing as reversability? Should a date be added where the escrow would be cancelled, and the transaction would automatically go through?

Actually, the whole idea of reversability beyond escrow is stupid. Escrow is almost like reversability as it is. Either you give the other guy his money or you don't. If you can't trust him at a distance, then get face-to-face with him and use cash. And keep your gun with you in case he grabs the product back out of your hands after you pay him. And if he has a bunch of his buddies along with him, come back when you have your buddies with you - all heavily armed, of course.

The point is, escrow companies are all that we need. The next best thing is the thing that LocalBitcoins and Bitcoin-Otc are doing. Rating the users so that we know who to deal with.

In all events, only trade small amounts until you are certain you are dealing with reputable people. Reversability amounts to built-in stealability.

[1714510921]

1714510921

[1714510921]

1714510921

[1714510921]

1714510921

[1714510921]

1714510921

[amspir]

Well you can't know your transaction was received by the intended recipient until you send it and they get it.  If you send some coins, and they are not received at the intended destination, you could potentially take corrective action.  Just waiting to send a transaction would not accomplish this at all.

If that is the goal, it would seem that the system that was compromised by a man in the middle attack should burdened with the task of encryption necessary to prevent the attack.  I don't see why the blockchain should be burdened for a lapse of security of the system between sender and receiver.

[Keyser Soze]

If the system is optional, couldn't a hacker or thief send the stolen coins as irreversible? Unless you mean the transaction reversibility depth is set before the transaction is made, which can cause problems in itself. Assuming the former, I suppose it could help with man in the middle attacks, if it noticed quickly enough.

Edit: Of course there are other potential issues that could arise from this.

Not the way I was proposing.  The first step would be to create a protected, reversible address.  Then you would fund it.  Any funds ever sent from that address would be reversible until the predetermined block limit had passed.  So if the private keys to your protected address were compromised, you would have a time window to undo it.

Only funds on addresses that were setup to be reversible would have any protection.  Regular address would subject to instant spend as is currently the case.

So potentially a user could have many different addresses holding coins, each with their own specified amount of time (blocks) of reversibility? For example, Alice has 3 different address that currently hold coins. Coins in address A are irreversible, coins in address B are reversible for 10 blocks, coins in address C are reversible for 1000 blocks.

[Cubic Earth]

So potentially a user could have many different addresses holding coins, each with their own specified amount of time (blocks) of reversibility? For example, Alice has 3 different address that currently hold coins. Coins in address A are irreversible, coins in address B are reversible for 10 blocks, coins in address C are reversible for 1000 blocks.

Exactly!

[Brangdon]

Well you can't know your transaction was received by the intended recipient until you send it and they get it.  If you send some coins, and they are not received at the intended destination, you could potentially take corrective action.  Just waiting to send a transaction would not accomplish this at all.

You could give the transaction an nLockTime, sign it, and send it to them. They then confirm receipt. When the nLockTime expires, they broadcast the transaction, and then dispatch your goods. If they don't confirm receipt, you create a new transaction that sends the same funds back to yourself. Then when nLockTime expires, it's too late, and the first transaction will be rejected as a double-spend.

I'm not sure how their confirming receipt is any less able to be faked than their sending you their payment address in the first place, but that's also a problem with your new protocol.

Your other scenario is someone hacking your wallet. One problem here is what do you set your reversible time to? If you set it to a short period, say 5 hours, you may not notice the hack quickly enough. If you set it for a week, the hack might happen when you are on holiday and you'll still miss it. If you set it for longer, then it becomes impractical to spend the coins normally because Overstock won't want to wait weeks for the transaction to become irreversible.

In summary, the benefits of your idea over what we already have seem too minor to be worth bothering with. You can also get forms of reversibility by using escrow agents, and you can get defence against hackers by using insured storage (eg, Elliptic Vault).

[BADecker]

Well you can't know your transaction was received by the intended recipient until you send it and they get it.  If you send some coins, and they are not received at the intended destination, you could potentially take corrective action.  Just waiting to send a transaction would not accomplish this at all.

...

In summary, the benefits of your idea over what we already have seem too minor to be worth bothering with. You can also get forms of reversibility by using escrow agents, and you can get defence against hackers by using insured storage (eg, Elliptic Vault).

Private judges, like from Robert Heinlein's "The Moon is a Harsh Mistress."

----------

 A boy about fourteen spoke up. “Say! Aren’t you Gospodin O’Kelly?”

 “Right.”

 “Why don’t you judge it.”

 Oldest looked relieved. “Will you, Gospodin?”

 I hesitated. Sure, I’ve gone judge at times; who hasn’t? But don’t hanker for responsibility. However, it troubled me to hear young people talk about eliminating a tourist. Bound to cause talk.

 Decided to do it. So I said to tourist, “Will you accept me as your judge?”

 He looked surprised. “I have choice in the matter?”

 I said patiently, “Of course. Can’t expect me to listen if you aren’t willing to accept my judging. But not urging you. Your life, not mine.”

 He looked very surprised but not afraid. His eyes lit up. “My life, did you say?”

 “Apparently. You heard lads say they intend to eliminate you. You may prefer to wait for Judge Brody.”

 He didn’t hesitate. Smiled and said, “I accept you as my judge, sir.”

...

 “Kids are paying seventy dollars Hong Kong for judgment. You should match it. If you can’t, open pouch and prove it and can owe it to me. But that’s your share.” I added, “Cheap, for a capital case. But kids can’t pay much so you get a bargain.”

 “I see. I believe I see.” He matched with seventy Hong Kong.

 “Thank you,” I said. “Now does either side want a jury?” Girl’s eyes lit up. “Sure! Let’s do it right.” Earthworm said, “Under the circumstances perhaps I need one.”

 “Can have it,” I assured. “Want a counsel?”

 “Why, I suppose I need a lawyer, too.”

 “I said ‘counsel,’ not ‘lawyer.’ Aren’t any lawyers here.” Again he seemed delighted. “I suppose counsel, if I elected to have one, would be of the same, uh, informal quality as the rest of these proceedings?”

 “Maybe, maybe not. I’m informal sort of judge, that’s all. Suit yourself.”

...

 I went behind desk, sat down, put on Brody’s plug hat—wondered where he had found it. Probably a castoff from some lodge. “Court’s in session,” I said. “Let’s have names and tell me beef.”

----------

Point is, we don't need any governmental judges to judge in practical situations. We all live life. We all understand what's right and wrong... at least in the more evident cases. We don't need reversability of Bitcoin. We may want private judges, and for a judicial fee. People could build a rep as an impartial, fair, private Bitcoin judge.

[Cubic Earth]

You could give the transaction an nLockTime, sign it, and send it to them. They then confirm receipt. When the nLockTime expires, they broadcast the transaction, and then dispatch your goods. If they don't confirm receipt, you create a new transaction that sends the same funds back to yourself. Then when nLockTime expires, it's too late, and the first transaction will be rejected as a double-spend.

That would be a way of accomplishing the main-in-the-middle defense part of what I proposed.  Difference is it is on a per-transaction basis instead of a per-address basis.

I'm not sure how their confirming receipt is any less able to be faked than their sending you their payment address in the first place....

Its easier to fake just one thing than two.  The same logic is behind 2 factor authentication. Just because one thing (the payment address) has been compromised doesn't mean everything else has been too.  If the receipt of payment came over a different channel, say a sms or email, that would make the deception harder to pull off.

...but that's also a problem with your new protocol.

In no way whatsoever do that have to do with my protocol suggestion, which is about bitcoin, and not for how one might go about verifying the authenticity of communication with another party.

Your other scenario is someone hacking your wallet. One problem here is what do you set your reversible time to? If you set it to a short period, say 5 hours, you may not notice the hack quickly enough. If you set it for a week, the hack might happen when you are on holiday and you'll still miss it. If you set it for longer, then it becomes impractical to spend the coins normally because Overstock won't want to wait weeks for the transaction to become irreversible.

This is a logical trap you are trying to set.  You are in essence saying "options are bad, because how do you choose?".  Right now, everything is instant.  Instant would remain a choice, so if you didn't see any benefit in having any sort of time-lock, just keep all you coins instantly spendable.  Easy.  Other people might not feel so paralyzed by indecision, and realize there could be a worthwhile security benefit to having some of there coins take 12 blocks to confirm instead of the usual 6.  It's a tradeoff that every person could judge for themselves, and given a choice, people would come to different conclusions based on their individual circumstances.

In summary, the benefits of your idea over what we already have seem too minor to be worth bothering with. You can also get forms of reversibility by using escrow agents, and you can get defence against hackers by using insured storage (eg, Elliptic Vault).

It may be so the benefits are too minor.  I know other companies can and will offer such services on top of the blockchain.  Although having needed functionality as part of the chain can save us all from the counter-party risk and fees of turning to those companies to conduct our business.  I appreciate that you read my proposal.

[bitvestor]

Well, your idea was suppose to be good, but you got it twisted..

[Swordsoffreedom]

A more than complex question reading through the replies I see some good points so not really going to put anything up

Just more of a note that while we haven't even scratched the surface of the protocol, it is possible to build a system onto the current one that can address these issues, including contracts and timed confirmations

Anyways this is a timeless issue going back to the beginning of bitcoin so sooner or later an idea will emerge to solve it whether people use it or not will depend on if they see utility in it
After all it would be part of a voluntary system 

[HorseCoin]

what happens if someone encodes a child abuse video in one of the comments.  how could we reverse that, without arresting everyone on the bitcoin network??

[cbeast]

what happens if someone encodes a child abuse video in one of the comments.  how could we reverse that, without arresting everyone on the bitcoin network??

You can't. You may include a link. So shut down the link.

[cbeast]

what happens if someone encodes a child abuse video in one of the comments.  how could we reverse that, without arresting everyone on the bitcoin network??

You can't. You may include a link. So shut down the link.

but the link is on your computer.  therefore your under arrest

They've been saying that about spam for decades. Not a real threat.

[Lauda]

A very bad thing.

[Brangdon]

You could give the transaction an nLockTime, sign it, and send it to them. They then confirm receipt. When the nLockTime expires, they broadcast the transaction, and then dispatch your goods. If they don't confirm receipt, you create a new transaction that sends the same funds back to yourself. Then when nLockTime expires, it's too late, and the first transaction will be rejected as a double-spend.

That would be a way of accomplishing the main-in-the-middle defense part of what I proposed.  Difference is it is on a per-transaction basis instead of a per-address basis.

Which makes it more flexible. Wallet software could apply it to every transaction from a given address, if that was desired.

I'm not sure how their confirming receipt is any less able to be faked than their sending you their payment address in the first place....

Its easier to fake just one thing than two.  The same logic is behind 2 factor authentication.

Well, no. 2 factor authentication should mean two different kinds of things, such as a memorised password and a physical dongle; not one thing being an email and the other thing also an email (or web page, or whatever).

Just because one thing (the payment address) has been compromised doesn't mean everything else has been too.  If the receipt of payment came over a different channel, say a sms or email, that would make the deception harder to pull off.

If they can fake the web page, they can fake the email addresses on it and send emails that are, or pretend to be, from it. As I said before, the gain in security seems so marginal that it is not worth changing the protocol for. (You may be realising how difficult changing the protocol is. The Bitcoin community is quite conservative.)

...but that's also a problem with your new protocol.

In no way whatsoever do that have to do with my protocol suggestion, which is about bitcoin, and not for how one might go about verifying the authenticity of communication with another party.

Both new and old approaches have the same problem, of waiting for a second contact that isn't likely to be more secure than the first contact.

Your other scenario is someone hacking your wallet. One problem here is what do you set your reversible time to? If you set it to a short period, say 5 hours, you may not notice the hack quickly enough. If you set it for a week, the hack might happen when you are on holiday and you'll still miss it. If you set it for longer, then it becomes impractical to spend the coins normally because Overstock won't want to wait weeks for the transaction to become irreversible.

This is a logical trap you are trying to set.  You are in essence saying "options are bad, because how do you choose?".

I'm arguing that there is no good choice. The law of diminishing returns sets in too quickly. The benefit of, say, a 5 hour reversible period is minor - the hack can happen while you are asleep or distracted by work. The cost of having to wait 5 hours before an order is confirmed is quite high. Longer periods increase the inconvenience of waiting significantly, without increasing the security significantly. Plus there is now more complexity for vendors accepting bitcoin, and for users managing their wallet options.

 I appreciate that you read my proposal.

My pleasure. I am still new enough to Bitcoin that I enjoy thinking and writing about it. I think many of the old hands have run out of patience with this (general) topic.

[mprep]

A very bad thing.

Such a bold statement (even though I agree to a lesser extent, more like not good) without any argument. Care to elaborate?

[theonewhowaskazu]

So, rather than sending a reversible transaction, why not just give a "future-dated" transaction to the merchant? After N blocks the merchant can redeem the transaction by broadcasting it, but it can be "reversed" in the meantime by simply spending the coins out of the address. What gives.

[MoonShadow]

Point is, we don't need any governmental judges to judge in practical situations. We all live life. We all understand what's right and wrong... at least in the more evident cases. We don't need reversability of Bitcoin. We may want private judges, and for a judicial fee. People could build a rep as an impartial, fair, private Bitcoin judge.

It's usually called private arbitration, and one can join an association for such already.

[r3wt]

what about Multisig, Consensus(unanimous) transaction reverseability? the Memorycoin voting system could be used to create such a system. this could be used to reverse thefts, however this would be an immense technological achievement. do it right, bitcoins are an even better asset. Do it wrong, we have a serious problem on our hands. the problem with such a system is the time it would take to reverse the transaction. hacker/thief could have did many things, such as trade the crypto for fiat or purchase items from bitcoin retailers. that's just my .02

[BBmmBB]

I think people have only read the title to my post, and not the proposal.    Seriously.

It already is reversible. As long as the counter-party agrees, they can send the money back to you.   

This is not about protecting the two parties in a transaction from each other!!.  This would be used to make sure your funds got to the intended destination or if your computer was hacked, you could recover the money, if you acted fast.

Do people understand there would be a time window of your choosing?  It could be as short as one block?  There are good points to make against this idea, but so far hardly anyone has addressed what I wrote.

I'll just restate again for people to lazy to read my OP - an address would be optionally designated by you, ahead of time, as reversible for a given time period.  If you were a merchant, or anyone else receiving funds, you see immediately upon receipt that the funds were provisional and could be rescinded.  You would not treat reversible funds as cleared / confirmed until the hold had expired.

Once the hold expires, they are no longer reversible.

This system would not in any way protect you from an dishonest merchant whom you sent fund to.

the only way this would be effective to stop hackers is if all BTC transactions were switched to this "reversable" type ... not going to happen imho !