Hi! I'm introducing Riecoin. This is a new coin with proof of work based on prime numbers. Riecoin is forked directly from Bitcoin 0.8.4 EDIT: I'll be including changes from 0.8.5 and is not related to primecoin. I've been working for some time now on a prime number proof-of-work coin. While I knew that the user primecoin was taken on github, its launch took me as a surprise while my work was still not finished. Luckily primecoin's approach is different to riecoin's (I don't use Cunningham chains), and I think riecoin has some good advantages so I kept going with the experiment. It will have some ltc-like parameters: 2.5mins per block starting with 50 coins per block. I'm a software developer but not a designer, so I'm starting a logo contest. The coin is named after Bernhard Riemann, whose work on prime numbers was revolutionary. I'll do a fair launch without premine or instamine, so I cannot set a big bounty for this contest, all I can promise is your name and contact info of your desire in the about dialog and/or the splash screen of the QT wallet (I'll choose the winner), and the first block I mine (that's 50 RIC). Since Riemann is already on the coin's name, I don't feel it's necessary to have his face on the logo. I thought it could contain a lower-case Greek letter zeta with 1 or 2 bars (like $ is an S with a bar) as an homage to the Riemann zeta function, but I'm open to whatever looks good. EDIT: since zetacoin already uses the zeta letter, If you decide to use it I suggest you do it in a subtle way, ie don't make it the main feature of the logo. Another cool drawing that could be used for inspiration can be found here: http://en.wikipedia.org/wiki/File:Zeta_polar.svg you can see it in a more gentle color on the cover of this book: http://www.amazon.com/Prime-Obsession-Bernhard-Greatest-Mathematics/dp/0309085497/ref=tmm_hrd_swatch_0?_encoding=UTF8&sr=&qid=I like minimalistic designs, but do whatever you like, I'm open to any suggestion. I need the logo, a .png file for the splash screen (480x320), and the icons in different sizes/resolutions as in bitcoin. If you could provide icons in both .ico and Mac's .icns format it would be awesome. Don't worry if you can't, I can convert the files. It would be nice to have a different set of images and icons with different colors or something for testnet. I hope you like the concept, let the contest begin! I'll give it one week, starting now. Cheers, Gatra EDIT: "Official" twitter: @riecoin |
|
|
|
|
It is possible, and yes, you may have some inflation for some time, which may be a good or a bad thing, I can't foretell. Reminds me of elacoin.
The easier would be to have difficulty adjust to have blocks each n seconds, and then reward = K * difficulty.
This should make a reward tied to your hashrate. You may want to adjust K for Moore's Law, for example start with 1 and halve every 2 years, under the assumption that 1GHps today should be worth more than 1GHps from 2 years in the future where hardware is faster/cheaper.
So mining power increases reward, passing time decreases reward, the balance between these will decide the amount of coins to be ever created, which may be infinite or may converge to a fixed sum, depending on coin adoption and the ability of hardware to keep up with Moore's Law.
If you are serious about paying for having this developed, PM me.
cheers!
gatra
|
|
|
|
new services, promotion, community support, new features built into clients. These things seperate one coin from the other
but the developers are not needed for anything of that (except new features built into clients, and let's face it: most clients all feel the same without any new features except maybe messages embedded in the transactions). you don't need a takeover to ask service providers to accept payments in DMD... service providers are not (at least most of them should not be if you want a healthy economy) the same people as the coin developers. EDIT: I agree that you need them to be present and active for people to have any confidence on the coin, I was just wondering what tasks would they have to perform that cannot be performed by other people interested in the coin |
|
|
|
|
hi! would you please explain what do you mean by "managing a coin" or "providing support"? I really don't know what tasks are required or expected...
One would be updating checkpoints in the client. What else?
You don't need the devs for setting up a pool or asking an exchange to support the coin.
If there are no bugs that need fixing, what other support do you need that you can't do yourself (not you personally, I mean members of the community without the programming skills involved in updating the client and without access to the github account to make an "official" new client)?
I'm a software developer and I could add a checkpoint to a source code, but I'd really like to know what are you expecting from the devs.
cheers!
gatra
|
|
|
|
|
1000000 with a premining of 30000, that's 3% or about 3 months of blocks in coin-time.
|
|
|
|
|
I started mining at the launch and all my blocks were orphaned. It was instamined. After diff adjustments, block kept coming at the same instamining rate, meaning that what was stopping the creation of blocks was not the difficulty, but the time it took the network to distribute the blocks. A small group with high hash rate and fast connections took all the blocks for the first hours, and there were more blocks per hour than what there were supposed to be.
|
|
|
|
I have an optimization that I wanted to apply, so that's why I wanted sources. I'll just give it to you so you can include it in next versions: in prime2.cpp this: nSolvedMultiplier = ((fixedInverseU64) * (pU64 + 1ULL)) % pU64;
is the same as this: nSolvedMultiplier = fixedInverseU64; because pU64 is obviously 0 modulo pU64, and fixedInverseU64 is already less than pU64 Ahh true. Thanks, I didn't think this way. It will be included in the next release. It works in the other case too: if nBiTwinSeq is odd, you can do this: nSolvedMultiplier = pU64 - fixedInverseU64;
because what we want is ( (-1) * fixedInverseU64 ) modulo pU64 |
|
|
|
I'm not a programmer so I hope I just implemented your suggestion incorrectly.
You did not... try this: unsigned int nSolvedMultiplier;
if (nBiTwinSeq % 2 == 0)
{
nSolvedMultiplier = nFixedInverse;
}
else
{
nSolvedMultiplier = nPrime - nFixedInverse;
nFixedInverse = (nFixedInverse * nTwoInverse) % nPrime;
} |
|
|
|
and again... new binaries, no updated sources...
Can't you just wait even a few minutes? I usually release the binaries first, upload them on ypool.net, maybe try some other stuff out and then push the source to the github. hehe, ok, that was fast, I'm sorry I have an optimization that I wanted to apply, so that's why I wanted sources. I'll just give it to you so you can include it in next versions: in prime2.cpp this: nSolvedMultiplier = ((fixedInverseU64) * (pU64 + 1ULL)) % pU64;
is the same as this: nSolvedMultiplier = fixedInverseU64; because pU64 is obviously 0 modulo pU64, and fixedInverseU64 is already less than pU64 |
|
|
|
ypool reposts the release of version .35
and again... new binaries, no updated sources... |
|
|
|
In opposite, SHA256 parts can be runned parallel accross multiple core and uses a lot less memory.
This is not correct. All rounds of SHA256 have to be run sequentially. Calculating one sha256 hash it not a highly paralellizable task. Granted, it requires far less RAM and CPU to calculate two SHA256 than one scrypt, but still your post is not accurate. |
|
|
|
pleas Latest stable miner is v 0.32. Working 100% no stale share get 26 shares in 30 minutes (Q6600).
please publish the source code for v0.32! github is still at 0.31 |
|
|
|
hey mikaelh! try this: in the function FermatProbablePrimalityTestFast, you don't need this part: // Failed Fermat test, calculate fractional length
mpz_sub(mpzE, mpzN, mpzR);
mpz_mul_2exp(mpzR, mpzE, nFractionalBits);
mpz_tdiv_q(mpzE, mpzR, mpzN);
unsigned int nFractionalLength = mpz_get_ui(mpzE);
if (nFractionalLength >= (1 << nFractionalBits))
return error("FermatProbablePrimalityTest() : fractional assert");
nLength = (nLength & TARGET_LENGTH_MASK) | nFractionalLength;
If Fermat's test fails, just return false. The fractional part is irrelevant if your first number in the chain is not prime. Since most candidates fail Fermat's test, this code is executed many times, so it should give you some speed up. It did increase PPS 25% for me, but I didn't have the trial division optimization. btw, I don't know how effective is that, we are looking for Fermat's pseudo primes to the base 2, not for actual primes, so maybe your optimization is filtering numbers that would have passed the test. For those who'd like to share some love: ARQYnPjkeSgtmx41bypmnkbcHLvWPafGR5 I'd do a pull request, but there's no github anymore regards |
|
|
|
|
I would expect PPS to go down when the diff crosses integer boundaries because it's when the sieve is updated. So you filter more numbers, and are left with less primes. But again, since PPS "just for fun", forget about it. It does not mean that the speed or efficiency or your miner went down. It's the other way around actually, since difficulty calculation is not uniform/linear, using the current mining algorithms for looking for blocks with diff 9 is actually easier than finding blocks with diff 8.99.
EDIT: clarification: you are left with less primes, but each one of those has a higher probability of being the first of a chain.
|
|
|
|
|
I have a very hard proposal for you: despite of his bad english, his obvious agenda, FUD throwing, etc... can you look past that and see if he is right about some of his points?
He throws hard numbers, if should be easy to verify them: are those numbers invented and full of crap? or are they accurate? I don't know, I didn't check. Did you?
|
|
|
|
|
sif, prime, quark, do not have public GPU miners yet, however it does not mean they aim for GPU resistivity.
You mentioned an expected 2x/3x for primecoin, my guesstimate is 2 orders of magnitude higher than that...
|
|
|
|
At any given moment, what is the chance that one of the chains with bonus blocks is on one?
(If it is still low, not to worry, as people keep spewing out such chains that chance should keep climbing, yes?)
if it depends on the last block's hash (or the height or any other known value) and you know it, you don't need probabilities: you know for sure if next block is a big one or not. If you want to know the general pobability without knowing last block's hash, then it's constant and it doesn't climb, because each block has a "random" independant probability. I meant is it unlikely that looping through all such coins checking each to see if its next block will be a high paying one will discover at any given moment at least one such coin, or are there enough now that you will almost certain find, by the tiem you have mined a high paying block of such a chain, that one of the others is already in a "next block is a higher paying one' state so that you already have at least one chain to hop to to find a lucky block? Maybe it will end up more a matter of how much higher paying, due to typically there being more than one chain whose next block is a lucky block... -MarkM- oh, then it gets tedious to do the math since there are many coins, and each have different block duration times, which are actually geometric distributions. But you don't need to calculate that to implement it. Just hop to the most profitable one and adjust your profitability every time one of the chains has a new block. If 2 chains are in a superblock at the same time, still one will have highest profitability (if tied, flip a coin). If all your chains are in below average blocks, then default to BTC or LTC or whatever. If you are worried about your ability to quickly switch, you can limit yourself to fewer coins, but I think the calculation and switching can be done very quickly. ARG will be above average 2/5 of the time so I guesstimate you will not be in your default coin most of the time |
|
|
|
At any given moment, what is the chance that one of the chains with bonus blocks is on one?
(If it is still low, not to worry, as people keep spewing out such chains that chance should keep climbing, yes?)
if it depends on the last block's hash (or the height or any other known value) and you know it, you don't need probabilities: you know for sure if next block is a big one or not. If you want to know the general pobability without knowing last block's hash, then it's constant and it doesn't climb, because each block has a "random" independant probability. |
|
|
|
take a look at this: https://bitcointalk.org/index.php?topic=232741.0I find the random block reward idea pretty stupid, specially how it's implemented in most sh*t coins. You know in advance the reward, so you could mine only high reward blocks. In the case of ARG your expected return is 5 per block instead of 3, that's a 66% improvement! I say it's stupid because not only adds useless variance (supposedly making it more "fun to mine"), and favors reward hopping instead of constant mining, but it also encourages block witholding: if reward depends on previous block, when you find a block you know next's block reward. If it's below average and you know next one is gonna be above average, then you have and advantage by delaying the submission of the new block and starting work for the next block before others. If it's orphaned, you lost a block that was below average, so it doesn't hurt you that much. |
|
|
|
|
Show Posts
