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

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.

Thank you clo1 for these useful links. I updated rieMiner to include SegWit support (at least experimental for now) after struggling to understand how and where I had to put that default_witness_commitment.

rieMiner is now able (if the segwit Rule is set in the options, like below) to mine Segwit transactions between "t" addresses in TestNet, and also blocks with mixed segwit + legacy transactions, so I assume that rieMiner is now SegWit ready in case it ever gets actived. It also worked with legacy transactions produced by 0.10.2 in Testnet too, so current normal mining should be unaffected. More testing is welcome, and I invite you to comment the update if needed clo1, you are the expert.

I added a "Rules" option where one can add rules for the GetBlockTemplate call. For example,


Will send


While


Would send


Both instead of


Would this be enough for indicating support for the remaining softforks and use them? What rule strings do we have put for Bip 65, 66, etc if we want to indicate support and use if they are activated? I just know that for SegWit, it is "segwit"... Would I need to do something else to support properly these softforks?

I couldn't find documentation showing exactly what is needed anywhere but here is some:
soft forks
https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate_changes

segwit
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0144.mediawiki
https://github.com/bitcoin/bips/blob/master/bip-0145.mediawiki

some pages I came across while searching for default_witness_commitment
https://bitcointalksearch.org/topic/preparing-for-segwit-1674590


Some observations:
To activate segwit you first have to change the activation time window in chainparams.cpp. Change line 213, testnet segwit nTimeout to something really big. If we decide to activate segwit we will change the mainnet timeout to something reasonable.
        consensus.vDeployments[Consensus::DEPLOYMENT_SEGWIT].nTimeout = 14935968000 // I added a 0

Once this is done 'segwit' will show up in the vbavailable field of getblocktemplate. The correct bits were already set in version so there is nothing to do here.

You then need to mine 2 full cycles of 288 blocks before segwit activates. I've already done this on testnet.

Once activated getblocktemplate will return 'segwit' in the 'rules' field. Segwit transactions can now be added to mempool. In order for them to show up in the getblocktemplate call you need to add a parameter to the call.
   jsonGbt = sendRPCCall(_curl, "{\"method\": \"getblocktemplate\", \"params\": [{\"rules\":[\"segwit\"]}], \"id\": 0}\n");

From BIP145, 'when witness transactions are included in the block, the primary merkle root MUST be calculated with those transactions' "txid" field instead of "hash" '.
        hexStrToBin(json_string_value(json_object_get(json_array_get(jsonTxs, i), "txid")), txHashInvTmp)

Also from BIP145,  'a secondary merkle root MUST be calculated as per BIP 141's commitment structure specification to be inserted into the generation (coinbase) transaction'. I believe this is in the default_witness_commitment field of getblocktemplate. I stopped here for now. I didn't want to spend any more time on something we might not activate anyway.

Sorry, I didn't realize there was a pull request. I'll take a look later.

Could you give me some documentation about these? I need to know precisely everything I have to do to implement these features in rieMiner. I plan to release the first stable rieMiner 0.9 version in December 16, it would be great that until then, it provides everything needed for 0.16.3.

Else, you can do these yourself and make pull requests as you seem to be very knowledgable about Bitcoin Core code (honestly, I am not that good in this field). For anything involving the Coinbase, everything is in GetBlockTemplateData::coinBaseGen() in GBTClient.cpp for GetBlockTemplate. For Stratum, as the Coinbase comes from the pool, owners will need to upgrade their code as well.

"In the transactions you need to use the txid field instead of the hash field." What do you mean?

I have heard about support bits for Softforks, do I need to implement them, or they are already included in the GetBlockTemplate call? I think that we could add these support choices as options in the configuration file if needed.

Also, could you please merge my pull request that updates remaining Bitcoin icons to Riecoin ones?


It seems like a good start. Do anyone mentioned agree?
We should contact dga as he did not appear since a very long time, but seemed to be a good supporter of the project. I will try to PM him.

We should find a domain name that rocks, like rieco.in, and check that the domain is available (or even buy it quickly before someone else does). Any suggestion is welcome.