Topic: [Announce] Project Quixote - BitShares, BitNames and 'BitMessage' - page 12. (Read 48297 times)

Lets apply some basic game theory...

If you speculate and go short BitUSD by placing 2x the value in escrow and giving up the dividends.    You can get your money out of escrow any time for 50% the price by repurchasing the BitUSD.  Thus buying pressure caused by opportunity cost. 

Now the only reason you would go short is if you thought the price change would be more than your opportunity cost.

I'm sorry but I don't understand a word you are saying. Where is the "buying pressure" coming from?

The market price of stream A is twice the market price of stream B. How is the price of stream A in terms of stream B related to the price of the USD in terms of stream B?
Simply because one stream is called "bitUSD" or is there a real reason? Do you really think people will pay attention to your names when they have no fundamental link to the real world?

Of course it is important to have a good design from the beginning on. But as has been stated earlier it is also very important for mining algorithms to be adapted to technological advancements. Furthermore protocol changes are sometimes a really good thing. So I think everyone would agree that it is important to be able to change parameters later on.
Why do you assume miners would be better to make decisions about the network? Why not developers? Or the rich (which is equivalent to PoS)? Anyway, you have to decide from the beginning on how decisions should take place. In the bitcoin network it is clear that all decisions are taken by core developers and to a small degree by miners. I wouldn't argue that it is very bad if developers take some decisions. But I see a huge conflict of interest if miners are the decision makers, because they are neither the ones who have the best technical understanding of the protocol nor do they represent the stakeholders of the coin. Miners are more like external entities who get rewards for their service. As I said, they are like external component suppliers of a company. They shouldn't have a right to vote for changes in the protocol.

On the other hand, if you decide that PoS is used for voting for protocol changes or mining algorithm updates, then you have several benefits:
1) No conflict of interests (especially in regard to mining rewards and network security)
2) Regular users will leave the expert options of their clients untouched and therefore will just vote for the option, that the developer of his client choose to be the best option
3) Automatic check if the userclients do support some of the new features (therefore new features will only be enabled if enough clients do support them)
4) Very flexible, esspecially if you consider that you want to have several Bitshare-blockchains, because each shareholder of a specific blockchain could vote for their desired protocol parameters. Therefore, from the beginning on, it wouldn't make sense to create altcoins of your cryptocurrency. You could just add modules to the core client, and then shareholders of some specific blockchains could vote to enable this specific new feature.

Just think a bit about the implications of the last point! Let's consider Bitshares become really popular. You will have many specialized experts who would like to trade in a very specific framework with some specific network parameters. It would be so much beneficial if they could just use the standard client and create a new subchain, where they are the shareholders, and vote for their desired parameters. The whole ecosystem of Bitshares would hugely benefit, because it would automatically support a wide range of different users:
- Some users might prefer a subchain with high double-spend security so that they will vote for a large percentage of PoW contribution
- Some users might want to take part in a subchain, which has a high block frequency, but they don't care about bandwidth, so they create their own chain with these parameters
- Some users might want to trade in a subchain, where the blocksize is just 100 Kb and others might prefer 1 MB, so they will just move to a corresponding chain which has these parameters set

If bitcoin would have been build with this in mind, it would have a huge advantage in regard to protocol updates and technological and scientific progress. There are currently many altcoins, who try to improve the protocol of bitcoin. But they have no chance to be used just because of the network effect of bitcoin. Although, some of these changes are well tested and understood, it is no possible to change the bitcoin protocol, because there is no democratic decision process implemented. I think this idea is in total agreement with the ideas of bytemaster and charleshoskinson.

I understand, that it is very hard for a developer to give up some control to the users. But it would be beneficial in the long term if it is clearly defined how protocol changes should be introduced. If this is defined, then progress is possible in a very controlled way after the initial launch. In contrast, if you want that miners vote for changes in the mining algorithm, then you will create a deadlock from the beginning on (similar to the inflexible bitcoin mining algorithm).

So if you read my post carefully, I hope you could maybe agree that it is shortsighted to assume that all users will be satisfied in all time with the specific set of parameters of your initial design. I very much prefer a wide range of parameters that could be tested and then the subchains with the best parameters will win. You would make altcoins unneccessary because they could all be incorporated within modules in your software. So the whole ecosystem is more flexible. Thereby you would enable design-by-popularity in contrast to the bitcoin way where you are constrained by economics-by-design.
(*Edited for clarity)

To create BitUSD,  2x the value of USD worth of BitShares are held in escrow.    (Both the short & long put in the market price of USD in BitShares to create the long position (BitUSD) and the short position (collateralized debt) ).    The dividends from the collateral are paid to the holder of the BitUSD.   Thus an opportunity cost on the short position creates buying pressure, and the higher BitShare return on BitUSD makes them more liquid to those who wish to earn a higher return in BitShares.     If there is expected price 'stability' between USD and BitShares then it makes sense to buy BitUSD rather than hold BitShares because you will end up with 2x as many BitShares at the end of the day (at the risk that BitShares could rise and you would lose that gain).

Okay, 2 shares of stock are worth twice as much as one share of stock. What does this have to do with BitUSD again?

I can prove that BitUSD will not go to 0 with a very simple proof.

1) Given two revenue streams in the same 'unknown asset of non-0 value'  Streams A and B
2) Assume A pays 2x as much per unit time as B....
3) What is A worth relative to B?
4) Answer is that A is always worth 2x B regardless of the unit of the revenue stream.

I can therefore conclude that only looking at differential dividend rates and ignoring margin calls and other market factors that BitUSD would be worth 2x as much as BitShares based upon the revenue stream alone. 
The other reason it will not go to 0 is that the 'short position' incurs an opportunity cost and is in a nash equilibrium where they would rather buy and get 75% of their money back than 'not buy' and lose 100%. 

Conclusion: I have proven, mathematically, that the price is not 0 unless BitShares are 0.  Furthermore, I have demonstrated that there exists demand for BitUSD at a price point equal to the backing collateral due to dividends alone.

Myself and at least 2 others have challenged you to present any sort of explanation or proof as why those assumptions above are true. At least two of us are thinking there might not be an equilibrium and the BitAsset might perniciously migrate to its intrinsic value of 0. Notwithstanding my silly error (when I attempted a simple logic to prove it would go to 0), the point remains that you haven't shown any substantial (non-hand-waving) theory to back this claim. Future's markets are always backed by the threat of taking delivery, which will not apply in this case. You mention NPV in the whitepaper, but that was handwaving.

I am not asserting you are wrong. I am saying a wish and a prayer is not science.

Well you could just try it.

Either it was in a dream or reality, someone already tried something like this and it went to 0. I am trying to discern the vague memory that is teasing me from the back of my mind.

I don't think it is the Tulip Mania I am thinking of.

I could trade the Mona Lisa over a trustless p2p network and I will use the Mona Lisa as an example because it highlights the following:

1) My system does not transfer the actual item, nor create the item, nor is it 'backed' by the item in question.
2) My system does transfer the value (purchasing power) of the actual item
3) My system does transfer value between longs and shorts proportional to the price movement.

Suppose that every couple of years the Mona Lisa comes up for auction.  As a result we have an estimated market price as a foundation.

You and I could then speculate via a 'prediction market' what the Mona Lisa will sell for in the future.  We would back our speculation with a crypto-currency.

If there were enough people speculating on the prediction market then I could trade my long position with someone else. 

Now the Mona Lisa market would have a wide spread and suffer sudden jolts every time there was an actual auction that provided a new data-point to the 'prediction market'.   Every rumor, appraisal, or piece of news associated with the Mona Lisa would directly reflect in movements on the prediction market.   

BitGold is just the long-side of a continuous, collateralized, prediction market on the future price of Gold relative to BitShares.  If you buy BitGold and the price of actual Gold goes up relative to BitShares, those short BitGold would transfer to you the purchasing power that would allow you to enter the market and buy actual Gold.       Unlike the Mona Lisa, there is continuous data feed of prices on the open market and therefore there will not be the jolts experienced by the Mona Lisa market. 

To turn this into a P2P way of trading actual gold consider that because the price is always a relatively constant ratio between Gold/BitGold the buy sell spread will be much lower locally than local-bitcoins.   So, you take your gold, sell it to someone for BitGold, wire the BitGold across the globe to your friend.  They then take the BitGold to a local coin shop and buy actual gold.   All of this while having minimal exchange rate risk for the duration of the transaction even if it is spread out over a year or more. 
 

 

The tragedy (lie) of democracy is that the masses can be manipulated by the rich who control the media and goodies that the masses want. And the rich have the most stake.

My point in my reply upthread is that the developers only get one chance to apply their best design, then the vested interests take form.

I prefer economics-by-design than design-by-popularity which devolves to centralized control.

It still holds, that the ultimate value of the network stems from the stakeholders and they should have the right to vote for protocol changes. The idea to let miners vote for protocol changes is fundamentally flawed. The shareholders should have the ultimate decision about the security of their coins. I really do not see ANY advantage of letting miners vote in comparison to letting shareholders vote.
Compare it with the shareholders of a company. Your proposal is similar as saying some external component supplier of your company should vote for the next component supplier of your company. Instead it makes much more sense to let the shareholders of the company vote for these decisions.

It is really not so complex to incorporate several PoW algorithms together with PoS in your design and let PoS vote for all major protocol changes.
It is also more secure if you combine these algorithms such that at a certain block height it is determined which of these algorithms has the right to submit the next block.
If you want to just use a CPU/memory intensive mining algoirthm, then you are so insecure against botnet owners.
So really, there is no principal disadvantage of incorporating PoS with several PoW algorithms in parallel? there are just advantages.
And then you also have a mechanism to justify that a majority of users is behind a protocol change.

I explained some of my early thoughts and calculations on blockchain scaling. Since then, I have looked at the MiniBlockchain proposal and need to sort through what is the best design.


I posted some issues there.

P.S. you joined this forum 2010, I joined March 2013, and didn't really start to think deeply about technical design until perhaps August 1.

bytemaster can you please give me an explanation on how could you possibly trade gold over a p2p trustless network? How will it be backed?

I want you to put the explanation as simple as possible. Thanks.

I ran a poll on new features for an altcoin, and as I expected (my username is AnonyMint), anonymity is the #1 request:

https://bitcointalksearch.org/topic/poll-ranking-new-features-for-decentralized-currencies-279340

Anonymity may become even more important when the G8 begins the already officially published plans for bail-in confiscations (note bank derivative losses take precedence over bond holders and depositors).

Results at 27 votes:

2. Blockchain scaling
3. GPU-resistant
4. Energy-efficient mining
5. Create new coins forever
   P2P exchange (cross-chain txs)
   0-confirmation txs

As you can see, this forum is very into mining (4 of the of 7 top features) and very concerned about privacy.

It seems to me that either a tumblr (a.k.a. coin mixer or laundry) or the ability to send an untraceable message is going to be crucial for supporting anonymous transactions. For even if I am paying a known entity (e.g. a website), I don't want that website storing my public key on a server that any one can find. Thus I want to be able to send my proof of payment in a message that ends up at a server which no one can find, which replies to me with a key I can use to enter at the website to gain access to what I paid for. In this way, even if the known server is hacked or served a court order, the key can't be linked with my coin public key without finding that server that can't be found. Then even if I reveal my identity on that website (e.g. interactive porn cams or forum with pics of my genitals), that can't be linked to the public key for my coin without finding that server that can't be found. However, the downside of this, it expects the other party to do many things correctly. Whereas a tumblr delinks the public key back to my other transactions, thus is more robust. Devil is in the details though, as to which is more practical and scalable.

It seems there is much more work to be done on anonymity that you are not yet talking about.

I'm not sure how Newton's method is being applied here, though I guess you are choosing difficulty as a nonlinear function of recent block arrival times and current difficulty in order to minimize the expected deviation in the block interval. Better to use a a flexible linear approximation of your function and OLS esitmates of parameters.

If you insist on nonlinear optimization methods, you should use a simplex method; it is derivative free and therefore much more robust to discontinuities than Newton's method. Google the fminsearch function on matlab which uses a simplex algorithm. Trust me if you want to avoid something going wrong in your optimization program the simplex method is much more reliable than newton's method. A good book on relevant nonlinear techniques is Numerical Methods in Economics by Kenneth Judd.

If you do use Newton's method make sure you calculate your derivatives over a long time interval say 300 blocks.

Regardless of the optimization method you choose, do not be too aggressive in updating model parameters based on recent history. It is better to err on the conservative side than frequently overshoot the adjustments. Oscillations due to overshooting could produce unstable behavior.

Takeaway:
Use a linear model and OLS to estimate parameters
Update parameters slowly to avoid overshooting

Final advice: use a consevative number of parameters; say a quadratic function of difficulty, difficulty at times (t, t-1, t-2) and block interval average at times (t, t-1, t-2). That is a total of six variables, yielding a constant term, six linear parameters, and eighteen quadratic parameters.

This is boring stuff so offer to send BTC my way if you want more advice. I'd charge 1 BTC per hour. The above is 30 minutes.

A determined, highly capitalized attacker might be able to prepare FPGAs and launch an attack within say less than a month, maybe even only a week if they are the NSA or other highly organized entity.

Increasing the memory requirements significantly reduces who can capitalize such an attack.

But if you are only depending on being able to change the hashing algorithm, this seems to me to be very risky, not only for the above reason, yet also because hashing algorithms will have different performance profiles on different models of CPUs and systems, so vested interests may form. Also even with auto-update, there may be a limit to how fast miners can upgrade due to being offline for say a week while someone is on vacation, their computer is in repair, their ISP blocked the port, etc.. Murphy's Law applies when ever you expect large diverse systems to coalesce.

Also depending on how the blockchain is designed, doesn't this mean keeping the old hashing algorithms around to verify the historical blockchain?

Also if the hashing algorithm is going to change frequently, it is more difficult for miners to plan in terms of buying the optimum hardware. They won't be able to do reliable ROI calculations, e.g. a hashing change could alter the total difficulty power in the network, because not all systems have the same profile relative to the performance of different hashes.

Unknown risk doesn't build confidence. Whereas, a hash that has withstood the test of time, does.

---

My thought on ASICs is embrace them, so that everyone can plug one in to their PCIe port, yet insure memory is the higher cost. Moore's law is steady and so miners can plan. Someone who claims they design ASICs backed down on their criticism and complimented me when I mentioned that strategy.

So now I have revealed to you one of my secrets. I have more secrets on how to make the Scrypt GPU-resistant. Actually they aren't secrets, just buried in my past posts, but I didn't even write-down the pseudo-code yet, just a verbal discussion.

P.S. I may not be the ultra-elite-tier technician, mathematician, etc.. yet I am conversant in (and nearer to the top in some areas of) technology and I combine big picture and marketing analysis.

Off top-of-my-head (not really thinking it through deeply) need a damping factor that increases if not converging. I won't say more unless I write down some math.

I started a new thread dedicated to the technical details of the Bitshares ID system.  You will see why it is VERY different from Namecoin with very different properties and scalability. 

https://bitcointalksearch.org/topic/m.3033138

This is exactly what I had in mind down the road.   

Those do appear to be a potential killer feature, but I am not sure if they are the most important need at the moment. Something to contemplate.

Suppose back in the days when CPU mining was the majority and GPU mining was just starting to gain traction but still a minority.   The CPU miners would all vote to move to something that would keep them in power before the GPU owners could take over.  The FPGA developers wouldn't even begin investing any effort.  The only way to perform a successful ASIC take-over would be to perform a 51% attack before anyone knew it and then vote to keep yourself in power.   Of course, such an attack would immediately undermine the entire currency.

So the CPU users must pro-actively change the hashing algorithm at least once per year to prevent any secret ASIC developments.  Combine this with a hash algorithm that doesn't give ASIC as much advantage as SHA256 does (by being memory and computation hard, ie: the point behind the scrypt white paper) and even if ASICs were developed they would not be able to gain a majority of the hashing power quickly nor cheaply.