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)
If you'd like an example, load up bitaddress.org and liteaddress.org and test these two example privkeys:
BTC: 5KWWbi82n63rdf8Y78N4YnntYUmtHJCodU3SpYFRQenRSSCktS2
LTC: 6vpF4qfZgWWj732PcxA2LBa4VxLMV6eqQ9ScXjGT87738LKdmPV
Note both these privkeys show identical pubkeys.
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/MarketcoinWhitepaperOriginal Source:
http://xk.io/wp/?p=6
