Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1895. (Read 4671953 times)

Use CPUMiner-Multi

I can't pool mine on CryptoNote Wallet v0.2.0. I don't know what to do, please help me.
It always says disconnect and sleep....

I'm loving Minergate, such as nice and easy to use app to mine MRO. We need more people to join our pool. Start promoting MRO. Minergate would be easy for new-comers, simple create account, download and run and your mining.

www.minergate.com

agree - you can also add the counterparty protcol/xcp

but when you follow the discussion of the bitcoin veterans, monero or cryptonotes in general are the only coins which have a future

DOGE has extreme concentration of mining. If you only have one miner (by which I mean actual miners i.e. pools, not just people contributing hashes), you will have zero orphans, regardless of block time. If you want to actually have a p2p network where people can come and go and still mine solo effectively (even if it is a gamble -- though in some cases I argue that could be an appeal), then you need a better design.

EDIT: Yes I know DOGE doesn't have one pool. That was an extreme example for discussion purposes.

Only a little, and last I checked that code was not particularly portable or well documented. I also tested it on a few platforms and saw little improvement (over the current daemon hash code -- clearly it is much better than what was there before). I'm sure it does help in some cases, but the code in the daemon needs to be a bit different than what you get trying to squeeze a few cycles out of a miner. Although ultimately the optimization should go in.


60 seconds is a decent amount of time. The problem is that you don't have 60 seconds. To get below 5% (not really a good target) you need processing latency and dissemination within 5% of 60 seconds, which is only 3 seconds. That's actually very hard to do, and likely impossible with current technology for a self-organizating ad-hoc p2p network.

The reason Satoshi picked 10 minutes wasn't that it would take 10 minutes to disseminate blocks, it was so that collisions would happen infrequently. 1-2% assumes a 6-12 second dissemination time.

It it somewhat hard to tell but it seems like duck has a very low orphan rate, at most a few percent, maybe less. There may be other factors, but the 4 minute block time definitely helps.  (Sampling error is significant here since there just aren't that many blocks total.)

I agree with what you said about the pool software, and other software sources of latency. But at the same time, it is easy to say "just fix the code" but actually deploying new or modified code requires careful design, implementation, and testing. It may be that simply increasing the block time is a more expedient low-risk if partial fix, despite the need for a hard fork. Of course the two are not mutually exclusive either.


They are still a big problem system-wide, they just aren't a big problem for individual miners.

All the points are spot on and I think this in particular deserves attention in the near-term. Back when everyone was solo mining in April and early May, we certainly didn't have these absurdly high orphan rates. There have to be some low-hanging fruit in the pool implementation. The most comparable conventional crypto is DOGE (scrypt, 1 minute block time) and we should use that as a benchmark for orphan rates (adjusted for MRO's slower PoW).

What have you done to that end, exactly? Have you optimized the pool's code somehow? 

Hello everyone,

We've been working hard with my friend to improve the pool : http://monero.crypto-pool.fr

We'll find much more block, the orphaned block rate will be much lower, the payment will be more regular.

Let's hash !!

strong statement. for comparison i think chinese communism started in a shed. apple started in a garage and dell started in a dorm room.

1)  Most of the Bitcoin forks use LevelDB.  It's a very reasonable choice, but it depends a bit on exactly what semantics you need for your blockchain storage.  Worth considering, at least.

2)  Any solution should provide a platform-independent serialization so that wallets and blockchains can be copied between 32/64 bit and *nix/mac/windows.  Again, LevelDB should do that, as would Berkeley and several others.

3)  I'm confused why people think that the block time needs to be increased so much without trying some other things first.

In particular:
  (a)  Verification can be faster.  The current daemon is not using the most optimized code from my/wolf's efforts.  That should be fixed -- particularly on machines with AES, it'll help.

  (b)  The pool software needs to be examined carefully.  I mine solo in the wallet, and I don't see nearly the orphan rates the pools are seeing.  It's possible there are some extra sources of delay sneaking in there that can be eliminated.

  (c)  Investigate carefully the bandwidth use of the daemon and see if there are some straightforward ways to reduce its chattiness and the volume it sends out.  (Using zippy might be effective for some kinds of traffic, for example).  This will reduce the latency of communication between daemons and help reduce the orphan rate.

60 seconds is a decent amount of time for wide-area network communication.  It requires a lot more care and feeding than Bitcoin's 10 minute block time, but I'd be quite surprised if some tuning could not get the orphan rate below 5%.

And, as others have noted, orphans aren't really that big a problem... they don't affect the difficulty, so it's not like you "lost" money on the orphan.

More like what Bitcoin uses - Berkley DB or something. I don't think sqlite would be performant enough, but maybe worth a looksie when we have the time:)

That's a Cloudflare thing. Try later on compile (https://bitcointalksearch.org/topic/m.6945897 may help).

Edit: fixed

So somthing similar to TimeKoin. I think they are doing something along the lines of SQL.

Any hardfork changes like this should be considered for an extensive period of time before being implemented. Even a change to 2 min will only drive the orphan rate to about 15%, as shown with BCN. Unfortunately, there are many factors contributing to the orphan rate right now (slow hashing function, P2P net code) and unless you extend the block time dramatically I don't think we'll see the orphan rates drop to anywhere near something like LTC with 2 min blocks.

The ideal solution is a proper database implementation -- the ByteCoin devs appear to be working on it, so we're waiting on them, but after 1 y or so we'll need a proper db.

they just dont know how to add this coin

dont ask them what they cant do..

MONERO is totally the most profitable coin! Do you know where investing is it gonna lead you? Exactly. TO THE MOOON! Happy trading!

So would there be a way to create a checkpoint within the daemon that splits the blockchain into multiple files at a certain heights. The splits would be catelogued and organized and sit in limbo waiting to be called for if needed. Lowering the need for high memory due to increased blockchain size over time.

throw NEM onto the list. it will be a player