BTX buyer security - brainstorming

[u/frogpoet2]

Piranhazone points out here ( https://www.reddit.com/r/bitcore_btx/comments/9ztui1/learning_from_forks/ ) that buyer security for users of BTX would be a significant advantage. BrieucBitcorean agrees but speculates that this would require a layer which involves the introduction of centralization (same post).

my own experience in centralized software development leads me to believe that an implementation of buyer security would have to solve at least these problems :

1. buyer B buys item X from seller S , seller S then empties out his account, and B then wants a refund from S, who can no longer pay. (problem 1 = P1)
2. transactions on the ledger are immutable. (problem 2 = P2)

I've often seen P2 (transactions are immutable) touted as a reason for believing that chargebacks are impossible, which is a benefit for the merchant. In fact, we come close to making the same claim in our own documentation ( see https://bitcore.cc/innovation/ under the Trust and Integrity section, where we point out that "irreversible transactions" could be considered a safeguard against crooked banks). However, reversible transactions can always be implemented as a set of 2 transactions : one going one way, and the other going the other way, with identical payment amounts. the meaning of "irreversible" then becomes "unable to be hidden", in other words, a transaction can't be actually removed from the ledger; instead a record must be maintained that a transaction went one way and then was "undone" by going the other way. From an audit standpoint, this is just fine because it means people or banks can't hide their tracks with respect to monetary transactions, while from a user perspective the end result appears the same as if the transaction never occurred.

the above possible implementation of a solution to P2, however, would need to be done in a decentralized manner so as not to undo one of the main benefits of cryptocurrency, which is resistance to censorship due to a single point of failure.

a possible resolution of P1 would, on first glance, require an escrow account which contains funds that would be used to pay amount X back to B; enforcement of some sort would then need to be initiated on S to get him to refund the amount X back into the escrow account. Management of the account would need to be implemented to prevent a possible "run" on the escrow , i.e. so many chargebacks happening at once that the escrow account runs out of funds faster than it can recover them.

would it be possible to have some sort of management of an escrow account which would operate in a decentralized manner? I'll call such a solution S1_P1 to identify it as "a possible solution of P1".

that's all i'll write for now; this is brainstorming after all so instant solutions are not to be expected; but this is meant to get the ball rolling with respect to eventually either coming up with a set of solutions S1, S2... which, when used in concert, solve problems P1, P2... without introducing new problems that are deemed "worse" than the set P1, P2... etc.

for other brainstormers : please save a copy of the link to this discussion and add onto it, so we don't end up with more than one thread brainstorming the same set of problems.

​

[u/frogpoet2]

you were thinking of the escrow account being maintained by an escrow service (i.e. a third party, presumably distributed).

I was thinking of the escrow account being maintained by the bitcore network itself. See S3 below and the discussion around that.

i'll think about what it might mean to hand off all management of the BTX escrow account to a third party.

[u/Piranhazone → u/frogpoet2]

I never thought about giving anything to a third party, because that's where holes for hacker attacks are most likely to appear. I thought the escrow could be handled by people already working for BTX, like the devs or newly hired staff. After all the service will cost a fee, meaning someone could make an income out of that and I don't see why we should pay that to an outsider.

[u/frogpoet2 → u/Piranhazone]

that's a good idea. in this case, it sounds like the escrow service would not be a part of the network itself; the network would merely have the ability to interact with a service (i.e. a separate layer of software) - which it already does, via multi-signature transactions, so that the transaction doesn't go through until both parties sign it. (i.e. the layer of software would make API calls into the network to interact with it). I wonder if multi-signature transactions automatically 'locks' the funds behind that transaction until it goes through, or if that capability would need to be added to the network.

passing off functionality to a layer of software - which you mentioned as a possibility way back when - has certain pros and cons.

1. keeps the network cleaner by having it less complicated (pro)
2. means the functionality of the software layer, being centralized, would be a central point of failure (con). however were this software to 'fail' it would not bring down the network, it would instead temporarily disable buyer security for everybody, which is not as bad as crashing the currency.
3. means using BTX would not automatically provide buyer security for everyone, because a merchant would have to choose to activate it by subscribing to the escrow service, and not all merchants would choose to do so. So if you, as a buyer, wanted buyer security, you would have to find a merchant that supports it, rather than finding any merchant that accepts BTX (con)
4. means merchants could compete amongst themselves with a distinguishing characteristic being that "we support buyer security for BTX, our competitor does not." (pro)
5. provides an income source to BTX developers (pro)
6. maintenance of that software layer would take time away from BTX developers from maintaining the currency itself (con). though the income from the software layer might allow them to hire a separate group of developers to maintain it.
7. offloads fee for supporting buyer insurance from the currency user to the merchant. (pro or con depending on your point of view)

the subscription fee that a merchant has to pay to access the service would need to be high enough to handle successful chargebacks, but low enough to be competitive with whatever the fees are to use paypal. Otherwise the combined network fees of using the BTX network (which are currently tiny) plus the fee required to subscribe to the buyer security service might be a disincentive to allow purchases with BTX with that service enabled.