• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Mint-Gox

The question is, do we have the development capacity to take this on? I'm not part of the dev team but from where I'm standing Evan seems to be having trouble finding help for the day to day progression of Darkcoin let alone for a major feature like this.

It might be that their code/product/idea is unsuitable. It be that they're owned by Alex Green (joke!). My point being is that we don't know if we need them or not.
fair enough as i do not know ether what technically has or is to be done !
if you down there anyway, propably gonna be super interesting
tell them i heard of them from
Dave Shin / Hong Kong (coin dojo chat)
 
I've got some spare time in a week or two. I'd be happy to meet with them in Vienna.

do we need them ?

Basically it's a lot of work and they are looking for 2 more full time Java devs themselves just to advance their project.
Stonehedge it would be very useful you go talk to them. And I think you'd be very welcome. They are thinking about a strategy to approach alts for integration to let the project be better known.

https://groups.google.com/forum/#!topic/bitsquare/jP58Np_MwMk

Interesting side note: Mike Hearn joins in the discussion there with some tips for them.

They just don't want to be caught up with shitcoins. As the only alt with long term potential plus their interest in anonymity we would be their perfect partner :)

why Java? They use bitcoinj to integrate with the bitcoin protocol. We'd need bitcoinj to be ported to darkcoinj and then it would be pretty easy for them to support us. We had this discussion before. Let me see if I can find it...

EDIT: we already have darkcoinj https://github.com/HashEngineering/darkcoinj
 
We have another killer argument why they should work with us and integrate drk: a huge advantage in Darkcoin will be the masternodes consensus system which Evan will develop for InstantX. The same or a similar mechanism could be used for automated arbiters. Even for automatical bid ask matching.

"Economists assume a trusted intermediary operates the mechanism. Here's a simple example of using this virtual computer for a mechanism. Alice can submit a bid price, and Bob an ask price, then their shared virtual program which has one instruction, "A greater than B?". The computer then returns "true" if Alice's bid is greater than Bob's offer. A slightly more sophisticated computer may then decide the settlement price according to a number of different algorithms (Alice's bid, Bob's ask, split the difference, etc.) This implements the mechanism "blind bargaining" with no trusted intermediary."

http://szabo.best.vwh.net/msc.html

The "virtual computer" needs to be trustless and not a lot of "computers" can provide this service. But masternodes can.
 
I think we should get Minotaur to get in touch with them
as he is our Biz Developer and definitely the man for the job !
 
We have another killer argument why they should work with us and integrate drk: a huge advantage in Darkcoin will be the masternodes consensus system which Evan will develop for InstantX. The same or a similar mechanism could be used for automated arbiters. Even for automatical bid ask matching.

"Economists assume a trusted intermediary operates the mechanism. Here's a simple example of using this virtual computer for a mechanism. Alice can submit a bid price, and Bob an ask price, then their shared virtual program which has one instruction, "A greater than B?". The computer then returns "true" if Alice's bid is greater than Bob's offer. A slightly more sophisticated computer may then decide the settlement price according to a number of different algorithms (Alice's bid, Bob's ask, split the difference, etc.) This implements the mechanism "blind bargaining" with no trusted intermediary."

http://szabo.best.vwh.net/msc.html

The "virtual computer" needs to be trustless and not a lot of "computers" can provide this service. But masternodes can.

Good thinking !!!
 
The reason there aren't any useable p2p exchanges yet is because they introduce problems that nobody has yet solved.

There are two models that I have come up with:

1. p2p exchange/marketplace using a DHT as the 'market database' - think bittorrent, but instead of peers swapping files, all they swap/propagate to other connected peers is the database of what's for sale. This db would include, for example, seller, product, price, contact info etc.

2. Use Masternodes or some other server network to host the database, distributed and kept current between Masternodes, and have a separate client to access them. Think usenet, but again, it's not a million different files that need hosting, just the one current database.

Either way, it's fairly easy to have the whole thing end to end encrypted, and limit user access via keys that for example a seller might need to grant you to view their wares and buy from them.

There are other problems though with both approaches.

In both cases, I have yet to come up with a bulletproof way of preventing spam and deliberate market corruption, this is particularly true of #1. You need a mechanism to prevent peers from flooding the marketplace/exchange (I use the terms interchangeably, because they are at root the same thing - a means of connecting buyers and sellers) with garbage.

One approach would be to charge for access - difficult to do with #1, another would be a reputation system that limited injections according to a scale based on past behaviour and feedback from other peers - still not exactly rock solid.

Approach #2, even with IP obfuscation of the hosts, leaves server ops potentially liable for content they host, and is less truly 'p2peery' - but then usenet existed before the www, and usenet will exist after the www... ;) However #2 also makes spam control far simpler, as there would exist a distributed 'authority' to cull garbage.

Another thing that users are going to have to get used to is that p2p trading is going to require a bit more effort on their part. Buyers and sellers are going to have to liase with each other, and arbiters if required, there is no automated way of doing this that maintains perfect market freedom and does not lead to restriction of trade through centralised services. Such is the price you pay for not having a 3rd party do everything for you, including run off with your money.

p2p markets would also hopefully deal with the problem that plagues current centralised exchanges - idiots leaving their money on the exchange which makes it trivial for exchange owners to game the market with that money via bots, or simply steal it. The current concept most people have of an exchange order book may need to be revised, but IMO this is a good thing.

The arbitration thing is easy, just have an arbiter market offering multisig escrow in whatever currency the arbiter is competent to do it in. Bitcoin and Darkcoin work exactly the same way here, if you have a tool to do one, a simple find/replace bitcoind/darkcoind in the code will get you the other. I could put a radio button and corresponding variable in one of my simple tools to select which in a few minutes. I imagine bitcoinj/darkcoinj are the same story, if you're using that as a back end.

Heh, I could go on for hours, but I need my morning coffee. Just thought I'd throw some thoughts out there.
 
Last edited by a moderator:
Another thing that users are going to have to get used to is that p2p trading is going to require a bit more effort on their part. Buyers and sellers are going to have to liase with each other, and arbiters if required, there is no automated way of doing this that maintains perfect market freedom and does not lead to restriction of trade through centralised services. Such is the price you pay for not having a 3rd party do everything for you, including run off with your money.

The arbitration thing is easy, just have an arbiter market offering multisig escrow in whatever currency the arbiter is competent to do it in. Bitcoin and Darkcoin work exactly the same way here, if you have a tool to do one, a simple find/replace bitcoind/darkcoind in the code will get you the other. I could put a radio button and corresponding variable in one of my simple tools to select which in a few minutes. I imagine bitcoinj/darkcoinj are the same story, if you're using that as a back end.

What if the abitration is automated by the masternodes? What if they are the 3rd party? See my previous post with my link to the "God Protocols" by Szabo. What if a random subset of masternodes could become a reliable source of automated checking functions, protocol enforcers. There could be even be a masternode api developed for simple checking functions like blockchain lookup, bid ask order matching in a database etc.

Heh, I could go on for hours, but I need my morning coffee. Just thought I'd throw some thoughts out there.

you need more coffee ;)
 
what about smart contracts !
isn't that what they can/should do trust less ?
 
What if the abitration is automated by the masternodes? What if they are the 3rd party? See my previous post with my link to the "God Protocols" by Szabo. What if a random subset of masternodes could become a reliable source of automated checking functions, protocol enforcers. There could be even be a masternode api developed for simple checking functions like blockchain lookup, bid ask order matching in a database etc.

That could work. I think any exchange stuff should be kept discreet from the core coin machinery though. The server just needs db access like any other peer, plus a few admin capabilities, and could offer escrow via whatever backend, running the whole thing as a different user, I'd leave the MN daemon alone, although I used it without issue in one of my little multisig demos.
 
Another thing that users are going to have to get used to is that p2p trading is going to require a bit more effort on their part. Buyers and sellers are going to have to liase with each other, and arbiters if required, there is no automated way of doing this that maintains perfect market freedom and does not lead to restriction of trade through centralised services.

Sir Crouton mentions an very important practical aspect of p2p exchanges. More "effort" in p2p trading is maybe acceptable in case you are selling and buying goods. Especially not easy to come by goods. But for a currency exchange? Imagine having to wait for a human arbiter to intervene and check if the price you paid into your one time multisig trading wallet is exactly the correct amount which you agreed to pay on settlement? And then check the seller's account? And then sign and release the payment? Forget it. http://bitsquare.io/ , which has been developed by Manfred Karrer with Fiat to BTC in mind, solves some tedious aspects of the arbiter problem with collateral payments. The speed aspect however has not been solved afaik. And it's not a big issue in fiat to btc too, because the bank wire is not instantanous (yes! 1:0 for cryptocurrencies). In order to solve the speed problem there needs to be an automated mechanism of some kind. It could be centralised and trusted, like in the existing centralised exchanges. But then we're back to the issue of whoever controls the automated mechanism can fix the price. Or it could be decentralised and trustless. POW is not really very attractive in solving the speed problem because you don't want to wait 2.5, no, not even 1 minute, until you know if your market order was filled or not. You need a pretty quick response or you will fall back to use centralised exchanges next time you want to sodl your dark (don't ever do that!). But what other decentralised mechanism do we know of, which is not POW? Hmmm.... maybe a consensus of randomly selected masternodes which are quick as lightning and ready to go whenever you need them? Sound about right to me. I think whoever will develop a decentralised currency exchange really needs the masternode architecture, or a derivative thereof. bitsquare needs us. Just saying.

On the other hand, think of what it would mean for dark to showcase the first decentralised currency exchange built on the masternode architecture, using the instantX-style consensus mechanism. People have been talking about the possiblity of decentralised stock exchanges (I mean stock exchange like NYSE, Nasdaq, CBOT etc) that can be built on the bitcoin protocol for years. Can the bitcoin architecture solve the speed problem? If we can solve the speed problem for this little currency exchange thingy it would be huge. But that would only be the beginning :eek:
 
It's going to be hard making p2p trading as fast as centralised trading, dealing with multiple nodes is going to be slower than dealing with a single entity, but you could at least bring consistency by having a set tickrate, a temporal resolution if you like. If that could be brought down to a reliable sub 20 seconds I think that would be adequate.

Traders need to decide which system they prefer - guaranteed bot rape* and possible coin theft via a centralised exchange, or waiting a few extra seconds in a trustless p2p system. I would think everyone but the botmasters would prefer the latter?


*It's a free market etc. but I would be strongly in favour of making any decentralised exchange architecturally as hard as possible to operate bots in. HFT doesn't 'improve liquidity,' that's just the bullshit they feed people as if they are doing the economy a favour, it just makes the players with the most resources richer, faster, at the expense of the rest of us. Just having a tickrate would knock bots down a couple of notches. And no machine-useable trading API. No API at all maybe, just the client.

Enough rambling, I need to update my Masternodes to v15! :smile:
 
There is this thread which points to several projects that have been started in this vain. https://bitcointalk.org/index.php?topic=155603.0 If we can start where others have left off, we wouldn't have to reinvent the wheel, however, we would also inherit their baggage. One would have to know what they're looking at and evaluate each project to see which one would scale for our use?!
 
The question is, do we have the development capacity to take this on? I'm not part of the dev team but from where I'm standing Evan seems to be having trouble finding help for the day to day progression of Darkcoin let alone for a major feature like this.

It might be that their code/product/idea is unsuitable. It be that they're owned by Alex Green (joke!). My point being is that we don't know if we need them or not.
No, this would have to be a pet project of an entirely new team. We might get someone on the main team to be a go-between, but unless Darkcoin spurs on new development groups, it's not going to realize it's potential. This would only be one project that could change the crypto world for the better, there are many, many other ideas worthy of their own team! We need to find developers that want to take projects on, many projects. Each developer, with the talent, can start any project that excites them and be the lead on it. You don't have to create (yet) another coin, recreating the wheel over and over again, but join up here and create something NEW and EXCITING!
 
Basically it's a lot of work and they are looking for 2 more full time Java devs themselves just to advance their project.
Stonehedge it would be very useful you go talk to them. And I think you'd be very welcome. They are thinking about a strategy to approach alts for integration to let the project be better known.

https://groups.google.com/forum/#!topic/bitsquare/jP58Np_MwMk

Interesting side note: Mike Hearn joins in the discussion there with some tips for them.

They just don't want to be caught up with shitcoins. As the only alt with long term potential plus their interest in anonymity we would be their perfect partner :)

why Java? They use bitcoinj to integrate with the bitcoin protocol. We'd need bitcoinj to be ported to darkcoinj and then it would be pretty easy for them to support us. We had this discussion before. Let me see if I can find it...

EDIT: we already have darkcoinj https://github.com/HashEngineering/darkcoinj
That would be really awesome, as we do have something to offer (masternodes) to help secure the transactions, etc... and of course, we should join forces if possible rather than fork off what they did to something separate. This could be excellent! (oh, you already said that, ROFLMAO)
 
I think we should get Minotaur to get in touch with them
as he is our Biz Developer and definitely the man for the job !

And if Minotaur so wishes, I'll take care of some corporate hospitality in Vienna :wink:

I'm going to be in Belgium for a while and its a short flight from Brussels.
 
The reason there aren't any useable p2p exchanges yet is because they introduce problems that nobody has yet solved.

There are two models that I have come up with:

1. p2p exchange/marketplace using a DHT as the 'market database' - think bittorrent, but instead of peers swapping files, all they swap/propagate to other connected peers is the database of what's for sale. This db would include, for example, seller, product, price, contact info etc.

2. Use Masternodes or some other server network to host the database, distributed and kept current between Masternodes, and have a separate client to access them. Think usenet, but again, it's not a million different files that need hosting, just the one current database.

Either way, it's fairly easy to have the whole thing end to end encrypted, and limit user access via keys that for example a seller might need to grant you to view their wares and buy from them.

There are other problems though with both approaches.

In both cases, I have yet to come up with a bulletproof way of preventing spam and deliberate market corruption, this is particularly true of #1. You need a mechanism to prevent peers from flooding the marketplace/exchange (I use the terms interchangeably, because they are at root the same thing - a means of connecting buyers and sellers) with garbage.

One approach would be to charge for access - difficult to do with #1, another would be a reputation system that limited injections according to a scale based on past behaviour and feedback from other peers - still not exactly rock solid.

Approach #2, even with IP obfuscation of the hosts, leaves server ops potentially liable for content they host, and is less truly 'p2peery' - but then usenet existed before the www, and usenet will exist after the www... ;) However #2 also makes spam control far simpler, as there would exist a distributed 'authority' to cull garbage.

Another thing that users are going to have to get used to is that p2p trading is going to require a bit more effort on their part. Buyers and sellers are going to have to liase with each other, and arbiters if required, there is no automated way of doing this that maintains perfect market freedom and does not lead to restriction of trade through centralised services. Such is the price you pay for not having a 3rd party do everything for you, including run off with your money.

p2p markets would also hopefully deal with the problem that plagues current centralised exchanges - idiots leaving their money on the exchange which makes it trivial for exchange owners to game the market with that money via bots, or simply steal it. The current concept most people have of an exchange order book may need to be revised, but IMO this is a good thing.

The arbitration thing is easy, just have an arbiter market offering multisig escrow in whatever currency the arbiter is competent to do it in. Bitcoin and Darkcoin work exactly the same way here, if you have a tool to do one, a simple find/replace bitcoind/darkcoind in the code will get you the other. I could put a radio button and corresponding variable in one of my simple tools to select which in a few minutes. I imagine bitcoinj/darkcoinj are the same story, if you're using that as a back end.

Heh, I could go on for hours, but I need my morning coffee. Just thought I'd throw some thoughts out there.

Unfortunately, I don't understand how exchanges are programmed, BUT, what if we basically have a normal exchange, hosted by each masternode, BUT synced up to eachother, and a type of blockchain to keep track of what has been exchanged. The difference would simply be that the funds that are put up for the exchange are literally held in the user's wallet (but locked until taken down or exchanged). It should look and feel just like an exchange, only access is through your wallet.

In this case, I don't see how one can spam. To initiate a transaction, you have to put up and lock funds. Unless you're doing that, how else can you engage the system in order to spam?

I can see needing a minute or so to make sure that over 50% of the nodes have a consensus regarding each transaction, but that's a small price to pay!

Also, this particular blockchain can be foreshortened anytime, as it's only recording transactions, which, over time, can expire (people can keep their transactions forever in their wallet, but these exchanges have nothing to do with verifying coins are ligit, only that the trade was made.
 
Last edited by a moderator:
And if Minotaur so wishes, I'll take care of some corporate hospitality in Vienna :wink:

I'm going to be in Belgium for a while and its a short flight from Brussels.
A distributed exchange as you describe still needs some way of preventing bad actors from spewing nonsense into the mix and fargling things up for everyone else.
 
Would a page out of Evan's book of tricks function for us? Make it so you're charged fees for "acting bad"? I would have to think people should be allowed to pull their order as fast as they can, because sometimes we make a mistake and need to stop it before it's too late. Can you give an example of how the system could be messed with? I'm just not versed well enough with this. Why can exchanges do this, but not masternodes? Because the masternodes would have to talk to eachother? Is that the weak point?
 
Would a page out of Evan's book of tricks function for us? Make it so you're charged fees for "acting bad"? I would have to think people should be allowed to pull their order as fast as they can, because sometimes we make a mistake and need to stop it before it's too late. Can you give an example of how the system could be messed with? I'm just not versed well enough with this. Why can exchanges do this, but not masternodes? Because the masternodes would have to talk to eachother? Is that the weak point?

It would be difficult to maintain the same financial barrier to setting up a rogue node without integrating the exchange into the core daemon, which I don't think is a good idea, for financial/legal liability as well as security reasons. But you could in theory implement a similar but separate requirement for exchange nodes.

Are Masternodes themselves ever charged collateral fees? I don't see how they can be, the MN balance remains locked up.

I think a far simpler approach to a decentralised exchange would be to just keep trades between individual buyers and sellers. Any 'depositing' anywhere and you're back to Bot Town.
 
Back
Top