Still here, just waiting on the time and energy for comment. Haven't read the updated whitepaper yet though. In regards to the previous one I read I think it needs some more technical details before I can wrap my head around it. Will provide more feedback in a few hours.

2. Isn't this a function of the userbase? How do you present a large number of bids/asks on an otherwise perfect P2P exchange that only 7 people worldwide use? I think this should be removed, but I understand why it's here.

Suggestion: "It must present the deepest market possible given outside constrains on the system, such as userbase"

7. I've voiced my concern about putting requirements for fiat in these criteria. I won't go into too much detail (again) but I would actually suggest that fiat is a corruption of 'ideal money' and so necessitates a corruption of the 'ideal exchange'. I hope we're not using fiat in 10/50/100 years time, and what is an 'ideal' exchange will be different because of that, and probably won't mention fiat. Just a thought.

13. I'd like to suggest an expansion to this "It should address known scalability issues with Bitcoin or be able to take advantages of scalability improvements when they are made to Bitcoin". Not the most elegant wording, but hopefully you can understand what I mean by that. It worries me if we try and develop too much at this stage we'll miss the opportunities for innovation. Scalability is an issue for Bitcoin, but not just yet. We'll see what develops over the next few years.

I think the current requirements for integration with the system as I've written up are:

• Can be used as a parent chain for merged mining
• Uses transactions where outputs can be confirmed
• Uses transactions which are confirmed in a blockchain
• Irreversible transactions

One of the advantages is it works with standard Bitcoin transactions, and can be used with addresses (instead of pubkeys) if the same keypair is used on both the Bitcoin and Marketcoin network.

The last three properties are important for proof-of-payment, the first is important for having a perfect-knowledge system (or close enough for these purposes; not sure of the limits here). Maybe knowledge discovery is a better term.

I'm planning to expand the proof-of-payment algorithm so 'pledges' (similar to what Marketcoin uses) can be used as proof-of-intent-to-pay, where once the trade is made coins will be released. This is a little more complex though. It would be nice to support this for the first mainnet release, but I'm unsure if it's properly do-able or feasible as I haven't put that much thought into it yet.


I think there plenty of productive uses if we use liberal amounts of imagination, in terms of salient productive uses, not so sure.


I hope so, that's what Marketcoin is, ultimately. Let's see in 6 weeks


Awesome! I look forward to seeing how this pans out!

On the note of the atomic trading alg and comparing it to Marketcoin:

• Marketcoin requires no changes to the Bitcoin/altcoin network
• Marketcoin does not use nLockTime (Marketcoin's finalisation system is different, you can look at the reversal as similar to nLockTime but it isn't the same thing)
• Marketcoin has very interesting economic properties such as eliminating arbitrage between all currencies on the exchange
• After the orders are locked in a block only one party has to do anything, the seller of MKC just sits back and waits
• Way fewer steps
• Possibly less opcode needs, but this won't fall either way until the protocol is fully developed

Also, love the use cases.

As I mentioned in the proposal I'm not looking to fund development, just community stuff at this stage. Once there's a community and some development then I'll consider asking for development funding. The whitepaper is very much a work in progress. I'm quitting one of my jobs at the end of June so I can work on Marketcoin part time.

Unfortunately the only use ATM is trading to Litecoin or shitecoin, but I don't see these altcoins being particularly useful. Ultimately I'm looking to create infrastructure that will help exchange between Bitcoin and purposeful currencies, be they local currencies or for novel purposes (like Namecoin).

Also, I don't expect this grant to be successful. Worst case is the board reads it and says no; I'll be working on it either way, though it might be a little slower without a grant. I'll be applying for another in 3 months in any case. At least they hear about it and there'll be some discussion.

I believe that Marketcoin will not fragment the Bitcoin ecosystem; rather it will help it flourish. The philosophy behind Bitcoin is present in Marketcoin, and will continue to be.

Edit: Grant Proposal submitted. View it here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md

I am always ready to be proven wrong, especially when the benefit of the community is at stake.


It seems to me this depends on how we look at that last sentence. Is Marketcoin a P2P exchange in the extreme? How do you then reconcile the idea of a unified single system such as Marketcoin. On the other hand, looking at systems like Bitcoin, one can argue that every individual *is* a bank, and so I can see that it can be resolved with a particular frame of reference.

Ultimately this is a small point to argue, but I'd like to see some academic investigation into it. (Though now is not the time or place to try and resolve such differences since I think we can all agree you're certainly correct enough for this conversation).


I agree that 4. is the ideal, though I'm not sure how easily it can be achieved. Still need to read the BitShares whitepaper though, so don't take my word for it. As a side point, I'd anticipate that Marketcoin would be compatible with such systems.


A lot of 'ifs' there, though I look forward to your solutions





more . I look forward to it.


I agree with this, it's certainly a two part issue, and I think this separation is important.

---

On the note of using SSL style systems, these are probably one of the better ways of dealing with the issues fiat raises, and it helps p2p trade of fiat without needing to buy into a cryptocurrency solution; as always there's two sides of the coin, but having more options is always beneficial.

---

Has anyone else thought about applying for a grant from the Bitcoin Foundation?. I'm applying for one with Marketcoin; though only a little one to begin with. If anyone has systems they'd like to develop but don't have the funds I'd really encourage it. Peter, Gaving and Lindsay all encouraged me to write one for Marketcoin. You can find my application here: https://github.com/XertroV/MarketcoinWhitepaper/blob/master/GrantProposal-Q2-2013.md

---

Edit: Tumak has updated the crosschain p2ptrade algorithm to be clearer, please find the updated version here: https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade

A few comments:


I'm really presuming the word 'ideal' isn't in the above line. I'm not even sure if an ideal p2p exchange could work. Ideally I could trade you my gold bar for bitcoins truslessly, but there are myriad issues that prevent that. I think we should compartmentalise what we want these exchanges to do, more so than just 'a p2p exchange', and more like 'a p2p fiat exchange', 'a p2p fiat and cryptocoin exchange', etc.


There are two parts to a trade - matching and locking the orders, and transferring value. "When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so." Really I think this means "When you are watching a graph of trades and you would like to make a trade at that current price, you must be able to do so, or have the same ability to do so as every other member of the exchange". Trades with fiat can't be instantaneous, but locking in a price can be.


Where did the 'value' term go? You've now removed the reference to generic money and are specifically talking about fiat. Also, a 'perfect representation of fiat' doesn't really mean anything because there is no perfect representation. Maybe cash, but you'd have to mail it or exchange in person; bank transfers are IOUs. I am not certain this new criterion is even possible in the world of fiat.

I can't come up with a better point 6 than we had before, but I think this change is not a good one.

I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell.

Edit:
I should add that I'm not talking specifically about litecoin/shitecoin/etc. I'm talking about currencies created to be particularly useful in certain cases or environments.


I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin.

There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above?
I can, however, see how some easy modifications could eliminate some edge conditions.

Edit2:
I've responded to tumak's post below in a PM to avoid derailing the thread further

This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community.


Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?

This is where something like Marketcoin is very useful, quick trustless exchange of value between chains means altchains only need one function (like a zerocoin altchain or a bitshares altchain) in order to be useful. We should function on creating functional, innovative coins instead of trying to cram everything into Bitcoin. Bitcoin is wonderful, but it is designed as money and I think it would be good to keep it that way. The entire point of open source is that if someone want's to improve or alter Bitcoin they can.


Exactly. It is commonly believed that trading between chains trustlessly is impossible with the current Bitcoin implementation. There is plenty of discussion on the Bitcoin wiki about the chain-trade algorithm and why it isn't good enough. It could work but only with mutually assured destruction (if the trade falls through all funds are lost).


Edit:
I realised I didn't really address the above. Marketcoin incentivises early payment and late finalisation. The speed is determined by the buyer's eagerness. (When I talk about buyer and seller this is in the context of MKC). In this sense the seller will know if they've been paid before the network (and anyone else who checks the address). There's probably room for improvement here.
/Edit

Currently I'm leaning towards the idea of the buyer of MKC offering a 'pledge' which is sacrificed if they fail the trade. This shows intent to trade. The seller isn't required to do this because after orders are matched the trade is out of their hands.

The pledge could go to miners (but not to the miner who has the opportunity to block finalisation) or to the seller of MKC, or a combination. That would at least be some recompense for having the trade fall through. It also limits market manipulation. If the trade succeeds the pledge is returned to the buyer.


This is and isn't an issue; my current vision for Marketcoin does not include an order book. In this way, trades will only stay active as long as you specify (similar to locktime) and if you're selling MKC then you don't have to worry about that.


My original idea included using the same keypairs on both the Marketcoin chain and altchain (same privkey -> same pubkey -> different address). This lets Marketcoin handle everything on it's own, but only if you leave the keys unencrypted or have the password in memory. Not fantastic solutions, but my phone has unencrypted keys after all.


The 'freshness' idea is similar to what I've got down at the moment.

The unpredictability is mitigated somewhat by having multiple trades with slightly different offers which are less likely to have the same buyer. The exchange


Very similar to what I've got down, but there's also a pledge on the part of the buyer. Marketcoin is always one currency being transacted and the pledge is also made in MKC.


Remember that the network incentivises fast payment and slow redemption. In the sense you provide, Marketcoin is not atomic, but I'm not really sure atomic is a good word to use.

24hrs is an arbitrary number, remember. It needs to be long enough to avoid fallout from chainforks but short enough to be tolerable.

Also, no two people can make identical trades, just like no two transactions on the Bitcoin network are identical unless they are, in fact, the same transaction.


This is where I see Marketcoin standing. It is not the whole puzzle, but I think it is the most important piece, as we won't be using fiat much longer (because it just can't compete). Well, at least I'll be trying my hardest to ensure fiat dies out as quickly as possible. [I'll be running for the Australian senate in 3 yrs, and every 3 years thereafter]


I agree that escrow and exchange should be separated when talking about fiat.

For me, a fiat -> cryptocoin exchange has one main purpose and one main property:

PROPERTY: Can't be prevented by third parties
PURPOSE: To facilitate a transfer of value from fiat to cryptocoins (I like to call this type of money 'factum' money, and could possibly be a larger set than just cryptocurrency. It's a bit of a joke because fiat means 'let it be so' (roughly) and factum means 'done'. Also, I like the idea of calling something fact based money, or fact backed money.)

---

Another thing about Marketcoin: one of the things that will slow adoption is that, like Bitcoin, it's difficult to get into. To trade large volumes very fast you'd need some sort of other exchange to give you a large enough sum of MKC straight away. I do have one plan to help with that, but it isn't trustless, just easy.

This is because you have to make a 'pledge' to buy MKC. This is easy to deal with from a network standpoint with policy:

1. small trades require no pledge
2. number of small trades per block is limited (yay competition)

---

TL;DR Spam mitigation is a bitch.

You can create artificial market forces via a central-ish authority that exchanges 1:1. The black market might differ by a few %, but it should be reasonably stable. Maybe. Until we have an implementation we might not be able to truly tell what will happen.


I'd like to hear more about this. At the end of the post I ask if you're talking about BitShares.


Agreed. Marketcoin simpliciter will not fail due to someone being hit by a bus.

In Marketcoin, after orders are matched:

• Seller of MKC gets hit by a bus: Trade continues as normal as onus is on buyer
• Buyer of MKC gets hit by a bus: If the altcoin payment has not been made then a short while (24hrs maybe) later the trade reverses; if the altcoin payment has been made but the trade is not finalised then the buyer might end up with their MKC returned and the Altcoin payment.

This is precisely how Marketcoin works.


This is an issue. I don't think we need to halt the exchange, as it is the onus of users (like when a blockchain fork occurs in Bitcoin) to determine when they will accept the transaction/trade. The advantage of Marketcoin is you can wait to broadcast the finalisation; you can make the payment on the altcoin network and wait an hour or ten before broadcasting the finalisation, this gives ample time to make sure blockchain forks haven't occurred. With some nice code it shouldn't be too difficult to have some sort of basic alert to let users know that trading may be unstable at the current point in time due to blockchain forks (on altcoin or otherwise). An advantage of Marketcoin is the uncertainty only falls on the currencypair affiliated with the forked altcoin, other markets will keep working.

I think the best way to structure the system is to give onus to users and not try and let the network fuddy-duddy around with txs trying to repair damage. Bitcoin doesn't do it, Marketcoin shouldn't either.


I think the best thing is to make the Marketcoin client connect with alt-clients in the style Armory uses, and possibly a little RPC as well. This lets the Marketcoin client be a bit lighter and even supports remote servers while still maintaining some degree of separation from the altcoin client.

Keep in mind Marketcoin is aware of all blocks on the altcoin network and will have access to the most recent ones. [It stores the block headers indefinitely and keeps blocks for 24/36 hours in order to fully validate payments]

I'd like to automate things as much as possible, something like a mode where it prompts you to interface with your Bitcoin client and executes payments as needed but also allows for manual transactions (if you want to separate things a little more or use a light client).


One idea I had was using the same keypairs in Marketcoin as in the altcoins, which cuts down on the information transfered and means Marketcoin can sign txs for the altcoin network and submit them on its own. Knowing all the blocks and having a connection to the altcoin network lets you automate everything.

Part of the Marketcoin protocol is a 'trade-timeout' condition. An amply long period of time should be provided (24hrs say) but not so long that it ties money up for an unacceptable period of time (3 weeks).

20 minutes is a rough figure off the top of my head. We won't be able to tell till the network has a testnet. Ultimately it depends on block times and some other things. Keep in mind that for a transaction on the Bitcoin network to complete it can be instant (if you want to accept zero-confs) or it could an hour or more, depending on your own criteria. Likewise, a Marketcoin trade can occur in 10/15/20 minutes but if the buyer wishes to delay it (for added security against chain forks and the like) they can submit payment on the altcoin network and finalise on the Marketcoin network much later. They could even broadcast the finalisation with a minimum block number and it will be only included after that point.

All the measurements of ~24hrs and things I keep saying is an approximation, really it would be 144 blocks or whatever is expected for 24hrs.


Marketcoin facilitates offline or cold trades (similar to offline / cold transactions on Bitcoin). But, like Bitcoin, you'd have to move the data yourself.

I presume 'atomic' means trading 1 satoshi and the like. Marketcoin allows this but it may be restricted to minimize dust trades (similar to what Bitcoin-QT does with transactions now).

When you talk about your approach do you mean BitShares?

I am very curious about this idea; could be of great use to Marketcoin.

Edit: Sadly can't comment on weather it is more or less secure, but it certainly seems like a much better proposal than (ab)using the merkle tree.

As an FYI to everyone, I'm currently working on a completely trustless p2p exchange for trading between altchains.

Copy pasta (mostly) from the foundation's forum in the p2p exchange thread:

---

I am working on something like this currently. The only exception is point 5: Have three-user (trustless) trading, so a non-interested 3rd party always hosts the trade between the buyer and seller. (And should provide Escrow too!))

Marketcoin (the name of the system) doesn't require three-user trading for trustlessness. It wouldn't be difficult to implement though, I suspect.

Marketcoin is required to be a new cryptocoin; I've looking into the chain-trade style setups, and there seem to be issues. Introducing a new cryptocoin allows these issues to be solved because we can make the new network have rules that eliminate these risks. (IE: after the orders are matched the onus is all on the buyer; the worst that can happen is the buyer sends the altcoin but doesn't redeem the marketcoin and they are returned to the original owner, furthermore, as marketcoin is a new blockchain, we can force it to take the risk to enable trustless exchange)

Note that Marketcoin is only compatible with Cryptocoins; however, pegged cryptocoins are also compatible.

Github (Whitepaper - not yet complete)

A P2P Distributed Exchange MUST:

1. Be without any central points of failure, since a government or two WILL be coming after it one day. I suggest a Bitorrent-like software schematic.
Marketcoin is based on a PoW blockchain and is as decentralised as Bitcoin (it will be forked from Bitcoin, after all)
Thus inherits properties of Bitcoin relevant to this point.

2. Show everyone a very large number of possible trades to choose from, (thousands?) so assets can form a stable price. (e.g. a Bitcoin is going for $120)
Number of trades is basically volume. Marketcoin (the exchange) will inherit this as the network matures. (Just like any other exchange). On this note, the same scaling issues are present in Marketcoin as in Bitcoin, and it will have similar transaction capacity.

3. Transact trades pretty much INSTANTANEOUSLY, so when you're watching a graph and want to trade at a very specific time you can do so. (This is extremely important for arbitragers and other traders who help keep the price fluctuation down.)
The successful finalisation of a trade has similar probabilistic natures as in Bitcoin. Required steps: broadcast order, order is confirmed in block, payment made on altcoin network, payment confirmed in a block on altchain, finalisation broadcast on Marketcoin network. After this control of the disbursement of the Marketcoin funds falls to the buyer.
I suspect the average time taken for trades will be 10-20 minutes or so. (5 minute blocks on marketcoin, requires a conf from altcoin network, then broadcasting the finalisation on marketcoin network; can be very fast, but higher risk, the converse is also true)

4. Offer Graphs and APIs for for graphing like MtGox does.
Getting market history is as trivial as getting past history in Bitcoin. The Marketcoin blockexplorer *is* the equivalent of BitcoinCharts. Charts will probably be built into the client too, though this isn't the most crucial priority.

5. Have three-user (trustless) trading, so a non-interested 3rd party always hosts the trade between the buyer and seller. (And should provide Escrow too!)
See above. This is not required but is possible (I suspect, since Marketcoin will inherit many of the scripts of Bitcoin (opcodes and whatnot)). In some frames of reference the network itself is this third party.

6. Hold and transfer VALUE, not just IOUs. (With Cryptocurrency this is easy... With fiat? Not so much.)
Trades involve real transactions of Altcoin and Marketcoin. For coins to be redeemed proof of payment (a standard transaction) must occur on the Altcoin network.
Work on Marketcoin is slow at the moment; I'm working full time and am trying to do what I can where I can. I'm also trying to be as transparent as possible as this provides the best chance of a successful launch for a new cryptocoin. Furthermore, for it's longevity it needs to get the market structure and dynamics right from the get-go, which is exactly why it can't be monetized.

---

On the note of fiat, I think the best way to move forward is to allow entry into a pegged cryptocoin. Then you inherit many of the nice properties of Bitcoin like irreversible transactions. Ultimately I think every discussion of integrating fiat with P2P exchanges is considering where the trust lies. I'm pretty confident you can't integrate fiat without some form of trust. In an OT/BitMessage style exchange the trust is with the other party accepting the trade; so trust is different for each user, thus each user will have a slightly different experience but the network is somewhat resilient. On the other hand with a centralised trust system (like a pegged cryptocoin) all trust lies with one (or a few) organisation(s) which might result in cataclysmic failure in the even of a regulatory-crackdown or change in legislation.

Also, I think that instant trades on an exchange is a terrible idea. We've the chance to reinvent the market, let's try and make it fair. (I can explain this point some more if anyone would like, but I'm at work in a foreign country atm, so I should probably get back to it)

On a random note, if someone can figure out a way to use cash + Zerocoin (with physical cash -> blockchain) then we might solve the p2p cash issue. Anyone want to start a bank which takes deposits and gives out zerocoins?

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.

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

Cheers Zeilap,

That seems to have fixed the issue. I'd presumed the conversion was done when bitcoind received the RPC command, not when it was sent. The more you know!

I'm attempting to add an RPC command to bitcoind. (createchaintradetx in this case)

(Code thus far: https://github.com/XertroV/bitcoin/commit/645c88d361a18c330845e5697ea9c817045bd452)

I'd like to convert one fo the input values, and it seems there's a lot of that done in bitcoinrpc.cpp in function RPCConvertValues.

I've added the line I presume I need:
However, I continue to recieve
I presume the conversion is failing. I've confirmed this with a previous RPC command I tried to add and had the same problem.

Does anyone know why this is failing? I've grepped through for other function names (such as createrawtransaction) and can't find other references to them that would hint at what is needed to fix this.


Edit: as a testcase to produce the above error, if you clone the chaintrade branch linked above, you should be able to compile and run the following on testnet:

I've been thinking recently about the potential applications for pegged cryptocoins. The setup would be something like this:

• A Transparent Not-for-profit creates a new cryptocurrency and premines ^[1] a great deal of coins, hundreds of thousands or millions of units.
• They maintain control over the cryptocurrency.
• They exchange 1 AUD (australian dollar) for 1 AussieCoin (or whatever it's called). There may be a small fee (0.5% or something, to support the organisation).
• They maintain a 1:1 reserve of distributed AussieCoins to AUD held. This allows the currency to remain pegged and can guarantee their 'value'. ^[2]

We now have a cryptocurrency that can easily work as Bitcoin does, but is intrinsically linked to the Australian Dollar. ^[3]

Why is this important? Once we're in Cryptocurrency-land, issues we have now do not apply. We can easily exchange one cryptocurrency for another with little issues of trust and fraud. (As transactions on both chains are irreversible). The most crude (safe) implementation would be using a 3rd party to hold coins from both chains in escrow. Once they are confirmed, the two parties can exchange. If there is any issue, the escrow party has the final say on the trade.

This potentially opens up an easier supply chain for changing Fiat into Bitcoin or other cryptocoins. Furthermore, it means we have an introductory step for new users. New users may be unwilling to trust Bitcoin (a currency sans government backing and whatnot) - but it will be easier for them to trust electronic fiat in their 'native' currency.

Furthermore, with the recent FinCEN report, if a USCoin exists it may be easier and safer for a company / not-for-profit to comply with regulatory laws (since once we enter cryptoland, we leave all jurisdictions).

However, before these ideas become viable, we'll need both the exchange infrastructure and the right legal environment - which might mean needing more regulation. After all, when you try and shut something like this down, it will sprout another head; we just need the motivation.

---

[1] They could premine, or, for simplicity, they could simply make the first block rewards massive, and latter rewards 0. Or they could create a way to 'mint' currency on demand. The trust required for such a setup requires a transparent not-for-profit IMO.

[2] This is why they need control over the currency, how much is up for discussion.

[3] There may be issues if the free-market exchange rate differs from the pegged rate (i.e. 1:1). This is possible if there are issues with supply, or for money laundering purposes (buying off the grid and selling back to the not-for-profit).

On the note of "if price has gone up or down since the last update" - I personally don't see the point of this (comparing updates to a single other) since someone selling BTC0.01 will change the "trend". If other's support the idea, then by all means go ahead, but I would find it more useful if it compared the behaviour of the market over an hour or more, which will start tapping into the actual trends of the market. Not sure how best to implement this in order to accurately reflect the 'trend', but it is food for thought, at least.

Thanks for these improvements dude, much nicer.

Tipped again

rGwLgcQGXxcs3PkowNs8eWGBbMnwmoamUv