Topic: For Public Consideration: [Marketcoin | MKC] A P2P Trustless Cryptocoin Exchange (Read 2603 times)

It's interesting, I think generally you're on the right track.

How do the consensus witnesses get access to the data about what's going in and out of other people's accounts? I don't know Sofort - do they publish that information? Even if they do, you're now relying on them to publish accurate data.

What's so hard about a simple check on that, using services like Sofort in Germany, that can check the fiat-user's fiat account? That can be cross-verified by other nodes who can see that particular account. So you get consensus.

(How to keep those consensus witnesses honest?
By freezing some of their own money to insure the transaction, unblocked when that one is successful.
Why would they participate?
To earn fees.)


Do this : go read up any whitepaper on crypto, trust, security, and when you see "trusted third-party", replace with "distributed proof mechanism".

I answered in the cvToken thread to avoid pulling this one off-topic.

Looks interesting. I'm not sure that I followed it all - if you're trying to peg to (say) AUD don't you have the same problem I mentioned up-thread of needing to trust somebody to provide external information about the exchange rate of your currency to AUD? You say,


But how does that work? The problem everyone has been bumping their heads against with the p2p concept is that nobody has a good way to know what's going on at the fiat end of any given transaction.

XertroV and edumundedgar, have either of you looked at cvTokens?  They are a way to accomplish stable currencies like these without trusted parties and within a useful framework of incentives.

Right - I guess the main point of failure / excessive trust that you're stuck with is that you need a reliable way to know your own exchange rate. Once you've got that, in theory it should be possible to do the rest just with algorithms in the software, eg. people can volunteer to destroy coins if the exchange rate is too weak, and get rewarded with the ability to print them when the exchange rate is too strong.

For that element of trust, I guess you'd just have a list of trusted public keys in the client for people who could be relied on to give accurate information about the exchange rate for a fee, and the community would have to police that list if anybody got caught misbehaving.

One hard thing about boot-strapping this is that the currency can't work without reasonably liquid exchanges, and you can't create liquid exchanges without an established currency. But once somebody comes up with a nice, open system allowing you to trade Bitcoins for AussieCoins (etc etc) you could then piggy-back off publicly available data about the Bitcoin exchange rates. I think you could design this so that the system could survive not being confident about the exchange rate all the time - you just need to know that any sustained deviation from 1 AussieCoin == 1 AUD will eventually be corrected by printing or destroying money, at which point you should be able to rely on speculators to keep the price in line.

I completely agree. As a first step in this direction at some point in the future I'd like to start an Australian cryptocoin that is pegged to the Aussie Dollar. You'd be compromising many of the values inherent in Bitcoin, and introducing central points of failure, but properly managed it would be a powerful force, especially if AUD -> AussieCoin is easy, then you can cheaply, quickly and easily change AussieCoin for Bitcoin without any restrictions.

Sure, but low-friction, trustless P2P exchanges between crypto-currencies would be a very useful step, combined with some other projects.

One place where it would help with the USD<->Bitcoin problem would be in combination with a parallel currency with that had its money supply automatically adjusting to keep it stable against USD. You'd then have low-friction p2p exchanges to trade between between Bitcoin and that. This wouldn't directly solve with the core problem of what to do if you have a bunch of USD and need some Bitcoins, but it would mitigate a lot of the problems you get when the exchanges fail; For example, you'd have a decentralized way to do price discovery, and you'd also be able to hedge easily and cheaply against currency volatility. It would also probably make it easier to sell cryto-currency for USD, because it's easier to run a shop for something that doesn't change in value very often than an exchange for something that does.

I didn't read the full post, but I wanted to comment on trustless P2P exchanges.  Most payment methods people want to exchange for Bitcoin (PayPal, credit cards, bank transfers, etc) inherently require trust.  Until that demand changes, all P2P exchanges seem destined to require trust as a central component.

It will be exciting indeed when cryptocoins are adopted widely enough that a design such as you suggest can be popular.

I will attempt to describe Marketcoin below. The idea is in its infancy and will probably require great adjustment (as well as making some protocol decisions) before it is viable (if ever).

This describes Marketcoin, what I plan to become a P2P Trustless Cryptocoin Exchange. I suggest units be called named 'kets' (eg. milikets, kilokets, etc; similar to the colloquial milibit).

I can't think of any flaws just yet, but I don't describe much of the protocol here. Notably, an exchange matching system is required. I'm quite fond of batch trades at every block production for the currency pair (will explain more on that later) which appears to have a trivial application in a blockchain. This can be a 'discreet double auction' style system easily, which also appeals to me. Having an open and free exchange which is liberated from the burdens of HPC and buy/sell wall manipulations is something I (and hopefully many others) would happily use.

There is a lot of room for discussion and improvements, beyond the idea presented below.

I will refer to the buyer and seller throughout this. This particularly refers to the buyers and sellers of Marketcoin, if not otherwise specified. Their public keys are respectively Pb and Ps. In addition, Altcoin will be a general term used to describe a currency such as Bitcoin, Namecoin or Litecoin.

Marketcoin:

This idea rely's on the same private key generating the same public key in both cryptocoins. One of these cryptocoins will always be Marketcoin. (A Many->One and One->Many relationship is far easier to manage than Many->Many)


Marketcoin is a Bitcoin-like system, however, transactions are drastically revamped, as well as the data stored in, and the mechanisms behind the blockchain. Bitcoin is a comparably simple system; there is one ledger and it must do no more than ledge. Marketcoin's blockchain will need to record transactions, and enough information to help verify those. What I will suggest is not a normal blockchain, but a hybrid, as we shall see.

In addition, those transactions must have certain properties. Their primary facility is to enable exchange of cryptocoins, not to act as a currency in their own right. Thus, transactions are not as arbitrary as traditional cryptocoin transactions. I suggest all transactions in Marketcoin be directly tied to a transaction in another cryptocurrency; with null being an option. You can think of these transactions as trades, though that is not technically correct, as it is really a conditional transaction.

Furthermore, transactions are not generated by one party, but are rather a product of the network (or the miners/auditors if you prefer). The beginning of a transaction is the matching of two orders, each signed by their respective owners. As each order is signed, the buyer and sellers' public keys are known (each corresponding private key is imported into both the Marketcoin client and the Altcoin client for the respective party).

I suggest transactions be necessarily 2-staged, in the following way:

• To begin with, an order is broadcast, once it is matched (included in a block) the combine to form a transaction which is confirmed but not finalised. This transaction is Ps -> Pb.
• At this point, to finalise the transaction, a signed transaction for the agreed amount from Pb -> Ps on the Altcoin network must be broadcast within the Marketcoin network. Furthermore, it must have been included in an Altcoin block produced prior to the Marketcoin block it appears in. The Altcoin block's hash should be included.
• Once this condition is met the Ps -> Pb transaction on the Marketcoin network becomes finalised, and the buyer can trade their marketcoins for whatever other cryptocurrency they please.
• If this condition is not met after 24 hours in blocks (144 blocks on the Bitcoin network) the transaction is reversed and the marketcoins are spendable by the seller once again.

This has some distinct advantages:

• Once the order is matched, the trade is out of the seller's hands. Furthermore, the buyer must prove payment before finalising the Marketcoin transaction, but whether the trade is completed is entirely within their hands. However, this does raise the potential for abuse.
• Transactions on Altcoin networks just need to be standard transaction; no changes are needed to Bitcoin or other cryptocurrencies to trade with Marketcoin.
• Fees are possible on both ends of the transaction, and the buyer pays if they have a big altcoin transaction.

Though it has some disadvantages:

• As mentioned, the potential for a DoS by a malicious party matching orders but not fulfilling trades. There may be some way to get around this using coin-age on the altcoin network (Proof of Stake), or setup a reputation measure based on passed unfulfilled trades.
• Marketcoin could not trade with Alt-Marketcoin as proof of payment is required as part of the protocol. The easy workaround is to detour through Altcoin.
• Difficult to charge a fee for placing an order to buy marketcoins. Perhaps a fee can be optionally included, and then once someone has marketcoins they can easily place buy orders with minute fees. It might be a little difficult initially, but once you have marketcoins it should be easy.
• As we rely on transactions from other cryptocoin networks, a block reorganisation on those networks could have disastrous complications for Marketcoin. There must be significant buffer (at least 6 blocks / 1 hour) and appropriate reorganisation protocols in place to help mitigate the potential of doublespends on an Altcoin network forcing a re-organisation on the Marketcoin network. I believe this can be mitigated, however.

There are certainly subtleties I've ignored here, such as how are trades matched. There are obvious requirements, such as being completely deterministic and as fair as possible. I imagine there are a few potential systems out there but there is time still to examine that aspect.

The blockchain is rather more complicated than transactions. To remain secure a user must be able to verify that a past trade made with a cryptocurrency he does not have access to is legitimate, if done incorrectly this may compromise the fungibility of Marketcoin. Because of this transactions will somehow need to be cemented after some time to prevent trades through bogus altcoins being reversed to reverse the marketcoin transaction (and all those following). Perhaps a solution is something akin to n blocks of leeway for altcoin reorganisation, and then the marketcoin transaction becomes not simply finalised but irreversible, the marketcoins now being safe to use in another transaction. This is a matter of protocol, and will need to be investigated early on. This also ties in with requirements of age of proof-of-payment transactions included in marketcoin transaction finalisations.

I envisage the blockchain being comprised of a myriad of blocks; a different type for each currency-pair, in fact. Each type of block is mined in the same manner as the parent Altcoin (SHA256 for BTC/MKC blocks, Scrypt for LTC/MKC blocks, etc) to enable merged-mining. This will help support the security of each currency pair and the security of Marketcoin overall. Each currency pair block will have a list of all block-headers and their hashes from the altcoin not currently included in the currency pair chain, up to some maximum. This means that the Altcoin proof of work chain is included in the Marketcoin proof of work chain. This enables quick and easy transaction verification by checking the Altcoin txid exists in the claimed block (these are specified in the transaction finalisation). Merged mining is also very complementary to the validation of transaction finalisations. Trivially, the correct currency pair chain is decided by the largest total proof of work of the sum of both the currency pair blocks proof of work and the included Altcoin proof of work.

The block reward situation is a more difficult issue. My solution is as follows:

• Let all currency pairs be denoted by set C = { C1, C2, C3, …., Cn }
• The block rewards all draw from a central pool of size P, the exhaustion of this source triggers the next retarget.
• At the beginning of each retarget period, the volume of Marketcoin transacted (Sk) for each currency pair Ck, is summed to total S.
• Each currency pair has their block reward set to Sk/S*P for the remainder of the retarget period.
• Each currency pair starts with difficulty=1 and block reward=0. This is to facilitate a quick catchup period before the market 'opens' - or becomes stable. Though trading will still be possible.
• Once the market opens the reward is calculated as part of set C.
• If there is not enough left in the central pool a miner shall take the remainder and this will trigger the next retarget period.
• Each retarget period is treated to a small decrease in pool reward size, a continuous function as opposed to Satoshi's step function.

This means there is still a provably limited supply; in addition, periods of growth will be treated to faster increases in supply, providing not only economic benefit, but also reducing the maturation period of Marketcoin.

There are still possible avenues for abuse, one possible example being someone creating a cryptocoin, attempting to fake large volumes (which requires many marketcoins) of trades with consistent low difficulty, and then when the reward readjustment approaches they are able to claim a large proportion of the pool for that retarget period. There are two ways around this: the first is to make demurrage or transaction fees high enough to make such an attack unprofitable, the second is to allow users to decide which currency pairs are allowed (similar to nonstandard transactions in Bitcoin). This will need to be dealt with.

Apologies if some of this rambles a little, it's getting late here in Australia. Hopefully it's clear enough.

As an FYI, unless there are game changing issues found with this I would like to communally publish a whitepaper and begin development. I've was working on a chaintrade implementation when I came up with this.

I've set up a github repository for the Marketcoin Whitepaper here: https://github.com/XertroV/MarketcoinWhitepaper

Original Source: http://xk.io/wp/?p=6