[Announce] Project Quixote - BitShares, BitNames and 'BitMessage'

[domob]

You (domob) definitely have the right approach. ... There is no one trained (or even vaguely familiar with) in mathematics-based economics on their staff. In fact they disavow constructs such as game theory as invalid by some anti-math axiom.

While this sounds very flattering to me, I have to admit that I also don't think this is fair judgement.  I don't know about their staff, but you also don't really know about myself.  I don't think I really have the expertise in economics / design of "mechanisms" you mention to be better situated in designing a project like that.  I'm just used to mathematical thinking and would like a bit more rigour in the description in order to understand and "believe in" the ideas behind BitAssets.

And I'm also aware that of course it all depends on how "BitUSD" is perceived by the market participants - after all, it doesn't matter whether or not it is called "BitUSD" or "BitBananas" or whatever.  (But to be fair, bytemaster already mentioned this some time ago and is seemingly well aware of that fact.  His argument was that, since people want/need a P2P exchange, it is to everyone's advantage to agree upon BitUSD tracking USD and thus this will happen.  (Please correct me if I'm misrepresenting you, that is how I remember it.)  Not sure about this, but I'm not the person to judge whether or not such thinking is ok.)

However even if we leave this point away for now, I just did a very simplistic calculation I want to present here:  Assume that 1 Bitshare (BS) is worth ps USD (as mentioned above it doesn't matter whether we use USD here or any other unit of "value" someone interested in investing is holding) and that 1 BitUSD (BU) is worth pu USD at the moment.  We have Ms BS in total and Mu BU created (how that works is not important for me now).  C BS are held of the Ms in collateral for the Mu BU.  D is the total amount of dividends paid for all BS in some time interval.

This means that 1 BS pays D/Ms dividends in this interval, and 1 BU pays D/Ms C/Mu, also in BS.  If I'm now an investor holding x USD and looking for a return, I can consider the two choices to invest in BS or in BU:

1) Investing in BS: I can buy x/ps BS, which pay x/ps D/Ms BS dividends.  My return in USD is thus this times ps, which is x D/Ms per time interval.

2) Investing in BU: I can buy x/pu BU, which pay x/pu D/Ms C/Mu BS dividends.  My return in USD is thus x ps/pu D/Ms C/Mu per time interval.

Comparing both, it is clear that the crucial question for me is whether the expression ps/pu C/Mu, which is the "difference" between both possible returns, is larger than 1 (in which case I should invest in BU) or smaller than 1 (in which case I should buy BS).  If it is the former and I buy BU accordingly, this decreases the price ratio ps/pu and makes the expression smaller.  If it is the latter and I buy BS, it increases the expression.  Thus at least from this very simplistic analysis, it follows that this system should converge to an "asymptotically stable equilibrium" where

pu / ps = C / Mu.

This makes sense because it means that the relative price of BU in BS should equal the quotient of the total amount of collateral in BS backing the all BUs to their monetary base.  However, I wonder how this result fits to the premise that collateral must be 1.5 times the amount of BU created ... wouldn't that imply that no-one ever has an incentive to create BU because he/she always gets less dividends back?  The only reason for why I could want to issue BU is that I imagine that the market price of BU relative to BS will rise, so that I can make money not from dividends (which I miss out on) but rather speculation.

Let's consider this.  Assume that C/Mu = 1.5 pr, where pr is some mean average relative price at the times when BU were issued against BS collateral.  If now others join the game, they will follow the same decision process as above, and if no fresh BU are issued and only BS or BU bought on the market, this will lead again to the equilibrium of

pu / ps = C / Mu = 1.5 pr.

Thus it is indeed expected that the price of BU in BS rises to 1.5 times the price at which BU were issued.  Because this means that the price rises which each issuance of BU, it should be fair to assume that pr as average price over all past BU issuances is less than the price at which I was able to issue BU if this is the current market rate (not sure about how this is done in the current BitAssets proposal though).  Thus the anticipated price rise is less than what I need to get even with the dividends, so it makes no sense for me to issue BU except if I speculate on others also doing this after me ... which feels like a Ponzi scheme.

As stated I have no training in economics, so please forgive me if my interpretation is wrong.  But it seems to me as if it would not matter at all whether I invest in BU or BS (assuming the market reached equilibrium already), and that issuing BU is a loss for me if not others also do it after me.  This is the dynamics by itself without considering that people might "want" BU to track USD (pu = 1), but it seems like an odd system to me (particularly because of the 1.5 factor in the collateral requirement).  Please also note that the forum is not very well suited to typing formula (although they are quite simple), so if it helps in reading I could also typeset this calculation again in LaTeX.  And finally, please excuse if I made any typos in the formulas or similar ... I just wanted to contribute my quick calculation but haven't done thorough review.

Thoughts anyone?

[td services]

Do you have a planned date when mining will start? I thought it also was this fall, maybe I misread something.

Also, will the mining code be available to test mining prior to the actual start?

Finally, how do the current investors plan on earning a return on their investment in Bitshares?

Thought I'd ask again since I think the questions got lost in all the economics discussion. This has a large impact on my mining approach and timing.

We have a method to our madness, but that is our trade secret.   As for timing code availability, we are considering a competition on the algorithm so the final candidate is not known at this time.

OK, can you at least say whether or not the planned return on investment involves mining. If it is from just selling mobile apps or other interfaces and services, it doesn't affect my plans, but if it involves deploying preconfigured and optimized mass CPU power to mine at the very start then it would have a large impact.

Again, thought I'd ask again since the question probably got lost in all the technical discussion. Thanks.

[bytemaster]

Do you have a planned date when mining will start? I thought it also was this fall, maybe I misread something.

Also, will the mining code be available to test mining prior to the actual start?

Finally, how do the current investors plan on earning a return on their investment in Bitshares?

Thought I'd ask again since I think the questions got lost in all the economics discussion. This has a large impact on my mining approach and timing.

We have a method to our madness, but that is our trade secret.   As for timing code availability, we are considering a competition on the algorithm so the final candidate is not known at this time.

OK, can you at least say whether or not the planned return on investment involves mining. If it is from just selling mobile apps or other interfaces and services, it doesn't affect my plans, but if it involves deploying preconfigured and optimized mass CPU power to mine at the very start then it would have a large impact.

Again, thought I'd ask again since the question probably got lost in all the technical discussion. Thanks.

Yes, we will be mining like everyone else, we would be crazy not to.    Though with the current popularity and people like you out there ready to jump in on day one, it will be a challenge for us to acquire significant numbers of bitshares through mining. 

[bytemaster]

Thoughts anyone?

My thoughts are that your math is very hard to follow. 

The carrying cost of shorting BitUSD is the dividend rate on the collateral.
The benefit of holding BitUSD is  1.5 to 2.5 x the dividends per unit value.
Thus, it is only wise to short BitUSD if the expected rise in the price of BitShares is greater than 1.5 to 2.5x the dividend rate. 

Assuming a stable exchange rate (or growth rate below the dividend rate), it is wise to sell (not short) BitShares for BitUSD because you would get 2x the rate of return.

This creates buying pressure for BitUSD that will bid the price of BitUSD UP and push BitShares DOWN  until an equilibrium is reached where no one is willing to switch from BitShares to BitUSD because it is 'over-priced' and the risk of a correction outweighs the 2x return.     As the price rises, it will also increase selling pressure from shorts which will tend to increase the supply as needed to keep prices near equilibrium.

If BitUSD is extremely under priced, it makes sense for shorts to cover and for holders of BitShares to buy, wait for the correction, and sell. 

Now how does one know whether BitUSD is over or under priced relative to BitShares?   It doesn't really matter because anyone can look at the market and look at the ratio of BitUSD to BitGold vs USD to Gold and do ratio trading with the value of BitShares being irrelevant.   If a large number of speculators adopt the ratio trading strategy then I believe it is self-evident that the value of BitUSD will track USD because the entire network would have to be off by a 'constant' factor and thus gains and losses in BitUSD would be proportional to change in the price of BitUSD.

[AnonyMint]

Yes, we will be mining like everyone else, we would be crazy not to.    Though with the current popularity and people like you out there ready to jump in on day one, it will be a challenge for us to acquire significant numbers of bitshares through mining.  

I am conflicted on premining. I don't believe in socialism. Opensource doesn't mean you can't reward yourself for the investment you put in.

What you need is to incentivize people to work with you early on to help you. So they should participate in the premine. During the premine, you can agree to reset, if there is some serious problem of unfairness that had to be fixed.

Flipping a switch from no real world test to the entire community, seems a bit abrupt.

Thoughts from others?

I am very curious how people feel about this, because it affects how I might launch a coin and/or contribute to this effort.

I believe the only entities that should premine are the programmers who are contributing. First of all, they did most of the word. Second, they know the issues well if there is a bug, so the process can be most efficient and of short duration.

One problem then is their coins aren't anonymous, unless they were anonymous from the beginning, which isn't the case here.

A benefit is then the developers have an additional strong incentive to continue to maintain the project.

[domob]

Thoughts anyone?

My thoughts are that your math is very hard to follow. 

The carrying cost of shorting BitUSD is the dividend rate on the collateral.
The benefit of holding BitUSD is  1.5 to 2.5 x the dividends per unit value.
Thus, it is only wise to short BitUSD if the expected rise in the price of BitShares is greater than 1.5 to 2.5x the dividend rate. 

Assuming a stable exchange rate (or growth rate below the dividend rate), it is wise to sell (not short) BitShares for BitUSD because you would get 2x the rate of return.

This creates buying pressure for BitUSD that will bid the price of BitUSD UP and push BitShares DOWN  until an equilibrium is reached where no one is willing to switch from BitShares to BitUSD because it is 'over-priced' and the risk of a correction outweighs the 2x return.     As the price rises, it will also increase selling pressure from shorts which will tend to increase the supply as needed to keep prices near equilibrium.

Yes, that's basically also the outcome of my calculation (which I find not really complicated ... if you have specific questions and I did not point things out clearly let me know).  But at least I as mathematician find it much more convincing to have a calculation like that instead of just "arguments in words" as you did above (but maybe the calculation is not so easy to understand for people who don't think that way, I don't know).

What my fundamental question with that is then:  To me as non-economist it seems like a very weird situation to have such a strong incentive to buy BitUSD for BitShares and have consequently rather the expectation that the price rises over time ... also from my calculation it follows that the price of BitUSD will increase to 1.5 the average price at which it was issued.  Thus whenever someone issues BitUSD at the current market rate (which is higher than the average issuance price before), it raises this average price which leads to further increase in the market rate.  On the other hand, this means that I'm encouraged to issue BitUSD as long as I believe someone else will do that after me again - which somehow means that people will issue BitUSD until they (or "the market") thinks that the amount of BitUSD issued so far is "correct".  Maybe this leads to exactly the correct structure (decentralised control over the BitUSD supply), but it gives me a weird gut feeling as mentioned already.  (I feel like this could easily lead to bubbles, because everyone profits who's not the last to issue BitUSD - like a Ponzi scheme.)

[td services]

Yes, we will be mining like everyone else, we would be crazy not to.    Though with the current popularity and people like you out there ready to jump in on day one, it will be a challenge for us to acquire significant numbers of bitshares through mining. 

I am conflicted on premining. I don't believe in socialism. Opensource doesn't mean you can't reward yourself for the investment you put in.

What you need is to incentivize people to work with you early on to help you. So they should participate in the premine. During the premine, you can agree to reset, if there is some serious problem of unfairness that had to be fixed.

Flipping a switch from no real world test to the entire community, seems a bit abrupt.

Thoughts from others?

I am very curious how people feel about this, because it affects how I might launch a coin and/or contribute to this effort.

I believe the only entities that should premine are the programmers who are contributing. First of all, they did most of the word. Second, they know the issues well if there is a bug, so the process can be most efficient and of short duration.

One problem then is their coins aren't anonymous, unless they were anonymous from the beginning, which isn't the case here.

A benefit is then the developers have an additional strong incentive to continue to maintain the project.

I didn't see it as an issue, but there has been a very negative reaction to Ripple due to premining (though in this case it was 100% premined). The advantage of not premining is there is more interest in it when it launches. An advantage of premining is it is a way to incentivize as mentioned.

My personal preference would be no premine since I'm not a programmer but am very familiar with hardware and building systems. If there is premine, it would be important that it be disclosed as to the amount so those who can't can plan accordingly and decide whether or not it is worth participating. Lack of communication and secretiveness seems to often lead to suspicion and loss of interest in a project, whether justified or not.

[AnonyMint]

However even if we leave this point away for now, I just did a very simplistic calculation I want to present here:  Assume that 1 Bitshare (BS) is worth ps USD (as mentioned above it doesn't matter whether we use USD here or any other unit of "value" someone interested in investing is holding) and that 1 BitUSD (BU) is worth pu USD at the moment.  We have Ms BS in total and Mu BU created (how that works is not important for me now).  C BS are held of the Ms in collateral for the Mu BU.  D is the total amount of dividends paid for all BS in some time interval.

This means that 1 BS pays D/Ms dividends in this interval, and 1 BU pays D/Ms C/Mu, also in BS.  If I'm now an investor holding x USD and looking for a return, I can consider the two choices to invest in BS or in BU:

1) Investing in BS: I can buy x/ps BS, which pay x/ps D/Ms BS dividends.  My return in USD is thus this times ps, which is x D/Ms per time interval.

2) Investing in BU: I can buy x/pu BU, which pay x/pu D/Ms C/Mu BS dividends.  My return in USD is thus x ps/pu D/Ms C/Mu per time interval.

Comparing both, it is clear that the crucial question for me is whether the expression ps/pu C/Mu, which is the "difference" between both possible returns, is larger than 1 (in which case I should invest in BU) or smaller than 1 (in which case I should buy BS).  If it is the former and I buy BU accordingly, this decreases the price ratio ps/pu and makes the expression smaller.  If it is the latter and I buy BS, it increases the expression.  Thus at least from this very simplistic analysis, it follows that this system should converge to an "asymptotically stable equilibrium" where

pu / ps = C / Mu.

This makes sense because it means that the relative price of BU in BS should equal the quotient of the total amount of collateral in BS backing the all BUs to their monetary base.  However, I wonder how this result fits to the premise that collateral must be 1.5 times the amount of BU created ... wouldn't that imply that no-one ever has an incentive to create BU because he/she always gets less dividends back?

My understanding is the short puts up 1/2 the collateral and the long puts up the other half.

Who earns the dividends, the long or the short?

The only reason for why I could want to issue BU is that I imagine that the market price of BU relative to BS will rise, so that I can make money not from dividends (which I miss out on) but rather speculation.

Yeah that is the problem with your astute model on dividend ROI, it only considers the ROI of the dividends, and not the expectation of the relative moves of ps vs. pu.

And you are only considering one-side (actually as far as I can see you conflated long and short together) of the trade.

Assuming the holding period is very short such that the relative ps / pu secular trends are not a factor (day trading is a 50/50% fair coin, i.e. no secular price trend asymmetry), and assuming the holding periods and other factors are symmetrical between long and short, such that the distribution of possibilities w.r.t. to return on ps / pu are symmetrical, then I think you can use a dividend only analysis.

My key point since upthread, is that if the probabilities are not balanced, then since the options don't have the threat of delivery, then the expectations of price could drift perniciously in the direction of the asymmetry. Now someone needs to model all the factors correctly.

[AnonyMint]

Yes, we will be mining like everyone else, we would be crazy not to.    Though with the current popularity and people like you out there ready to jump in on day one, it will be a challenge for us to acquire significant numbers of bitshares through mining. 

I am conflicted on premining. I don't believe in socialism. Opensource doesn't mean you can't reward yourself for the investment you put in.

What you need is to incentivize people to work with you early on to help you. So they should participate in the premine. During the premine, you can agree to reset, if there is some serious problem of unfairness that had to be fixed.

Flipping a switch from no real world test to the entire community, seems a bit abrupt.

Thoughts from others?

I am very curious how people feel about this, because it affects how I might launch a coin and/or contribute to this effort.

I believe the only entities that should premine are the programmers who are contributing. First of all, they did most of the word. Second, they know the issues well if there is a bug, so the process can be most efficient and of short duration.

One problem then is their coins aren't anonymous, unless they were anonymous from the beginning, which isn't the case here.

A benefit is then the developers have an additional strong incentive to continue to maintain the project.

I didn't see it as an issue, but there has been a very negative reaction to Ripple due to premining (though in this case it was 100% premined). The advantage of not premining is there is more interest in it when it launches. An advantage of premining is it is a way to incentivize as mentioned.

My personal preference would be no premine since I'm not a programmer but am very familiar with hardware and building systems. If there is premine, it would be important that it be disclosed as to the amount so those who can't can plan accordingly and decide whether or not it is worth participating. Lack of communication and secretiveness seems to often lead to suspicion and loss of interest in a project, whether justified or not.

I read another thread on this forum about premining, and it seemed like the consensus from the reasonable people was that a premine was okay if it was not excessive nor duplicitous, e.g. SolidCoin. Ripple hasn't released their source code.

Seems to me 1% of the 30 year forward money supply is not excessive for a premine test period?

[domob]

However even if we leave this point away for now, I just did a very simplistic calculation I want to present here:  Assume that 1 Bitshare (BS) is worth ps USD (as mentioned above it doesn't matter whether we use USD here or any other unit of "value" someone interested in investing is holding) and that 1 BitUSD (BU) is worth pu USD at the moment.  We have Ms BS in total and Mu BU created (how that works is not important for me now).  C BS are held of the Ms in collateral for the Mu BU.  D is the total amount of dividends paid for all BS in some time interval.

This means that 1 BS pays D/Ms dividends in this interval, and 1 BU pays D/Ms C/Mu, also in BS.  If I'm now an investor holding x USD and looking for a return, I can consider the two choices to invest in BS or in BU:

1) Investing in BS: I can buy x/ps BS, which pay x/ps D/Ms BS dividends.  My return in USD is thus this times ps, which is x D/Ms per time interval.

2) Investing in BU: I can buy x/pu BU, which pay x/pu D/Ms C/Mu BS dividends.  My return in USD is thus x ps/pu D/Ms C/Mu per time interval.

Comparing both, it is clear that the crucial question for me is whether the expression ps/pu C/Mu, which is the "difference" between both possible returns, is larger than 1 (in which case I should invest in BU) or smaller than 1 (in which case I should buy BS).  If it is the former and I buy BU accordingly, this decreases the price ratio ps/pu and makes the expression smaller.  If it is the latter and I buy BS, it increases the expression.  Thus at least from this very simplistic analysis, it follows that this system should converge to an "asymptotically stable equilibrium" where

pu / ps = C / Mu.

This makes sense because it means that the relative price of BU in BS should equal the quotient of the total amount of collateral in BS backing the all BUs to their monetary base.  However, I wonder how this result fits to the premise that collateral must be 1.5 times the amount of BU created ... wouldn't that imply that no-one ever has an incentive to create BU because he/she always gets less dividends back?

My understanding is the short puts up 1/2 the collateral and the long puts up the other half.

Who earns the dividends, the long or the short?

From how I understood some earlier BitShares proposal, the issuance happens such that a single entity puts up a certain amount of collateral in BitShares and receives a matching amount (market rate / 1.5 or some other factor) of BitUSD freshly "created".  The dividends that would be paid on the BitShares that are now in collateral are then put into the pool of dividends that (all existing, not just the just issued) BitUSD pays proportionally to all holders.

Sorry, I'm not so much into economics - I don't really understand what exactly you mean by your comment about "the short" or "the long" - in the case of issuance as I understand it, there's only one person involved going "short" on BitShares for BitUSD and no-one is going "long" on BitShares until the collateral is redeemed (but in that case, no-one is "short").

[AnonyMint]

However even if we leave this point away for now, I just did a very simplistic calculation I want to present here:  Assume that 1 Bitshare (BS) is worth ps USD (as mentioned above it doesn't matter whether we use USD here or any other unit of "value" someone interested in investing is holding) and that 1 BitUSD (BU) is worth pu USD at the moment.  We have Ms BS in total and Mu BU created (how that works is not important for me now).  C BS are held of the Ms in collateral for the Mu BU.  D is the total amount of dividends paid for all BS in some time interval.

This means that 1 BS pays D/Ms dividends in this interval, and 1 BU pays D/Ms C/Mu, also in BS.  If I'm now an investor holding x USD and looking for a return, I can consider the two choices to invest in BS or in BU:

1) Investing in BS: I can buy x/ps BS, which pay x/ps D/Ms BS dividends.  My return in USD is thus this times ps, which is x D/Ms per time interval.

2) Investing in BU: I can buy x/pu BU, which pay x/pu D/Ms C/Mu BS dividends.  My return in USD is thus x ps/pu D/Ms C/Mu per time interval.

Comparing both, it is clear that the crucial question for me is whether the expression ps/pu C/Mu, which is the "difference" between both possible returns, is larger than 1 (in which case I should invest in BU) or smaller than 1 (in which case I should buy BS).  If it is the former and I buy BU accordingly, this decreases the price ratio ps/pu and makes the expression smaller.  If it is the latter and I buy BS, it increases the expression.  Thus at least from this very simplistic analysis, it follows that this system should converge to an "asymptotically stable equilibrium" where

pu / ps = C / Mu.

This makes sense because it means that the relative price of BU in BS should equal the quotient of the total amount of collateral in BS backing the all BUs to their monetary base.  However, I wonder how this result fits to the premise that collateral must be 1.5 times the amount of BU created ... wouldn't that imply that no-one ever has an incentive to create BU because he/she always gets less dividends back?

My understanding is the short puts up 1/2 the collateral and the long puts up the other half.

Who earns the dividends, the long or the short?

From how I understood some earlier BitShares proposal, the issuance happens such that a single entity puts up a certain amount of collateral in BitShares and receives a matching amount (market rate / 1.5 or some other factor) of BitUSD freshly "created".  The dividends that would be paid on the BitShares that are now in collateral are then put into the pool of dividends that (all existing, not just the just issued) BitUSD pays proportionally to all holders.

My understanding was the short puts up collateral (in units of BS) of pu and the long who is buying the BU pays pu too. Then the BU is backed by 2x pu.

Sorry, I'm not so much into economics - I don't really understand what exactly you mean by your comment about "the short" or "the long" - in the case of issuance as I understand it, there's only one person involved going "short" on BitShares for BitUSD and no-one is going "long" on BitShares until the collateral is redeemed (but in that case, no-one is "short").

The long is the entity buying the BU created by the bid of the long matching to the ask of the short on the open market.

Perhaps bytemaster can can correct me if my understanding is incorrect.

[favdesu]

there are now like 3 active threads running and it's really hard to follow IMO. Could you please open a subreddit dedicated to your services?

[bytemaster]

My understanding was the short puts up collateral (in units of BS) of pu and the long who is buying the BU pays pu too. Then the BU is backed by 2x pu.

This is correct.

As far as your 'short-term day-trading', it should be noted that all dividends earned in the last 24 hours before an output is consumed go to fees.  Thus on a 'short term' basis, dividends play no role in the economic calculation.   The reason for this is that 'dividends' are not final until the block has enough confirmations that the mining reward may be spent (in bitcoin this is 100 blocks).   It also causes all of the 'rounding, sub-satoshi' dust to accumulate in the mining reward before being applied. 

[bytemaster]

there are now like 3 active threads running and it's really hard to follow IMO. Could you please open a subreddit dedicated to your services?

This thread is being purposed to BitAssets, one to Bit ID, and one to BitDNS and they are each different enough that different people have different interests.  It is a challenge for me as well, but I think it would be more confusing to have such varied topics in a single thread.

[bytemaster]

From how I understood some earlier BitShares proposal, the issuance happens such that a single entity puts up a certain amount of collateral in BitShares and receives a matching amount (market rate / 1.5 or some other factor) of BitUSD freshly "created".  The dividends that would be paid on the BitShares that are now in collateral are then put into the pool of dividends that (all existing, not just the just issued) BitUSD pays proportionally to all holders.

Before continuing in this thread, you should read the latest white paper.  Ideas from my early design were entirely overthrown and you will only add confusion to this thread by mixing my VERY EARLY (May) design with my June 2+ design.

[bytemaster]

Regarding pre-mining, my original plan (Pre-VC money) was to pre-mine 5% and pay it to those who funded the project.    I received about $15,000 on that model when Charles found the VC funding.  A condition on the VC funding was no premining.

So, I consider a reasonable pre-mine to be around 5% or less.   It is really a balance between rate of adoption (and thus value of the coin), percent ownership, and the potential for someone to simply modify the open source code to remove the pre-mine and launch an 'alt-coin'.   

At least by avoiding pre-mining we can legally claim we are not 'issuers' of a currency.

Based upon the response and interest we I have received, I expect there to be several thousand people mining at launch and probably even more computers.  It will be a new-fashioned gold rush.

[nomailing]

Here is another suggestion for improvement:

In the white paper you propose:

Unfortunately, merged mining requires a Merkle tree as the proof-of-work (POW) and thus takes more space in the block headers that must be stored for a year or more.

...

Thus you can calculate your mining reward as  block-reward / 2^(merkel-branch-depth). The end result is that if Red and Blue BitShares have equal market value and difficulty then merged mining is equally as profitable single mining.

You do not have to include the full merkel-tree in your block header, but just some nodes of the tree. If you have a merkle tree with depth N, then it is enough to include only N hashes in each individual blockchain, but at the same time you can merge mine in parallel in 2^N chains. So i hope you realize that the problem of space in the block headers, what you describe, is not really such a big problem.
*EDIT: see https://en.bitcoin.it/wiki/Merged_mining_specification for more in depth explanation

So if you discount the block reward by block-reward / 2^(merkel-branch-depth), as you suggest in the white paper, then you give incentives to miners to not do merge mining, because it wouldn't generate more reward but would require more bandwidth and storage. This is a very serious security issue, because this will lead to maybe 1000+ chains eventually (as proposed in your paper) with miners distributed across all chains not merge mining. In this distributed mining environment, it is very easy for an attacker with less than 1% of the total hashing power to control over 50% of the hashing power in one of the individual chains.

So you really should either remove the discounting based on the merkel-tree-branch or at least do the discounting proportional to the space requirements by merged mining. So instead the reward could be:
block-reward / merkel-branch-depth

Edit: i.e. if you do merge mining on 4000 chains, then you just have to include 12 hashes in the block headers. This is really not so much space, if you evaluate the benefit of much improved security and the benefit of more miners running full nodes in all chains if their bandwidth allows it.

@bytemaster
You still haven't replied, so I guess you overlooked my post?
Do you agree to my point? Or do you have a fundamentally different understanding of how a multi-chain system should be secured by mining? My point is, that merge mining does not only increase the reward of the miners, but it is actually very important for the security of all chains. Without merge-mining, all chains are insecure because chain-hopping of mining resources will make it easy for an attacker to gain 50% in individual chains.
Or do you think that my reasoning is flawed? Then why?

[bytemaster]

Here is another suggestion for improvement:

In the white paper you propose:

Unfortunately, merged mining requires a Merkle tree as the proof-of-work (POW) and thus takes more space in the block headers that must be stored for a year or more.

...

Thus you can calculate your mining reward as  block-reward / 2^(merkel-branch-depth). The end result is that if Red and Blue BitShares have equal market value and difficulty then merged mining is equally as profitable single mining.

You do not have to include the full merkel-tree in your block header, but just some nodes of the tree. If you have a merkle tree with depth N, then it is enough to include only N hashes in each individual blockchain, but at the same time you can merge mine in parallel in 2^N chains. So i hope you realize that the problem of space in the block headers, what you describe, is not really such a big problem.
*EDIT: see https://en.bitcoin.it/wiki/Merged_mining_specification for more in depth explanation

So if you discount the block reward by block-reward / 2^(merkel-branch-depth), as you suggest in the white paper, then you give incentives to miners to not do merge mining, because it wouldn't generate more reward but would require more bandwidth and storage. This is a very serious security issue, because this will lead to maybe 1000+ chains eventually (as proposed in your paper) with miners distributed across all chains not merge mining. In this distributed mining environment, it is very easy for an attacker with less than 1% of the total hashing power to control over 50% of the hashing power in one of the individual chains.

So you really should either remove the discounting based on the merkel-tree-branch or at least do the discounting proportional to the space requirements by merged mining. So instead the reward could be:
block-reward / merkel-branch-depth

Edit: i.e. if you do merge mining on 4000 chains, then you just have to include 12 hashes in the block headers. This is really not so much space, if you evaluate the benefit of much improved security and the benefit of more miners running full nodes in all chains if their bandwidth allows it.

@bytemaster
You still haven't replied, so I guess you overlooked my post?
Do you agree to my point? Or do you have a fundamentally different understanding of how a multi-chain system should be secured by mining? My point is, that merge mining does not only increase the reward of the miners, but it is actually very important for the security of all chains. Without merge-mining, all chains are insecure because chain-hopping of mining resources will make it easy for an attacker to gain 50% in individual chains.
Or do you think that my reasoning is flawed? Then why?

I have been meaning to get back to this topic.   I put a lot of thought into it.   Allowing users to merge mine with 0 extra cost opens up potential attack vectors where a 'legitimate block' and an 'attack block' are mined at the same time with no additional cost to the creator.   In fact, it allows people to subsidize their creation of alternate histories.   So allowing it to be 'free' is not wise.  

Assuming all chains are of 'equal' value, then my algorithm if discounting the mining reward proportional to the tree depth^2 would result in equal payout for mining vs merged mining.   This assumes that all chains follow the same rule.

What is the goal of merged mining?   In my view it is to share one set of hash power across the entire network.  With the depth^2 discount, hash power is shared but profits are identical assuming the two chains have equal value.  

If one chain has more value than the other (different dividend payouts, different reward rates, different markets)  then merged mining is a calculated / speculative risk.  You divide your hash power evenly between them, but your immediate payout will be the average value of the two chains rather than the sum of the value of the two chains.   Both chains still benefit from added security.  

New chains do not have to follow the same rules, and to drive adoption may allow 100% reward even with merged mining until the difficulty reaches some threshold.  This would change the economic calculation on merged mining yet again such that as long as the alt-coin had at least 50% of the value of the 'main-coin' then it is more profitable to merge-mine.  

[bytemaster]

Regarding the secure messaging feature, be aware of:

Signcryption

Digital Signcryption or How to Achieve
Cost(Signature & Encryption) <<
Cost(Signature) + Cost(Encryption)

Claims to eliminate the need to sign and encrypt in separate steps as PGP does. I didn't read it yet, just passing it along.

Signcryption, a kind of public key cryptosystem,
succeeds in simultaneously encrypting the message
while digitally signing. Compared with the traditional
systems like PGP that executes signing and encrypting
a message in sequential procedures, such a
characteristic makes signcryption system securer and
more efficient. To be specific, the efficiency of
performance based on the signcryption system can be
enhanced atout 50% to 90% than the traditional ones

Secure messaging system works as follows, if it can be modified to utilize the above that would be great.

Lookup User's pubic key with BitID  =>  RecvPublicKey

Generate a one-time PrivateKey  => SenderOneTimePrivKey and  SenderOneTimePublicKey

Calculate a ECDH shared secret...    SenderOneTimePrivKey * RecvKey  => Shared Secret.

Create your message  TXT
SIG = SendPrivKey.sign( SHA256(TXT) )

AES_ENCRYPT( SharedSecret,   (TXT + SIG) )  => EncryptedMessage

CHECK = RIPEMD160( Shared Secret + EncryptedMessage)

Broadcast:  SenderOneTimePublicKey + CHECK + EncryptedMessage

The receiver will then test each of their private keys like so:

RecvPrivateKey * SenderOneTimePublicKey => Recv Shared Secret
TEST(RIPEMD160(Recv SharedSecret+EncryptedMessage) == CHECK)
AES_DECRYPT( Recv Shared Secret, EncryptedMessage )  =>  TXT + SIG

Recover SenderPublicKey via  SHA256(TXT) and SIG

Note:  this algorithm has not yet been audited so any feedback is appreciated.

[nomailing]

Here is another suggestion for improvement:

In the white paper you propose:

Unfortunately, merged mining requires a Merkle tree as the proof-of-work (POW) and thus takes more space in the block headers that must be stored for a year or more.

...

Thus you can calculate your mining reward as  block-reward / 2^(merkel-branch-depth). The end result is that if Red and Blue BitShares have equal market value and difficulty then merged mining is equally as profitable single mining.

You do not have to include the full merkel-tree in your block header, but just some nodes of the tree. If you have a merkle tree with depth N, then it is enough to include only N hashes in each individual blockchain, but at the same time you can merge mine in parallel in 2^N chains. So i hope you realize that the problem of space in the block headers, what you describe, is not really such a big problem.
*EDIT: see https://en.bitcoin.it/wiki/Merged_mining_specification for more in depth explanation

So if you discount the block reward by block-reward / 2^(merkel-branch-depth), as you suggest in the white paper, then you give incentives to miners to not do merge mining, because it wouldn't generate more reward but would require more bandwidth and storage. This is a very serious security issue, because this will lead to maybe 1000+ chains eventually (as proposed in your paper) with miners distributed across all chains not merge mining. In this distributed mining environment, it is very easy for an attacker with less than 1% of the total hashing power to control over 50% of the hashing power in one of the individual chains.

So you really should either remove the discounting based on the merkel-tree-branch or at least do the discounting proportional to the space requirements by merged mining. So instead the reward could be:
block-reward / merkel-branch-depth

Edit: i.e. if you do merge mining on 4000 chains, then you just have to include 12 hashes in the block headers. This is really not so much space, if you evaluate the benefit of much improved security and the benefit of more miners running full nodes in all chains if their bandwidth allows it.

@bytemaster
You still haven't replied, so I guess you overlooked my post?
Do you agree to my point? Or do you have a fundamentally different understanding of how a multi-chain system should be secured by mining? My point is, that merge mining does not only increase the reward of the miners, but it is actually very important for the security of all chains. Without merge-mining, all chains are insecure because chain-hopping of mining resources will make it easy for an attacker to gain 50% in individual chains.
Or do you think that my reasoning is flawed? Then why?

I have been meaning to get back to this topic.   I put a lot of thought into it.   Allowing users to merge mine with 0 extra cost opens up potential attack vectors where a 'legitimate block' and an 'attack block' are mined at the same time with no additional cost to the creator.   In fact, it allows people to subsidize their creation of alternate histories.   So allowing it to be 'free' is not wise.  

Assuming all chains are of 'equal' value, then my algorithm if discounting the mining reward proportional to the tree depth^2 would result in equal payout for mining vs merged mining.   This assumes that all chains follow the same rule.

What is the goal of merged mining?   In my view it is to share one set of hash power across the entire network.  With the depth^2 discount, hash power is shared but profits are identical assuming the two chains have equal value.  

If one chain has more value than the other (different dividend payouts, different reward rates, different markets)  then merged mining is a calculated / speculative risk.  You divide your hash power evenly between them, but your immediate payout will be the average value of the two chains rather than the sum of the value of the two chains.   Both chains still benefit from added security.  

New chains do not have to follow the same rules, and to drive adoption may allow 100% reward even with merged mining until the difficulty reaches some threshold.  This would change the economic calculation on merged mining yet again such that as long as the alt-coin had at least 50% of the value of the 'main-coin' then it is more profitable to merge-mine.  

I cannot follow your argument, why miners would merge mine with your given equation.
Let me illustrate it using a simple example:
We have four chains A,B,C,D with block-reward/difficulty:
A: 5.6 BTS
B: 5.2 BTS
C: 4.8 BTS
D: 4.4 BTS

A merge miner would have a merkle branch depth of 2 and therefore with your equation an average reward of 5 BTS. Therefore it is less profitable in comparison to mining on A, which will directly give you 5.6 BTS reward. Therefore all miners will switch to A and do single mining and nobody would do merge mining.

You might argue, that after time this will decrease the mining reward in A and B because people will switch to it, and increase it in chains C and D. So there might indeed be a fix-point at which all four chains have a reward of 5 BTS. BUT this fix point is not very stable, because as soon as you perturb the system, all miners will switch to the chain with the highest reward.
So the whole system of all your chains will only contain miners, who do not merge mine, and the system will get oscillatory behavior.
You might argue, that your adaptation of your block-reward is so fast, that it will dampen these oscillations. But, my original point still remains: It is insecure because an attacker can easily obtain 50% hashing power in one of your chains, because nobody will merge mine, because they will seek the maximum profit in the chain with the currently maximum reward.

If we look at the same example and you use my modified equation, where you give a reward of block-reward / merkel-branch-depth, then a merge miner will get an average reward of 10 BTS. Therefore you would give an incentive to do merge mining (and thereby also to run full nodes in many chains). This would be much more secure, while you still lower the reward.