Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 16. (Read 685387 times)

Motivation is good, but how can I be sure that you will be reliable?
I could also say that I have 30+ years of experience in C++/Java/Lisp/Haskell/PHP/MySQL/... development...
It is your only one message in BitcoinTalk.

You must provide solid work for Riecoin and we must be sure that you will always be present for new work like upgrading Riecoin Core to 0.17.0 and later. Please contact clo1 and collaborate with him first to see what you can do for finalizing the 0.16.3 version.

To be clear, we do not want people only writing words without doing actual work in our team.
Also people with already some reputation here (in BitcoinTalk) are preferred.


You could open a Hindi topic like someone did in Russian, or in any common language, though translation are completely voluntary tasks and will not qualify you for the Community Manager role.
I cannot even control myself if the translation quality is good enough...

RESERVED for HINDI translation....

helloo admin.... can i translate ANN page / WHITE paper  to HINDI(INDIA) language ??

here is my portfolio.....
https://drive.google.com/drive/folders/1TTRWTdF-VC71_TgP4dcsy6wH4BoL9cxB

PM me if you need HINDI translation..... thank you....

Count me in too.

I am an experienced C, C++, Java and Pascal developer. I would like to be in the team.

i'm in for everything I can do!

About building a new Riecoin team, here is the situation and summary of who does what currently. Please discuss in this topic if you have interest to add or update your name in the list (also read this topic to see what the roles mean).
Personally, at least for now, I claim the leader role. And obviously the miner dev one.

Current de facto, unofficial team: see this post

So we have developers, though we are not sure if everyone agree to compose a new team and be a part of it (the other direction for lzknv, he said that he wanted to assume his role, but did not provide actual work for now). More important developers in the team are welcome.
I am not sure to be able to lead alone the project so another leader is welcome. If possible, someone that has resources to pay things like listing fees.
Pool owners did not express anything for now.
We need someone for a proper and beautiful new official website.

Not sure if you are a supporter of these 3 projects by calling them "pathetic" but Gapcoin seems also interesting, I will take a look to it. It could be interesting if we team up and collaborate to provide the best software and community support for the 3 projects instead of each working on its own side. They do all have interesting and useful proofs of work which are all prime number based but still different.

Now unfortunately, this rieMiner stable release will be my last action for a while, I am really short on time starting from now, sorry.
I will see if I could do a rieMiner fork/branch for Gapcoin, but probably not before February.

Good work,

That puts you far ahead of the pack I think most pathetic project of 3 is PrimeCoin, than Gapcoin, Than maybe RieCoin, but Gapcoin is very simple but no developer maybe you could work 2 projects PttnMe?

Thanks

In my side, I just released rieMiner 0.9, the first stable version. PDF manual, please read.
Binaries: standalone Win64, Deb64 (should work on fresh Debian or Ubuntu).

Summary of the updates from fastrie, the previous reference Riecoin miner:

• Adds solo mining with a Riecoin Core wallet using the GetBlockTemplate protocol. Supports custom payout addresses (P2PKH and P2SH);
• Adds a Benchmark Mode to allow much easier performance comparisons;
• Some bug fixes like the long delay before Stratum mining starts or some random segmentation faults;
• One important bug fix is the CPU Underuse: when running with 16 threads or more with fastrie, the CPU usage would not be maxed out at current difficulties. It could be worked around by launching multiple instances with each less threads, (not practical at all and wastes a lot of memory), or reducing the Prime Table Limit (significantly lower 6-tuples find rate). Note that the issue is actually still present (notably in Testnet), but negligible in practice;
• Performance enhancements (threading improvements, assembly optimizations, precomputed data usage). From fastrie, you will get a gain of around 5-10% for the same settings and computer. You can thank Michael Bell for all his contributions;
• The assembly optimizations include usage of SSE, and AVX, AVX2 or AVX512 when available. AVX512 support is experimental and not much tested, but a huge performance increase of ~20% over AVX2 has been reported! As a trade off, the CPU needs to be x64 with SSE to be able to run rieMiner. However, a "Light" branch is provided in order to support older CPUs and other architectures (you can for example mine Testnet blocks with a Pentium II computer or a RaspBerry Pi);
• Now supports prime table limits (PTL, also called "Sieve Max") higher than 2^32, to get even better speeds by reducing the ratios between k and (k + 1)-tuples. Indeed, using a PTL of 2^33 instead of 2^31 (which is not possible on fastrie) for benchmarking with Difficulty 1600 increased the blocks/day metric a lot (about 25%)! However, in order to set such a high PTL, you would need at least 24 GB of RAM;
• Support of prime constellations types other than the Riecoin one (rieMiner can be configured to find 7 or 8-tuples, for example);
• Use of configuration files instead of command line options, much more parameters to customize;
• Complete source code refactoring for a much more modern and developer friendly code;
• Cleaner user interface, more interesting statistics.

For comparing performance with fastrie, you can use the rieMiner's Benchmark Mode and my fastrie fork (benchmark branch). Note that you need to test long enough to get precise numbers.
I hope that some pool will eventually talk about rieMiner in their homepages... There is no real reason to use fastrie/xptminer anymore.

Happy Mining !

New PR that should enable reproducible gitian builds:

https://github.com/riecointeam/riecoin/pull/3

thank you again for your work in this coin clo1 !!

i feel that we re getting closer and closer 

Well I will mine this when we get a GPU miner, best of luck.

I've merged the pull request and updated the 1000000 block thresholds in the repository.

I am find partner of Gatra on flixio project https://twitter.com/adriangarelik https://twitter.com/flixxo end send link on this topic. I just sent to this person tweet with Text: "Pleas contact with you frend Gatra and tel him about riecoin project https://bitcointalk.org/index.php?topic=446703.5920 "  may by hi tel for Gatra. Recomend for all users send tweet for him...  
 
Sory for my English...

I just sent an email to gatra at riecoin dot org and info at riecoin dot org...
This is probably the last chance for gatra to come back. If he does not answer before 2019, we can assume that he completely abandoned us and a new team definitively needs to be built.
In this case, let's hope that Zapple's new features will attract a lot of people, with some of them getting interested in Riecoin.

Can anyone try to reach him via Twitter or Facebook?
Or via Flixxio?

Awesome clo1, thank you! I was able to mine blocks with P2SH "t" payout addresses in Testnet and rieMiner was updated ! That said, I will not support Bech32 addresses for now. Note that I also had to remove the 0xAC (OP_CHECKSIG), else it would still accept the block, but without crediting the address.

In Testnet, it works for all the 4 cases (P2PKH or P2SH using SegWit or not), and also when there are mixed SegWit/Legacy transactions (obviously, SegWit transactions will be ignored when mining without the segwit rule). So rieMiner should also be ready for Mainnet.

We should agree on activating Segwit or not... The software is here, but we need the consensus from the whole community.

But more importantly, the community should start using 0.16.3. Also, ziiip, XpoolX, simba84, any plans to upgrade to 0.16.3 soon?
clo1, you should update the 1000000 thresholds in the repository, and don't forget about my pull request.

This is correct. Remove the marker/flag (0x0001) and the witness field (0x0120 plus 32 bytes of 0). Keep the default witness commitment in the txouts.

The scriptPubKey is different for the 'T' transactions (P2SH). (BIP 141)

        0xA914{20-byte-script-hash}87 instead of 0x76A914{20-byte-hash}88


It's different still for 'bcr' addresses (P2WPKH or P2WSH).

        0x0014{20-byte-hash} or 0x0020{32-byte-hash} depending on length.

Thank you for the pointers. I tried without success to make a proper SegWit Coinbase Transaction after researching and trying a lot... I read Bip 141 and other pages about SegWit transactions.

I am trying to mine a block with tNWRWWGvr8GGKXWXDYBPoyzmkVDt7a93fy as payout address. I modified the code and am now generating Coinbase Transactions like this one:


But the block is rejected with a bad-txnmrklroot error ("ERROR: ProcessNewBlock: AcceptBlock FAILED (hashMerkleRoot mismatch)" in the Debug.Log). For the Merkle Root, I tried to use sha256^2([nVersion][txins][txouts][nLockTime]) = txid instead of hashing the whole Coinbase Transaction like usual without success... Same using a 00...0 hash (they say that wtxid of Coinbase Transaction is this). Changing the version to 2 do not help either... Placing sha256^2(default_witness_commitment . 00...0) instead of just default_witness_commitment for "Commitment hash: Double-SHA256(witness root hash|witness reserved value)" is not working either.

Without the Marker and Flag and the Witness section, but with the default_witness_commitment (current implementation), the block is accepted but the payout address is not rewarded at all... However, if I use a regular "r" address, it is properly credited...

I compared to an actual Segwit Coinbase Transaction and do not really know what I missed... The syntax seems correct, and this one just contains a third output...


I guess that I will just renounce to it and only allow legacy payout addresses for now...
Contributions to the code are welcome if anyone is motivated to implement SegWit payout addresses support in rieMiner.

One possibility, it looks like you are creating a standard transaction for the coinbase instead of a witness transaction (see BIP141). For a witness transaction you need to add marker (0x00), flag (0x01), and a witness. For coinbase, the witness is the "witness reserved value". I'm not sure what witness reserved value is used in calculating the default_witness_commitment.

EDIT: It looks like the "witness reserved value" is 32 bytes of 0x00.

There is an issue though, I forgot to say that I was unable to mine blocks with "t" addresses as payout address in TestNet.
Actually, the blocks are accepted by the network, but the given "t" address is not credited. I do not really know what I need do to support them. Any idea?

It's great that you got these working. I'm hardly an expert in these softforks. There is nothing to do for BIP65, BIP66. Once the activation block is reached the rules are automatically enforced all the time.

The only untested parts of the code now are CSV and CLTV. These allow creating transactions that can't be spent until some time in the future. I haven't touched this code so they should work. I don't think there is an easy way to create these transactions. I think they require creating custom scripts using python or node.js or maybe riecoin-tx.