You need to be able to say these are the things that we can change and these are the things that are core to the coin.
My opinion is the emission curve shouldn't be changed as in my opinion it is core to the coin. Despite the likely economic benefit to me if I were to take the other side.
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1390. (Read 4670630 times)
September 25, 2014, 07:38:35 AM
September 25, 2014, 07:37:52 AM
So, I just recompiled bitmonerod, and now it seems to be stuck on block 232616. Here's some of the output:
2014-Sep-25 00:59:26.151813 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:32.237618 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:38.255829 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:44.404735 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
Did I do something wrong?
2014-Sep-25 00:59:26.151813 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:32.237618 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:38.255829 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:44.404735 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
Did I do something wrong?
I'm in the same boat (and the same block). I'm wondering if it's due to everyone I'm connected to not being on the latest rev.
Smooth, my diff says:
2014-Sep-25 01:04:34.991768 BH: 232616, DIFF: 1074246915, HR: 17904115 H/s
Please make a new clone from github one more time. There was a bad commit that got removed but then got reapplied later. Some people ended up with the wrong one. Everything is fixed now afaik.
September 25, 2014, 07:37:17 AM
My interest in making changes would but entirely motivated by wanting to see the project succeed and believing that such changes make that more likely.
The problem with this philosophy is that at some point you are simply playing God with your own opinions.
You run into so many ethical questions that if nothing else it is simpler to have certain things laid out in a fixed state until the end of time so to speak.
September 25, 2014, 07:34:04 AM
So, I just recompiled bitmonerod, and now it seems to be stuck on block 232616. Here's some of the output:
2014-Sep-25 00:59:26.151813 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:32.237618 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:38.255829 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:44.404735 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
Did I do something wrong?
2014-Sep-25 00:59:26.151813 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:32.237618 [P2P5][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:38.255829 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
2014-Sep-25 00:59:44.404735 [P2P8][188.232.142.138:18080 OUT]Sync data returned unknown top block: 232616 -> 232692 [76 blocks (0 days) behind]
SYNCHRONIZATION started
Did I do something wrong?
I'm in the same boat (and the same block). I'm wondering if it's due to everyone I'm connected to not being on the latest rev.
Smooth, my diff says:
2014-Sep-25 01:04:34.991768 BH: 232616, DIFF: 1074246915, HR: 17904115 H/s
You can check diff-height on all pools via FrokGuard:
http://forkguard.com/
September 25, 2014, 07:31:08 AM
The sanctity of the original features be they good or bad must be respected.
That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
It deeply concerns me to hear you say that.
What do you think would happen if bitcoin developers turned round tomorrow and said we are changing the emission schedule because this new one is better we think?
I think bitcoins chances of success would go up (depending on what the were doing of course as it is certainly possible to make bad changes)
September 25, 2014, 07:30:46 AM
The sanctity of the original features be they good or bad must be respected.
Seriously now, this is a piece of software, not a religious doctrine. That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
That does not mean that something necessarily is broken, but "sanctity" precludes even considering it.
It is an economy that people bought into because of a set of basic rules that were presented to them - changing those rules is a material change to the original contract. The only way it could ever be considered is by obtaining a 50% majority of coins in favour of the changes and even then I would still be against it.
Which essentially means, if it would come to that, you recommend to go against an economic majority because it is different from your minority view (EDIT: in this scenario. Not saying your view is necessarily the minority view). Yes, makes sense.
It's really pretty simple: if the change of the original rules is perceived as so terrible that a large number of early buyers are sufficiently turned off, then a) there won't be an economic majority supporting the change, and b) if there would be an economic majority in support of changes, the early buyers in the minority can still sell. Wondrous how markets work like that.
I see your point, I was really trying to say that at or around 50% I think the status quo should continue. I'm not sure what the appropriate number for change would be economics suggest 50% obviously my personal view is that for such substantial changes that number should be closer to 60% for various reasons.
September 25, 2014, 07:28:55 AM
the problem with slowing the emission rate is that we create a worse off/ better off situation which differs from the beginning of the emission "contract" - that said nobody cares if we change the blocktime due to technical reasons and adjust the emission rate accordingly.
yep
The sanctity of the original features be they good or bad must be respected.
Seriously now, this is a piece of software, not a religious doctrine. That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
That does not mean that something necessarily is broken, but "sanctity" precludes even considering it.
It is an economy that people bought into because of a set of basic rules that were presented to them - changing those rules is a material change to the original contract. The only way it could ever be considered is by obtaining a 50% majority of coins in favour of the changes and even then I would still be against it.
agreed, I only speak for myself if Monero changes the emission I'm out.
I rather see it stagnate for months with no development if some devs thinks they are not getting their fair cut.
perhaps we see another fork like with the bitmonero, anything can happen if the community is backstabbed.
I can't speak for anyone else but for me it has nothing to do with a fair cut. My interest in making changes would but entirely motivated by wanting to see the project succeed and believing that such changes make that more likely. Of course it is fair to disagree on that point. Regarding voting if we were to do that it would not surprise me if such a thing could well be supported by 50%+ and not just because some whales support it but also because a great many people sincerely believe the emission of this coin is just too fast and that will impede success down the road. We are being forward looking.
Please try not to attempt to marginalized these view with inflammatory language such as fair cut or backstabbed.
September 25, 2014, 07:28:38 AM
what about icebreakers proposal for some kind of an postmine, which could be auctioned for financing development? For some reason I did not make entirely clear for me I think this is quite a good solution
September 25, 2014, 07:25:13 AM
The sanctity of the original features be they good or bad must be respected.
Seriously now, this is a piece of software, not a religious doctrine. That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
That does not mean that something necessarily is broken, but "sanctity" precludes even considering it.
It is an economy that people bought into because of a set of basic rules that were presented to them - changing those rules is a material change to the original contract. The only way it could ever be considered is by obtaining a 50% majority of coins in favour of the changes and even then I would still be against it.
Which essentially means, if it would come to that, you recommend to go against an economic majority because it is different from your minority view (EDIT: in this scenario. Not saying your view is necessarily the minority view). Yes, makes sense.
It's really pretty simple: if the change of the original rules is perceived as so terrible that a large number of early buyers are sufficiently turned off, then a) there won't be an economic majority supporting the change, and b) if there would be an economic majority in support of changes, the early buyers in the minority can still sell. Wondrous how markets work like that.
September 25, 2014, 07:22:00 AM
agreed, I only speak for myself if Monero changes the emission I'm out.
I rather see it stagnate for months with no development if some devs thinks they are not getting their fair cut.
I feel the same way. Whilst I am not the largest Monero holder my exit would certainly move the price.
September 25, 2014, 07:19:39 AM
The sanctity of the original features be they good or bad must be respected.
That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
It deeply concerns me to hear you say that.
What do you think would happen if bitcoin developers turned round tomorrow and said we are changing the emission schedule because this new one is better we think?
September 25, 2014, 07:15:08 AM
XMR is the future.
September 25, 2014, 07:14:05 AM
The sanctity of the original features be they good or bad must be respected.
Seriously now, this is a piece of software, not a religious doctrine. That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
That does not mean that something necessarily is broken, but "sanctity" precludes even considering it.
It is an economy that people bought into because of a set of basic rules that were presented to them - changing those rules is a material change to the original contract. The only way it could ever be considered is by obtaining a 50% majority of coins in favour of the changes and even then I would still be against it.
September 25, 2014, 07:07:55 AM
Slowing down the emission is a good idea to distribute the coin for longer period. We can achieve that by increasing the block time from 1 min to 3 min. We can implement that with 1 second block time increase per week. When XMR is adopted more in commerce, we can reduce the block time slowly, from 3 min to 1 min. The main reason to do that is that I found there is no transaction in most of the mined blocks.
Adjusting the emission in anyway is a terrible idea. I don't know if those suggesting it are simply selfish, incompetent or just have an overwhelming sense of grandeur.
I do not have many XMR. If we slow down the emission, more people can mine it for longer term in the future.
the problem with slowing the emission rate is that we create a worse off/ better off situation which differs from the beginning of the emission "contract" - that said nobody cares if we change the blocktime due to technical reasons and adjust the emission rate accordingly.
regarding the financing of development, I think this is the most crucial point in the evolution of monero. a development solely driven by donation does not work. I could write a wall to explain why this is different to the early days of bitcoin
September 25, 2014, 07:03:22 AM
Slowing down the emission is a good idea to distribute the coin for longer period. We can achieve that by increasing the block time from 1 min to 3 min. We can implement that with 1 second block time increase per week. When XMR is adopted more in commerce, we can reduce the block time slowly, from 3 min to 1 min. The main reason to do that is that I found there is no transaction in most of the mined blocks.
Adjusting the emission in anyway is a terrible idea. I don't know if those suggesting it are simply selfish, incompetent or just have an overwhelming sense of grandeur.
I do not have many XMR. If we slow down the emission, more people can mine it for longer term in the future.
September 25, 2014, 06:54:15 AM
The sanctity of the original features be they good or bad must be respected.
Seriously now, this is a piece of software, not a religious doctrine. That it function well takes precedence over sanctity, and if something is broken, perhaps by design, we should fix it.
That does not mean that something necessarily is broken, but "sanctity" precludes even considering it.
September 25, 2014, 06:49:36 AM
Transaction fees were always meant to be adjusted over time by the DEV team I think even a compulsory fee should have little to no negative impact on the economy where as changing the emission curve, which is a core original feature, changes the parameters by which every current owner of Monero agreed to be a part off.
The sanctity of the original features be they good or bad must be respected.
The sanctity of the original features be they good or bad must be respected.
September 25, 2014, 06:46:46 AM
I also think a lot of people would turn it off. The experience with p2pool where an extremely high percentage of users turn it off does not encourage me. That is a very valuable piece of software that provides a critical counterbalance against centralization of pools yet most users were so cheap they essentially killed the project by turning off donations.
I tend to agree with you, economics would suggest that the fee be default On but configurable and in the event that system failed then moving to a compulsory fee model. I think in practicality jumping straight to the compulsory fee model may just save time.
September 25, 2014, 06:41:13 AM
If the desire is to raise funds for development there is a clear way for this to be done and that is for either a fixed or % based fee be added to every and all transactions the network performs.
That's the current proposal on the table that is most universally liked, completely optional and configurable (default on @ 50% match tx-fee) per-tx donation. However, it is going to be an extremely sluggish way of fundraising, as it will only grow as the number of tx's grow. The counter-balance to this would be for people to set their donation % to, say, 150% or 200% of tx fees in the short-term, and then decrease that in future.
What is currently envisioned is doing it in a GUI client (more or less necessary to include the concept of people setting their own donation level), which would be even worse than a blockchain based method in terms of the amount raised because a good many of the transactions on the network now are not created by a human using a GUI. Thus the amount raised in the near term would be even more negligible. Of course it could grow in time.
It does address dust since the wallet could just keep track of the donation amount and send it occasionally in larger chunks.
I also think a lot of people would turn it off. The experience with p2pool where an extremely high percentage of users turn it off does not encourage me. That is a very valuable piece of software that provides a critical counterbalance against centralization of pools yet most users were so cheap they essentially killed the project by turning off donations.
September 25, 2014, 06:39:28 AM
If the desire is to raise funds for development there is a clear way for this to be done and that is for either a fixed or % based fee be added to every and all transactions the network performs.
That's the current proposal on the table that is most universally liked, completely optional and configurable (default on @ 50% match tx-fee) per-tx donation. However, it is going to be an extremely sluggish way of fundraising, as it will only grow as the number of tx's grow. The counter-balance to this would be for people to set their donation % to, say, 150% or 200% of tx fees in the short-term, and then decrease that in future.
The benefit of this model is that it has bilateral motivation. It motivates MEW to build the surrounding economy to increase transaction volume and it encourages DEV's to write good code to make the network more usable. I agree the LAG in between is an annoyance but that is all that it is and you could argue the LAG also increases DEV motivation and if nothing else certainly makes them more personally invested.
Configurable with default set to on seems like the most viable of the options, although compulsory is a close second.
Jump to: