[XMR] Monero - A secure, private, untraceable cryptocurrency

[Anon136]

As for the social contract obsession. Its important. Granted it creates some problems of course reasonable flexability would be ideal. But without the social contract you have nothing. You have no trust. No one knows what they are buying.

Monero is at an embryonic, barely usable stage (particularly when considering the potential for attacks, exploits, very damaging but unintentional coding errors, etc.). We used to call it alpha-quality software. With the benefit of the past six months of experience, I'd demote that to pre-alpha proof of concept.

I mostly agree that getting to a point of a "hard" social contract with inviolable trust is a good goal (I think there are alternatives but they are vague and not fully developed, so I won't go there), but I'm not convinced we are ready to do that yet, in a practical sense.

Ah right you were talking about monero and i was talking about bitcoin. I agree that there is no clearly defined social contract with monero yet. Not the same as saying that there is none at all. You clearly cant go and double the money supply after people already bought in for example. But with that said, neither are the exact specifics of the emission curve set in stone either, for example. Fundamentally i think we are in agreement here.

It should be obvious that as long as you are relying on a central developer team for critical fixes and essential features, you are not operating a decentralized cryptocurrency at all. Instead, you are holding a speculative crypto asset that might, someday, turn into a decentralized cryptocurrency.

decentralized can mean different things in different contexts. monero is decentralized in the sense that it uses a decentralized proof of work mechanism to generate network consensus and provide byzantine fault tolerance. but yes in other ways it certainly is less decentralized than it could be.

When mistakes are recognized as this early stage, the benefits of fixing them outweigh the disadvantages of being stuck with them forever. And in reality, as you say, even Bitcoin isn't stuck with anything forever. If it were to fail catastrophically, this "trust" you describe would be broken out of necessity anyway. I say fix what we can now, when the impact is relatively small, to avoid the potential for much bigger and worse impact later (or what I consider more likely, the reaching of a fairly low success plateau where the "untouchable" mistakes limit further growth).

Yes i agree. and that is why i say that we have something of a loose sort of tennative social contract that is developing as a result of discussions just like these and slowly solidifying with time. Its like wet concrete that is every day in the process of becoming slightly more dry.

We are at a natural transition point right now, after having worked for nearly six months, having recognized that the initial donation funding model is a failure, the coin needs a lot more work than any of us realized, and has also in some ways been more successful than any of us expected. Let's regroup a bit, not take anything off the table, and do whatever needs to be done to really push this far beyond where it is right now.

total support.

[iCEBREAKER]

without a lower limit, it is uncertain whether tx fees will be sufficient to provide incentive to miners.

It is not uncertain, it won't work. The "hard money" BTC types are being unrealistic about how the technology operates, entirely indepetent of whether their monetary theories are valid or not (I take no position).

BTC is on a collision course with failure, or being reinvented as a centralized ledger system (with the degree of centralization that already exists its almost there already, so this isn't hard to imagine at all) or switching to PoS or something else equally retarded. This is a good example of what I'm talking about when it comes to not being strangled by an inflexible "social contract."

The only way it could possibly work would be that have some internal source of mining rewards that don't increase the money supply, for example demurrage. Actually that's the only one I could think of but maybe there are others. But I guess the Bitcoin version of "social contract" probably prevents that too. Bitcoin is likely beyond saving.

There is a reason that Monero was designed with a minimum block reward, although I'm skeptical that the rapidly declining rewards will continue to secure the network even long before the minimum kicks in. Still better than Bitcoin though.

Thanks for your insight.  Luckily for us, the letter of Monero's social contract is still a work in progress.  The spirit of voluntarism is what we are inflexible about.  Even in Tacopia, hard principles like property rights have exceptions such as taxes, easements, eminent domain, and adverse possession.  Subsidies and externalities must be eliminated if possible and regulated if not.

Since we'd like to replace lost coins as they presumably become more valuable (and less likely to be lost), what about a diminishing lower limit of something like 17.59 XMR/(block height^1/3) for all blocks after coin 18.4MM?

Edit: Initial reward/cube root(height) gives a reward of 0.0968 XMR at block 6,000,000.  That seems about right, and provides 139 XMR/day for miners.  Somebody else will have to math the limit on the sequence, I've been up too long.

[smooth]

Did I miss the discussion about the cost/difficulty of exposing multisig?  I see it's already in Cryptonote...

I don't think we have come up with a concrete estimate. We reviewed the implementation from Cryptonote and found it to be of generally poor quality and largely unsuitable to use. Further, carefully vetting it (since they can't be trusted) would likely be too expensive to be practical.

It also has the limitation of not working with ring sigs. I'm not sure that is a show stopper, and it is allegedly fixable, but no one has written down a full design for doing so (that we have seen). Even in our own implementation, we'd have to decide whether to take that on or not, since doing multisig without ring sigs is rather more obvious and well defined.

Let's add multisig, trustless Blockchain type web wallet, and p2pool to our Wish List of items for the final platform to be funded by the Bootstrap.

Agreed.

Anything else crucial we want, while keeping within the 184k XMR/~$300k budget?

Open to suggestions!

[smooth]

decentralized can mean different things in different contexts. monero is decentralized in the sense that it uses a decentralized proof of work mechanism to generate network consensus and provide byzantine fault tolerance. but yes in other ways it certainly is less decentralized than it could be.

Remember, I said you are relying on developers for critical fixes. Which means on occasion (such as two weeks ago), this sort-of-decentralized system won't be able to use PoW to provide BFT (or to perform some other essential function) on its own without help from the developers.

Small point of disagreement though, and we generally agree on much of everthing.

Thank you for your thoughtful comments.

[iCEBREAKER]

Did I miss the discussion about the cost/difficulty of exposing multisig?  I see it's already in Cryptonote...

I don't think we have come up with a concrete estimate. We reviewed the implementation from Cryptonote and found it to be of generally poor quality and largely unsuitable to use. Further, carefully vetting it (since they can't be trusted) would likely be too expensive to be practical.

It also has the limitation of not working with ring sigs. I'm not sure that is a show stopper, and it is allegedly fixable, but no one has written down a full design for doing so (that we have seen). Even in our own implementation, we'd have to decide whether to take that on or not, since doing multisig without ring sigs is rather more obvious and well defined.

Let's add multisig, trustless Blockchain type web wallet, and p2pool to our Wish List of items for the final platform to be funded by the Bootstrap.

Agreed.

Ah good, we can count multisig as part of the overall CN refactor and not an additional task.

The Bootstrap Block presale will go much better if we provide details on exactly what the funds raised will be used for, so this is all very helpful.

We don't need to worry about making multisig compatible with rings for a while.  For dev fund purposes, mixin 0 is fine/required.  Once the Bootstrap frenzy is over, the Monero Research Lab can start work on more difficult longer term projects like ring multisig, pruning, and other forms of polishing to perfection, while funded by the ongoing miner devtax and any leftover Bootstrap funds.

[Anon136]

decentralized can mean different things in different contexts. monero is decentralized in the sense that it uses a decentralized proof of work mechanism to generate network consensus and provide byzantine fault tolerance. but yes in other ways it certainly is less decentralized than it could be.

Thank you for your thoughtful comments.

you as well

[iCEBREAKER]

Edit: Initial reward/cube root(height) gives a reward of 0.0968 XMR at block 6,000,000.  That seems about right, and provides 139 XMR/day for miners.  Somebody else will have to math the limit on the sequence, I've been up too long.

Good formula but still too much, if XMR is at ~1000usd at block 6mm thats ~140k fresh usd that new to flow daily.

What would the "~1000usd at block 6mm" market cap be?  I'm guessing it is high enough to justify/demand at least $140k/day worth of network security.

If we use inital reward/square root(height), the reward at 6MM falls to 0.00718 XMR/block, or 10.34 XMR/day.  Better?  $10k/day to secure a multi-billion dollar network seems far too low.  Of course tx fees also have to be guestimated and included...

We have our pick of many fancy numbers between 2 and 3 for fine tuning our eternal reward with irrational or transcendental flair.   

e  = 2.718 --> 0.0563 XMR/block6MM; 81.11 XMR/day

phi+1 = 2.618  --> 0.0452  XMR/block6MM; 65.14 XMR/day

6^1/2 = 2.449 --> 0.003  XMR/block6MM; 43.22 XMR/day

Adam's Question = --> 0.02916 XMR/block6MM; 42 XMR/day

5^1/2 = 2.236 --> 0.0163  XMR/block6MM; 23.529 XMR/day

pi-1 = 2.1415 --> 0.012  XMR/block6MM; 17.29 XMR/day

I'll start the voting by saying I have no preference and expect tx fees to dominate by block 6MM if the coin is a success.   

[grendel25]

Price of XMR going down, it makes me cold.  The leaves of autumn turn dreary and my spirit sinks.  The winter of my discontent comes the morrow.

[Hotmetal]

Price of XMR going down, it makes me cold.  The leaves of autumn turn dreary and my spirit sinks.  The winter of my discontent comes the morrow.

Until this whole "exploit" fiasco is sorted out, XMR (and likely other CN coins) are headed towards ground zero.

[xulescu]

Edit: Initial reward/cube root(height) gives a reward of 0.0968 XMR at block 6,000,000.  That seems about right, and provides 139 XMR/day for miners.  Somebody else will have to math the limit on the sequence, I've been up too long.

Good formula but still too much, if XMR is at ~1000usd at block 6mm thats ~140k fresh usd that new to flow daily.

What would the "~1000usd at block 6mm" market cap be?  I'm guessing it is high enough to justify/demand at least $140k/day worth of network security.

If we use inital reward/square root(height), the reward at 6MM falls to 0.00718 XMR/block, or 10.34 XMR/day.  Better?  $10k/day to secure a multi-billion dollar network seems far too low.  Of course tx fees also have to be guestimated and included...

We have our pick of many fancy numbers between 2 and 3 for fine tuning our eternal reward with irrational or transcendental flair.  

(some examples)

I'll start the voting by saying I have no preference and expect tx fees to dominate by block 6MM if the coin is a success.  

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.

[Odalv]

I was wrong, now I'm beginning to understand. :-) Thank you for your patience and responses. Monero looks fine.

I cannot find out where is the check  SUM of inputs == SUM outputs + transaction fee. 
Can you help me ?

[acha]

Moneropool.com:

Network
 Hash Rate: 20.64 MH/sec
Our Pool
 Hash Rate: 9.04 MH/sec

35% not observed?

[generalizethis]

Price of XMR going down, it makes me cold.  The leaves of autumn turn dreary and my spirit sinks.  The winter of my discontent comes the morrow.

But what I bury in fall rises in spring
so get a shovel and we'll sing
to girls and dancin' and champagne
never found on Monero's blockchain


 

[nioc]

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.

For the bootstrap I was thinking along the same lines.  I was using 18.4M total emissions and the suggestion of 1% or 184k for X.  3.5M has been mined so for the 14.9M  remaining the block reward would need to be reduced, I assume this is what you meant by burning, by ~1.23%.  If burning till the end is too long for the "injustice" the % would need to be increased.  For 4 years from the genesis block I get 1.47% and for 3 years I get 1.67% for 16M and 14.5M mined respectively.  In one month from now it goes up to 1.28%, 1.53% and 1.75% respectively due to an additional ~1/2M more coins that will have been mined.  I don't do math but hopefully I got the arithmetic correct.

The idea of 1% for the devs going forward has been suggested in addition which is getting a bit steep. 

I am not suggesting anything but just putting some numbers out for perspective.  As David said we don't have to do just one thing but IMO it needs to be done soon.  I am using the original definition of soon.

[iourzzz]

Price of XMR going down, it makes me cold.  The leaves of autumn turn dreary and my spirit sinks.  The winter of my discontent comes the morrow.

Until this whole "exploit" fiasco is sorted out, XMR (and likely other CN coins) are headed towards ground zero.

Price may be falling as well due to Bitcoin falling.

[rpietila]

Might be good for someone to compare XMR price development over the two days to other altcoins. Might well be that the effect of FUD is not even existent...

[argentinx]

btc is going down because it can not longer be used to buy in the markets of tor
All purchases of bitcoin are tracked by the FBI
then they can not use them on the markets
are caught immediately
so you have to do a bit of advertising on XMR
in these markets
buy bitcoins and exchange them for XMR
and then use them to do what you want
if XMR does not do so
will do it some other CN currency
they will
before XMR
and lose the boat
if we do this will stabilize the price of btc
and at the same time, XMR could rise to levels that we can not imagine
you have to convince the markets on tor
to use XMR
this is the best thing for Monero

[generalizethis]

Price of XMR going down, it makes me cold.  The leaves of autumn turn dreary and my spirit sinks.  The winter of my discontent comes the morrow.

Until this whole "exploit" fiasco is sorted out, XMR (and likely other CN coins) are headed towards ground zero.

Price may be falling as well due to Bitcoin falling.

Just checked--only 2.44% lower on BTC scale. Much buy 

[OrientA]

Moneropool.com:

Network
 Hash Rate: 20.64 MH/sec
Our Pool
 Hash Rate: 9.04 MH/sec

35% not observed?

The hash rate is very concentrated.

Dwarf pool: 5.28 MH/s,
crypto-pool.fr: 3.5 MH/s.

So for those three total: 17.7MH/s, or 85% of total.

If those 3 were taken out, XMR is in trouble.

[smooth]

I was wrong, now I'm beginning to understand. :-) Thank you for your patience and responses. Monero looks fine.

I cannot find out where is the check  SUM of inputs == SUM outputs + transaction fee. 

There is no tx_fee stored in the transaction. tx_fee is computed as =(sum of inputs) - (sum of ouputs). If you are looking for that in the code and can't find it let me know and I'll point it out for you.