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

[Ultros]

It seems we have consensus?

Well yeah the 4-5 of us are in agreement. Let's take over the world. 

Idk about you guys but here it's quite early in the morning. Give it time.

[leathan]

 CPU + GPU mining (about 1:1 performance for now)

Is this still real? Do you suspect it will hold up? Sorry if thats hard to answer.

[user2]

Hey guys, sorry if my question has been answered somewhere on previous 700 pages

This mining tax (on block rewards I gather?) you were discussing, did you mean to hardcode some wallet address in bitmonerod?

[OrientA]

CPU + GPU mining (about 1:1 performance for now)

Is this still real? Do you suspect it will hold up? Sorry if thats hard to answer.

For me, the CPU:GPU (AMD) is about 3:2. CPU is more efficient. That is why hash rate is so high as CPU miner can still make a profit.

[smooth]

CPU + GPU mining (about 1:1 performance for now)

Is this still real? Do you suspect it will hold up? Sorry if thats hard to answer.

Neither performance has changed much over the past few months as far as I know.

Whether it is really 1:1 depends on how you measure. A low end GPU (750ti for example) seems to hash something comparable to high end desktop CPU, with comparable power usage, but the GPU is much cheaper (though it requires a computer) and building a multi-GPU rig is very practical (with either these or higher end GPUs that are faster allowing for high capacity rigs, but at slightly worse hash/watt).

However, it is certainly true that the performance ratio is quite low compared to other algorithms and CPU mining can still compete.

Whether it will "hold up" in the future is something I doubt anyone can really answer.

[smooth]

Hey guys, sorry if my question has been answered somewhere on previous 700 pages

This mining tax (on block rewards I gather?) you were discussing, did you mean to hardcode some wallet address in bitmonerod?

No particular implementation has been discussed at all.

Of course since everything is open source you can't hard code anything really, since people can just modify it or take it out.

[user2]

...

Of course since everything is open source you can't hard code anything really, since people can just modify it or take it out.

Not if you are putting it in the blockchain.

Edit: I mean if for block to be considered valid 1% should be sent to some hardcoded address.

[smooth]

...

Of course since everything is open source you can't hard code anything really, since people can just modify it or take it out.

Not if you are putting it in the blockchain.

The blockchain is only validated by the software people use. If people modify the software, we can't prevent that at all, nor would we even try to force anything on the community.

This is getting a bit off topic though, but I'd encourage you to read http://hackingdistributed.com/2014/06/19/bitcoin-and-voting-power/ (even though I don't 100% agree with it -- but it gets at the relevant issues).

Ultimately we can't put anything in the blockchain, only you, the community can do that.

[user2]

...

This is getting a bit off topic though

Okay, to stay on the topic. I'm community as you rightly noted and I'm a miner and I think that's a great idea. To split (or tax or whatever) block reward to finance development or whatever the said community deems necessary. If only the proceeds would go to some special address and can be spent by some voting system hardcoded in the client (and some special transaction put in the blockchain). Something akin multisig only for all coin holders . If community can't decide on what she wants money is unspent, no harm done.

Edit grammar

[fluffypony]

Okay, to stay on the topic. I'm community as you rightly noted and I'm a miner and I think that's a great idea. To split (or tax or whatever) block reward to finance development or whatever the said community deems necessary. If only the proceeds would go to some special address and can be spent by some voting system hardcoded in the client (and some special transaction put in the blockchain). Something akin multisig only for all coin holders . If community can't decide on what she wants money is unspent, no harm done.

Edit grammar

The problem is that in these early stages we (as in the core team) need to take the role of "benevolent dictator". The reason is that "design by consensus" has never worked - invariably someone or some group will be able to swing the vote in favour of what "they" want. By having a "benevolent dictator" that the community trusts will act in the best interested of the cryptocurrency (and not in the best interests of individuals with voting / buying power), AND who will revert a change / proposition if there is sufficient kickback, you allow for a more unified vision to be realised.

As a core team we have a pretty concrete vision, but it's hard to put it down on paper and look ahead when we're scrabbling to fix urgent things right now.

What I think would work is for us to raise funding to sort out the short-term urgent issues, and then longer-term we can raise funds for specific features / aspects.

[XDO]

Haven't heard anything on per kb fees for a while. The current high transaction fees are really damaging mining profitability for small miners like me, and are also exposing us to greater risk as we move coins to the exchange less frequently.

It would be great if the new fee structure could be implemented sooner rather than later. I see lots of check-ins recently implementing the TestNet, hopefully this is the last necessary prerequisite for the change in fees?

[smooth]

It would be great if the new fee structure could be implemented sooner rather than later. I see lots of check-ins recently implementing the TestNet, hopefully this is the last necessary prerequisite for the change in fees?

Yes, exactly. We need to test the per-KB fees code on a testnet. The code for per-KB fees has been largely done for a while, but we're not going to release it without testing. (We've been fairly lucky about releasing some changes without a testnet before, largely out of necessity, but let's not press our luck.)

EDIT: typo testing->testnet

[XDO]

Yes, exactly. We need to test the per-KB fees code on a testnet. The code for per-KB fees has been largely done for a while, but we're not going to release it without testing. (We've been fairly lucky about releasing some changes without a testing before, largely out of necessity, but let's not press our luck.)

Great. Thanks for the update. Hope the testing goes without a hitch.

[oda.krell]

plus 1 for classical fundraising, minus... a lot for a forkraiser. As if we don't have enough detractors, just imagine what will happen if we build a payout into the protocol.

Who exactly is detracting BBR for it?

I think we will have detractors for being (slightly) successful no matter what we do. I don't think the mining fundraiser is necessarily a bad idea nor would have any material change on the degree of hate directed against us.

Got no problem with an optional payout (and even setting it to non-zero as default in the official client).

The proposal I reacted to made no mention of it being a setting, i.e. optional, however.

[SlyWax]

Today In POW cryptocurrency, we give the money creation to the people that are securing the network.

So how this money is distributed :
- Chipset makers
- Electricity
- Cloud server service
- Miner margins

In the beginning the miners margin is big ( using already owned hardware, idle cycle, not a lot of concurrence, etc... ), then when the coin get noticed, the miner margin tend to shrink. Why is that ? Well mainly because there is no human value added in mining (basically you set up your node and the rest is just computer running), so you can scale it up without much work.
In this tread I read that the miner margin is around 5%. So that leaves us to 95% is given to actors that aren't involved in crypto at all.
So when you are defending the miner part, you are basically defending this 95% !

But there is much more about a cryptocurrency than securing the network.
And that bring us to development.
Maybe it's time to realize that this money creation should be used to this extent too !
So setting a % of money creation to support development is the road to sustained growth of features and code security.

The problem is, we have a commonly accepted way of distributing money to the network securer (you should note that I didn't say fair, because the more it goes the less it's fair), but not yet for the developers part.

So the next step would be to figure out an acceptable way of distributing the developer incentive.
And that would be the subject of another post.

SlyWax.

[infofront]

As a miner myself, I would support a small mining tax. We could see how a crowd funding approach works first though.

[binaryFate]

... a small mining tax ...

That sounds awfully altcoinish.

[fluffypony]

Got no problem with an optional payout (and even setting it to non-zero as default in the official client).

The proposal I reacted to made no mention of it being a setting, i.e. optional, however.

Ah ok, so just to make sure everyone's on the same page, this is the screenshot from the Missive:



The idea was to make it "ticked" by default, and it's a per-wallet setting, but if people want to disable it or increase/decrease the percentage they can at any time. Before the GUI is even released, though, we wanted to add this in to simplewallet / rpcwallet - again, prompted during wallet creation, and configurable at any time.

Now I know this seems like a small amount, and it won't do much difference, and you're right. This is not going to satisfy the immediate and large funding requirements. Which is why this is more of a longer-term thing to make sure we always have budget for ongoing efforts / maintenance. It does not preclude fundraising for specific features / tasks.

[oda.krell]

Got no problem with an optional payout (and even setting it to non-zero as default in the official client).

The proposal I reacted to made no mention of it being a setting, i.e. optional, however.

Ah ok, so just to make sure everyone's on the same page, this is the screenshot from the Missive:



The idea was to make it "ticked" by default, and it's a per-wallet setting, but if people want to disable it or increase/decrease the percentage they can at any time. Before the GUI is even released, though, we wanted to add this in to simplewallet / rpcwallet - again, prompted during wallet creation, and configurable at any time.

Now I know this seems like a small amount, and it won't do much difference, and you're right. This is not going to satisfy the immediate and large funding requirements. Which is why this is more of a longer-term thing to make sure we always have budget for ongoing efforts / maintenance. It does not preclude fundraising for specific features / tasks.

Has my support, as long as it will always remain optional. Leaving it as 'opt-out' is also fine with me, we're adults who should be able to read/decide

[oda.krell]

Quote and my response from the speculation thread, where it was off-topic (thanks smooth for the heads-up)

In my opinion the emission schedule should be decreased by 50 %.
For example, the current block reward is around 14 xmr - better to change it to 7 xmr.
It will help the dumping pressure and gives nice and steady growth for the coin.
The existing balances and total number of coins should not be touched but just give 100 % more time for the rest of emission.

Some would call it a community-fastmine. Not like I'm saying it's fundamentally bad, but it doesn't look clean.

If something like that were to be done, and I'm not saying it is even on the table, it would have to be for better reasons, like the long term viability of the coin. Every time the issue has come up, though, it is always presented as a way to manipulate the market. That is a total non-starter. We could convert to a PoS shitcoin if we wanted, and not have to deal with any dumping at all. There is zero interest in doing that. Move on to one of the 1000+ of those if you want to be free from dumping.

Alright, I'd like to chip in on that.

Preliminary remark: Please assume good faith in what is about to follow. You can sometimes react a bit too abrasively - understandable given the constant attacks against this project, but not necessarily always a justified reaction to what you respond to.

a) There are good reasons for thinking that a different emission would be desirable, put forward by members of this community that are not interested in a quick p&d, but instead have a long-term interest in this project.

Note: I am not saying they are necessarily better than the arguments of the opposing side, but they are not all to be dismissed as "pump and dumpers GTFO".

b) No one in his right mind is suggesting a quick curve change to prevent price from dropping. This is not supposed to be a quick fix to a temporary problem (like a flash crash), if it were to considered. It is a complex question that has to be seriously discussed before considering implementing it.

c) The April vote made it clear that there would be a very real problem with a 'smooth' curve switch, in the sense that it would require somehow giving back coins that were mined "ahead" of the new curve. I am going to go out on a limb here and say that's not really a realistic option anymore.

d) Which would mean a change in the emission curve would be discontinuous, should it come to that. Which, correctly mentioned here already, would possibly open up the door to "community fast-mine" accusations coming from outside (and maybe even inside, by community members that came here later).

I am not convinced if that is the end of it, though: I still think that, should the community / economic majority favor a change in emission, referring back to that community choice would leave those accusation mostly impotent, but I understand that there are now two open questions:

- do we want a change in emission? (if so, what are the pros/cons?)

- can we afford a change in emssion? (as in: will the negative reactions be prohibitively expensive).