REQUEST: Cash by mail in USD and CAD markets

Tanks for explanation, hope someday it will work :slight_smile:

Hi All

Have you read this?

Creating a P2P Bridge between Fiat Currency and Ethereum Cryptocurrency

1 Like

Dear erizo!
Thanks a lot for keeping us updated!
Hope, soon it is will be really easy, and safe to deal with crypto\fiat.

Hi all, I have redesigned the purchasing algorithm by cash by mail, I think it can now work in an environment like Bisq

It would work like this:

  • Seller offer 1 BTC, deposit 0.03 BTC

  • Buyer takes offer, deposit 1.003 BTC

  • Buyer send cash by mail

  • The seller receives the money and signs the transaction

         The buyer receives BTC from the seller and recovers his deposit
         Seller recovers your deposit
    
  • The Seller does not receive the money

          The seller marks the transaction as Not Received
          The seller informs the referee about it.
          The referee takes the buyer's deposit
          The referee takes the BTC from the seller
          The referee returns the deposit to the seller
    
  • The seller does nothing and the transaction ends

           Buyer's deposit passes to arbitrator
           Seller's BTC passes to arbitrator
           Seller's deposit passes to arbitrator
    

The buyer can not exert any pressure. If you send an empty mail, the seller would choose the option with least losses (NOT RECEIVED), and at least recover their deposit. The buyer would lose his large deposit. No one would do that.

The seller can not exert any pressure: if he receives the money and decides not to sign, the transaction will end on time limit and he will lose his deposit and his BTC.

From the moment the offer is accepted, the parties are bound to cooperate with each other, under penalty of suffering serious losses.

The NOT RECEIVED option means sending a notice to the referee to make this option somewhat more complicated than simply signing the transaction. Thus, if the seller receives the money, the easiest and most direct way is to sign. The referee may request an explanation from the parties although, given the difficulty of proving anything in that environment, usually, unless you see it very clearly, always choose to execute the options described.

It is imperative that there is no communication between the parties to avoid extortion or social engineering scams. Envelopes, ordinary mail, should not enter the true address of the user, to avoid such responses.

In order to avoid serious losses to the parties, in case of lost mail, this option could be limited to small quantities, such as 0.2 BTC.

Well does anyone know of how to crack this system?

1 Like

I like the idea, but afraid reality with us postal service is not so optimistic.
A few days ago, my friend sent me a little present by U.S. mail.
He informed me that the package will arrive Friday, but nothing comes to my house.
My friend checks tracking and found out that it was delivered to the wrong address.
He gives me address where my package was delivered and I drive there, but nobody opens the door.
I leave messages with my phone # asking to call me about my package, but since today (Tuesday) nobody calls.
The package cost only $20.
What will happen if someone sent 0.5 BTC ($2000 now) and someone get it on wrong address? looks like lots of trouble.
I mean Your system is a grate in theory, but US postal service sucks in reality.

1 Like

Wow, I’m sorry about your package. Therefore I advise in my proposal to limit the amounts to 0.2 BTC for this payment system, to minimize losses in case of postal system failures, in this way also envelopes would have a limited weight and thickness. You can always make more orders if you want to trade with more quantity, or use a reliable shipping service, for larger quantities.

I do not know how it works in the US but in Europe the postal service is quite reliable in general. Letters usually arrive regularly, and mail is never inspected or rarely.

The idea is to have a cash payment service, not banking, and not vulnerable to scams, robberies or coercions. This system seems to fulfill it. Anyone have any idea how to break it?

1 Like

I would like bisq to support this type of payment method.
However, isnt this latest idea flawed, its assuming people are honest?
The seller of BTC, with little deposit at stake, can always claim money not received?
There was a prior proposal/idea that had both parties have similar value at stake and made more sense to me. Am i missing something?
Also, does this type of payment method even require an arbitrator? We should just have adequate warnings/use at own risk.
idea: Could bisq generate a qr code/something/data/singing/key, that is only shown to the buyer and it must be sent on paper printout with the cash. Only way to unlock the btc funds by is to use this code.

1 Like

No, this system is independent of trust between the parties.

The seller can not claim his BTC, the seller can only claim his deposit in case you have not received anything. In that case the return is not automatic, since if you receive the money well the option to sign would not be better, you would have no incentive to sign.

If the seller does not receive the payment, the seller can ask the arbitrator to return his deposit. He will do this practically always, but he will listen to the parties just in case. In case of being very convincing the referee could even return his BTC (although it is difficult), so if he does not receive his payment the arbitration option is the obvious choice. The buyer will lose his deposit, much greater.

A rule could be made for money to always travel in a sealed inner envelope. The buyer would take a photo of the stamps and could film the closing, the seller as well and could film the opening, In the event that the referee requests it in the future. It is not a great test, but it could have some small weight in case the seller receives an empty envelope, in any case it is not essential for the system to work.

I do not find it useful to enter a code to unlock funds, since the seller already has the incentive to sign to recover their deposit, it is the same.

Can you see the flow chart, and tell me where it can fail?

Well, I made a small improvement: if the seller does nothing and the transaction ends by timeout the buyer receives the BTC and recovers his deposit. The seller loses his deposit because of his inaction. If the buyer made the payment, he should receive the BTC, even if the seller does nothing. If the buyer did not pay, the seller must select the NOT RECEIVED option to recover his deposit.

1 Like

Thanks, i understand now :slight_smile:

1 Like

Thanks for such grate job and tables, so it is clearly visible and easy to understand

1 Like

Joining late to the discussion I want to provide my feedback.

I would love to find a secure solution but so I have not seen one. Here my concerns and some rough ideas.

The proposed solution from @erizo has the problem of extortion risk for the side who loses less.
I am pretty familiar with that problem because the very first concept of Bisq was based on a 2of2 MS and the game theoretical “mutual destruction” setup.
E.g. You construct a situation where either both are winners or both are losers if they don’t cooperate. Unfortunately that has a flaw if the amount to lose is not exactly the same for both all the times and it cannot be the same with fiat as the hand over of the fiat is always a non-atomic transactions and creates moments in which one party has more to lose than the other.

Lets make an example to make that more clear.

  1. Trade start:
  • Buyer: 1 BTC deposit locked in: total to lose 1 BTC
  • Seller: 1 BTC deposit locked in + 1 BTC trade amount locked in: total to lose 2 BTC
  1. Buyer sends Fiat:
  • Buyer: 1 BTC deposit locked in, fiat sent (equivalent to 1 BTC): total to lose 2 BTC
  • Seller: 1 BTC deposit locked in + 1 BTC trade amount locked in: total to lose 2 BTC
  1. Seller received Fiat:
  • Buyer: 1 BTC deposit locked in, fiat sent (equivalent to 1 BTC): total to lose 2 BTC
  • Seller: 1 BTC deposit locked in + 1 BTC trade amount locked in, received fiat (equ. 1 BTC) : total to lose 2 -1 BTC = 1 BTC

As seller has now less to lose than buyer he can try to extort buyer to offer him an alternative payout, say Buyer receives only 1.5 BTC instead of 2 BTC. Seller would lose 1 BTC if buyer does not agree, Buyer would lose 2 BTC. For buyer it is rational to accept the extortion offer to lose only 0.5 BTC instead of 2 BTC.

You can move around those deposit amounts as you like you never solve the problem that there is asymmetry which opens up that extortion risk at some point of time for one party. Arbitration solves the problem but without it it does not work.
This risk might not be abused in small scale but you cannot build a secure system based on that.

Adam Gibson (waxwing, one of the PageSigner devs and JoinMarket dev) discovered that problem when I presented my first concept and I got convinced that this cannot work. There are other projects (BitMarkets) who use that and either don’t understand the problem or ignore it and I agree that it might work in small scale or in combination with reputation and/or centralized systems.

In Bisq the arbitration and ability to verify the fiat transfer is the key why it works.
Reputation system might help but thats another unsolved challenge for a decentralized system.
Also exit scams show that it does only work in a limited scope.
Another thing which is different to market places is that we don’t that typical asymmetry between buyer and seller. A merchant is interested to build up reputation and thus it is easier to build up a reputation system in a market based on merchants. But that does not work for currency exchange as any trader who would exchange large amounts gets legal issues in many countries (see LBTC cases in the US regarding money transmitter).

So why it partially works in other contexts is because they have a different setup/environment. For the Bisq setup where privacy and decentralization are key aspects I don’t see how to apply that.

Another approach might be repeated micropayments to build up a reputation between both traders. Thats what Coinffeine did but you need a very cheap and fast payment channel for that, Postal services are for sure not cheap and fast to do 100 small transactions and settle each those offchain until the total amount is exchanged.

I would suggest to try to think in other alternative directions:
Is there a way to replicate the logic of hash commitments (atomic swaps) for that use case?
The trick there is that by spending your money you reveal the secret the other peer needs to access his part.
Timeout make sure that the first user is forces to reveal his secret in time.
Is there any way how to apply that to our use case?

We need a system where the mechanism to get access to the money is coupled with revealing the “secret” the other peer needs to access his part.
One problem is that receiving a package does not mean that in the package is money and not just a brick ;-).

Bank notes have a serial number. Would there be some way to use those for some scheme or shared secrets or hash commitments? I have not found yet a way how that could work. But maybe someone has an idea?

The tracking number of the delivery system (post) might be another thing which could be maybe used. Piggybacking on centralized infrastructure is a smart way to get the benefits without the disadvantages. We do that in some way with the banking system. Maybe there is for the postal services a way as well?

So far more questions than answers…

Even if we find a smart analogy of atomic swaps it would be a very different implementation of the trade protocol. Not a weekend job… but rather one for several months. Is there a large enough market to justify that effort? Postal costs are rather high as well.

Building it with no real security (like filming the packaging and unpackaging - can be easy faked) might work at small scale but will get abused once it would be more used. It is not very logical to build a system which can only work as long not too many are using it and therefore pay the costs for the development.

But I don’t want to spoil the excitement about that option. Just don’t see a solid solution so far.

Thanks for the response!

What do you think about approaching the idea as an experiment? For example, rather than trying to decide a priori whether a “cash by mail” or “cash in person” payment system will/won’t work, offer the feature on a trial basis. After trying it for a few months, you’ll have actual data about the number of people using the system, problems that you encounter, percentage of scam trades, etc. You could then decide to tweak or abandon it at that time.

A system does not have to be perfect in order to work for most of the participants.

Remember, bisq does not currently have a truly private method of exchange at all right now. This seems to defeat the purpose of bisq, which appears to have been intended as a way to do trustless trades in a way that can’t be easily monitored or censored.

“But that does not work for currency exchange as any trader who would exchange large amounts gets legal issues in many countries (see LBTC cases in the US regarding money transmitter).”

Isn’t that an even bigger risk for large traders without a means of trading privately now? If you have a bunch of large cash deposits to your bank account, banks are going to notice. And the record of those transactions could be used against you if there were ever legal proceedings.

“Reputation system might help but thats another unsolved challenge for a decentralized system.”

Note that reputation system on bisq could simply be an aggregate score that’s updated as you make trades. The underlying identifying information from the transaction (amount, dates, buyer/seller names, etc) need not be retained. Or could be retained in an encrypted fashion–with homomorphic encryption, you could obtain summary data ( successfully completed transactions, disputed transaction count, transaction total, etc) without knowing the underlying data.

“Also exit scams show that it does only work in a limited scope.”

Exit scams could be eliminated by requiring vendors to put up increasingly large security deposits the more open transactions they have.

“Building it with no real security (like filming the packaging and unpackaging - can be easy faked) might work at small scale but will get abused once it would be more used.”

How do you know it’s small scale? Have the exchanges that offer “cash by mail/in person” payment released any statistics on the matter?

“It is not very logical to build a system which can only work as long not too many are using it and therefore pay the costs for the development.”

How much do you estimate it would cost to develop? If the community were able to raise the money to pay for the cost of development, would you go ahead with it?

Actually extortion is only possible if it is possible to use a method of communication, but if the buyer’s letter containing money is a simple mailing with no real sender, the seller is not able to communicate the extortion to the other side and will lose his BTC.

All in all, I agree that we have to think more about this. It’s funny how I thought about some of the solutions you thought of, how to use the serial numbers of the bank notes, but I have not come to anything useable.

Ps. Homomorphic encryption seems great to get a reputation score from a merchant, without seeing the real data

Yes the communication issue is a good point and what I also agrued against back when I had the 2of2 MS concept. But the attacker can publish as way how to contact him via public pages like the forum or anything where most users will get the information. Sure that becomes a bit “theoretical” but if it would scale up large scammer would likely do that.

Hopefully the is a solution with using some extra tricks. I think we need to look to some more exotic ideas because the obvious ones are already considered enough that we can assume there is no proper solution, otherwise someone would have found it.
Piggypacking on existing infrastructures might be a good direction as well. Though also no idea how to do it. Some physical tools for sealing the bank notes might be interesting as well, but no idea about such stuff…
Another approach is to use giftcards, vouchers, etc. But I assume there are other projects already serving that market. Not familiar with details about that area…

One way to avoid the extortion risk is to make sure the peers have deleted the btc key for creating the payout tx. They create the intended tx initially and then delete the key. Then the blackmail cannot work as the buyer cannot sign a changed payout tx.
That idea was brought up back in 2013 when we discussed that problems by DanSmith, one of the TLSNotary devs. The problem here is still that it is rational to avoid the deletion of the key and the attacker can assume that rational peers will do that and only pretend that they have deleted the key which would re-enable the blackmail.
Though I think in reality 99.9% of users are technically not skilled enough to do that so the attacker would have very high failure rate which would render his attempts expensive for himself. Sure someone could start to provide alternative implementations where the key deletion is removed but then users need to trust that app provider and opt in break the security concept. Game-theoretically that would be not a solid concept but I am wondering if it would be good enough in reality and the friction and uncertainties would be good enough that attackers will consider it too expensive and risky.

At least as long there are no better solutions that “mutual destruction” concept (either both win or both lose, but amount what they lose is diferent) might be worth a try? Also if it would fail it would be just a limited damage for one payment method to get removed (which we don’t have anyway now so not worse than now). So it might be worth a try.
Important is to make it clear to users that it is a high risk payment method.

Anyone wants to work out all details and write up a Bisq proposal?
It should not require changes of the current model otherwise it is unrealistic to get added soon because of lack of dev resources.

A proposals is a tech spec sufficiently clear defined that a dev can implement the feature.
We have a repo for those: https://github.com/bisq-network/proposals
You can see the account witness proposal as example, though the cash by mail feature would require less effort and complexity. Though it should contain all steps in the trade process with required popups and text as well as all payment method fields and possible dispute cases and suggestions how to deal with them.
A quality proposal is subject for a compensation request (you get paid in BSQ).

I think it’s a good solution. If it can fail only when the user uses a modified application or of dubious origin, I do not think it is a high risk. We just need the App to be able to delete the btc key for creating the payout tx.

I do not see myself with enough theoretical knowledge of Bisq to make a sufficiently technical proposal on Github, I hope someone will do it and I hope it will be a great success for Bisq