I'm happy the Bitmonero attracts so much interest. I'm not happy that some people want to destroy it. Here is a simple a clear statement about plans: https://bitcointalk.org/index.php?topic=582670We have two kind of stakeholders we have respect: miders and coin owners. Before any protocol changes we will ask miners for agreement. No changes without explicit agreement of miners is possible. We will never take away or discount any coins that are already emitted. This is the way we respect coin owners. All other issues can be discussed, proposed and voted for. I understand that there are other opinions. All decisions that aren't supported in this coin can be introduced in any new coin. It's ok to start a new fork. It's not ok to try to destroy an existsing network. |
|
|
|
Hello! I have to write this post in order to make a clear statement about the future of Bitmonero and about plans we have because there is a lot of discussions that are very missleading for stakeholders (node owners and coin owners). 1. No protocol changes will be introduced in Bitmonero without explicit consent from miners. Why? - because miners are the main force that builds network security. No miners - no netwrok. - changes made without miners' consent are not possible technically. 2. There are two proposed protocol changes: - merge mining option - emission curve change option In both cases we will ask miners to state their opinion explicitely. The same voting procedure is used in Bitcoin. 3. No existsing coins will be discounted. There is a proposal to discount existsing coins but we don't accept it and no voting will happen about this. Why? Because discounting existing coins destroy trust to developers. All people having BMR coins now have stated their agreement with Bitmonero parameters so far. We have no right to make parameters worse for them. In case emission curve will be changed this will happen only with future block rewards. Not past. 4. No name changes will be introduced without voting process. All changes and voting needs time to be implemented. We have almost finished implementation of merged mining. As soon as it will be 100% complete I'll post about it. While we are working on code improvement you can help us by voting for Bitmonero to be included into Comkort exchange: https://comkort.com/vote |
|
|
|
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins  Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split. This is the point. The network that isn't supported by miners is useless. We have to ask them. Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed. I agree. Let's make two separate voting processes. Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok? For emission schedule modification is 75% a good margin? 75% percent is probably a good margin for miners to approve just about any hard fork. With anything much less than that you are going to end up with a split. Let's not forget though, non-miners have to approve too. Do you mean non-miners as a forum users? |
|
|
|
This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM?
Merged mining essentially forces people to merge both coins because that is the only economically rational decision. I do not want to support the ninja-premined coin with our hash rate. Merged mining makes perfect sense for a coin with a very low hash rate, otherwise unable to secure itself effectively. That is the case with coins that merge mine with bitcoin. This coin already has 60% of the hash rate of bytecoin, and has no need to attach itself to another coin and encourage sharing of hash rate between the two. It stands well on its own and will likely eclipse bytecoin very soon. I want people to make a clear choice between the fair launched coin and the ninja-premine that was already 80% mined before it was made public. Given such a choice I believe most will just choose this coin. Letting them choose both allows bytecoin to free ride on what we are doing here. Let the ninja-preminers go their own way. Everything is ok except the first argument: MM FORCES a MERGE of coins. It doesn't force and no merge will happen. You can continue to mine only one coin if you want. Any "parent" chain isn't required if you don't want to have it on your pc. - In case we introduce a MM it still will be only an option but not a requirement. - In case we introduce a MM each miner will decide himself which "parent" chain to use with MM: BCN or some other chain. Actually this is more technical and less political issue. Looks like I need to explain this more. |
|
|
|
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split. This is the point. The network that isn't supported by miners is useless. We have to ask them. Yes I agree with that, as I said. To be fair though, I believe that a large portion of the current hash rate, most likely a clear majority, was active in the meeting where these things were discussed. I agree. Let's make two separate voting processes. Merged mining will be turned on only in case 75% of hashpower will be supporting it. For me this is ok. If less we will not introduce it. Is this ok? For emission schedule modification is 75% a good margin? |
|
|
|
There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins Also, miners aren't the only stakeholders, and while a miner voting process is great, it isn't the answer to every question. Though I do agree that miners need to be on board with any hard fork to avoid a harmful split. This is the point. The network that isn't supported by miners is useless. We have to ask them. |
|
|
|
For the record I approve of the voting process.
I do not approve of merged mining. It hurts this coin more than it helps it. With what we have done here we can easily build the largest and most secure network using the cryptonote design. We're well on our way to doing that already.
We should just go our own way, and leave bytecoin and its ninja-preminers to do the same.
That is my view.
I suppose that merged mining as a possible option is a good idea as soon as nobody is forced to use it. MM is a possibility to accept PoW calculated for some other network. It helps to increase a security of both networks and makes it possible for miners not to choose between two networks if they want both: - BCN only miners will continue to mine BCN - BMR/MRO only miners will continue to mine BMR/MRO - merge miners will mine both at the same time (now some of them mine BCN only and other - BMR only) Important things to know about MM: - MM doesn't imply that BMR is smaller or has a less hashpower. In case BMR will has more mining power than BCN it will simply accept less BCN blocks. - MM doesn't force BMR users to have BCN chain on their HDD - BCN chain isn't neede to verify blocks - MM doesn't require any specific parent chain. Miner decides himself which parent chain to use: BCN or any other chain supporting the same PoW method. Actually the only change that goes with MM is that we are able to accept PoW from some other net with same hash-function. Each miner can decide his own other net he will merge mine BMR with. And this is still very secure. This way I don't see any disadvantage in merged mining. What disadvantages do you see in MM? |
|
|
|
Hello!
It is very good that you've created this thread. I'm ok about renaming.
But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum.
Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless.
Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?
Seems alright to me. You should create a voting instructions tho, cause it's not looks like an easy process In few days I will publish a code with merged mining support. This code will be turned ON only by voting process from miners. What does it mean: - miners supporting merged mining are to update their nodes and miners. New miners will issue blocks with modified minor_version field indicating they are ready to accept AuxPoW blocks. But no AuxPoW blocks will be issued before 75% of last 1000 blocks will have a positive vote (a changed minor_version). - miners not supporting will not update but will still be able to mine and accept blocks. In case of successful voting they will have to switch to new code. In case of voting failed they can stay on old version. The same procedure is suitable for all other protocol changes. Sounds fair enough for me to go with a system like this, the coin is still young so major changes wont have a really big impact atm. But still, i think the emmision fix is more important then the merged mining for now. I'm not sure about not having really big impact argument. Now we have a support of a lot of people (see hashrate image below). In case a change is harmful from their point of view we will loose them either in form of not-upgrading (i.e. chain split) or in form of abandoning this coin.  Any order of issuing fixes is ok for me. I suppose that merged mining will be ready (from dev. point of view) before an emission fix. |
|
|
|
I know I am now going to get accused of being a pump and dumper by those too emotionally attached to this coin, but how can that be true when I have less than 500 coins? Or is it 250? Or will it be 125?
How about I just give you 250 coins? The idea here is to move forward and correct the error, not rip anyone off. I don't want your coins and I'm not suggesting that anyone is trying to screw anybody, this is all about the perception of devs being able to take coins without any mandate - please try to take me seriously. We don't agree that a reverse split amounts to "taking" coins. I also wouldn't agree that a regular forward split would be "giving" coins. It's an exchange of old coins with new coins, with very nearly the exact same value. There is a very slight difference in value due to the way the reward schedule is capped, but that won't be relevant for years or decades. Such a change is entirely reasonable to fix an error in a in coin that has only existed for a week. There were no error made in this coin but now there is an initiative to make some changes. Changes are always bad and changes destroy participant confidence even in case these changes are looking as useful. We have to be very careful before making any changes in coins |
|
|
|
Hello!
It is very good that you've created this thread. I'm ok about renaming.
But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum.
Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless.
Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?
Seems alright to me. You should create a voting instructions tho, cause it's not looks like an easy process In few days I will publish a code with merged mining support. This code will be turned ON only by voting process from miners. What does it mean: - miners supporting merged mining are to update their nodes and miners. New miners will issue blocks with modified minor_version field indicating they are ready to accept AuxPoW blocks. But no AuxPoW blocks will be issued before 75% of last 1000 blocks will have a positive vote (a changed minor_version). - miners not supporting will not update but will still be able to mine and accept blocks. In case of successful voting they will have to switch to new code. In case of voting failed they can stay on old version. The same procedure is suitable for all other protocol changes. |
|
|
|
Hi! I'm ok about renaming. But I'm not ok about proposed hardfork without support of at least 50% of miners. See new OP for comments. |
|
|
|
|
Hello!
It is very good that you've created this thread. I'm ok about renaming.
But I can't agree with any protocol changes based only on decisions made by bitcointalk.org people. This is because not all miners are continiously reading forum.
Any decision about protocol changes are to be made by hashpower-based voting. From my side I will agree on such a decision only if more than 50% of miners will agree. Without even such a simple majority from miners such changes are meaningless.
In case of hardfork that isn't supported by majority of miners the network will split into two nets with low-power fork and high-power not-forking branches. I don't think that this will be good for anybody.
Such a voting is easy to be implemented by setting minor_version of blocks to a specific value and counting decisions made after 1000 of blocks. Do you agree with such a procedure?
|
|
|
|
Nice. Also just sending .1525 BTC would put it at the top of the list. That's about a $76 listing fee . . which is very cheap considering they list it for free otherwise (by just waiting and getting votes). Hey while you're here . . are you planning on submitting your coin to CryptoNote? HoneyPenny already did and got a response, so I'm just wondering if you plan on doing this? Thank you for your help! Yes, for sure I will submit. |
|
|
|
Hi! Thank you for all supporting Bitmonero, new CryptoNote-based currency. 4 days since start everything looks to be all right and difficulty is growing (at height 6380 difficulty is 256671). Let's create a logo. Logo contest duration is two weeks. The best logo will be choosen by community via voting on forum. Author of the best logo has to provide proper logo sources suitable to create icons and images for web site. Logo bounty is 300 BMR. In case you want to add some coins to this bounty, please let us know by posting to this thread. You can add coins to bounty anonymously by sending them to one of following addresses: BMR: 44ygVMGfS9aUdw616f6mmTLMrjqrA89TK8NWURxmHyDZ5QNKSQsrWRR17YUJVeobP5V5EBQbsNxGhNK 6efN8dF25LuKmA9y BCN: 29fpJpWgLaqd1kCh4mXCnkF4piQs1AYYVNQRTsoa92TTJTgwg51mxehPPiPB9MHpgkXGhgvwCVYV6Bn M7pU2PuCpQ4CFtL8 BTC: 1P6u6bxZk2riGkR5XRXvE4qymG6MqcWPx5 All logo candidates are welcome on this topic. Original Bitmonero post is here: https://bitcointalk.org/index.php?topic=563821 |
|
|
|
You changed a lot of the code. What are the consequences? Previously the tx's were sorted more thoroughly.
2 changed files with 14 additions and 47 deletions. I hope that nothing bad can happen. But we have to be careful |
|
|
|
It's up on git. Can someone compile the Windows binary?
Please see my comments below: patch wasn't tested properly. It's better to stay 1-2 days with some node not patched. This will help in case of problems with this patch. The absense of this patch doesn't influence miner's income in most cases. Sorry, I'm confused, can we continue mining with the wallet and bitmonerod from yesterday? Yes, you can. The problem with the block chain being stalled was caused by no one having the patch. As long as some nodes have the patch, everyone else can continue using the old code. I confirm this is correct. |
|
|
|
The problem is in block generation code. In one of last updates in Bytecoin there was a bug introduced: it calculates extra-size penalty the wrong way. As a result we see that a mined block isn't accepted by the network. I will consume the big transaction now into correct block. As soon as network accepts this block I will release new mining code to git.
Here is the tx that caused the problem:
id: <f1d8e3391161e4e98566c746d605f97cf432cbd19c83d8b0444e02748f54117e>
blob_size: 20534
Does BCN still possess this issue? Probably yes, but it doesn't influences network operations as much as in BMR. Why? I suppose that there is a number of BCN nodes using old or very old mining code. This bug has been introduced a week or two ago and BMR has been started from last snapshoot of BCN code and we met this problem. This way there is no real problem with BCN even with a bug in last commits. But I've sent them an e-mail. |
|
|
|
It's up on git. Can someone compile the Windows binary?
Please see my comments below: patch wasn't tested properly. It's better to stay 1-2 days with some node not patched. This will help in case of problems with this patch. The absense of this patch doesn't influence miner's income in most cases. |
|
|
|
|
Show Posts
