Uptrenda white paper: peer-to-peer cryptocurrency exchange - feedback requested

[Uptrenda]

I've been working on a new design for an altcoin exchange that's significantly more practical and secure than anything that presently exists. It's primarily based around peer-to-peer trading using smart contracts, however it also incorporates aspects of regular currency exchange to facilitate fast partial matching (with a slight twist.)

My white paper is available here: https://pdf.yt/d/KzFdlJWF3UTTlf_i

The main benefits of my system:

• Huge multi-currency support. It will work with Bitcoin, Litecoin, Dogecoin, Namecoin, Feathercoin, Peercoin, ... any of the hundreds of altcoins and future altcoins can be traded in arbitrary combinations.
• My design does not rely on non-standard transactions to operate so trades will execute faster. Plus - it will work with real coins and not just test coins like other exchanges.
• It solves the transaction malleability problem that effects all existing smart contracts by constructing a new kind of dispute system. The dispute system allows third-parties to act as a fail-safe without the usual disadvantages of third-party trust.
• It's unbelievably secure. You keep full control over your coins at all times and traditional deposits are not required.

My exchange works by using double-sided micro-payment channels to allow participants to trade directly without having to depend on a third-party to move coins. Micro-payment channels and cross-chain contracts (currently used by Mercury) are both vulnerable to transaction malleability meaning an attacker can break a contract and cause coins to be irrecoverable - a situation leading to an extortion scenario. My exchange solves this problem by using a new kind of dispute system that requires minimal trust to operate. The full abstract is given bellow.

Abstract:

A peer-to-peer cryptocurrency exchange would allow for cryptocurrencies to be traded directly between users without the security risks present in centralised exchange. Smart contracts provide part of the solution but suffer from transaction malleability. In this paper, I propose a simple solution to the malleability problem by introducing a dispute system that is both practical and secure. The dispute system allows a third-party to mediate with minimal involvement and for trades to be verified against an unspent quantity. When a trade has been verified, a server is used to partially unlock the coins and allocate them between contracts which are carried out directly using incremental multi-signature transactions. This process gives the owners full control over their coins and third-party mediation is only required if a contract is interrupted or if the participants are unable to reach consensus.

Release date:
I have a proof of concept that proves the exchange mechanism works which I'll be releasing as open source in the coming weeks. It's by no means ready for use beyond simple testing (sorry if I got your hopes up) but its still an excellent first step in establishing the first secure cryptocurrency exchange.

Special thanks to: Joepie91 / Sven Slootweg for proof reading early drafts of this paper and giving valuable technical feedback; Peter Todd for helping me fix my early contract code (and generally helping me understand what I was doing.) Noel Tierman for his pioneering work in cross-chain contracts, his excellent ideas about trading systems, and the huge amount of time he took responding to my questions; Mike Hearn for his work with micro-payment channels -- the inspiration for this whole design; Jeff Garzik for creating the only library to manipulate raw transactions that isn't painful to use and generally every other person who has helped - thanks.

[1715121210]

1715121210

[1715121210]

1715121210

[1715121210]

1715121210

[GoingAround]

Shoulda post this on development, you'll get more feedback. https://bitcointalk.org/index.php?board=6.0

[kaykurokawa]

Hi, the individual components are well described but it is a little bit unclear to me how the whole system fits together. Maybe the paper could benefit from a conclusion section that describes how the entire process works in one or two paragraphs. From what I understand the system is basically:

P2p matching of orders (orders signed with unspent tx)
Deposit into green address as described by section 5 (this is the funding address)
Micropayment channels from the green address into contract outputs as described by section 10

I am also not sure exactly how and where the contract server described in section 7 fits in to this system. Can you explain this to me?

Nice work, and I look forward to your replies.

[Uptrenda]

Hi, the individual components are well described but it is a little bit unclear to me how the whole system fits together. Maybe the paper could benefit from a conclusion section that describes how the entire process works in one or two paragraphs. From what I understand the system is basically:

P2p matching of orders (orders signed with unspent tx)
Deposit into green address as described by section 5 (this is the funding address)
Micropayment channels from the green address into contract outputs as described by section 10

I am also not sure exactly how and where the contract server described in section 7 fits in to this system. Can you explain this to me?

Nice work, and I look forward to your replies.

Thanks for taking the time to read my paper - it's quite a dense paper and I'm not very good at explaining things so I appreciate it.

RE: how the contract server fits in: micro-payment channels aren't done directly from the green address. The green address is just a temporary clearing house for setting up the contract outputs. So coins are moved from the green address to one or more contract outputs to initialize the contracts - this is the same thing as the "bond" transaction described in normal micro-payment literature. The difference with this system is you're using funds from a green address as the input to the bond transaction instead of random funds from your wallet.

To actually answer your question: the contract server allows dynamically setting up contracts from a green address. It allows you to create a single setup transaction from a green address to one or more bond outputs. The contract server indicates in real time the status of these outputs (has the opposite side also allocated a bond to us?) meaning you can freely reallocate any pending bond amounts as change (or even swap in new contracts.) It's basically how you prevent DoS attacks and do fast partial matching without having to wait for numerous confirmations between each match.

green address -> setup tx (contract 1 out, contract 2 out, ...) -> broadcast = contracts are now setup, micro-payments can now begin
contract 1 out -> micro-payment channel
contract 2 out -> micro-payment channel
...

I hope that makes sense.

(I'll try publish some raw transactions tomorrow if I get time.)