Regarding inflation after the 18,000,000 coins are minted.
I believe that a constant amount of coin release is superior to a 1% inflation. The Ethereum guys are going to probably do it this way.
1% constantly devalues everyones coins, whereas if we just made the final block reward 1 MRO, thats about 500,000 mro per year (Or 250,000 per year with 2 minute blocks). It would be about 2% inflation for that year it came into effect, but would gradually become less than 1%.
A fixed eventual supply of 500,000 mro is going to always be enough to entice miners. Remember that the value of those 500,000 will probably increase as time goes on.
A 1% reward will just devalue the currency for everyone else.
A constant supply will create a long term rare coin without the reward problem that Bitcoin will run into.
I am a fan of the economic model of constant supply. I am not a fan of 1% inflation.
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1925. (Read 4671660 times)
Thanks to Tacotime and all the devs who brought this coin to where it is today. Looking forward to tomorrow.
np, the experimental branch should put an end to blocks like this: http://monerochain.info/block/7933b43b3bf22479dfcf1a4fec2c401ffbcbb8a078db989675c51d77c6c8ecd9
Thanks for the update! I'll try it out now too. Maybe you or someone explained this already, but how does the regular update work? Does it restrict tx sizes by denying large size transactions and couple the larger ones with the higher fee? Or are all tx's going to have the same fee you set regardless of size now? What's different with the experimental update 0.8.8? Does it scale on the medium block size or something?
Thanks to Tacotime and all the devs who brought this coin to where it is today. Looking forward to tomorrow.
np, the experimental branch should put an end to blocks like this: http://monerochain.info/block/7933b43b3bf22479dfcf1a4fec2c401ffbcbb8a078db989675c51d77c6c8ecd9
How frequently is this happening?
See for yourself; http://monerochain.info/
Thanks to Tacotime and all the devs who brought this coin to where it is today. Looking forward to tomorrow.
np, the experimental branch should put an end to blocks like this: http://monerochain.info/block/7933b43b3bf22479dfcf1a4fec2c401ffbcbb8a078db989675c51d77c6c8ecd9
How frequently is this happening?
Thanks to Tacotime and all the devs who brought this coin to where it is today. Looking forward to tomorrow.
np, the experimental branch should put an end to blocks like this: http://monerochain.info/block/7933b43b3bf22479dfcf1a4fec2c401ffbcbb8a078db989675c51d77c6c8ecd9
New Windows binaries are available that are compatible with the fee update and tx size restrictions.
https://www.dropbox.com/s/38aa9pb9zfw7ltf/monero.win.x64.0526.zip
https://www.dropbox.com/s/uevvh90maa8r1zm/monero.win.x86.0526.zip
Those wishing to try to the experimental 0.8.8 branch may also use it:
https://www.dropbox.com/s/aqcz044228veu92/monero.win.x64.experimental.0526.zip
https://www.dropbox.com/s/nfeqsv9i2zx9dox/monero.win.x86.experimental.0526.zip
Please let me know of any bugs it may have.
https://www.dropbox.com/s/38aa9pb9zfw7ltf/monero.win.x64.0526.zip
https://www.dropbox.com/s/uevvh90maa8r1zm/monero.win.x86.0526.zip
Those wishing to try to the experimental 0.8.8 branch may also use it:
https://www.dropbox.com/s/aqcz044228veu92/monero.win.x64.experimental.0526.zip
https://www.dropbox.com/s/nfeqsv9i2zx9dox/monero.win.x86.experimental.0526.zip
Please let me know of any bugs it may have.
Thanks to Tacotime and all the devs who brought this coin to where it is today. Looking forward to tomorrow.
New Windows binaries are available that are compatible with the fee update and tx size restrictions.
https://www.dropbox.com/s/38aa9pb9zfw7ltf/monero.win.x64.0526.zip
https://www.dropbox.com/s/uevvh90maa8r1zm/monero.win.x86.0526.zip
Those wishing to try to the experimental 0.8.8 branch may also use it:
https://www.dropbox.com/s/aqcz044228veu92/monero.win.x64.experimental.0526.zip
https://www.dropbox.com/s/nfeqsv9i2zx9dox/monero.win.x86.experimental.0526.zip
Please let me know of any bugs it may have.
https://www.dropbox.com/s/38aa9pb9zfw7ltf/monero.win.x64.0526.zip
https://www.dropbox.com/s/uevvh90maa8r1zm/monero.win.x86.0526.zip
Those wishing to try to the experimental 0.8.8 branch may also use it:
https://www.dropbox.com/s/aqcz044228veu92/monero.win.x64.experimental.0526.zip
https://www.dropbox.com/s/nfeqsv9i2zx9dox/monero.win.x86.experimental.0526.zip
Please let me know of any bugs it may have.
no merchant cares whether there are any confirms unless the value is high enough to wait.
Truth. Are you trying to steer toward a conversation about the market price? I'll bite.
What I see happening now is that the markets (and us) are paying for those who have overextended themselves. End of the month bills are now due and that includes rent, power and especially amazon. Altcoin markets are filled with this and I've seen this repeat at usually the last week of the month for a lot of 'overmined' alts. Not to say that this doesn't deserve the attention, but surely historic volumes tend to cause some people to go a little more nuts than they would not have otherwise. I just hope that people reading this, that are in that situation, can learn from this overshoot and maybe reach a little less far in the future. Just my thought is all.
So, whats everyones hash rates at?
Mines at a hefty 12.74KH/s
That is one big hashrate. What are you mining with? Mines at a hefty 12.74KH/s
Please keep the 1 minute blocks! Else Monero wont have a chance to compete with other coins for mainstream adoption. It's simply to slow for every day transactions. Any coin that shall be used in daily live has to beat the "Starbucks challenge", that is: Buy your coffee and settle the payment before you walk out the door. No merchant will accept a payment that requires him to wait minutes for settlement when credit cards or cash do that in seconds. If you argue that 1 minute blocks result in too many orphanes and are thus unfavorable for miners, I ask you to rethink your priorities when it's most crucial to design a friendly experience for the users instead of the miners that will stay regardless.
On the issue of emission schedule, Im also in favor of a flatter curve. 87% in 4 years is not much time. Most likely thats when cryptos really catch on. We should think middle- long term instead of short term gains if we want this one to succeed and also provide a reliable Bitcoin-like source of revenue. I'd be happy to halve emission per block while keeping block times intact for the greater good.
On the issue of emission schedule, Im also in favor of a flatter curve. 87% in 4 years is not much time. Most likely thats when cryptos really catch on. We should think middle- long term instead of short term gains if we want this one to succeed and also provide a reliable Bitcoin-like source of revenue. I'd be happy to halve emission per block while keeping block times intact for the greater good.
no merchant cares whether there are any confirms unless the value is high enough to wait.
So, whats everyones hash rates at?
Mines at a hefty 12.74KH/s
Mines at a hefty 12.74KH/s
I don't know if this has been addressed but zone 11 download link in op does not work.
Correct link is https://github.com/zone117x/cryptonote-easy-miner/releases/download/v0.0.3/cryptonote-easy-miner_v0.0.3.zipThank you
I don't know if this has been addressed but zone 11 download link in op does not work.
Correct link is https://github.com/zone117x/cryptonote-easy-miner/releases/download/v0.0.3/cryptonote-easy-miner_v0.0.3.zip Some additional features were added to my 0.8.8 branch:
- Merged in latest PR
- Temporary fix for block reward penalty being too large
https://github.com/monero-project/bitmonero/tree/0.8.8update
The latter is important for pools or miners who have been having issues with low block subsidy due to block sizes being too large. This new update will allow for the slow increase of median block size until we have a proper fees calculation, which will take more time.
The codebase appears to be relatively stable, as me and several others have been using it without issue, but I would like more comments. Upgrade at your own risk. Please note if you're using this daemon for mining, you will reject all tx with less than the minimum fee (5 * 10^9 AMU).
If you're using zone117x's pool, you will need to adjust your fees in your config file:
to
or else your payouts will not go through.
- Merged in latest PR
- Temporary fix for block reward penalty being too large
https://github.com/monero-project/bitmonero/tree/0.8.8update
The latter is important for pools or miners who have been having issues with low block subsidy due to block sizes being too large. This new update will allow for the slow increase of median block size until we have a proper fees calculation, which will take more time.
The codebase appears to be relatively stable, as me and several others have been using it without issue, but I would like more comments. Upgrade at your own risk. Please note if you're using this daemon for mining, you will reject all tx with less than the minimum fee (5 * 10^9 AMU).
If you're using zone117x's pool, you will need to adjust your fees in your config file:
Code:
"transferFee": 1000000,
to
Code:
"transferFee": 5000000000,
or else your payouts will not go through.
I don't know if this has been addressed but zone 11 download link in op does not work.
^^^ I will come out with a MIP for it (it's MIP0003), we will debate it there. Right now there's just a placeholder. I'm starting to lean towards tiny exponential inflation when we hit ~1% inflation per year.
https://github.com/monero-developers/mips
https://github.com/monero-developers/mips
That sounds very reasonable.
^^^ I will come out with a MIP for it (it's MIP0003), we will debate it there. Right now there's just a placeholder. I'm starting to lean towards tiny exponential inflation when we hit ~1% inflation per year.
https://github.com/monero-developers/mips
https://github.com/monero-developers/mips
We will be hard forking anyway to place a minimum subsidy so that the network doesn't die in 8 years.
Did we come to a reasonable solution regarding that? It was discussed quite a bit in the economics thread:
Tacotime mentioned a hard fork proposal to never let the block reward drop below 1 coin:
I assume this is merely delaying the problem, however. I proposed a fixed annual debasement (say 2%) with a tx fee cap of like 0.001% of the current block reward (or whatever sounds reasonable). That way we still get the spam protection without worrying about fee escalation down the road.
Code:
if (blockReward < 1){
blockReward = 1;
}I assume this is merely delaying the problem, however. I proposed a fixed annual debasement (say 2%) with a tx fee cap of like 0.001% of the current block reward (or whatever sounds reasonable). That way we still get the spam protection without worrying about fee escalation down the road.
As long as the subsidy is a fixed proportion of the existing money supply (and not a fixed amount), it should be adequate.
Question that I am trying to understand. This type of mining is new for me and I could not find the answer.
I have the wallet synced and created a bat file which opened cryptonote easy miner. The address in the cryptonote easy miner is not the same as my wallet address on the balance page. I can't change the address in the miner to match. Am I mining for someone else? Can I change that to my address in the wallet to match?
I also tried to pool mine in the wallet but nothing happens when I click on the start mining but it will solo mine in the wallet.
Sorry for noobish questions just want to make sure I am doing this correct.
I have the wallet synced and created a bat file which opened cryptonote easy miner. The address in the cryptonote easy miner is not the same as my wallet address on the balance page. I can't change the address in the miner to match. Am I mining for someone else? Can I change that to my address in the wallet to match?
I also tried to pool mine in the wallet but nothing happens when I click on the start mining but it will solo mine in the wallet.
Sorry for noobish questions just want to make sure I am doing this correct.
Some additional features were added to my 0.8.8 branch:
- Merged in latest PR
- Temporary fix for block reward penalty being too large
https://github.com/monero-project/bitmonero/tree/0.8.8update
The latter is important for pools or miners who have been having issues with low block subsidy due to block sizes being too large. This new update will allow for the slow increase of median block size until we have a proper fees calculation, which will take more time.
The codebase appears to be relatively stable, as me and several others have been using it without issue, but I would like more comments. Upgrade at your own risk. Please note if you're using this daemon for mining, you will reject all tx with less than the minimum fee (5 * 10^9 AMU).
If you're using zone117x's pool, you will need to adjust your fees in your config file:
to
or else your payouts will not go through.
- Merged in latest PR
- Temporary fix for block reward penalty being too large
https://github.com/monero-project/bitmonero/tree/0.8.8update
The latter is important for pools or miners who have been having issues with low block subsidy due to block sizes being too large. This new update will allow for the slow increase of median block size until we have a proper fees calculation, which will take more time.
The codebase appears to be relatively stable, as me and several others have been using it without issue, but I would like more comments. Upgrade at your own risk. Please note if you're using this daemon for mining, you will reject all tx with less than the minimum fee (5 * 10^9 AMU).
If you're using zone117x's pool, you will need to adjust your fees in your config file:
Code:
"transferFee": 1000000,
to
Code:
"transferFee": 5000000000,
or else your payouts will not go through.
A hard fork isn't that big of an impediment. It can be placed over a month into the future so that everyone in our relatively small community can upgrade clients in time. We will be hard forking anyway to place a minimum subsidy so that the network doesn't die in 8 years.
I'm also in favor of 2 minute blocks. It's arguably better for commercial situations as smooth pointed out because the additional confidence in confirmations beats the time penalty.
'Double-spend proof' actually has to do with properties of the one-time ring signatures that CryptoNote uses. It can be proven that when ring signatures are linkable, you can't create a false signature and spend a coin again. Forking is something else and always possible in PoW (or PoS) coins.
I think CrpyoNote's choice of words here is a little misleading since most people think of constructing a longer chain and releasing it when they think of double spending. We're still vulnerable to that.
I'm also in favor of 2 minute blocks. It's arguably better for commercial situations as smooth pointed out because the additional confidence in confirmations beats the time penalty.
Yes, thanks. I was just wondering because Cryptonote coins advertise being 'double-spend proof' and wanted to know if this was because however magical way the blockchain might be set up that nobody can fork it.
But ok, thanks
But ok, thanks
'Double-spend proof' actually has to do with properties of the one-time ring signatures that CryptoNote uses. It can be proven that when ring signatures are linkable, you can't create a false signature and spend a coin again. Forking is something else and always possible in PoW (or PoS) coins.
I think CrpyoNote's choice of words here is a little misleading since most people think of constructing a longer chain and releasing it when they think of double spending. We're still vulnerable to that.
Jump to: