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

Edit: I should also add that I'm not sure v0.10.2 had all the correct ports defined... You may want to remove your peers.dat file and try a restart.

I am seeing outgoing traffic on port 8333 and 28333 from this new client.

I thought RieCoin only communicated on port 28333.

Have I been making an incorrect assumption?

Major new version

Binaries and source code:

...

Glad to hear that, I wonder how much RIC/day you are earning. At least the RaspBerry Pi uses very low power.

Works. Merci.
had to add to the rieMiner.conf:


512 MiB didn't work

still states "using >1100MiB" which is funny since RPi3 only has 1024 MiB, but hey, it works...
Hashrate is >340 kH/s (says my pool)

Is there a chance that coinmarketcap will track RIC again? Or am i only doing Mathematics a favor now?

Enjoy.

#256 Men in Black
PrimeTableLimit = 268435456

Unfortunatly i can't compile rieMiner on my Raspberry Pi3b - Screenshot:....
Looks like that there are some issues with including cpuid.h?
(https://github.com/SoftEtherVPN/SoftEtherVPN/issues/574#issue-343408913)
(https://www.reddit.com/r/reddCoin/comments/688ya8/compile_reddcoin_on_raspberry_pi_b/)
btw, i am using pi64-lite as OS

cheers

I compiled rieMiner in a Toshiba AC100 (Armhf CPU, Ubuntu 16.04) without any issue, so rieMiner should work in a Raspberry Pi with Linux. Note that you need to use the Light branch. Also be sure to read properly the README.md (in particular, 32 bits compilation instructions (no longer needed) and reduce the PrimeTableLimit for less memory usage). If you need help, please post questions here.

# apt install g++ make git libjansson-dev libcurl4-openssl-dev libssl-dev libgmp-dev
git clone https://github.com/Pttn/rieMiner.git
cd rieMiner
git checkout Light
make -j 4

I compiled rieMiner in a Toshiba AC100 (Armhf CPU, Ubuntu 16.04) without any issue, so rieMiner should work in a Raspberry Pi with Linux. Note that you need to use the Light branch. Also be sure to read properly the README.md (in particular, 32 bits compilation instructions and reduce the PrimeTableLimit for less memory usage). If you need help, please post questions here.

Hi, may I ask a naive question?

I noticed that once a while there are couple of blocks with 22.66 block rewards instead of 25, for example:

https://chainz.cryptoid.info/ric/block.dws?7d613e7cb67c960620d11c8cc5d958cad179bce7480322e3de4939ef501e3374.htm

Do you know what is the cause? Is that a mining software bug or something in the Riecoin consensus rules?

Thanks!

Ah, I think I found some of your technical issues... My impression is that I don't think transaction size should be any issue for Riecoin since we will most likely never approach scaling issues like upstream. I wasn't aware of any issue with zero-fee transactions and segwit, if a miner wishes to mine them I don't see a reason why that is not allowed (that would be a pool or miner setting, correct?).

Segwit's benefits for Riecoin are beyond scaling though, Script versioning and MAST, Schnorr, others come to mind.

I looked into transaction fees a a bit. I think there is enough flexibility through configuration options that we don't need to add a zero transaction fee capability. The parameters are:
mintxfee           - the minimum transaction fee in RIC/kB
minrelaytxfee  - the minimum transaction fee for a node to relay the transaction in RIC/kB
blockmintxfee  - minimum fee for a transaction to be included in blocks created by mining code, in RIC/kB

The defaults are all 0.00001000 RIC/kB. The smallest value is .00000001.

-mintxfee=.00000001 -minrelaytxfee=.00000001 -blockmintxfee=.00000001 will allow transactions of 1 satoshi (or gatra). I have tested this on testnet.

This way we allow users, nodes, and miners to determine what rates should be instead of fixing it in code and we stay consistent with bitcoin.

I could see possibly lowering the defaults.

Two other values that might be useful:
fallbackfee           - the standard fee, defaults to 0.00020000 RIC/kB
m_discard_rate    - any change smaller than this is considered dust and is added to the transaction fee, default is .00010000

...

My only worry is that "All Others" miner goes along with the upgrade as well, since they do not publicly discuss anything we'll have to keep a close eye on if/when they signal support.

Ah, I think I found some of your technical issues... My impression is that I don't think transaction size should be any issue for Riecoin since we will most likely never approach scaling issues like upstream. I wasn't aware of any issue with zero-fee transactions and segwit, if a miner wishes to mine them I don't see a reason why that is not allowed (that would be a pool or miner setting, correct?).

Segwit's benefits for Riecoin are beyond scaling though, Script versioning and MAST, Schnorr, others come to mind.

The reasons I think segwit is unnecessary for Riecoin.
1) The blockahin is heavier (transactions require more space)
2) The fee is smaller only for some kind of tx
3) Riecoin traditionally had zero fees for transactions with fewer than 7 inputs(not positive on this number off the top of my head but zero fee is default for small size tx)
4) Since segwit tx get discounted fees by weight and Riecoin still wants 0 fee tx, it only makes sense to change this and make segwit tx more expensive since it requires more space. (this would require change to current Core implementation if segwit is adopted)

Given these points I still see how it's valuable to follow BTC code because it's easiest to merge future updates etc (probably why 99% of altcoins blindly follow it exclusively)
FWIW I really don't care if we continue with following Bitcoin Core at the end of the day these issues are very minor since the chain is not likely to see high use such as the bitcoin chain.

I personally like what Bitcoin Unlimited is doing, primarily with graphene and other improvements to help block propagation, further reduce orphan rates. But I'm not married to that solution, just decided to play around with the idea.

Hopefully that answers your question. I don't intend to have a huge debate about it, but I think the fee situation should at least be given special attention, unless of course everyone is fine with ditching 0 fee tx.