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

Domain squatting is a creature of price fixing combined with first-come, first-serve awarding of names.   The goal is to maximize the economic utility of each unique piece of real estate.  In my approach, imagine all available names as being real-estate in the New World.  No one knows which acres have gold, oil, or nice views until they can be explored.   It is absolutely ridiculous to create a system where all lots are the same price and then sell them all to the first person in line.    To solve this problem I have created a name crypto-currency that acts as 'stock' in all names and owners of this stock make a profit anytime a name is sold.  To ensure proper price discovery names are auctioned.   The result is that the most profitably way to 'squat' is to own the crypto-currency because it sees almost all of the profits from every name actually sold and no need to tie up capital in names speculatively.  It puts everyone on a equal playing field in the domain squatting game because whether you have $100 or $1M to invest, you can get the same rate of return by investing in 'unclaimed' names via owning 'stock' in the crypto-currency.

My motivations are always economic and never about 'social justice' or redistribution for 'feel good' or 'nanny' reasons. The goal is efficient allocation of resources and profit while avoiding socialist concepts of 'fair prices', price fixing, and other economic policies.   THe result is a better system that can compete on the market, not 'nanny developers'.

Well you have piqued my interest in finding out about Scala but I think that after more than 15 years of C++ programming I am probably not the right person to become a convert.



(maybe we can end the OT language stuff now and get back to what I think could be a very interesting project)

I agree let's work together.

I will just say it is hard for people who learn Scala to go back to C++, just as it would be painful for you to go back to ASM or only C.

Languages do progress.

I think I'd have to agree with bytemaster that this had crossed into "Language Wars" which is not productive for anyone (so will not further it with more fuel).

If you have found your nirvana with Scala then I am not against that at all - so please don't argue that my nirvana with C++ is somehow *inferior*.

Enjoy your programming and *change the world* - that is what we are really striving to do here (rather than win a silly argument about which compiler/interpreter/parser is the best).

We are really only going to have the greatest influence by working together rather being at each others throats about our choices of computer languages.

You completely missed the point. Try reading again.


Everyone who breathes eventually dies.

Correlation is not cause and effect.

If those who code in C++ did not use the bad libraries that caused the problem, does not mean that coding in C++ is inherently more secure (and not less secure).

Also the sample size is way too small to make any statistically relevant conclusions.

And the main issue here is to write a lot of compelling s/w as efficiently (quickly, correctly, etc) as possible.

Scala fits that bill better than C++ if we are evaluating purely on the productivity of an expert Scala programmer vs. an expert C++ programmer.

However, we have to factor in there are a lot more C++ programmers than Scala programmers. And the learning curve for those who don't know Scala.

And factor domain specific expert knowledge (in this field) may be reside more amongst C/C++ programmers.

Yet more programmers does not always trump the quality of the best few programmers.

In any case, I was only sharing my personal opinion of what I would contribute to. You did more than share back your personal opinion of what you would contribute to. You thought you could scold me, yet you got caught with bad logic. You deserve the embarrassment because your intentions were to embarrass me, but it backfired on you.


We are writing altcoin clients here with networking, bit twiddling, GUIs, etc.  


I would express my opinion that I would not wish to code in C++ ever again after learning Scala.

It is like going back from C to assembly language. I wrote 5MB of 68000 assembly language for my WordUp before C arrived on my radar.


Imagine the assembly programmer who never tried C.

Guys, language choice is a holy war and not productive debate for this thread.    All I will say on the subject is that making asynchronous applications easy to read and develop is hard.  Designing software that can handle the number of async connections, encryption demands, database demands, and memory demands of a block-chain that is running at full capacity (1 MB of trx every 5 minutes) with the ambitious goal of operating in the background as an always-on app like your email client means that picking a language with a lot of overhead would be enough to push us over the threshold that is ambitious to achieve even with optimized with C++.  Fact of the matter is, native C++ apps with Qt provide a better user experience than apps built with a host of other languages where your cross-platform support is limited by the availability of a runtime environment.   Runtime environments represent a source of bugs and security holes that are unacceptable for this application.     Even if you assume all of these things are a wash, as the primary developer C++ is the only option for the core code because I can write the best code in C++.    THe core components can be compiled into a library and then provide bindings to any language. 

If you think that Scala is so much faster to develop in, then you should be able to catch up to the work I have done in the past 6 weeks within a couple of weeks.   I would gladly work with you to define an open over-the-wire spec and if you really can get the kind of improvements you are talking about and can catch up then that would be great.  In my experience though, those types of gains are mostly on paper.

Yes, and they are divisible and have all of the properties of Bitcoin.


Yes, Options also work this way.


Aside from margin calls, positions can only be closed by finding a buyer and trading out of your position.  Fortunately the market is liquid and all BitUSD is fungible.


When a short 'covers' their position they do so by BUYING the BitAsset on the market using the collateral.  Thus some owner of BitUSD is now the proud owner of the some of the Bitshares held as collateral based upon the price. Any left-over collateral is returned to the owner of the short position.


First of all, BitUSD is composed of 1000's of positions entered at different prices by different people.  The price would have to fall 50% in 5 minutes and even then there are no losses because the collateral would still be able to purchase the BitUSD at market price.   Obviously the short positions would be entirely wiped out in such a rapid movement in price as they are forced to buy as much BitUSD as their collateral will allow and bid up the price in a short squeeze.  Worst case outcome is that some people will end up with BitUSD with no backing at all and thus 0 interest.   Fortunately, new BitUSD is always being created as new shorts / longs enter the game and the new BitUSD would be fungible with the old so only someone attempting to sell BitUSD in a very narrow window may face a discount to face value.  Because market forces always push the price back toward parity, speculators would readily buy up BitUSD at a slight discount created during such an insane price move.  

There is no reason to ever have expiration on longs (see above).


A miner could exclude a new bid or ask in the most recent block, but would be unable to do anything about limit orders placed in prior blocks that were not filled.  The miner will always have a slight advantage in picking which bids get into the block chain and thus how the price moves in the 5 minute window of the block they win.   But in a given 1 hour window, there will be 12 different miners who win and they will have different goals with respect to which way they want the price to 'move' based upon their individual position (short or long).    The reality is that the offers placed on the block chain are generally spread in a collar around the current bid ask and therefore the order book will be full on both sides of the trade at the start of mining.  No single block would be able to budge that order book by more than the 'new bids/asks'.    So margin calls will be based upon a wider bid/ask spread than the 'real-time market'.  Most people who care about price fluctuation in time periods of less than 1 hour should be trading on an Open Transactions exchange that is funded with BitUSD / BitShares.    

I suspect that the small market advantage garnered by generating a block would further motivate miners and ultimately help secure the network.   Of course, the reason why decentralizing the hashing algorithm is important is to keep a large percentage of the hash power in the hands of non-professional miners and thus limit the ability to control the market by any one actor.



Any action that could be taken by a miner must wait for the 'chain reorg window' to pass.  Bitcoin currently uses 100 blocks before miners can 'spend' their rewards because during a re-org, decisions of the miners based upon then-current prices are no longer valid.   If I cancel my order and then a re-org occurs, a miner in the reorg may have executed my order prior to the cancel.     Obviously, re-orgs are a risk for any trade executed by a miner and those that care about having instant spends should use the off-chain system to exchange and sign an atomic transaction that could survive a re-org.   This is another example where the only bids/asks that will end up in the block chain are the 'open orders' / backlog that will only be executed if the price moves significantly (1% or so) in one direction or another.  


We want the minimal security required to prevent chain forgeries and ensure things are decentralized.  You don't go around paying for the MAXIMUM security for your house because after a while additional security has a marginal ROI.  Dividends provide the following benefits that ultimately improve security of the network:

1) then encourage saving and value accumulation within the chain.
2) they create an incentive to bring the unwashed, greedy, masses such as Grandma, into the system because they can get a better ROI than their bank with a better risk profile.  
3) having a relatively secure way to generate passive income will help make this go viral
4) increased adoption means more small time users, each of which can profitably mine with their CPU, and thus there will be more hash power in the network.



Thanks for all of your feedback, it is nice to see some deep conceptual thinkers picking through the paper and design.!






 

So this is just getting pointless - now your argument has conveniently changed into one that I can write *shit* in C++ - so I can't possibly write *shit* in Java?

(again - the only BTC lost though shitty programming seems to be via Android and Java - nothing from C++ but of course I *must* be wrong so please correct me)


I made the point in regards to *financial software* (traditional banking and insurance apps) and as stated I am a C++ guy first and foremost.

Once again I would just like to ask - if Satoshi posted here again would you criticize him for his (according to you) *stupid* use of such a *crappy* language?

In regards to Scala I know nothing about it so am not qualified to comment about it (apart from to say that languages are languages - there is no *perfect* one).

That doesn't even catch half of the issues.

And it doesn't force you to use them.

In the JVM it is absolutely impossible to get a pointer and change where it points to in memory.

I wanted to say "Geez  " because of the way you scolded me for my suggestion to use Scala. I can be nice, if you are too.

Be careful with getting all pompous on me, I know my shit.



So write a Bitcoin client in COBOL please?

It is more secure for its narrow area of applicability because as far as I know, COBOL can't realistically be used to program generally any kind of personal computer application. Thus, it isn't any more secure for the things we need to program.

And here you are making the argument for managed code, not against it.

Also you did not address my points #2 and #3.

Perhaps you've never heard of std::string and std::auto_ptr (i.e. these problems were fixed back before the Java vs. C++ language wars had even really started and a big reason why I really don't buy the whole Java is safer argument).

You can't *overrun* a std::string (unless you're trying to) and std::auto_ptr's look after the memory and validate the pointers themselves - did you miss something?


COBOL and DB/2 SQL (with pre-compiled queries) is used because it does *not allow anything dynamic* period (i.e. it is more secure than *anything* else available today).

Understand that it is simply *not possible* to do a SQL Injection attack when you use DB/2 pre-compiled queries (which is what COBOL apps normally do).

Also understand that I am a C++ programmer (and advocate) but I understand and respect what is used in banking and insurance industries because I spent years *working* with them (and no it's not just because of the legacy code being there - they can afford to get it re-written anytime they like just as they spent billions sorting out the Y2K issues with the COBOL programs they are still running today).

As far as I know, security holes have been in libraries and Java code not in the JVM (Java Virtual Machine), i.e. it doesn't apply to Scala unless we use crappy libraries.

Code written in C++ also has security holes, just as severe and numerous as Java code if not more.

The difference is:

1. Managed code (JVM) removes a large class of security errors that you can make in unmanaged code like C/C++, e.g. buffer overruns and erroneous pointers.

2. Scala is 2 - 3X more concise than Java (and C++), and concise code enables clearer code study.

3. Using vals and pure functional programming concepts, a whole other class of security errors (referential transparency) are eliminated.

COBOL is still used because of legacy code, not because it is more secure (is it?).

And Scala is just a hell of lot more fun to program with  

The downside of Scala is if you don't restrict yourself to commonly known idioms, it is possibly to write code that no one can read except yourself (write-only languages are bad for open source). However, if you avoid the unnecessary use of such constructs, then Scala is more readable than Java.

P.S. I am working on a language that removes those constructs to limit Scala to a more readable subset. The name of my language is Copute and it is often even more concise than Scala.

How is this not an arbitrary definition, given that the short is never in 'debt' either if there is no obligation to pay the long any more than the market value of the BitAsset?

So then where does the collateral of the long go?

How does the short profit?

There is never any reason to call margin on the long.  The long isn't in 'debt' and the result of the price move is to increase the margin of the short.  As a result Longs only ever voluntarily sell.

Regarding gmaxwell picking on you upthread over the PoW algorithm, I just challenged his logic skills w.r.t. to anonymity.

Seriously gmaxwell is more knowledgeable about the details of crypto algorithms than I am.

So it's strange then isn't it that still the majority of banking and insurance back-end software is written in COBOL not Java.

(something to do with *security holes* like we are seeing with Java implementations perhaps?)

Am not really into language wars, however, recent *thefts* that have occurred have been due to Android and Java (not heard of anything similar in that horrible language C++ which Satoshi himself stupidly decided to use).

See this from core developers discussion:


Note Scala is a better Java and runs on the JVM, so it is a managed language also.

HELP.org, you and I are in complete agreement.

Unfortunately I detect a whiff (not too strong) of socialism-leaning slant to the designers of this proposal. I urge them to back away from the instances of "equality" (e.g. BitShares-wide, wide-area dividend pools) in their design (unless these can be economically justified) back to the time-preference (opportunity cost) return on capital as a model of economics. Capital != money. Capital != wealth. Those are proxies for capital, which is the human productivity.

The only known global optimization algorithm where the dynamic variables are not known a priori is simulated annealing (why ice formed with slow cooling has less cracks than if flash frozen), i.e. maximum degrees-of-freedom (i.e. independent actors) with many microsteps of the state machine (slow cooling).

Binding things together (pools, sharing, and centralization) is the antithesis of degrees-of-freedom, e.g. a train has less degrees-of-freedom of movement than an offroad motorcycle (although the train has more degrees-of-freedom in cargo capacity), c.f. my two relevant blogs:

http://unheresy.com/Information%20Is%20Alive.html#2nd_Law_of_Thermo
http://unheresy.com/The%20Universe.html#Entropic_derivation

Sometimes we tradeoff degrees-of-freedom in some facet in return for greater short-term efficiency (expediency) in another facet, e.g. closed source is more expedient but over the long-term it is less optimal.

Many domains that I registered and never used, ended up being used by others after I gave them up because of the hassle and cost of maintaining the $10 per year registration fees wasn't worth my possible use of them someday.

You can't give away for free a resource that is finite (the number of good brandable names is finite). One of my examples is the toll road from Makati, Manila to the airport in Pasay costs about $1 and takes 20 minutes. The free public roads take about 1 hour. Which economy do you want? Gridlock or efficiency?

I am a rational min-anarchist, so generally I agree with your ideology. But my rationality (and the min-) says that if you let people sit on capital forever without incurring any costs or dilution, then the economy must mathematically stagnate. This is why I am frowning on the proposal for dividend pools (socialism!), we need decentralized (not centralized top-down control of) inflation (c.f. the links I provided in my prior post). It is very important to understand the math at the above link. Many (probably most, if not 99% of) people who claim to be capitalists are really socialists because they don't understand the concept in that link. I also recommend reading the following tutorials on economics:

http://armstrongeconomics.com/2013/08/18/money-had-never-been-tangible-period-if-you-do-not-understand-what-money-is-you-will-lose-your-shirt-more/

More:

http://armstrongeconomics.com/2013/08/24/gold-5000-why/
http://armstrongeconomics.com/2013/08/24/14007/
http://armstrongeconomics.com/2013/08/22/no-single-investment-will-ever-be-perpetual-it-all-changes/
http://armstrongeconomics.com/2013/08/21/as-the-war-cycle-turns-up-middle-east-is-going-nuts/
http://armstrongeconomics.com/2013/08/24/yes-in-a-mad-max-dark-age-not-even-gold-has-value/
http://armstrongeconomics.com/2013/08/23/gold-the-coming-slingshot-move/
http://armstrongeconomics.com/2013/08/24/the-fire-is-burning-we-need-more-fuel/
http://armstrongeconomics.com/2013/08/19/emerging-markets-collapsing/
http://armstrongeconomics.com/2013/08/05/how-empires-collapse-a-orderly-path-to-conclusion/
http://armstrongeconomics.com/2013/03/27/are-we-head-to-a-mad-max-scenario/
http://armstrongeconomics.com/2013/05/23/mad-max-begins-in-spain/
http://armstrongeconomics.com/2013/05/08/the-mad-max-outcome/

BRIC-by-BRIC global collapse (underway)

The leverage I proposed apparently can be controlled by abs(market value - collateral) x leverage ÷ 2 as the amount of collateral of the losing side awarded to the counter-party.


So far, my only idea for a solution is that market makers should be separate entities from miners. Miners must take all the bid and asks sent by each market maker (take it all or none, so more difficult to hide manipulation). Each market maker resolves the bid/asks before sending them to the miners. Market makers need to receive some compensation. Users choose which market markers to use based on their performance. The miner still resolves the margin calls, using the market pricing from the market makers which the miner included in the block. The miner will have much fewer variables to play with, since users will pick market makers. Users can't pick miners, because PoW does randomly (weighted by miner's share of difficulty).

This has another benefit of enabling market makers to present real-time data of their bid/ask distributions.

It is not perfect (relies on trust which is inherently centralizing, although freedom-of-choice and P2P is more decentralized than the trading systems we have now), but no such trading system will ever be. At least you can make this P2P and the barrier-to-entry for new market makers is fairly low. Users keep it honest by monitoring the market makers they trade with.

This is why we must keep the altcoin transfers (PoW mining) orthogonal to trust based trading. The market marker will always have to be trusted.

I think an axiom is to never never make miners responsible for time-preference transactions, because there is too much conflict of interest that corrupts mining from its primary purpose which is to secure the block chain. When transactions don't have a strong time-preference then the random selection of miners by PoW insures that transactions are likely to go through, unless one entity controls a large % of the difficulty.

When I wrote my Bitcoin: The Digital Kill Switch (mirrored on a popular financial site), I was primarily worried about corporations gaining a large percentage of the PoW and then using such a cartel to gain leverage w.r.t. to time-preference of consumer transactions, e.g. Amazon's quick checkout (1 click). Later I came to find out the key developers and Satoshi had long planned (the link is buried in my posts) for Bitcoin to be taken over by the large corporations (which is very dangerous given we are headed into a period of fascism due to the need of boomers to tax at greater than the Laffer limit in order to sustain the bankrupt socialism with a police state). We are in the dangerous stage where the financial center of the world transfers, this time to Asia after 2033 with lots of pain between 2007 and 2033 (mirroring 1929 to 1955). Btw, inflation is necessary and also this link, it is centralized inflation that is bad.

Btw, I think I may have already solved the level playing field for GPU/ASIC-resistant PoW (some details buried in my posts, no code written yet). I see you are coming closer to my ideas on that since the astute (obviously very intelligent) core Bitcoin developer Gregory Maxwell challenged you.

P.S. I had some tangential misconceptions (e.g. thinking Bitcoin could be a Ponzi scheme) when I first got seriously into Bitcoin when I wrote The Digital Kill Switch. Nevertheless, the main aspect I was concerned about remains my concern.

Perhaps the following is why tracking ETFs are known to lose value during periods of volatility, because they roll over short-term futures contracts usually daily.

I need to think more deeply about this and the math. This was just off the top-of-my-head, as I just quickly read the first half of your whitepaper a couple of hours ago. Someone sent me a PM with a link to this thread.