Topic: Let's Design The Ideal Bitcoin Exchange - page 2. (Read 4969 times)

The concept of a decentralized exchange has been discussed a lot here
https://bitcointalksearch.org/topic/p2p-exchange-for-bitcoin-172705

how about limit the size of each transactions to be no more then X% of the entire volume. then someone cant simply spike or crash the market with one order

Thanks for the link, bud. I like that Justin dude having had the pleasure of meeting him twice.

No bots?

I would argue for exactly the opposite: An exchange with built-in automatic trading capabilities so that all users have the option to preprogram their responses to the market as easily as possible.

Consider:

It is very difficult & time consuming to trade bitcoin optimally without assistants who watch & react to the market for you 24/7. Automation lets you more perfectly execute your trading plan.

There seems no way for an exchange to completely prohibit bots, because software can interact with a web page just as any ordinary user can. (A bot can parse the HTML or screen-scrape the web browser. Also, you need to provide APIs if you want to let users use external trading platforms such as Metatrader, Zeroblock, BitcoinCharts Pro, etc.)

The most you can do is minimize bots and prohibit high-speed trading. An exchange would have to place restrictions on all traders, by limiting the number of trades which can occur in a certain amount of time, or (annoyingly) by requiring completion of a captcha every so many trades. (But captchas can be bypassed in real time at low cost via services using software and human workers to solve them. They would mainly annoy your regular customers.)

Worst of all, eliminating automated trading would tend to make your exchange much less popular: spreads would be much larger, volume would be reduced, arbitrage would have longer lags, and there would be less "action." There would still be arbitrage going on, however: your price would generally follow that of any other exchange, just not moment to moment. So you could not simply isolate your exchange from all the others which are influenced by bots.


(Regardless, we should only support exchange designs where users retain most or all control over their assets and how they will be traded. GIven that, you can't tell users not to use algorithmic trading, but you can make it available to all users.)

The conversion to Fiat is one of the biggest weak points, if not the biggest. The second is keeping the txs off the blockchain and keeping them fast.

The idea i've toyed around with is splitting the exchange into 3 separate main parts: A local user wallet, A third-party trusted escrow, then the Orderbook(audited/run an altcoin).

You would force users to deposit into a local wallet the user keeps that produces a certificate that funds indeed exist. Then in order to use the funds on the exchange, the funds are sent from local to escrow with a certification. On send and receive to the escrow, the orderbook would 1:1 carbon copy assign all inputs to an Altcoin exclusively run by the exchange (with audits). This could even just be a couple wallets containing all the pre-mined altcoin/orderbookcoins and let the wallet handle all transactions internally. This would keep trading at a real-time input level. Then when someone wanted to 'cash out' or even after a set amount of time after not making any trades, the altcoin/orderbook would push out the current account information to the escrow and then verify and move the bitcoins in escrow accordingly. This would of course create a delay for verification from blockchain but only on deposit and withdraws. Everything else inside the orderbook would flow in real time.

The methods opens up fractional reserve, but its bound to happen at some point. But ignoring that. You would set the altcoin wallet accounting to always check for 1:1 match to the coins in escrow, and whenever coins left escrow the would leave the orderbook/altcoin wallet as well. No matter what with Fiat involved, a third party is going to have control over your money at some point. You can keep bitcoin txs almost completely out of it, but at some point you need to verify that the bitcoin balances are real and unspent.

I think it's awesome, now the definition of a transaction is split up into many parts.
1) the order buyer and seller sign respectively
2) the wallet/client/server acknowledgement/notary
3) the transmittal of info to server and blockchain for requisite confirmations
4) if all is well simultaneous release and exchange of items to wallets

in the case of disconnected internet service from phone, wallet, server, or anything else, are funds in limbo until connection is made, or otherwise waiting

chris gave the impression that they would be somehow waiting somewhere

whooops, while I was typing above I see you made an entry relating to what I wrote, .... could you delineate the transaction process so that the distinctions between wallets, servers, clients, gateways, blockchains, and whatever else are made

I'm not even sure how you came up with that analysis of OT?



No, it is an open source project.  You can run the software on any server you want.  From their website:

"The Open-Transactions project is a collaborative effort to develop a robust, commercial-grade, fully-featured, free-software toolkit implementing the OTX protocol as well as a full-strength financial cryptography library, API, CLI, and prototype server. The project is managed by a worldwide community of volunteers that use the Internet to communicate, plan, and develop the Open-Transactions toolkit and its related documentation."


No...you will use gateways to deposit into the network


From their website:

"Is Open-Transactions centralized?
The vision is not of a central server that you must trust. Rather, the vision is of federated servers you don't have to trust."

(Albeit it is not decentralized in regards to the true purest meaning)


 It is simply an open source project that allows a federation of servers (you don't need to trust) to facilitate the transactions.  All the code is available on github so you do not need to use "their" server.  You can choose any server on the network.

I think it is designed as decentralized, but owned by a small group. Dont quote me on that one, please.

ok heres an idea.

imagine bitcoin transactions and mining.

but a whole new blockchain

but instead of just (in laymens terms) having the transaction saying "send 1BTC from 1ssgdfgdfdfg to 1awsdesaas"
it instead says "send 1BTC from 1ssgdfgdfdfg to 1awsdesaas and send 650Dollacoin from $pldfpgldpfg to $dldkfgldfkg"
(blue is jack, brown is jill)
so that the transaction has both parties transactions in one tx.

then just like bitcoin it gets passed through the peers/nodes. and miners mine the transaction into the block.

once the block has a confirm. then the clients balances adjust according to the block chain

(again thinking of the physics.)

open transactions is not decentralised.

whether a business has all their systems in one office building or in 50 different locations does not make it decentralised. its still owned, monitored by a single company. so its possible to extort funds.

open transactions appears to want you to deposit your funds, which then get spread across several of THEIR servers which then gives you a balance in their desktop client. and funds would only move if the majority of those dispursed servers see the trade agreement has been made and athenticated.

well if i had 10 servers and you sent me 20 bitcoin then each server would receive 2btc each and you are told that fnds wont move unless you have signed an agreement that jill should receive the 20btc.

... yet all it takes is for the server owner to update the servers to simply send all the funds to his address.. you still have to trust that they wont tinker with THEIR servers and that they wont change the server code yet make you believe that thecode on the server matches the open source code on github.

(a few webwallet people showed sourcecode that their webwallet generated and address and only the users had access.. months later without warning they changed the code and stole the coins)

open transactions owns the servers and the source. you have to trust that they wont change anything. we need to find a trustless solution. and thats the problem

ithought of many different ways. and i think the way that bitcoin-qt nodes validate transactions is the only way. where it has to be validated by 200+ users (not a centralised company) for the transaction to happen.. (im still knitpicking the physics of this plan)

I am not the best at trying to explain this difficult concept in a thread.  The first video I posted of Chris Odom explains the complete procedure using voting pools and multisig and how it would be accomplished.  I think if you fast forward to about the 9 min mark he will hit on the subject.  (But best to watch the entire thing however!)

so you say you want server involvement..

ok then.

so lets say the server is the one that takes Jacks passphrase: k46d3n6b8mfi4nfif9nfwlg and Jills: rmertkdf034mgsdfkdg and combines them to make a escrow address for the DollarCoin and the Bitcoin. it does not save the passprase or the privkeys. just saves the public key and posts back the public keys to be filled.

once the server sees the funds are confirmed jack and jill resend their passphrases and the server uses them to make the privkeys to send the funds to the recipient.

so all the server saves in the database is public keys, although given a bit of trust to atleast process addresses.

or do you mean funds move away from available balance into a locked in address still in the client program. which then when other person also moved funds to the locked address. then funds transfer..

again how to prevent sourcecode tweaking to unlock funds (finding the hidden privkey)

The funds would never sit on a server & escrow would not be needed.  They stay in your wallet until the transaction is performed.  The server acts as a notary to the transaction using M of N to pass the keys once the contract is fulfilled.  You client software would digitally sign the keys so they are not intercepted.  No one other than the two parties involved would ever have access to the coins. 

Wow, thanks for that pieces of cryptocurrency history ... I guess having XRP sitting at the top of the Market Cap List Of Cryptocurrencies sorta ingrains the notion that they are a CC (even if they really aren't)

preferably when both escrows (dollacoin and BTC) had one confirm. the protocol would wait for both single confirms then auto send to the recipients addresses.

but you have lead me onto the further issue i was going to mention later (although i mentioned it before in different posts) confirmations cause trading delays and day traders hate that

but in a open source p2p program that is sat on someone hard drive. how do you prevent one user tweaking their source code to release funds instantly? or make it so they cant doube spend so confirms are not required.

i think localbitcoins is another close option option that works. but we still need to decentralise the escrow and order list to be perfect system

ripple was the closest solution i could see. but most people ignored the whole point of exchanging bitcoins and dollars which were the important thing, and xrp was just a small thing sitting in the background where less then one xrp was removed from your holdings as a transaction fee (they gave people free xrp, so it was not meant to be a big deal)

instead thogh, everyone thought xrp was an altcoin and only traded xrp for btc via WTB thread posts on the forum. and then complained that xrp was not a altcoin..

they totally missed the point that xrp was not a currency and just a transaction fee.. much like cash in the mail.. xrp was the postage stamp and everyone started trading stamps, instead of exchange funds in the mail. and complaining that the mail service was making money out of stamps..

.. the mind boggles sometimes

in the situation that you posed, when would the automated escrow release the funds, upon receipt or upon x# of confirmations ?

the point of failure is the conversion to fiat.

the only solution is a p2p client program that accepts bitcoins and another coin that is designated as always having a $1 value. to avoid multiple bank transfers just to make multiple trades. (100+trades, day trading).

i can see it working where jack can see Jill request btc for DollaCoin on skype, facebook or even this forum. and they simply link up with a keyphrase. i can even see how the program requests the individuals to individually type in a passphrase that combines to make an 2 escrow addresses. and once both parties put the funds into the dollaCoin and BTC escrow the program then shows payment sent and then forwards the funds to the recipients own address.

i have read where people want orderbooks in this program listing peoples offers and bids.. which is more complicated to kee updating p2p style

so the lesser problems i see.
1. how to operate the escrow, which is not corruptible by people tweaking their client sourcecode. yet remain open source
2. how would the orders be communicated throughout the network at a reasonable speed where all the nodes get a active list instantly

wow, reading all of that plus these:

https://bitcointalksearch.org/topic/primer-for-a-p2p-distributed-exchange-212841
https://bitcointalksearch.org/topic/p2p-exchange-for-bitcoin-172705
https://bitcointalksearch.org/topic/a-new-idea-for-bitcoin-markets-145389

I'm surprised there isn't an OT proof of work thread

I was surprised at how Ripple got shot down at every turn even though they apparently are a decentralized exchange (or are they)

We've got to make it happen. Satoshi did it, so can we - his peers.