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
Ripple is based on social networks, in many countries these socialnetworks are prohibited as China, etc. Also, PAUV don't have a external dependencies.
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!).
<<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.
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.
<<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.
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!
Lisa cipher the content to allow the possibility of restore the transaction using external tools. This is only a feature to ensure that the information can be restored.
I see Alberto has already replied you!
BTW if you wanna collaborate the whole development process is totally open and you can drop me an email at me AT luisivan DOT net ;)
> 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.
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.
All information are public (only for themselves) and both users can restore the operation if something goes wrong.
Both users are interested on cooperate and can restore the operation from a web app or your application.
Also, is higly unprobably that something as this happens, is an automated process with a restore system. The system can restore the operation (knows all information to do it).
Well, that's true, but here we are talking about money and I have never met someone that wants to lose money... also, as Alberto said, we are working on some workarounds to prevent scenarios like that happen :)
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).
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.
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.
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.
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!
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.
Thanks for the book recommendation. This has been something I've been thinking about for several months now: how would a p2p exchange possibly implement a time-price priority queue to ensure proper order execution?
The more I think about it, the more I convince myself that it is likely impossible to get network incentives to line up correctly without relying on a trusted third-party (or making other show-stopping compromises). Nodes have no incentive to rebroadcast orders that conflict with their own, and any sufficiently motivated attacker could place nodes in strategic places in the network to manipulate execution in their favor.
If anyone wants to talk about this in detail, shoot me an email.
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.
42 comments
[ 4.8 ms ] story [ 109 ms ] threadI'm really looking forward to seeing more of this.
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-...
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!).
Another remark: what does mean "description message is ciphered"? You mean signed? Because ECDSA does not do encryption (like RSA), only signatures.
<<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.
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!
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.
The more I think about it, the more I convince myself that it is likely impossible to get network incentives to line up correctly without relying on a trusted third-party (or making other show-stopping compromises). Nodes have no incentive to rebroadcast orders that conflict with their own, and any sufficiently motivated attacker could place nodes in strategic places in the network to manipulate execution in their favor.
If anyone wants to talk about this in detail, shoot me an email.
At this point, has Lisa paid Homer yet? If not, what will force her to do so?
https://github.com/pauvorg