Topic: BANK RUN! - P2P Fiat-Bitcoin Exchange - page 6. (Read 39079 times)

Yes Twister is beside Bitmessage the preferred solution for the messaging system.
Dark Wallet will probably use that as well, and it could be that we will build on Dark Wallet. But it is still too early to discuss much about the technical decisions...

Are you more familiar with Twister?

I wonder if you know "Twister" (but probably the answer is 'yes') and if something comes out from that concept can be useful: It's a P2P microblogging platform.

It comes with an implementation from Libtorrent (DHT) for the resources management, and it uses the blockchain for the users management. White paper and documentation explains everything, definitely better than I can.

No that is not right. If you unlock you get your collateral back (0.1BTC in my example, 1BTC in yours). If you dont unlock then you lose that.


The collateral only serves as incentive to not hurt the other losing his money. There is no way to steal the others money. Even a small collateral like 10% can fulfill that job. If you behave unfair you will lose 0.1 BTC as well, even if the other will lose 1.1 BTC for rational persons it is not an incentive to lose anything if he only needs to click a button.
The height of the collateral can be freely chosen, but there will be probabyl a recommended value.
I will consider to set the default collateral higher maybe 50% or 100% of the trade volume.

Yes the collateral of 10% seems to me now also too low, but it is free to choose, but probably there will be a recommended collateral more about 50% or 100% (will be updated in the paper in a new version).

What will be the right collateral?
We could analyse the statistics of past trades (data from the blockchain) and estimate the rate of failed trades and see the collateral used there. That could be maybe a mechanism helping to find the right balance. If the collateral is higher all will be more safe, but if it is too high the chances that somebody take the offer will decrease, also the possible loss will rise.

If the other trader cannot continue unintendedly (death, hard disc crash,...) there is no way to unlock the funds if we dont use an escrow (still in discussion). But that case will be very rare. I assume 1 of 10 000 or less, so if you keep the trades low, that could be taken in account as kind of fee. Maybe a kind of insurance service could be used to flatten that effect, but that comes with new problems.
Another solution could be to use a lottery system to spend the locked funds to a lucky winner who has traded once successfully. So the negative effect could be turned into some positive. But that system opens again up new problems, but it is in discussion.

Yes that blackmail scenario waxwing has found is more serious then the one I discussed in the paper:
A normal blackmail would suffer from the asynchonious payment. So if you accept a blackmail and then as 2. step the blackmailer need to pay back the open funds, then you are exposed again to him. Nothing prevents him to repeat the blackmail. So that could be an infinite loop.
But if Bob signs a tx with changed outputs to his favor and send that to Alice, Alice only needs to sign and publish it, so there is no gap anymore between blackmail negotiation and payment. If Alice accept it and publish it, she will get her money back for sure. So that is a more serious attack scenario.

But it still has its problem to become a realistic threat:
The software does not provide any tool to do the signing and publishing for Alice in a way that a non-tech person can do it easily. Alice can not easily copy her private key, she need to be tech-savvy to do that. So Bob need to provide tools to help her and give technical instructions, making the attack more difficult to succeed.

Another more important point is that Alice know the real ID of Bob due the Bank account, so she could go to a lawyer or try to confront him in real life (Bob does not knwo who is Alice, she might be an innocent girl or the sister of a powerful mafiosi). Assuming that Bob does not use a stolen Bank account (but that will be out of the scope here).

There would be a way also to create a legal contract for the trade with the initial deposit tx. That would create then even more pressure to Bob to act fair. But we will try to keep the concept independent form the outside legal system, cross country trades would complicate all that as well...

Indeed, jubalix, the size of the deposit is open to debate. But the basic structure is that each side only stands to lose by defaulting on their commitment.

In my opinion this is not the main issue; the main issue is there is nothing forcing the two parties to pay out in the ratio (1.1,0.1) to (Alice,Bob) at the end. They could end up paying out (0.8,0.4) or anything else. This is one of a few things we've been discussing on irc #bankrun.

ok so if he want to get his 1BTC back he has to sign over the 0.1 btc to the other person as they are both locked up together so what is the mechanism to hold the 1 BTC locked up and who / what has the key and what trips it to pay out.

Whatever that is at its root faces the same problem.

Actually I kinda get it

the 1.2 btc multi sig, allows the 0.1 to flow back to bob, so he is motivated to sign it, he however does at this ratio can burn sender much more.

You likely need a ration that is higher

to really hurt bob if he does not sighn.

the other problem is if he just does not sigh, while this hurts bob, it does not help sender, so that need to be taken care of some how.

Eg Bob dies or looses keys then what?

" what motivation does he have to sign BTC over?" - To get back his collateral.
The 0,1 btc in the paper is only an example, can be any. Think to 1 btc collateral, that's much incentive to behave fair.
No, he does not increase his wealth (he has spent 1 btc + coll and received 1000 USD), so the collateral he needs to get back otherwise he loses.
The effect of a locked up btc is close to zero (about 1/10 M).
Locked funds will happen but probably very rare (1 of 1000?). There is no way to win money, only lose less then the other, that is for normal people no incentive to behave unfair.

Ok big issue

when the receiver of the BTC does not sign off the multi sig, he wins.

He has the cash, he withdraws it so bank can not claw back, or physically has it.

what motivation does he have to sign BTC over?

eg by no signing he acutly increases his wealth (sender is poorer) and marginally increases his and every one else BTC worth, by leaving BTC locked up.

time this by millions of transactions and you get alot of BTC locked up forever, and sender looses

This is good information, thank you. I imagine the escrow fee could be minimal as a percentage. If the fee were $5 on a $500 worth of BTC, that's only a 1% fee.

My original concept used several people to verify the transaction went through as intended. So, if humans were to do the verification on the WU website instead of a machine, would an Oracle machine and hosting be needed? In any case, I figured the fee could be adjustable if there weren't fixed expenses. The p2p exchange would use human input from the buyer, seller, and escrow agents to create a solvable block that would solve and dispense the BTC according to the escrows' consensus.

Here is how I envision the escrow fee process. Seller of BTC specifies the fee to be paid and the number of escrow agents to confirm. So a $5 fee with 10 agent confirmations would pay out $0.50 to each agent. Since the work required to verify is minimal, this might generate pretty rapid confirmations. If the seller wanted $5 and 100 confirmations, then there would be fewer willing escrow agents, although in poorer countries, this might still be attractive income. I suspect that market forces would choose an equilibrium between the fee, the number of confirmations desired, and the time this will occur in.

Possibly, new escrow agents could start out on the transactions that pay little in per-agent fees. Then, as their trust in achieving consensus rises, they can move up to higher per-agent fee transactions. Those traders with lots of money on the line can opt to pay a higher fee to get more trusted agents. Also, a feedback system can help to adjust agent trust levels. Buyer and seller likes the outcome, they can rank the transaction highly and the agents benefit. If one party didn't like the transaction outcome, this could hurt agents' trust. If trust drops, agents can end up back in lower tiers, etc.

Duane, what you called earlier an "anonymous escrow system" can only be implemented as an oracle machine which will query and parse the westernunion.com  URL in order to make a decision about whether to release the btc funds or not.
But some oracle machine operator has to host that oracle machine and pay for hosting. Thus inevitably, there will be a per-transaction cost on EVERY transaction even those where there is no dispute.
But if you get rid of the oracle machine hosting and use a 2-of-3 multisig escrow and call upon the human escrow agent ONLY when a dispute arises, then there will be NO transaction fee for all normal transactions. There will be only a fee(or rather penalty) payable ONLY by the offending party at the time of a dispute.

TLDR 2-of-3 multisig with a human escrow is much more fairer and preferable than an automated oracle machine.

https://www.westernunion.com/track-transfer?0

Also, I want to add that because this isn't anonymous,  it might not satisfy some of those on here who desire a totally anonymous system. However,  a large portion of the population really doesn't care.

From a thread I started in the russian forum:

@Duane Vick,

earlier you said


Could you elaborate, which URL the escrow should go to to check the transaction?

There have been mention of a few flaws in your concept, mainly the possibility of a trader holding currency hostage. Since BTC is irreversible, it stands to reason that it should not transfer to the buyer's wallet until the seller receives his cash. There is going to be a lot of concerned buyers who will be too scared that the seller won't deliver or that they hold the BTC hostage, thus stopping many transactions from ever occurring. It takes a great leap of faith to wire funds to someone without being sure they will deliver.

I don't think escrow has to rely on SSLs, statements, etc. If you review what I wrote, you will see that the escrow gets what it needs from the parties to the sale. The seller of BTC would provide the info to receive the funds such as what Western Union requires. The buyer provides the information such as MTCN with information that matches the seller's name, WU agent location, etc. The escrow agent simply needs to verify this data. Since my idea incorporates multiple random escrow agents per transaction, it isn't subject to exploit by a single escrow agent working on behalf of one of the parties.

As far as Bitcoin removing the need for money transmitters like Western Union, I don't agree that this has to be the case. There has to be a way to get fiat into Bitcoin that makes fiat irreversible. Western Union already has locations worldwide and they provide a way for a person to receive cash that is irreversible. If they become less relevant as a transmitter because of the growth of Bitcoin, they can still adapt to the new market. They could very easily incorporate a way to directly buy bitcoin from them, essentially becoming an exchange and providing a trusted centralized option for those holdouts who don't trust p2p. Also, I don't like the idea of bank wire, no matter how many people say they are irreversible. Truth is, as long as a person gets money deposited in their account, their own bank can screw them and take the money back out and send it back. It might not be the pattern of business currently, but there is no shortage of stories where banks and other financial services screwed their clients. With Western Union, you can get cash without having an account that they jack the money out of and send it to collections when you take a principled stand against them.

I understand your concern about escrows. I wish they weren't needed. However, escrow provides a way for the buyer to be assured that the seller can't hold back the BTC. Each transaction is separately verified and the disposition of BTC is already pre-determined based on the escrow review. The parties to the transaction commit to the terms of escrow when they open the transaction. Escrow terms can be pre-defined such as whole release of BTC, percentage release, or no release based on the results of verification.

You have linked to http://index.php

I don't know which particular country you mean, but it doesn't surprise me; many more authoritarian states have made noises in this direction. This is why I've been working in this area for a best part of a year. This "dark scenario" seemed somewhere between likely and inevitable and recent events have done nothing to change my mind.

This issue would be solved easily if you banked with a crypto-currency friendly bank. "There isn't one" you say, then create one!

You might be surprised, but I know of at least one country where it already happens (at least with Gox bank address) with all the major banks. With a bit of Googling, you will find which country I mean.

Yes, and I think you may have overlooked another element that will make this "attack" more practical - multisig transactions (2 of 2 or 2 of 3) are rare and easy to spot on the blockchain (3abc.. addresses).
But that's the sort of thing you worry about a long way down the line. Initially, what's important is that the current pattern matching algorithms will not flag transactions as suspicious - which I fully accept may happen, because a lot of what banks are checking is "is he doing something unusual".

I'm more thinking about the darker future scenarios where banks are explicitly trying to stop all such trades, which means blanket bans on exchanges - I think that's what this technology is really for.

Here is something that could be integrated into your platform, or used independently. It will provide 'near instant' conversion of digital assets into USD. We're just waiting for contributors to get the project started.

---

Yay!@SaneBox cleaned out 954 emails, leaving 271 important emails in my Inbox. Try it for free: http://sanebox.com/t/4qw44