
P2P Bitcoin exchange [pdf] - luisivan
http://pauv.org/paper.pdf
======
M4v3R
> If anyone doesn't meet the transaction contract (send the money or send the
> bitcoins), both lose the deposit.

Am I understanding this correctly that if a buyer tries to scam the seller in
whatever way (i.e. will initially sign the transactions but ultimately doesn't
pay) then the seller will lose his deposit? If that's the case then it won't
work. I ran a P2P Bitcoin exchange and it's a pretty common thing to have
"fake buyers" who place offers but ultimately don't fulfill them. With a third
party you can resolve these kind of situations easily, it's much harder
without them.

~~~
luisivan
If one of the parts doesn't fulfill its order, both the buyer and the seller
lose the same amount of Bitcoins. That's the way we prevent scam!

~~~
M4v3R
The problem is, that in a P2P system you don't have only scammers that will
not fulfill the trade. You also have careless people, who will mess something
up, forget about the transaction, delete their clients/wallets, etc. With this
schema, you are forcing the one party to take responsibility of stupidity of
other.

~~~
gwern
Unfortunately, if you try to make allowance for that, you incentivize scammers
to say 'oops!'. To deal with this makes things a lot more complex:
[https://en.wikipedia.org/wiki/Trembling_hand_perfect_equilib...](https://en.wikipedia.org/wiki/Trembling_hand_perfect_equilibrium)

------
bachback
An exchange is not just a transfer, it is a transfer at a price. Sure, you can
transfer 1 BTC to 100$, but how do you determine a price? If A wants to buy 1
BTC from B, what is the transaction? 1$,5$,1000$? You need to integrate with
the fiat system and you need a limit order book. I would suggest Harris book
on microstructure for an understanding of exchange markets (ISBN 0195144708).

~~~
luisivan
Each peer has to determine a price per Bitcoin when opening the order. Then we
match the orders that have the same price using a P2P discovery system. So
there isn't a global price but rather each user has to choose a price.

~~~
bachback
Well, a chosen price is a limit order, which can go unfilled. If I order 1000
BTC for 0.01$ am I going to get filled? At current market prices no, because
currently there is no supply of BTC at that price. A market determines the
price. If a good is well defined a market will automatically be centralized.
Gold and oil are extremely liquid markets traded on exchanges, that means
traded based on limit order books.

~~~
luisivan
Exactly, that's why we will include some graphs about the state of the market
so people can figure out their prices

~~~
bachback
The NYSE processes millions of orders per second, MtGox hundreds per second.
So you have machines which work over a protocol (FIX) to establish the price
mechanism. In a exchange system there are limit orders and the limit
orderbook. You basically have a timestamp problem, which is kind of
prependicular to the bitcoin system. At every point t in time, there is a fair
value of BTC-USD. And a system which solves that problem will be highly
centralized, by definition. So unless you come up with a new system for
processing limit orders, people will be arbitraging between a slower system
and MtGox, Bitstamp, etc.

~~~
luisivan
We know, you cannot get informed of every single trade made because of the P2P
architecture. But you can still use the exchange if there are enough trades
that you are informed of!

~~~
bachback
What problem you are actually wanting to solve? I don't see why I would use a
slower system. waiting can be very costly if the price is moving against you.
you need quick traders to provide liquidity. which is what you will find if
you get users onto such a system. the high volume traders won't like it. I
think there is actually room to reinvent the worldwide exchange system.

------
oleganza
Paper is not clear on how their scripts work because they don't show exact
scripts _per output_.

Meanwhile, using bilateral deposits you can insure any sorts of contracts, not
just currency exchange. In my scheme scripts are symmetrical:
[http://blog.oleganza.com/post/58240549599/contracts-
without-...](http://blog.oleganza.com/post/58240549599/contracts-without-
trust-or-third-parties)

The coolest part is when this sort of thing is used in autonomous programs
that randomly connect to each other and establish contracts. In such case
there's no place for extortion - there's no human to negotiate with. Based on
this idea you can build never-seen before networking protocols. For instance,
a micropayment network that propagates IOUs from peer to peer where each pair
of peers is mutually insured to repay all accumulated debt when it reaches 50%
of insured amount. It'll be like a global distributed clearing house with as
little fees as humanly possible (and instant confirmations!).

~~~
gotoalberto
<<Paper is not clear on how their scripts work because they don't show exact
scripts per output.>> You can found more information about contracts and the
flags used on Bitcoin Wiki.

~~~
oleganza
I know how scripts work in general. I mean, it's strange that you display
script outside the output. E.g. on page 7 you have two outputs and only one
script.

Another remark: what does mean "description message is ciphered"? You mean
signed? Because ECDSA does not do encryption (like RSA), only signatures.

~~~
gotoalberto
<<I mean, it's strange that you display script outside the output. E.g. on
page 7 you have 2 outputs and only one script.>> Consideer that this
transaction is not been broadcasted to P2P Network. You can storage a valid
transaction as this if you add the flags SIGHASH_ALL and SIGHASH_ANYONECANPAY
to the transaction.

<<what does mean "description message is ciphered"? You mean signed? Because
ECDSA does not do encryption (like RSA), only signatures.>> I'm not sure about
your question. ECDSA is a PKI key type, so i believe that it's possible.

~~~
kaoD
Even if ECDSA relies in a PKI, what you do with it is signing and not
encryption. The S in ECDSA stands for "signing". Either you don't mean
"ciphering" or you mean an EC encryption algorithm (and not ECDSA).

The problem is... why would Lisa cipher her own knowledge with her public key?
Only she would be able to decipher with her private key to learn... nothing!

PS: I'm from Madrid too!

------
pfraze
Don't know the relation, but I've heard
[https://en.bitcoin.it/wiki/Ripple](https://en.bitcoin.it/wiki/Ripple) is
catching on as a p2p bitcoin exchange.

~~~
cLeEOGPw
Ripple premined many ripple coins before releasing and it is distributed, not
decentralized.

------
jpswade
On a similar line, you may also find this interesting:
[http://sx.dyne.org/anontx/](http://sx.dyne.org/anontx/)

~~~
luisivan
Wow, that's pretty cool, we'll find a way to integrate it :)

------
galapago
I guess the code should be available in the future here:

[https://github.com/pauvorg](https://github.com/pauvorg)

~~~
luisivan
Exactly!

~~~
galapago
Great. Following.

------
izqui
That's the kind of stuff we need to make Bitcoin really take off.

I'm really looking forward to seeing more of this.

~~~
luisivan
Thank you! :)

------
marcell
> 5\. Homer sends to Lisa the transaction and Lisa adds some inputs to the
> transaction > as it happens in this example:

At this point, has Lisa paid Homer yet? If not, what will force her to do so?

~~~
luisivan
No! No payment has been made yet, because at that point the transference is
not valid

~~~
marcell
I see, that seems reasonable then. What happens in the case of reversed
payments, though? Chargebacks is the reason you can't buy bitcoin using
Paypal, Google Wallet, etc.

~~~
luisivan
We will only include payment processors that don't allow chargebacks, such as
OKPay or WebMoney

------
cLeEOGPw
How do I know if Lisa provided me with the correct amount of money in OKPay
account before transaction?

~~~
luisivan
Good question! OKPay has an API so we check if the correct amount has been
transferred to your OKPay's account. If that happens you sign the transaction
and the exchange happens

