Messages

At any given time, there will be 12 inches in every foot.

At any given time, the market cap will be equal to the 'price per share' multiplied by 'the total number of shares outstanding'.

It does not matter if a tree grows from being 40 inches to 50 inches, or the tree is measured in centimeters instead of inches, there will still be 12 inches in each foot.
It does not matter if the price per share rises, or if there is share dilution, the relationship between price and marketcap will be the same.

If you think that share dilution changes the relationship between market cap and price (a fixed MC = P * SO), then you are too ignorant of rudimentary financial concepts to post anything of value to anyone, sorry.

This is not even finance, it is 4th grade multiplication.

Is it a good idea to have "inches" and "centimeters" so rigidly connected?

Do you really not know how prices are determined? Obviously the two correct answers are "supply" and "demand".

Sure, price is from supply and demand, I don't see how that relates.
I was making a claim about the market cap, not the price.
I claim that the only way to raise the market cap is by doing POW, which can possibly take the form of advertising.

For anything with a fixed supply-schedule (all crypto-currencies), the market cap is the price...just expressed in different units. It is no different from measuring someone's height as 6.1 feet vs 73.2 inches.

To increase the marketcap, if supply is to be fixed, one must increase demand. If advertising increases demand, then advertising will increase the market cap. However, I don't think Bitcoin's marketcap ("price") increases because of advertising. Instead, I think demand comes from the need for things like monetary sovereignty, fungible value transfer, cheap international transfers, association with new technology, etc.

I want to make a blockchain with a $ trillion market cap.

There are 2 ways to increase the market cap of a cryptocurrency:
1) burning value by advertising.
2) burning value by mining.

Do you really not know how prices are determined? Obviously the two correct answers are "supply" and "demand".

You might consider improving your education, before pouring your scarce time into new theories. There are many free econ textbooks online, and you can usually learn math from a textbook's practice questions. I recommend listening to all of Chris DeRose's "Bitcoin Uncensored" podcast on Soundcloud, if you are still reading Vitalik you will be wasting most of your time, I'm afraid.

One thing at a time, please.

Previously, you said:

For example, imagine a group of people who owned $100 billion wanted to convert all that money to bitcoin. They should own 94% of all the bitcoin after this transaction, because all existing bitcoin is only worth 6% of the amount they are buying.

And I responded by saying that this was false, the "should" not own any default percentage of anything. The asset is not entitled to do anything for people who aren't owners of it. The "group of people" may own $100 billion, but Bitcoin has no way of knowing (nor should it) how many USD someone has.

You responded with a counter-example about fees, which I explained was actually not a counter-example.

Now, it seems that you agree:

No one would prefer the assets that have crazy expensive fees attached.

If you agree, then you have yet to state your goal ("what you are trying to accomplish").

> SVD is too slow when the matrix is big.

Reread the whitepaper. SVD can reliably handle matrices of 500 Million rows by 150,000 columns. Ours will never even come close to being that big.


> But torrents didn't kill music. The music industry adapted to making money in different ways.

More importantly, humans feel a natural compulsion to express themselves through music. Oracles are different, because they can steal money today, they will *need* to be (over)paid in the future. This is a mathematical result from the field of mechanism design, and not really up for debate.


> It doesn't matter what is best for musicians or music. Customers prefer to pay less. The cheapest technology wins.

The cheapest technology may win, but there's no knowing how much music will be destroyed in the process of winning. Reread the beginning of my "Oracles are the Real Smart Contracts" post...cancerous cells, in the human body, do indeed "win". It "doesn't matter what is best for the organ or the organism", the cancerous cells multiply anyway...until the organism dies (and the cancer cells with it).


> When channel state changes, it usually has to go through one or more hubs. The hub collects trading fees.
> The hub wants there to be lots of traders so he can collect lots of trading fees. There will only be lots of traders if there is a reliable oracle.

Again, it is like saying "the organism will only survive if he doesn't get cancer". It's perfectly true, but it doesn't help us prevent or treat cancer.


> The hub will spend money regularly for the oracle to settle questions that are being gambled on, even though the results wont get put onto a blockchain. He publishes settlements from the oracle to prove that the oracle works as it should.
> Once there are multiple hubs, they will probably share an oracle for some bets.

The more money directed to the oracle, the more likely the oracle is to work correctly. So, the best thing would be for as many hubs to share the same oracle as possible (which is the current setup because they call share one oracle).


> To fund settlement for an oracle that is shared between hubs, they could use a truthcoin dominant assurance contract.

These are highly experimental and you should probably assume that they don't exist, until we can learn more about if they ever work for anything.


> There is no way we will get this all right the first time. Smart contracts let us update later.

I think we'll get it right the first time. Updating SVD / MM / OB / MM is almost certainly not necessary, and changes to trading can arise naturally from a hub-and-spoke model. As long as the costs are correct (people pay, on blockchain, for the real life resources they consume), people will self-organize to minimize cost.

Moreover, as far as updates are concerned, "smart contracts" is entirely equivalent to a "hard fork", so there is no difference. Any C++ compiler is Turing-Complete.

I just followed the DigitalOcean guide for creating a SMF forum...there seemed to be no "option" for https.

In general, I assume that every password / message / post / whatever I do on the internet is logged, and I just try not to think about it.

If you have simple instructions, I'll follow them. Otherwise I don't care enough to figure it out.

Most would say that the asset should serve it's current owners, not prospective new owners.

If that were true, then every time a new address is added to the system, we should require a 100 bitcoin fee, which is shared among everyone who already had coins.

Say there are two assets, one which costs a fee to send, and the other costs fee + 100 BTC to send.

Why would I, as a current owner, prefer to own the one that is more expensive to send? That would be like owning an air conditioner which uses hundreds of times the electricity...not at all in my interest (as a "current asset owner").

It is an interesting concept.

What if the 99% vote in highly random and confusing ways, drowning the "true 1%" in an ocean of similar-but-wrong ballots?

Fortunately, SVD can help a great deal...I even wrote code (for the "Audit Ballots") which greatly simplifies the problem, reducing Ballots to 5 maximally-representative teams. Traders could specify their "team", but I'm not sure how this would actually be coded in practice.

A second, more fundamental problem, is that it seems to reduce (as almost everything does) to "buying VTC"...instead of needing to buy 51%, I can just buy 1%, and then spend all of that remaining money (what would have been spent on the 50%) on transaction fees immediately following the fork. An attacker will strike at the weakest link...so if this is cheaper you have actually decreased security. However, it is possible that this will not be cheaper, and furthermore it is possible that this change will make the 51% route more expensive for the attacker (because it is now 51% + surviving this second hurdle).

It is hard to tell, isn't it? The transaction-fee-differential is really just a proof of work, as well, as one can trivially make trades that are non-representative (buying 1 of each state risks no money, but allows one to pay a transaction / trading fee...hence it just becomes a wealth contest that has nothing to do with "trades"...I proposed this awhile ago but have since abandoned it as being not worth it).

Also, miners can simply censor transactions which they do not like, so your way would allow a 51% miner coalition to buy 1% of all VTC and then control the outcomes (in my way, they can simply veto and force the voting to be redone).

In general, a principled approach will be most robust to attacks, vs a whack-a-mole security patches. For example, in the whitepaper I attempt to explain, why I feel that a second token can represent reputation (a kind of "InTrade stock price"), and why RBCR should happen using SVD. These considerations are based on my real-life experiences with trying to uncover the truth amid a room full of potential liars.

Nonetheless, nice try.

> a state channel is like the channels that make up the bitcoin network, but they contain arbitrary state. The 2 participants of the channel can make bets with each other without wasting space on-chain.

I have a way of doing this, which I will try to publish tonight I guess.

Zack, you should be aware that I believe a few things:

1. No one involved with Ethereum knows anything useful about Bitcoin, the blockchain, or smart contracts. They are so far gone that it is pointless to even open a dialogue with them (about anything).
2. Generalized Smart Contract platforms (Ethereum/Rootstock) destroy the ability to compute an honest Oracle, making Truthcoin impossible while such systems exist. Since they provide no other benefits, Eth/Root will almost certainly not exist.
3. Moving the oracle resolution off chain is a bad idea, something akin to individuals who only pay taxes if they needed to call the police for help last year -- the result would be an underfunded police department, rampant theft, and everyone smart would move away (or avoid accumulating capital)...it would be impossible to ever raise tax money, in any way, and the town would have collapsed into violence and/or be avoided by everyone.

You are free to spend your time however you like, but it is a shame to see someone so dedicated waste so much spirit.

Hello Cryptophilanthropist,

I apologize for our lack of Roadmap. My experience has been that adding new helpers consumes more overall time than it saves...but that does not excuse my failure to lay out something so basic. I am drafting a version as we speak and will probably finish it up in a day or two.

It will (hopefully) include some descriptions of where everything is, and what the various classes are, and what I plan to do, and what I hope other people will do. Then, I'll probably post weekly updates.

Paul

The mechanism I describe for flying fox would allow them to own the full 94% they paid for.

Can you describe why you think that that is desirable? Most would say that the asset should serve it's current owners, not prospective new owners.

I think we have been approaching the POW vs POS problem from the wrong direction. Comparing cost of consensus mechanisms is the wrong way to think about this.

Yes, because as I and other have patiently explained many many times, all crypto-monetary consensus mechanisms must cost exactly the same.

It is bad to connect the consensus mechanism to the coin creation mechanism, because the rate of coin creation should be determined by the demand for new coin.

Because the units of money are of type="fractional", the creation of money is inherently redistributive -- it is a tax on some and a subsidy to others. The topic of what, if anything, should influence the rate of coin creation (particularly in the context of open source software) is very complex. I do not agree that it "should" be determined by the demand for new coin (whatever that would mean).

If your system is rewarding "miners" with transaction fees, it is still paying out coins.

So you still need to explain why you think that my general proof is wrong.