But Is It True?

Seriously though, this episode did not disappoint. When I read BullBear's reportage on the events I feel like reading the script to a Cold War spy movie.

Quality lulz

Is it true?

I've heard that the devs and whales have all the coins on Poloniex and will dump the price to 0, negative, then underflow to moon.

Is it true?

EDIT: OMG does this mean the devs and whales work with BCX to steal from Poloniex? Are they rob(b)in-hooding them? So we can all dump at moon price and make BTCBTCBTCBTC? Devs, whales, BCX, THANK YOU!!!

1. This discussion of what the reward will be at block 6M is completely inconsequential and simply spams the thread and the funding conversation. Nekomata simply provided an example, and your examples for the exponent prove that there is no practical difference between them given the orders-of-magnitude error bars on all the rest of the data.

2. All reward profiles that decay slower than ~ height^(-2) will lead to an infinite total emission, contrary to your earlier assertion that it needs to be finite. You propose decay between ~ height^(-1/3) and ~ height^(-1/2) which clearly generate nonconverging partial sums. So you contradict yourself.

3. I disagree with changing the overall shape of the emission schedule. There are good reasons to keep an exponential schedule and changing the base of the exponential leads to either (a) accusations of greediness among early adopters for increasing the base or (b) resentment from some early adopters for "halving their coins".

4. Exception to (3) for tail emission. Now the tail, no matter how it is chosen, must not result in increasing inflation, so inflation after the tail takes effect must be lower than inflation when the tail takes effect. Thus, it is not justified to change the emission schedule before inflation reaches that upper-bound (be it 1% or any other, as would be decided).

5. Even a simple schedule like "keep current until 1%, then keep 1%" leads to some possibly unintended consequences, like a nonmonotonic block reward (decreasing until tail starts, increasing afterwards). So making these decisions is not a simple task and should not be trivialized with arbitrary choices of irrational or transcendental values for the lulz.

6. The whole point of a different tail emission is (like smooth mentioned just a few posts earlier) that miners do not depend on transaction fees. Taking this to the logical conclusion, we should assume zero transaction fees for the purpose of the tail. Furthermore, the other purpose of transactions fees if not miner reward is spam prevention. This can possibly be deflected with proof-of-work "fee" and monetary transaction fees eliminated. You keep repeating that miners should be rewarded from the fees; this is precisely what we're trying to prevent with this discussion.

All these and some of your earlier comments like the inclusion of rpietila or CZ in the group that decides how the devfund is spent (7) suggest you either are trolling or have ulterior motives.

7. There is no reason or moral ground for a representative of the large holders or a competing crypto-currency to have this kind of decision power on the devfund. If CZ joins the Monero core devs, he would be entitled to that position. Similarly, rpietila will already represent the large holders to some degree through the Workshop. Once the Workshop dispenses half of the vote cost to the devfund, the Workshop should have no decision power on those funds.

I'm calling you out.

On topic:

I am still hesitant about the postmine, but if other methods like the crowdfunding do not work and it has to be done, then I propose we simply move emission from *before* the tail starts to the present.

Say a bootstrap block with reward X to the devfund is generated "soon". Then if X represents y% of the "total" 18.6M emission, it can be covered slowly by reducing mining reward by >y% until the deficit is covered. Thus the net effect would be that the core devs make a "loan" of X from "nowhere" at 0% interest, and then repay it back by burning part of future emission. This would make the bootstrap a contained problem, since it is a localized, surgical change in the emission schedule. To the first order, any injustice will only last until the devfund would have "repaid" the "loan".

But smooth, both for the crowdfunding attempt and as justification for the "loan", that spreadsheet needs to be done and it nobody but the core team that can do it.

It seems we have consensus?

But it's not begging. It's just filling a row for each task. It is an anticipated bill, if you prefer. Pretend you're a contractor and give an estimate for each task. Given the problem at hand, we're only looking for loose numbers.

I don't think once a week is unreasonable. You could update the table every Missive under the dev diary or as a "finance diary". It shouldn't take more than ten minutes. You don't handle the collection of the funds either since Anon136 offered to be the escrow.

But asking for funds is totally the way to get funds. In startups and FOSS alike, until the project gets a/some large enough backer/s.

Again, we don't want PowerPoints or grant proposals or anything like that. Just more transparency and accountability on the progress of the various branches of development that take place. And all this in the simplest, fastest and most minimalist data format that maintains easy readability. I believe you can raise enough now for a buffer and that monerists are going to read the Missives and vote on branches with their cash.

@smooth, @ultros,

Also consider that any price appreciation means we can better support you in the future. We need to get you a good chunk NOW and get the ball started. We don't need to decide on milions in the future. At least not now.

But smooth, look how absurd this discussion has become. The platform we would like IS the spreadsheet and an escrow. We have the escrow. I gave you the column headers I desire and find reasonable. I told you how many rows I would like in the spreadsheet, as a rough order-of-magnitude measure. Heck, it doesn't have to be a spreadsheet, just a forum post with tabs is enough. Is it that much of an effort to populate the fields? I can throw in 10 XMR to help grease it up. Is the project really not more modular in tasks than fluffypony's post? Surely there are more dev branches than that!

That logic doesn't work. You don't "develop" a product (i.e. the code), because if that was correct then I could just merge your changes into CryptoNoteX and derive the same benefit. That is clearly not the case as the distribution of coins is at least as important as the code (otherwise anyone could clone Bitcoin1-2-3-10 and they would be fungible with the original). You develop money, and an economy. Not a product, and not a service.

In this sense you are the central bankers (with limited powers).


This is not what I meant. My point is that the vote is not credible.

Suppose miners voted against, then they would damage your reputation and Monero. Thus, even if they might not agree to the screw-turn, the alternative is worse (i.e. why don't people rebel against inflation all the time? why do people just swallow injustices? because the alternative is often worse -- boiling frogs, slippery slopes, tragedies of the common and all that).

From this argument, a positive miners' vote would not indicate miners' approval, and the validity of the vote is under question.

Alternatively, suppose miners voted for and the motion passed smoothly (no pun intended). Then, even if this was indeed optimal, there would be suspicion of collusion between devs and miners, not unlike that between the corporations and the governments of the world. Monero's reputation, as well as the devs', would be damaged again.

From this argument, a negative miners' vote would not indicate miners' disapproval, and the validity of the vote is under question.

This is what I mean by misaligned incentives. No matter the outcome, it will not convince those who "lose" that their rationalization is incorrect and that Monero has not been corrupted by (a) greedy devs (b) greedy devs and miners colluding. From a reputation/credibility point of view, it's a lose-lose scenario unless transparency can counter both options (a) and (b) above.



We don't want grant proposals, we want transparency and accountability. We don't want to continue the "voluntarist" approach, in which you place a hat and start playing the instruments. We want to participate in a crowdfunding platform, which has been promised to us. We want to be able to back tasks and to observe how and what others back. But to do this, we simply need a list of SOME tasks in just marginally finer grain and more detail than what fluffypony already posted.

1. task id/name/description
2. estimated cost interval (XMR)
3. estimated time interval (weeks?)
4. estimated urgency
5. estimated impact

It probably takes you less than half an hour to compile this. But the non-developers among us need to understand more to throw our cash. Like aminorex said, again, "telling me to <<trust you>> does not inspire confidence" (paraphrasing).

We just want your best first guess. Again, just marginally finer grain and more detail than what fluffypony already posted. And if it doesn't work and no other solution seems workable, then it's time for the manual override.

We are trying to reach consensus here. If devs propose this and miners refuse, devs lose credibility. Thus miners would not refuse even if the decision is against their interests unless they wanted to damage Monero. This is a perverted incentive, related to the fact that there is not one 51% attack that is not in the attacker's best interest, but that the attacker would make it in the others' best interest to not disagree. I'm not saying the devs are going to steal it all and leave (heck, I'm arguing they already have supreme power now). What I'm saying is that this misaligned incentive makes the vote result biased (or at least makes it not convincingly unbiased) and that leads to the reputation damage I mentioned.

Also, "wrongheaded thinking" is a loaded expression. It is patronizing and denotes that you don't really consider other points of view. If the best counter-argument is "that's wrong" maybe you need to engage a bit more in the conversation.


This distinction becomes blurry and troubling when Walmart issues your currency. Or other imperfect analogy of the kind. You conflate the dev team with a company again.


Like I said earlier, I see it as a measure of force majeure. The atomic solution. It is clearly better than the devs packing and taking a hike. But I want to fully explore the posibilities before signing up to this.

More transparency about the funds and their destination would definitely attract more donations. Make a list of 10-30 itemized atomic tasks, how much effort (XMR) they require, what are their expected time requirements, what is their urgency and their impact. An Excel sheet could work for now, and a Form for investors to indicate binding or nonbinding commitment for each of the projects.

Also, @smooth: crowdfunding also works really well with completely experimental games. Sure, they often flop, but not because they didn't get the money but because they were either unrealistic in their requirements (too low) or inefficient.

I believe many things are wrong with this approach. I would ONLY use it as force majeure because it is so damaging to the image of Monero. It is not a business, it is not a producer, it is not a company or a startup. It is an open-source project in an environment of extreme suspicion. If something is imposed on the miners it is not a donation, it is a tax, and to pretend otherwise is doublespeak.

We are here because we don't believe it is wise for any entity, especially one as central and powerful as the developers, to have a rent on the system. We are here because we are dissatisfied with exactly such a system.

I have to agree with aminorex here:

1. Reputation damage
2. Corruptability / Tragedy of the commons
3. Yields too little now, too much later
4. Market methods are likely better in a suspicious environment - crowdfund small specific tasks, with specific requirements

Of course, "swag" of any kind is good and memorabilia better. Humans hoard and owning a unique/limited asset can be worth very large sums for some.

What I do not understand is, why you downplay the reputation damage, the socialization objection and the market methods, and handwave a complex adjustment mechanism for the tax level that looks even more worrying than a fixed 1% tax. Remember that the income tax in the US started at 1% as well.

I will consider this sarcasm, because you can't possibly be suggesting an impromptu premine.


Any compulsory tax erodes community trust, because it is still essentially a pre/post/fiatmine.


The emission curve must not change under any circumstances (except for long term behaviour). Remember how tense was the proposal to flatten the emission curve back in the beginning. I supported the change but ultimately it felt through. The opposite move will be viewed from outside as greedy and scammy even if I, you, or any of the old monerists feel it is fair.


Generally I agree with the miner tax as long as miners vote to soft-fork to the tax code. There could be some interplay with the pools also donating to the same fund - people could feel "double-taxed".

I believe the best option is to piggyback on the transaction fees. For instance, since the transaction fee hike after the spam attack, miners have seen a small increase in margins that retracted somewhat as more miners joined and drove the difficulty up. So no matter how the fees are reduced it will drive miners out. But suppose that the fees will be 0.02-0.2 XMR instead of 0.01-0.1 XMR and the fee was split equally between the miners and the devs. The transaction fee is not part of the social contract; the miners are in the same situation as if the fee was halved and the devs were getting nothing (except a slight decrease in transaction count - but since the change from 0.005 to 0.1 reduced transactions by ~25% that will not be significant); furthermore, the fees are small compared to the coinbase - XMR is still in the same regime as BTC.

I could further argue that there is consensus about the fee escalation tragedy of the commons in this thread and that is the main reason why Monero will have a perpetual debasement. If fees are to be kept NOT an incentive for the miners generally then their main purpose is spam protection. I used to think transaction fees should eventually be replaced with proof-of-work -- instead, they could entirely go to the dev team, with or without proof-of-work.

Please critique.

I did miss something - you were talking about a mining fee. I am generally OK with that, and I believe both the miner-voted miner-paid and tx-fee-donations can be used if necessary.

However, I believe it is essential for community trust that the development fund is made transparent before that.

I'm sorry, I must be misunderstanding something here. Are you suggesting a miner-dictated mandatory tax?

I am all for default-on developer-team donation together with transaction fees as long as the option is clearly presented in the wizard (as per the new wallet screenshots). But I am all against making it mandatory (even with the miners' blessing).

Golden.

The syntax is "transfer {mix in} {wallet address/account} {amount} {optional, payment ID}". So 45VC... is the address and 956e... is the payment ID.

Please use a mix in of at least 4 to take advantage of ring signatures. For the moment the transaction fee is constant, no matter the size of the transaction, and a larger mix in hides you among more others. So mix in = 0 means you are the only one signing the transaction, so it is just as transparent as Bitcoin who sent the money. Mix in = 4 should be sufficient for all common transactions.

This should not be possible as the 0.8.8.3 daemon has a checkpoint after the fork.
Are you positive you're running the new daemon and not an older one by accident?
Are you positive the daemon is loading the blockchain from the OP?

If both questions answer "yes", try to close the daemon, delete poolstate.bin and p2pstate.bin and restart the daemon.

Just mentioning that building Monero on Ubuntu 12.04 x64 is noob-safe.

install ubuntu, wifi driver, update, upgrade, dist-upgrade, run install_monero.sh, (choose make essentials, compile boost)

Also, it would be a good idea to correct the idea that Monero has a complicated recursive block reward (and further proof of intentional obfuscation). Shameless plug:


It's like Bitcoin, but ~2x faster and without the sudden halvings.

Percentage fees are exactly the rent seeking behaviour that cryptos try to remove.

There is no way to access the price of a coin inside the coin's code, because it is an extrinsic property.

Maybe proof of work could be used instead of tx fees or somehow incorporated? Would it help if you had to hash something when sending?