[PROPOSAL][RETRACTED] - Reversible Addresses with Chargeback

[ripper234]

tl;dr - we can create a way to use Bitcoins with or without chargebacks, and leave that choice up to users and merchants.

Update - this is actually not that useful. Retracted.

I'm sure similar ideas has been discussed before in various forms, yet I'm not sure that this specific implementation has.

The idea is to create a "sub-space" of reversible transactions within the Bitcoin address space.
This is a proposed breaking change to the Bitcoin protocol, designed to allow users a degree of chargeback to protect against scams and theft. The changing is a breaking change because it allows new types of transactions not permitted before.

The proposal entails dividing the Bitcoin address space into two regions:

1. Normal Bitcoin Space
2. Reversible Bitcoin Space

The NBS behaves like the Bitcoin we all know and love. Transactions within this space are irreversible.

The RBS is a subset of addresses (e.g. those beginning with a certain prefix), in which Bitcoin is treated as reversible.
NBS to RBS transactions are treated as normal transactions, and are irreversible.

Any RBS to RBS or RBS to NBS transaction can be reversed by its issuer within some period of time / blocks. This will give users the power to chargeback ... with all the pluses and minsus this brings. E.g. the Linode hack could not happen with RBS Bitcoins, because the transaction would just be reversed when discovered. There could even be multiple RBS spaces with different "grace periods".

After the grace period is over, the RBS transaction becomes locked and cannot be charged back anymore.

So, this gives users and merchants the option, not obligation, to support reversible transactions in Bitcoin. A merchant can give a discount to NBS payments, and offer RBS transactions at higher prices. For industries where the customer is well known or there is just very little overall fraud, the merchant wouldn't mind accepting RBS transactions, perhaps with the additional requirement of some form of identification to further deter frauds from issuing chargebacks without just cause.

For the user, the advantage of keeping his stash in RBS is clear - their Bitcoins are much safer there.

For any merchants or users that don't want to take part in all this nonsense, they can stick to the normal NBS space.


The question is - is there enough demand for reversible Bitcoins? This would be a significant protocol change that will probably take 6-12 months to implement because of "legacy" systems and the requirement to get a hash power majority for the change.

Come to think of it ... I'm not sure using a sub-space is actually better than using a separate blockchain. The benefit to using the same blockchain is removing the need to gain hash power for the separate chain, and maintain the value of NBS Bitcoins identical to RBS Bitcoins. The huge downside of course is that it's a huge breaking change, that is not likely to ever get a miner or dev majority.

I think it's important to have the inherent value of RBS and NBS as equal, and allow for easy two-way conversion (conversion from RBS to NBS just takes some time, but its value does not fluctuate). I don't think people are ready yet to think of their money in terms of multiple distributed cryptocurrency values ... being exposed  to a single volatile exchange rate is risky enough.

The question is whether there's a way to construct an alt chain where the coins will always have the same value as Bitcoin ... and I'm not sure that there is a clear way to construct such a chain. The so called Second Bitcoin Whitepaper had some ideas in that direction, but nothing that ultimately convinced me.

P.S.
Perhaps all this is a redundant complication, and can instead be achieved more cleanly with scripts. Have there been concrete proposals in that direction? (Links please)

[1714822332]

1714822332

[1714822332]

1714822332

[1714822332]

1714822332

[1714822332]

1714822332

[1714822332]

1714822332

[Ferroh]

It doesn't seem like you thought this through at all, sorry.

You suggest that the Linode hack wouldn't have been a problem because the stolen coins would have been charged back, but either:

a) Coins can be charged back for a limited amount of time, in which case virtually all of the linode coins would not be able to be charged back because Bitcoinica wouldn't allow you to trade with coins that can be charged back.

or

b) If anyone who spends coins can charge back the coins at any time, then it is a useless currency that no one can trust. Traditional money systems like Visa or Paypal can do chargebacks because they are a 3rd party authority that decides whether to do a chargeback. You can't give chargeback power to anyone and everyone who spends their coins (at least not without making some significant other addition that you haven't mentionted).

[muyuu]

With scripts you have contracts, which are a more general mechanism than this.

What could be interesting is to have private keys that only allowed one or several particular kinds of transaction scripts.

Then again, you already can find this in Armory (Watching-only wallets). On top of Armory you can build whatever system of privileges you want to, connecting a computer with a watching-only wallet to another with a full wallet. In the one with the full wallet you can then run a server that reject all transactions not passing a certain set of characteristics.

You can see these mechanisms (using for a different purpose) here: http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

[ripper234]

It doesn't seem like you thought this through at all, sorry.

You suggest that the Linode hack wouldn't have been a problem because the stolen coins would have been charged back, but either:

a) Coins can be charged back for a limited amount of time, in which case virtually all of the linode coins would not be able to be charged back because Bitcoinica wouldn't allow you to trade with coins that can be charged back.

or

b) If anyone who spends coins can charge back the coins at any time, then it is a useless currency that no one can trust. Traditional money systems like Visa or Paypal can do chargebacks because they are a 3rd party authority that decides whether to do a chargeback. You can't give chargeback power to anyone and everyone who spends their coins. I think that's obvious.

I was going for a. Let's analyze the situation for a second, and focus on a merchant, and not on a platform used for speculation and short term profits like Bitcoinica. I'm not saying this kind of chargeback is useful for everyone, but for some portion of merchants and users.

Merchant Moses is happily running his store on a cheap shared hosting site.

Honest user Adam sends Moses some reversible Bitcoins, Moses waits a week, then transfers them to his irreversible offline stash. All is well. Adam's "stash of coins" is protected, because he gets an email alert of any transaction from his reversible address, and can void any suspicious transactions he didn't commit himself.

Honest user Bob, a well reputed eBay user with lots of purchases, tries to buy a game online from evil user Eve. Eve gets the Bitcoin, but stalls and does not send the game. Bob waits a couple of days, and then issues a chargeback.

Eve now tries to scam Moses. She wants to make a purchase on Moses' store and issue a chargeback. But Moses only accepts reversible Bitcoins from trusted customers, that either made a few purchases earlier with other means, or send in their valid credit card details or some other form of ID. Eve cannot convince Moses that she's legit, so he will not accept her reversible BTC.

The above is a win-win scenario for Adam & Moses. Adam is able to keep his funds secure, and Moses gets extra business from clients like Adam that prefer stores that accept reversible Bitcoins. Moses does need to choose which clients he allows to pay with reversible Bitcoins carefully, and has one downside - his legitimate money is frozen for a week ... but that could be a price he's willing to pay for the 10% more clients he's getting compared to his friend that runs a similar shop that only supports non-reversible Bitcoins.

[ripper234]

With scripts you have contracts, which are a more general mechanism than this.

What could be interesting is to have private keys that only allowed one or several particular kinds of transaction scripts.

Then again, you already can find this in Armory (Watching-only wallets). On top of Armory you can build whatever system of privileges you want to, connecting a computer with a watching-only wallet to another with a full wallet. In the one with the full wallet you can then run a server that reject all transactions not passing a certain set of characteristics.

You can see these mechanisms (using for a different purpose) here: http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

Can scripts protect Bob from my example from an evil Eve that tries to sell him a game, but after receiving the coins does not in fact send the money?

Another solution to this problem is a trusted escrow. My proposal moves the problem of trust to the user-merchant interaction, and avoids the need for an escrow service. An escrow service will ultimately be some sort of judge, who needs to hear complaints and decide who is right ... this seems costly and bureaucratic for honest users and merchants. It might be simpler, and the right de facto solution, since my proposal definitely has its own complications ...

I don't know which solution will ultimately be easier to implement on a global scale.

[Polvos]

Am I in the destroying Bitcoin week and didn't notice it?

[muyuu]

With scripts you have contracts, which are a more general mechanism than this.

What could be interesting is to have private keys that only allowed one or several particular kinds of transaction scripts.

Then again, you already can find this in Armory (Watching-only wallets). On top of Armory you can build whatever system of privileges you want to, connecting a computer with a watching-only wallet to another with a full wallet. In the one with the full wallet you can then run a server that reject all transactions not passing a certain set of characteristics.

You can see these mechanisms (using for a different purpose) here: http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

Can scripts protect Bob from my example from an evil Eve that tries to sell him a game, but after receiving the coins does not in fact send the money?

Another solution to this problem is a trusted escrow. My proposal moves the problem of trust to the user-merchant interaction, and avoids the need for an escrow service. An escrow service will ultimately be some sort of judge, who needs to hear complaints and decide who is right ... this seems costly and bureaucratic for honest users and merchants. It might be simpler, and the right de facto solution, since my proposal definitely has its own complications ...

I don't know which solution will ultimately be easier to implement on a global scale.

Yes, it can. But then both Bob and Eve would have to agree to the contract script.

Bitcoin cannot solve the general problem of trust. If you trust someone and he or she screws you over you are SOL. No-chargebacks means the merchant is the trusted party. If you agree to a chargeback contract then the trust switches over. If you agree to an escrow then that's where your trust goes.

In a two-party transaction usually it makes sense that the seller has trust on its side. Sellers are usually fewer than buyers and you can have a reputation system in parallel, which wouldn't work as well for buyers.

[ripper234]

With scripts you have contracts, which are a more general mechanism than this.

What could be interesting is to have private keys that only allowed one or several particular kinds of transaction scripts.

Then again, you already can find this in Armory (Watching-only wallets). On top of Armory you can build whatever system of privileges you want to, connecting a computer with a watching-only wallet to another with a full wallet. In the one with the full wallet you can then run a server that reject all transactions not passing a certain set of characteristics.

You can see these mechanisms (using for a different purpose) here: http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory

Can scripts protect Bob from my example from an evil Eve that tries to sell him a game, but after receiving the coins does not in fact send the money?

Another solution to this problem is a trusted escrow. My proposal moves the problem of trust to the user-merchant interaction, and avoids the need for an escrow service. An escrow service will ultimately be some sort of judge, who needs to hear complaints and decide who is right ... this seems costly and bureaucratic for honest users and merchants. It might be simpler, and the right de facto solution, since my proposal definitely has its own complications ...

I don't know which solution will ultimately be easier to implement on a global scale.

Yes, it can. But then both Bob and Eve would have to agree to the contract script.

Bitcoin cannot solve the general problem of trust. If you trust someone and he or she screws you over you are SOL. No-chargebacks means the merchant is the trusted party. If you agree to a chargeback contract then the trust switches over. If you agree to an escrow then that's where your trust goes.

In a two-party transaction usually it makes sense that the seller has trust on its side. Sellers are usually fewer than buyers and you can have a reputation system in parallel, which wouldn't work as well for buyers.

+1, that's a good way to put it.

In effect, now that I think about it, the system I proposed is sort of equivalent to the seller not charging the buyer immediately, but giving him a grace period of 1 week to send his BTC ... except the issue of someone hacking into the user's machine, which has other neater solutions.

Fine, I retract my post.

[muyuu]

In effect, now that I think about it, the system I proposed is sort of equivalent to the seller not charging the buyer immediately, but giving him a grace period of 1 week to send his BTC ... except the issue of someone hacking into the user's machine, which has other neater solutions.

Fine, I retract my post.

Yep, in a 2-party system I can't see sellers handing over trust to buyers in a generic case. Much more so when said buyers are generally pseudonymous. For particular cases there's contracts.

[finway]

Good idea!

Go get the code and make a pull request.

[ripper234]

Good idea!

Go get the code and make a pull request.

Is this sarcasm? It's hard to say over the wire.

[jjjrmy]

The only possible thing I can think of is that it is reversible up to 6 confirmations.

I don't support this idea, but that is my input.

[the founder]

this already exists:

7 – Flexcoin solves the ‘charge back’ problem

Bitcoins do not allow for charge backs, period.  However, in the future, flexcoins will allow for a limited charge back period.

This feature is not implemented in the initial rollout.  It is our plan to (again, in the future) allow customers the ability to “take a charge back” until the vendor accepts the transfer.

If  Mike goes to the coffee shop and wants to pay for a cup of coffee, and he accidentally transfers 25 bitcoins rather than .25 bitcoins to flexcoin id coffeeshop, he will be able to “pull the charge back” and correct the amount prior to the vendor accepting the transfer.  Once the vendor accepts the transaction, the transfer would become final.

Again, we want to stress that the charge back system is not implemented in the initial rollout.  We want (and welcome) feedback from our clients (both customers and vendors) as to whether this would be a desired feature, before this is implemented network-wide.

http://www.flexcoin.com/?page_id=103

However I want to stress how it was implemented,  the merchant has to request this feature to be added, it's not something that will ever be added by default,  so far less than .01% of the people that use it have noted they wanted this feature,  hence I have to agree with the beginning of this post,  it wasn't that useful, and we spent a long time coding it...  IE: it was wasted time.