Topic: Announcing Project Invictus: a P2P Exchange Collaboration - page 2. (Read 11264 times)

Regarding DEX:

You provided some good replies, so let me counter.

Using tools like TOR and VPN it would be impossible to identify that 2 clients are not actually the same person.

Based upon your other description it seems like your bonds are actually backed by the ratings and nothing else.   So lets assume your 'ratings' system is better than Moody's and it accurately labels AAA vs B- then you still have a fragmented market for each bond type.  

I suspect that this would be a fractional reserve heaven!   I would start out as an honest dealer and then earn a AAA rating.  Eventually people will stop redeeming them and just trade them at face value.  As long as I am always able to redeem the 10% that actually get turned in then I am good.     Now because I have a AAA rating, if I ever face pressure from heavy redemption I can simply 'print more AAA' bonds and use them to buy  AAA bonds from other issuers which I would then redeem to meet my demand for redemptions.

Eventually everyone would catch on to this game and everyone would be playing the fractional reserve game until there is a bankrun on the whole system which would then come crashing down.  

*EDIT*  I take that back.. they are also backed by BTC held in escrow which would then prevent over-issuance.   If BTC generally goes up in value then you will be good.  Having them post 110% would probably be better. 

How does one find out where to redeem bonds?  Eventually all 'issuers' will be known and public because they either meet you in person or wire you the money.   Once their 'name' is tied to their 'bond' then it is quite clear that you have simply created a bearer instrument.

Without double checking all of your math, it looks like you have the right idea.  The only difference is that after each price calculation and before the trade is executed, all margin positions are checked and would take priority.

It is entirely possible that as trades progress the margin positions get worse and worse.  I can only 'cover' a margin position by matching against a real bid so if the price (of BitShares) falls too quickly and thus the collateral is no longer enough to cover the position... then I guess it would actually be best to simply buy back as much crypto-Gold at the lowest price it can.   This would actually be better than my earlier approach of paying it out as dividends because it would still server to SUPPORT the price of crypto-Gold rather than further remove demand.  

Thanks, sent!


Just small add-ons, not too much... So I'll counter your concerns here.


I just added a tiny line about that point, which I see as your most serious problem. However, this still comes down to a challenge for the coders.

Other systems have already solved 3-party trading in an open source environment, so I'm sure that you and I will both have to do so as well. Just off the top of my head, adding a check from all three stations could be made to see if the other two stations   are suspicious in any way, such as being from the same IP address.


That's what the Ratings and difficulty in obtaining said ratings are for. Vendors will buy back junk bonds or be forced to lose their coveted rating. It won't be easy to start up a new one.



 
Is a cryptobond really a "bearer bond?" I severely doubt that because FINCen won't call Bitcoin a Currency. Even if so, a Sting-as-Vendor is a very-reduced likelyhood due to vendor rankings. Ordering from high-volume vendors can be avoided, as of course will be low-rated vendors.

Sting-as-Customer? 1st of all a vendor would also have to be moving quite a lot of bonds to be worth targeting. (And customers can see vendor's volume from the fiat marketplace) Assuming so, perhaps it would be wise to mention in a splash screen that selling cryptobonds is illegal in a country, to deter them being sold in that country. Surely it wouldn't be illegal in a good 250-300 countries, and therefore the vendor is safe from sting ops. Vendors can also lie about which countries they are in as long as they accept the proper payment types.



There are many. Main ones are:

• Instant up-front fee earned
• another fee collected at redemption
• the chance to trade it for profit on the afterbond market,
• and most importantly the sound financial investment in knowing that the can collect their collateral back when it's MUCH higher than it is now, but during a loss, the most they are ever out is $1 for that bond. (If bitcoin goes to $0.) So the upside potential is huge with small risk... Which will seem even smaller because they know if the whole system crashes, they can walk away without that final redemption, leaving the DEX user holding the loss.

You simply have too little faith in the rankings system, which will be designed to thwart this kind of stuff. There will be a real difficulty involved with getting initial ratings. Public vendors are obviously not going to happen, so the effort will be put on making the ratings and rankings incentivize vendors to be honest.

Here is Luke's latest DEX paper for those with DNS trouble: http://the-iland.net/static/downloads/DEX.pdf

I will look it over for any changes and update my review accordingly.

With all due respect to MarketCoin and DEX I think we really need to combine our efforts.   From what I know of DEX it will not work.

Considering you stated that the largest 'bond' size would be about $1.55 (GBP) and have its own private key,  then that means that someone with $1000 in bonds would have to market/sell 1000 different securities on the exchange.   Just storing the value held in BTC would be 500GB of data.   I would guess you could improve things by offer $5, $10, $20, $50, and $100 bonds but that would just create more markets/instruments and thus increase the buy/sell spread as the market gets thinner.

With respect to MarketCoin, it could be created as a separate currency or its critical features could be provided by BitShares.   I also do not like demurrage as the premise (to prevent hoarding) is not based upon sound austrian economics.   Any currency that 'taxes me to hold it' is a currency I want nothing to do with.   I see your point about only wanting it used for facilitating trade (like ripple XRP) but it could accomplish the same thing without demurrage.  

Note: BitShares will not be a single chain, but a whole family of chains each with their own floating "BitShare" price where each BitShare floats against the other BitShares based upon the demand to trade among the sub-currencies on each chain.

I still think MarketCoin suffers from the need for interactive trades where all users are 'online' and that it does not allow a buyer of 1000 BTC to be matched against 20 sellers at different prices in one ATOMIC trade.  

So I propose we develop a team, where  XertroV focuses on cross-chain integration between BitShares and Bitcoin and I focus on the BitShare network and Luke can help wherever he feels he can contribute.   I highly recommend that you all don't attempt to develop your own chain 'just because' unless you are convinced that it can address something BitShare's cannot.      

 
  

The domain name isn't resolving, so I will base my comments upon a couple day old draft: http://the-iland.net/static/downloads/DraftDEX.pdf   

If anything has changed since we last talked, then my apologies in advance.

"Note: Like the matching engine, the escrow engine cannot be used on any orders as either the buyer nor seller on the same client."

This is an assumption that cannot be enforced because anyone could modify the clients source code *or* run two clients on two different computers and control them both.  To the extent that this is a requirement of a functioning system the system will not work.

If you can buy cyrpto-bonds from different people and then trade them all as if they were equal, then I would buy the junkiest bonds I could find and then trade them on the exchange to acquire less-junky bonds and then profit from the spread.   If the bonds are not fungible then the market would be fragmented.

Because the bonds do not post margin greater than the initial value of the bond, any price volatility in the wrong direction would immediately compromise the value of the bond as some percentage of the bond would be unsecured and thus 'a junk bond'.    Junk bonds have higher risk of default.    If users can trade bonds at values other than par then you will create a million fragmented markets where the ultimate value of the bonds will approach the value of the Bitcoin backing it.    If you don't allow trading of bonds within your system, it will occur outside of your system, mean while inside your system people will be taking advantage of the price fixing until the whole system falls apart. 

Lastly, issuing bearer bonds is 'illegal' and in order to redeem the bonds for actual fiat would require you give up your anonymity as the issuer.   Thus you would have tremendous risk from public operation.   

What is the profit motive for someone to issue a crypto-bond?   There is no opportunity cost to maintaing the position and if you sell the bond at a 'premium' then the buyer takes an immediate loss and there is no longer any incentive for this individual to redeem his bonds.    The network wouldn't be able to detect the fraud until he failed to redeem the bond at which point it is too late, the fraudster has already profited from the sale even if he never sees his bitcoin again.   He can then create a new client ID and start all over.     The only way to prevent this kind of fraud is if the issuers are PUBLIC and not anonymous.  If they are public then they are in violation of the law and easily shutdown if they operate in any significant volume what-so-ever.   If they do not operate in volume, then they will have 0 trust and thus the value of their bonds will always and forever equal the value of the collateral.   In effect, the bonds simply become Bitcoins.

If you attempt to fix these problems by simply requiring additional margin, you still will not have answered the following questions: 

1) Where is the profit motive to issue the bond?  To go short USD vs BTC.  If this is the case, then it is a head-I-win, tails-you-lose kind of bet.
2) What happens if the price changes more than the margin?
3) All bonds will vary in price proportional to the margin backing them and thus approach the value of the bitcoin backing, why should they have any other value?

I hope this feedback helps.

The domain name does not appear to resolve.  If you send me the .pdf I can host it for you while you wait for it to resolve. 

With respect to Dividend Calculation I would maintain a table which includes 'total dividends per share' based upon coinage going back 1 year.   Everyone would have to 'prove ownership' of an address once per year or lose 5% of their balance as the chain rolls the output forward.  This will prevent lost keys from accumulating dividends and prevent the network from storing worthless data for ever (outputs of lost keys).

The result would be 100K blocks per year * 8 bytes or about 800K lookup table per currency to calculate dividend based upon coinage.  Once very 10 minutes I would have to update the entire table.  Easy, Fast.

Dividends are then calculated and applied ONLY when the output is spent.  This prevents 'dust' dividends and minimizes rounding errors.

With 64 different currencies per chain that would be a little over 50MB dedicated to managing the dividend calculation.

Bitcoin is currently adding 1M new (net) unspent transactions per month.   12M per year at current transaction volume.   BitShares will probably be more efficient than BitCoin and generate fewer unspent-transaction for equal volume because there would be financial incentive (reduced fees) to combine inputs into fewer outputs and thus eliminate dust.    So lets assume that there would only be 4M year at the same transaction volume as Bitcoin.  Heavy trade volume does not affect this as each trade consumes 2 inputs and generates 2 outputs.   The trades and transactions do not need to be stored for more than a couple of days. 

The size of a basic 'transfer output' would be about 40 bytes and therefore to support the same number of 'users' as bitcoin would only require a database of less than 200MB assuming they were just performing transfers.

Bids, Asks, and Escrow transactions would require a more complex 'spend script' for the output and would probably require about 256 bytes (max) per output.  These transactions would occur far more frequently, but I doubt most users would end up with more than a couple of bids at different prices per currency.   Assuming 1 million users each with 1 bid per currency you would end up with about 1 GB of bids/asks at any given point in time.  I suspect most users will not be that active.  Therefore, that would be about 1M active traders which would imply a greater economy using crypto-currencies with 50M or more users.    By the time the data requirements for bitshares approaches those of Bitcoin today, BitShares would probably be several orders of magnitude larger. 

It is done.

Whitepaper for DEX Distributed Exchange (.pdf format, 22 pages)


May the games begin.

I'll be referring to Marketcoin throughout this as many issues are very similar.


Current plan is for Marketcoin to have demurrage to help liquidity. This isn't too much of an issue because, like Bitcoin, it does not work against the purpose; to move value between currencies. It does, in fact incentivise this.

Demurrage can be calculated formulaically; if you made the dividends only come from the mining generation you could get around needing to lookup all transaction fees and calculate what is owed. On the other hand, keeping a list of transaction fees paid in every block wouldn't be that difficult; my understanding is the Bitcoin client keeps some of these types of details in memory already (one entry per block style lists). You could also use some clever 'something' that was able to be used to calculate aggregate fees over a period of time. Not sure accumulators would be of use here, such as are proposed with merged mining.


Marketcoin avoids this by only supporting currency markets where one currency is Marketcoin. Nice and linear. Anything possible here in that regard? Have BitShares themselves play this role?


What's your calculation for this?

that's 50 bytes each block per dividend transaction? Even with a few thousand dividends you'd be using 100kb per block; which is a lot, granted.

Since 17th July 2010 there have been 5,300,000 trades on mtgoxUSD/BTC.
There have been 19 million transactions on the Bitcoin Network, and 242000 blocks.
242,000 * 100kb = 24 GB.

Fair enough, I can see your point here, won't even both using the other stuff.

Does the finite blockchain size idea help here? I mean you'd still need a bunch of those outputs but if they can somehow be rolled up as time passes it might make them easier to deal with.

What about dividends once a day, ever 144th block, or something?


That's really messy; I would think using them like TX fees would be nicer; allow someone to spend more than the outputs they list and dividends are calculated at verify-time. All you need is the last time the address was used and the numbers of the blocks between and a lookup table to the fees; then you can calculate the dividend easily I would think.


You could always just let Marketcoin do that for you... it will anyway if BitShares takes off.


Perhaps leverage Marketcoin or a fork of it to 'build in' interoperability between chains; chains which can fork to parallelise (as you'll only need the chains you're interested in) but do things like separating groups of markets later down the line, some on this chain, some on that chain. This can help control the overall size. You might also be able to link in finite blockchains to end up with little parallel blockchain worms crawling through time. But they can talk to each other. Almost like running SPV in the other chains and full in your chain. That would be enough. Merged mining them would be interesting, but with the accumulator thing you're aware of it might be feasible.

I'm going to try and walk through the alg below, but before that, what happens when a bunch of information is published (by say a rogue miner working in secret) which pushes someone past an acceptable margin position, and data continues to flow in making the situation worse? Is this possible?

Ignoring the possibility of a position requiring liquidation, is this how your alg works?

Each element is volume@price (chosen pretty much randomly)
Bids = [1@100, 3@99, 10@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99, 3@98, 2@97]

Step No.	Action
1	Highest Bid = 1@100, Lowest Ask = 2@97
1.1	As 100 >= 97, trade procedes
1.2	Average: 98.5; 1 unit traded at 98.5
2	Highest Bid = 3@99, Lowest Ask = 1@97 (remainder from prev trade)
2.1	99 >= 97, check; average is 98, 1 unit traded at 98.
3	Highest Bid = 2@99, Lowest Ask = 3@98
3.1	99 >= 98; average 98.5, 2 units traded at 98.5
4	Highest Bid = 10@98, Lowest Ask = 1@98
4.1	98 >= 98; average 98, 1 unit traded at 98
5	Highest Bid = 1@98, Lowest Ask = 2@99
5.1	98 < 99; NO TRADE

At the end the order-book-thing stands at:
Bids = [9@98, 1@97, 1@96]
Asks = [3@101, 20@100, 2@99]

Total trades: 4, volume: 5

Edit: as an aside, the pattern I've worked through above is what is used in Marketcoin (currently)

Are there any developers on this thread that are interested in helping develop BitShares?   If so, please contact me to discuss how you can be involved.

It was brought to my attention that I didn't detail the deterministic trading algorithm:

Given the set of all unspent outputs as UnspentOut
Given a currency pair, say crypto-USD / BitShares.
Given the same pair, find all crypto-USD issuance (short positions) and sort by margin.

Find all bids and asks and sort them.

While the HighBid >= LowAsk
    Average the HighBid and LowAsk to calculate the current Price
    if the price > margin threshold of lowest margin position
       match bid against margin call at Price
       push any left-over short position or bid to the stack
    else
       match the bid and ask at price
       push any left-over bid or ask to the stack.


The result of the above loop will be a single transaction of the following form:

1) all referenced bids, asks, and margin calls as inputs
2) the net result of all trades and margin calls as outputs.
         * note a bid may be paritial matched against 100 different asks and there
           would only be a single input from that bid and a single output of any
           change.  All of the intermediate steps would not enter the blockchain.

I wanted to clarify some things:

1) crypto-USD is not a separate blockchain, but is a separate 'unit' used on the same blockchain as BitShares.

2) Market Dynamics for mining will be interesting, and I think the result is that it will motivate people to start mining sooner.  After all, as the money supply increases the rate of return falls.   Miners who mine in the first year will end up seeing 100% dividend payments over the course of one year *if* they hold on to their bitshares after mining.   As a result, you want to mine as early and often as possible and hold on to the shares as long as possible.   This should cause the 'demand' for holding bitshares to be higher than the demand for holding bitcoins.  If you factor in time-value of money then the value of mining will probably be MORE than bitcoin even though the immediate payout is less.

I read through it, looked interesting. I like the atomic exchange directly between blockchains. I would break it down into smaller components which are modularly expandable. I'd heard the term "Atomic", didn't know what it was until a few days ago, turns out it is exactly the capability I want to see in a p2p exchange client. I'm more interested in direct exchange, even if it isn't as fast as a trading exchange on a server.

The market dynamics will be interesting with the miners losing 50% of the incentive to mine to the dividends, but the market price may be higher due the dividends, so it may be a break even or even more profitable to mine.

I very much like the tying of mining capacity to RAM to discourage GPUs and ASICs. I'd rather see mining distributed even into mobile devices and Freedombox type mesh networking gateways.

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.

Where did everyone go?  Any feedback on the white paper?

Updated White Paper on BitShares:  http://the-iland.net/static/downloads/BitSharesWhitePaper.pdf 

double-spending is not a 'global' attack on the network and could occur with less than 51% depending upon how many confirmations you require. 

The only people motivated enough to attempt a 51% attack are those who want to DOS the network.   

Define 'good' chains... all chains must follow the 'rules' so they are all equally good... but the chain that pays the highest dividends is 'best' provided it also has the requisite difficulty *and* didn't leave any potential dividends on the table.   

Denying valid transactions is just one attack vector. You can't prevent a double-spend that way, as the attacker would double-spend in forked chains that also include all other transactions.


Depending on the details, there may be further attack vectors that involve making nodes reject good chains.