THERE WASN'T A PREMINE
I was here on launch and I got block #4, and almost the number 1. If you lost the launch don't accuse of premine. This coin was announced 20 days before launch, and game was posted, I was playing before the launch to learn how to win. 20 days later the coin WAS EXACTLY LAUNCHED AT TIME with 0 BLOCKS MINED.
sorry to put it like this, but you are just wrong the launch may have been done with only one block, but if you look at the code... the first block has a reward of 450000, while the next blocks have 100 until the first halving. even the dev acknowledged there is a premine: There is special reward for 3 developers of Motocoin - each developer will get 150k motocoins. There will be tens of millions of motocoins so 150k is not very large amount (and some currencies are 100% premined). Also this reward ensures that developers will have strong reason to support Motocoin.
which I guess is ok if it's properly announced from the beginning, in the website and OP |
|
|
|
|
boooooo
I liked the concept of this coin, and I even thought about making a playing bot, but then I saw the premine that I didn't find mentioned anywhere in the OP or in the website.
They premined 450000 coins and apparently forgot to tell about it. I'm staying out of this coin, I won't spend time playing for the devs if they are not honest about it.
also, I have my doubts about the difficulty adjustments.... is half the time the double of difficult? does having the double of time make it twice as easier? it probably doesn't work like that, after a retarget it may get to a point where it is too difficult to win. It will get to a point where it's so difficult only bots can win anyway.
|
|
|
|
What makes this game unhackable?
What stops someone from modding the game so that the moto guy just goes through obstacles?
Or what if someone mods the game to only give maps that are easy?
(supposedly, I can't confirm or deny this because I haven't read the code yet) the solution is independently verified by each client, so you you make a "cheat" client it would be the same as modifying your bitcoin client to accept lower difficulty shares: you'd find lots of blocks and your wallet will tell you that you are a millionaire but you wouldn't be able to spend your money because you would be on a fork of the network that contains you and only you. I like the concept of the coin, the only "attacks" I can think of right now are (as someone mentioned) generating lots of levels until you get an easy one, or creating a bot that plays the game. |
|
|
|
Did you get it to sync? it will be slower than for example btc, because PoW verification is a little slower, but if you are using the latest client 0.9.1 it should sync much faster than previous versions: please make sure you have 0.9.1.
Nope... still 7 weeks behind! But this is only a GUI wallet issue... the daemon I have on my other pc is in sync (and took only one night on a slow connection). So, by now I have: GUI: v0.8.6.0-unk-beta (not in sync but slowly _SLOWLY_ catching up) riecoin-cli getinfo: "version" : 90100, (synced and the actual host for my wallet.dat containing the coins) The idea was to have a GUI which is easier to handle on a daily basis. Not that I dislike CLI but.... Do you have a link for the updated GUI? 0.8.6 is old. You should use the qt GUI version 0.9.1 as well, not only it is faster, it also has many new features like coin control. In Linux, you should find the riecoin-qt executable inside the tar.gz file here: http://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/In windows, you can download the installer from here: http://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/riecoin-0.9.1-win64-setup.zip/download and the setup utility will install the GUI, or you can download the zip bundle from here: http://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/riecoin-0.9.1-win.zip/download and look for the riecoin-qt.exe inside the zip. You can use this one without running any installer. |
|
|
|
BTW, any hint on why the GUI wallet is so slow in the sync? I think I've had that wallet open for 4 days with 8 peer connections and I'm still 8 weeks behind!  Did you get it to sync? it will be slower than for example btc, because PoW verification is a little slower, but if you are using the latest client 0.9.1 it should sync much faster than previous versions: please make sure you have 0.9.1. |
|
|
|
|
After the release of client version 0.9.1 with many new cool features, this was a slow week (not much news, been very busy with other work) for me for Riecoin.
I didn't have time to look at the android wallet yet. Also work done by aamarket on the ARM miner looks primising.
I plan to borrow a Mac this weekend and release an OSX version of the 0.9.1 client, and I'll keep working on stratum. Also I'll write down the math for expected pool shares vs blocks.
Thanks and stay tuned,
gatra
|
|
|
|
ubuntu should work fine with ./buildAll
fedora required a bit of help (see history here).
Also a small progress with ARM miner, investigation led me to the part of code,
I already marked with "?" long time ago when trying to understand some old miner ...
having
uint32* powHashU32 = (uint32*)powHash;
for(uint32 i=0; i<256; i++)
{
mpz_mul_2exp(z_target, z_target, 1);
if( (powHashU32[i/32]>>(i))&1 )
z_target->_mp_d[0]++;
}
It needs ">>(i%32))" I'd say - and I do not know why it works fine on x64, but the change helped to get seemingly proper targets on ARM.
Still no share submitted, so I do not know if it helped.
Thank you. Testing and thinking hard about this - this was part of the code I inherited. I'm going to run it past jh as well, because it likely reflects a bug in the base xptMiner as well. I'll commit this fix tomorrow if all is good. -Dave Looks good from here. Committed now and will back it out if jh says it's wrong. Thanks again for spotting this. I found this here: http://stackoverflow.com/questions/3394259/weird-behavior-of-right-shift-operatorThe logical right shift (SHR) behaves like a >> (b % 32/64) on x86/x86-64 (Intel #253667, Page 4-404):
The destination operand can be a register or a memory location. The count operand can be an immediate value or the CL register. The count is masked to 5 bits (or 6 bits if in 64-bit mode and REX.W is used). The count range is limited to 0 to 31 (or 63 if 64-bit mode and REX.W is used). A special opcode encoding is provided for a count of 1.
However, on ARM (armv6&7, at least), the logical right-shift (LSR) is implemented as (ARMISA Page A2-6)
(bits(N), bit) LSR_C(bits(N) x, integer shift)
assert shift > 0;
extended_x = ZeroExtend(x, shift+N);
result = extended_x<shift+N-1:shift>;
carry_out = extended_x<shift-1>;
return (result, carry_out);
where (ARMISA Page AppxB-13)
ZeroExtend(x,i) = Replicate('0', i-Len(x)) : x
This guarantees a right shift of ≥32 will produce zero. For example, when this code is run on the iPhone, foo(1,32) will give 0.
These shows shifting a 32-bit integer by ≥32 is non-portable. So ">> i" may run faster than ">> (i % 32)" in x86 or x86_64 because the % is optimized out, but is not a good idea because it's not portable and also >> with values larger than the operand size are undefined according to the C standard. Since in the miner this loop is done only once for each search of the 256bit nonce, you can do i%32 without any harm. Maybe a logical AND instead of the % would be faster? of course you should profile instead of believeing me but I think optimizing this is not worth the trouble. gatra |
|
|
|
I think both are correct. Take for example block 52879. The first prime in the 6tuple is 1717 bits, or 517 decimal digits. Both sites say the first prime is this: 3704548176830082402354888184036735265457513707514114282827126923346807719350909942106612520104867140576183570834177334161620337378149933509025093323038949528156249517533245340639394255761738073988903532935654252009350389903363559279831135436000899487506000499319552851131755478195997174057396243136009137212692071774950889359968473782298676131797996654711544972318803208178611638849274173834397469436974459765232720733141700830653120916133514543679046891468928196323731230202881016252244325991624419491234321088355327 This number has 517 digits, of which 50 are zeros, 56 are 1s, etc. Pretty close to what one would expect statistically. The one at https://darmstadt.goxadidi.dk/cgi-bin/block/block_crawler.py gives us extra info: this number is the result of: 29729085016233304338613443050818417113406958567487755830292125671859583168405516 × 2^1452 + 9807390440828730529431913914412731066772996652405249038309180536196528315391 When written in base 2, the number has a string of about 1200 consecutive zeros "in the middle". The function that transforms the parameters into the number is here: https://github.com/riecoin/riecoin/blob/0.9.1/src/main.cpp#L1243-L1266 - this generates the "base" from the difficulty and the block hash to which you have to add the "offset" (which acts as the nonce) to get the first prime of the tuple. EDIT: also, in base 16 each hex digit represents 4 bits, so the number will be 430 digits long, and you'll see 299 or 300 (I haven't counted them) zeros in the middle. |
|
|
|
My math is not that good .. anyone knows why primes generated by RIC miners have lots of zeros in the middle?
They have a lot of zeros in the middle (when you write them in base 2 or hex, you won't see this in base 10) because of the way they are encoded, we "insert" zeros to adjust the difficulty, and only store the quantity of zeros and an offset. This way the block header remains a structure with constant size but has the ability to store numbers of different sizes (potentially huge numbers, so large they won't fit in a hard drive). |
|
|
|
New Riecoin client v0.9.1 binaries are ready. Download from here: https://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/We have 3 packages for windows: 32 bit installer, 64 bit installer, and the full zip with sources and binaries. For linux, one tar includes all binaries and sources. Changes included: - submitblock rpc bug fix - speed optmizations - getprimes RPC call! - networkhashpers rpc call And all the changes from Bitcoin Core 0.9.1 that apply to Riecoin. These include the openssl update, coin control, 64-bit windows client, new makefiles, and payment requests among many others. EDIT: I forgot to mention another change regarding testnet. The trailing zeros limit was removed so miners with high primorials can now be used on testnet too. The problem is that old riecoin clients will not accept those blocks so it will cause a fork. So this version should be considered a hard fork for testnet. But hey, it's only the testnet, I only see 3 clients connected and there were no blocks for many days. Hey Gatra, will focus be concentrated on stratum mining now? yes, and I'm trying to see what's wrong the android wallet too |
|
|
|
|
I just tweeted about the new client version, please update facebook and the web site. northranger if you're not online I'll try to update it myself, but I must leave for a couple of hours now.
|
|
|
|
New Riecoin client v0.9.1 binaries are ready. Download from here: https://sourceforge.net/projects/riecoin/files/riecoin%200.9.1/We have 3 packages for windows: 32 bit installer, 64 bit installer, and the full zip with sources and binaries. For linux, one tar includes all binaries and sources. Changes included: - submitblock rpc bug fix - speed optmizations - getprimes RPC call! - networkhashpers rpc call And all the changes from Bitcoin Core 0.9.1 that apply to Riecoin. These include the openssl update, coin control, 64-bit windows client, new makefiles, and payment requests among many others. EDIT: I forgot to mention another change regarding testnet. The trailing zeros limit was removed so miners with high primorials can now be used on testnet too. The problem is that old riecoin clients will not accept those blocks so it will cause a fork. So this version should be considered a hard fork for testnet. But hey, it's only the testnet, I only see 3 clients connected and there were no blocks for many days. |
|
|
|
- getprimes RPC call!
Special yeah for this one! ( I'm being partial  ) I got a warning about incompatible wallets & Berkeley DB on Debian Wheezy however, I ignored it since I don't need portability, but it might be worthy a mention somewhere in the build instructions. Building now! (cxx is such a slug...) edit: build failed, any clues? /usr/bin/ld: leveldb/libleveldb.a(log_reader.o): relocation R_X86_64_32S against `_ZTVN7leveldb3log6Reader8ReporterE' can not be used when making a shared object; recompile with -fPIC
leveldb/libleveldb.a: could not read symbols: Bad value Solved it with https://github.com/bitcoin/bitcoin/issues/3686However now when running riecoind, I get ./riecoind: error while loading shared libraries: libdb_cxx-4.8.so: cannot open shared object file: No such file or directory got it working by using static Berkeley DB 4.8 & the ignore version After edit 2, I was going to write that if riecoind fails while loading shared libraries you could try building the static riecoind, but it looks like you figured it out. |
|
|
|
Hi!
New client 0.9.1 will be released in a few hours.
Now doing final test of the release candidate... but still a few things to do: generate "release notes", upload to sourceforge, etc. We'll have to update the OP and the website.
I wanted to recompile everything from scratch (including deps) to make sure all the gitian builder process works ok and it's taking forever. Going to sleep now, will upload binaries tomorrow. If you want to build from source, the final version 0.9.1 is available at github.com/riecoin/riecoin under the default branch ("0.9.1"), or tag "v0.9.1". Changes included: - submitblock rpc bug fix - speed optmizations - getprimes RPC call! - networkhashpers rpc call And all the changes from Bitcoin Core 0.9.1 that apply to Riecoin. These include the openssl update, coin control, 64-bit windows client, new makefiles, and payment requests among many others. |
|
|
|
it's sha2 and someone's gonna rip it with an asic sooner than you think
wtf? I have to think that this post was made by a bot... but... what's the point of this? |
|
|
|
Hi!
New client 0.9.1 will be released in a few hours.
Now doing final test of the release candidate... but still a few things to do: generate "release notes", upload to sourceforge, etc. We'll have to update the OP and the website.
This is excellent news!  Will you be able to help check why the android app is not working also? Yes, but I'm new to android stuff... is maven a must? I have sdk 4.4, can I target older versions while compiling with 4.4? |
|
|
|
|
Hi!
New client 0.9.1 will be released in a few hours.
Now doing final test of the release candidate... but still a few things to do: generate "release notes", upload to sourceforge, etc. We'll have to update the OP and the website.
|
|
|
|
|
Show Posts
