In ten hours the difficulty has stuck @ 1410 and no blocks found...
I'd have assumed that the difficulty would have plummeted by now... Not having looked at the protocol to much, do we need confirmations for the difficulty to drop?
Guess I was hoping for easy coins while 95%+ of the network was "dead"
Regards,
--
bsunau7
Yes, in all cryptocurrencies the "retargets" or difficulty adjustments need at least one block in order to be done. In our case, the next adjustment is about 137 blocks ahead. So I expect the difficulty drop a little (easy coins for everyone, blocks every 1 minute approx) and then recover at the following adjustment. |
|
|
|
There is surging of invalid shares with current state with Ypool. I had almost 50 of them one after another in last few hours. Confirmation of payout is also slowing down as my last payout was nearly 7 hours ago and still pending for confirmation. No new payout coming in from Ypool since.
Anyone experience these issues?
I just had news from ypool: they found the problem and need to resync the wallet. Apparently it was a bug in the wallet that we inherited from bitcoin. It should be back in a few hours |
|
|
|
There is surging of invalid shares with current state with Ypool. I had almost 50 of them one after another in last few hours. Confirmation of payout is also slowing down as my last payout was nearly 7 hours ago and still pending for confirmation. No new payout coming in from Ypool since.
Anyone experience these issues?
Yes, no blocks for the last 7hs. Maybe it's time to give http://ric.nonce-pool.com/ a try! You'll need the version of the miner that supports stratum https://github.com/gatra/fastrie/tree/stratum |
|
|
|
Hi gatra, do we have P2Pool support for RIC?
Not yet, but it's on my to do list Any update this week Gatra?
I'm currently on the hardfork. After some analysis and testing, I think that the best is to start with one superblock of (about one hour) per week and break the record for sextuplets. We would add an entry to the top ten once per week. After that and with more time we can think of breaking the others. I've been thinking on how to work with much larger tuplets that would take hours or days to find, without the need for superblocks. It would work similar to how pooled mining works: blocks would allow tuplets with one or two composites until we finally find the record tuple of all primes. Doing this we could obliterate all records for tuples of size 6 and onwards! Tuplets of fewer primes, like twin primes or even single primes are still out of reach until we have more ideas because block verification would take too long. Can we assume that this hardfork is the best option for Riecoin? Of course, I think it is... and almost all feedback was positive. Maybe we could take a more conservative approach... like doing it once per month or only a one-time superblock. I understand the concerns but everybody agrees that world record = good  If that experience works well then we can discuss the details of the more agressive approach that would require everyone to update their miners as well. we could have a poll.. what do riecoiners think? once a week or a one-time thing, just to prove our power and think of the other approach? |
|
|
|
Hi gatra, do we have P2Pool support for RIC?
Not yet, but it's on my to do list Any update this week Gatra?
I'm currently on the hardfork. After some analysis and testing, I think that the best is to start with one superblock of (about one hour) per week and break the record for sextuplets. We would add an entry to the top ten once per week. After that and with more time we can think of breaking the others. I've been thinking on how to work with much larger tuplets that would take hours or days to find, without the need for superblocks. It would work similar to how pooled mining works: blocks would allow tuplets with one or two composites until we finally find the record tuple of all primes. Doing this we could obliterate all records for tuples of size 6 and onwards! Tuplets of fewer primes, like twin primes or even single primes are still out of reach until we have more ideas because block verification would take too long. |
|
|
|
I mine RIC on ypool.net
Riecoin is too slow. hi! could you please specify how is it slow? is 2.5 minutes between blocks slow? is the client slow? takes too long to sync or to start-up? is mining relatively slow on your specific hardware? money income is slow? if it's slow it may be possible to do something about it... thanks and regards, gatra |
|
|
|
Any updates this week Gatra?
We're waiting for dga to merge the stratum code. I'm hoping he could make new binaries for Linux and Windows: that would leave miners no excuse for trying other pools. I've started working on the superblock thing which feels like the new priority, I'm thinking on the easiest and safest way to implement the difficulty adjustments taking superblocks into account. I'm determined to break at least one record. Thanks for keeping pushing me to write the updates! Argh - sorry. This is still on my todo, I'm just lagging a little. I will try to get it done by tomorrow. Ah. I hadn't realized it was a near complete redo of the communication-related parts of the miner. This will take a little longer than I'd expected, but I'm kicking at it now. I tried to leave the xpt protocol part without changes while inserting the stratum part there so when merging it should be easy to see if I did break anything... but yes the file has changed considerably. Thank you very much for your effort! |
|
|
|
III. Multiple Mining Channels: Coinshield has more options as a miner to help make the distribution as fair as possible. Dense Prime Clusters are found on the CPU channel from an SK1024 hash, while GPU miners do conventional SK1024 hashing. Each channel has its own difficulty adjustments and released rewards. The block trust is calculated to prevent streaks per channel, so in other words a different channel block will always break a streak of 2 or more blocks on a single channel. This makes each mining channel reinforce each other to prevent a 51% attack on any of them forcing an attacker to need 51% of all 3 mining channels [CPU, GPU, POS].
hi! sorry but the thread became tl;dr - could you please specify more about these Dense Prime Clusters? or point me to where it is explained? I like the idea of adjusting block trust "ony the fly" to prevent streaks, btw |
|
|
|
How and why is this better than using a well tested, well established, and well known system such as PGP?
you may have a point there I was just thinking that it may be cool to have and easy way (like, integrated to the qt-wallet) to securely send a message while being sure that the only recipient is the one who made a specific tx on the blockchain. That message could be used for exchanging pgp keys and we'd use pgp from there on... Except that you'd have to get your Bitcoin public key to them in the first place. You can't compute a public key from a Bitcoin address. Agreed. Doesn't look very useful, but for example if you have a public donation address you could send a private message to an anonymous donator (he revealed his public key while making the tx). If you include a pgp pubic key in your message he can answer you back. |
|
|
|
Any updates this week Gatra?
We're waiting for dga to merge the stratum code. I'm hoping he could make new binaries for Linux and Windows: that would leave miners no excuse for trying other pools. I've started working on the superblock thing which feels like the new priority, I'm thinking on the easiest and safest way to implement the difficulty adjustments taking superblocks into account. I'm determined to break at least one record. Thanks for keeping pushing me to write the updates! |
|
|
|
How and why is this better than using a well tested, well established, and well known system such as PGP?
you may have a point there I was just thinking that it may be cool to have and easy way (like, integrated to the qt-wallet) to securely send a message while being sure that the only recipient is the one who made a specific tx on the blockchain. That message could be used for exchanging pgp keys and we'd use pgp from there on... |
|
|
|
The private and public keys under ECDSA would not be related under another crypto scheme. If you reinterpret your ECDSA private key as a private key of a different scheme, you'll surely get an unrelated public key. It's not meaningful. What you really want is ECIES (Elliptic Curve IES) But aren't ECIES keys practically the same as ECDSA keys? isn't it just points on a curve? So reinterpreting ECDSA keys as keys of EC encryption would work. There are no new questions on bitcointalk (ok, perhaps a few, but not many). This has been asked (and answered) in the past: No. Bitcoin uses ECDSA which is a digital signature algorithm not an encryption algorithm. You could use another algorithm which supports encryption however Bitcoin address is not a Public Key it is a hash of the public key. If you need to use a third party algorithm, third party software, and exchange keys directly well you might as well use something that was designed for this purpose like PGP.
There are encryption systems which can use ECC keys. ECIES is one system: https://en.wikipedia.org/wiki/Integrated_Encryption_SchemeHowever a couple things to keep in mind. I don't know of any widely deployed open source software which uses it so you will be reinventing the wheel. Could you develop such software, extensively test it, and then ensure your recipient also has said software (doesn't do much good if the recipient isn't using it) so that you can encrypt a message using a PUBLIC KEY you obtain (not address which is a public key hash) so the recipient can decrypt it by exporting a private key from his wallet into some software he is unfamiliar with? Probably. It wouldn't work any better than other widely deployed systems like PGP and unless you are very good you run the risk of compromise which affects both systems. I would by default be suspect of any software where I have to export one or more private keys from my wallet (that control MONEYZ) to a third party software in order to decrypt a message. Even if legit it certainly doesn't sound smart or reasonable. ok, I agree I wouldn't just put my private key in any software, but if I'm really curious about the message I'd transfer the funds to another address and then proceed to decrypt... Adding it as a feature in the bitcoin client would be cool. |
|
|
|
ECDSA is used for signing and verifying messages. Not for encrypting them.
So, the answer is "not".
You should use another crypto algorithms
sure, ECDSA is for signing and not for encription, but the same keys used for ECDSA could be used for encryption, and it would work like what the OP needs... so, while he must use an algorithm other than ECDSA, the answer would be yes. |
|
|
|
|
Yes, I believe it works as you describe it.
However, I don't know if there are tools to do it easily... probably not
|
|
|
|
ugh, in the thread you link to, Sunny King sounds like a "disincentive for pool formation" is a good thing. I disagree, a minting pool will be needed, and it would be great if the pool could work only with the minting key and without actually requiring users to deposit. If there is a PoS block every 10 minutes, but after 90 days as time passes wihtout minting you start to loose interest, then there won't be enough room for everyone to mint and earn their full interest. So only those with high stakes will be able to do it, creating further inequality in the system. |
|
|
|
This kinds of discussions makes the value of Riecoin, it's lot more interesting than mixing and mashing hash algorithms!
Yes, this coin got me looking into ARM and SMID which I never had before. I am pretty sure I've got some very clever tricks in my sieve which no one else has considered (well, aside from riecoin there isn't much use for a fast p6 sieve). +1! I am surely moving the goalposts here, but would it be possible to amortize the verification over many blocks? Sort of a distributed partial Rabin-Miller (is that practical and can it be made provable?) ... It all hinges on the provability of a partial Rabin-Miller test, which may be a pipe dream This looks like a job for a pool where state across multiple miners can be maintained. Maintaining validation and reward allocation across a distributed network would be PhD material. yep, we are talking about millions of digits... so only verification can take days. For single primes, maybe not Rabin-Miller but this: http://en.wikipedia.org/wiki/Lucas%E2%80%93Lehmer_primality_test or this: http://en.wikipedia.org/wiki/Lucas%E2%80%93Lehmer%E2%80%93Riesel_test |
|
|
|
the font sucks but the ideas for different types of primes with unusual properties, i.e. with x number of consecutive zero's or any number
...
the variations are endless, not really useful from a 'scientific' standpoint,
agreed... our primes all have lot's of consecutive 0's when written in base 2.... not an interesting feature though. do you remember when the rsa used to post the bounties for primes ??
then they just stopped, i often wondered if they came up with a much more advanced way of factoring and deriving primes that they never bothered to share with anyone else, probably far fetched but they did pay those bounties and some were for big money ,
yes, many of us still have this question... did they lost interest, or did they find a secret algorithm? probably they just knew the records would be broken soon and decided to use the money for other things... take your time and think it over, the superblock is a pretty neat idea, and i certainly favor anything that can take riecoin ahead of prime coin in the record books and personally i don't care about the value the coin unlike almost everyone else......
i remember reading a paper about 3 or 4 years ago about possible scientific applications of 'unusual' prime numbers but i honestly can't remember what the application was , if it was 'real ' or just a proposal and exactly what they were looking for, maybe i can find that paper !!
whatever you decide you have my support, especially now that i am comfortable building wallets on the btc 9.x codebase
thanks, and let me know if you find that paper! if you fork the client and don't mind please suggest which versions of the tools you are using if different from the most recent bitcoin tools,
i remember the 8.x series of riecoin used qt 4.8.3
I use gitian to make the builds. I usually use the same as the latest available bitcoin release, since it's supposed to be well tested. Here are the latest deps: https://github.com/bitcoin/bitcoin/blob/v0.9.2.1/doc/release-process.md they still use qt 4 for compatibility reasons. |
|
|
|
yes, thanks! I didn't pay much attention to it before because I hate it how they use the "comic sans" font... |
|
|
|
Maybe rejecting blocks with same stake iteratively for up to 6 times would be safe.
I assumed they would reject the last block recursively until they were from different kernels... as many levels as they find. I don't know how they are planning to do it but if they did only the very last then yes, it would be slightly mitigated but they would still be vulnerable. |
|
|
|
In that scenario would it be possible to accept 6 to 9 tuples? Or more precisely allow the current miners to keep working on the "old" 6 tuples, while allowing new miners to mine greater tuples? perhaps with a small bonus to give an incentive to upgrade The appeal of world records is strong  yes, 6 to 9, to 10, whatever. Moreover, if my math is right and can be generalized this way, we would break the twin prime record in 11 minutes and the largest prime number in 16hs. The problem is that verification of each of those blocks would take some minutes, so the client would take a lot to sync. That's why I choose 6-tuplets: easy to verify, hard to find. But if we made it superblocks only once a month, syncing wouldn't be so bad, so it would be possible! Also, since block verification would take so long, we would be prone to DoS attacks by someone submitting fake blocks that would take a lot to verify.... if we could mitigate this, we would break records from twins to many-plets. Or even the largest prime number. We would be sacrificing a bit of the usability of the currency aspect in favor of the distributed computing aspect of the riecoin project.... and... there's a 150k USD price for primes larger than 100 million digits... I'm starting to think some reengineering of the mining process, and strengthening of the DoS protection could make us get there... getting too excited, need to think more about this...edit: verification would take prohibitively long for single primes and twins, even if we did it once per month. Probably for triplets too |
|
|
|
|
Show Posts
