The blocksize controls are being addressed by Monero. Not quite there yet, but the path is understood and the work is in progress.
Where is this being discussed? (sorry for the OT, but I suppose the changes are relevant for all the derivatives) Private discussion between developers for now. There will eventually be a code fork with proposed changes to review, and they can easily be adopted by the other variants if they choose. |
|
|
|
It's a merged mining coin, the way I see it, it completely relies on the main coins which are so far doing good. I highly doubt that dev will abandon this coin.
Quite the opposite. Merged mining normally has no reliance at all. It's just the same work used in two places via a commitment. The things that FCN is merged with can stop existing and FCN would continue along fine (which is also demonstrated by FCN not caring at all). The fact the merged mining is a non-trivial protocol change should be interesting— right now it generally seems that the bytecoin ecosystem as a whole doesn't have a lot of hard core technical attention on it, which is concerning, considering some of the issues in the system (e.g. the completely unhinged blocksize controls)... the fact that FCN has people working on it who are willing and able to do lowlevel protocol work is a positive sign. The blocksize controls are being addressed by Monero. Not quite there yet, but the path is understood and the work is in progress. |
|
|
|
Are deposits also manual? Waiting for BCN deposit for about 9 hours
They're not manual but somtimes the wallets get stuck and have to be manually reset. That's probably what happened. When they come online in a few hours they'll probably fix it. |
|
|
|
Yeah, like most CN coins now QNC is lucky to be one of the first, while MRO still leads in innovations, this coin has enough distinctions to keep in the game.
Such as? What are these distinctions you chose not to mention? Thanks It has two minute blocks and very slow reward schedule. |
|
|
|
Revise price to 0.4. Rest same
0.400 / 2M / 0.8 / smooth (expires 6/1; you send first) Is that what you wanted? No. Sorry for the lack of clarity. I will be more careful. 0.200 / 2M / 0.4 / smooth (expires 6/1; you send first) My offer still valid. To further clarify: 0.200 / 2M / 0.4 / smooth (expires end of day 6/1 UTC; you send first) |
|
|
|
How much is the network hashrate?
234866.829166666666667 |
|
|
|
There are a number of factors which contribute to orphans but they all stem ultimately from the one minute block time, which just too fast for an ad-hoc p2p type network. If you were running a centrally managed financial backbone (or you want to turn a coin into one) then you can probably optimize everything such that one minute blocks mostly work. But for a decentralized peer-to-peer system, it doesn't work.
If you look at these coins, Monero (1 min) generally has the most orphans and Duck (4 min) the least, though this of course varies according to network conditions. Probably closer to 4 minutes might be right, given the high cost of verification. 2 minutes is the bare minimum.
However, I would add that orphans really aren't as bad as they seem. The block target is determined by the rate of accepted blocks. If there weren't orphans the difficulty would be correspondingly higher. Everything comes out about the same, except more overhead and other secondary factors which aren't great and should be addressed by increasing the block time and optimizing the code in other ways. But it really isn't a "waste" of hashes or anything like that.
Hm, I know that there's a whole lot going on that causes this .. do you have any decent links that I can read up on to understand the situation better? You describe the situation very well, and I'd like to know more about specifically how multiple block solutions propagate through the network vs. which one is ultimately settled on (as well as the type of network infrastructure that it is propagated on) .. but I don't really know where to look. Satishi's paper described how one block is settled on, with the assumption of a random walk (not always correct, but correct to a point). As far as the actual network, there was another paper that measured bitcoin's propagation delays but I can't find it right now. There have also been some threads looking at propagation on ultra-fast coins such as DOGE (60 seconds), but again I can't find the links right now. Also interesting to play with is a node simulator I remember seeing. I think someone posted a link to one on this thread, but at 200+ pages, it will be hard to find. |
|
|
|
Where are all these orphans coming from? It's becoming harder to believe that it's entirely due to the 1 minute block times .. maybe that combined with the incredible mining speed increases we have now changes a few things...?
There are a number of factors which contribute to orphans but they all stem ultimately from the one minute block time, which just too fast for an ad-hoc p2p type network. If you were running a centrally managed financial backbone (or you want to turn a coin into one) then you can probably optimize everything such that one minute blocks mostly work. But for a decentralized peer-to-peer system, it doesn't work. If you look at these coins, Monero (1 min) generally has the most orphans and Duck (4 min) the least, though this of course varies according to network conditions. Probably closer to 4 minutes might be right, given the high cost of verification. 2 minutes is the bare minimum. However, I would add that orphans really aren't as bad as they seem. The block target is determined by the rate of accepted blocks. If there weren't orphans the difficulty would be correspondingly higher. Everything comes out about the same, except more overhead and other secondary factors which aren't great and should be addressed by increasing the block time and optimizing the code in other ways. But it really isn't a "waste" of hashes or anything like that. |
|
|
|
Revise price to 0.4. Rest same
0.400 / 2M / 0.8 / smooth (expires 6/1; you send first) Is that what you wanted? No. Sorry for the lack of clarity. I will be more careful. 0.200 / 2M / 0.4 / smooth (expires 6/1; you send first) |
|
|
|
2m for 0.25 expires 6/1
SOLD. Another 2m for 0.6 Conditions: expires 6/1 you send first Revise price to 0.4. Rest same |
|
|
|
20mil DUCK for 200btc  Wow, price is going up fast. Quack! |
|
|
|
2m for 0.25 expires 6/1
SOLD. Another 2m for 0.6 Conditions: expires 6/1 you send first |
|
|
|
Is there a trading thread for this yet?
Not yet I don't think, go ahead and make one? I can't put the time in to properly moderate over the next few weeks. Someone else should do it. You could start the thread without escrow service =) With the my format (that everyone seems to copy now) you still need to edit the first post with the order, so it ends up being a fair amount of work. Escrow is actually pretty easy, especially if people are trusting enough to just send and wait for delivery. |
|
|
|
Is there a trading thread for this yet?
Not yet I don't think, go ahead and make one? I can't put the time in to properly moderate over the next few weeks. Someone else should do it. |
|
|
|
When I look at the "Pool Blocks" tab on MoneroPool.org, I see that almost 40% of the blocks show as "orphaned".
What's with that?
Is this a result of the 60 second block time? Is it the result of some other flaw/factor in the CryptoNight algorithm? As far as I know, most other coins have much smaller orphan rates.
I assume if other pools were any different, someone would have reported it here.
This seems to me like a HUGE waste of everyone's hashes. Not so?
No not really. The difficulty would be higher without the orphans. |
|
|
|
How long does it take the wallet to sync? It is just saying initializing. I am using the Cryptonote wallet
Few hours probably, if you type set_log 1 into the console you'll get some block spam if it's working If you can download a block chain snapshot. That is much faster. |
|
|
|
Moneropool.com is having that "problem" again.
PLEASE SPREAD YOUR HASH!!! THIS POOL HAS OVER 51%When I look at the "Pool Blocks" tab on MoneroPool.org, I see that almost 40% of the blocks show as "orphaned".
What's with that?
Is this a result of the 60 second block time? Is it the result of some other flaw/factor in the CryptoNight algorithm? As far as I know, most other coins have much smaller orphan rates.
I assume if other pools were any different, someone would have reported it here.
This seems to me like a HUGE waste of everyone's hashes. Not so?
Even qcn has huge number of orphans, so its not the block time. Two minutes may still be too low for these coins, given the higher verification cost. Subjectively speaking the orphan rate on DUCK (4 minute target) seems quite low, but the coin is new so hard to say. |
|
|
|
Ahh ok. And where you know that from?
He knows it because most 5 star posters know that L3 cache latency is not an ASIC or GPU deterrent. It most certainly is a GPU deterrent to some extent. Whether there a clever work around remains to be seen. Even if there is, the GPU factor will likely be low and still may not be economically viable (compared to near-zero-cost CPU mining). It is less clear whether it is an ASIC deterrent. It is clearly not at some (potentially impossible) market cap, but the actual market conditions where it makes sense to try to compete with CPU R&D are not clear. Your point about putting actual numbers on this is valid. |
|
|
|
|
Is there a trading thread for this yet?
|
|
|
|
|
Show Posts
