Bitcoin Forum
April 24, 2019, 12:59:34 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 [294] 295 296 297 298 299 300 301 302 303 »
  Print  
Author Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record  (Read 660307 times)
IGJ
Newbie
*
Offline Offline

Activity: 29
Merit: 2


View Profile
October 11, 2018, 10:10:46 AM
 #5861

Is there anything new about this coin, I checked the website and it looks like they need some updates in it, it would be very nice if they do this, the site is an important part to convince investors to join in it.

You are right. To change official site rights and access have only the founder of the project and seems he is too busy right now. Also only he have rights over the official domains. The official domain is registered till 2022. That why I registered riecoin-community.com . For now we have board (forums), where we can expand themes about the Riecoin and coordinate better. If somebody serious want to start working on a modern look stylish site for the coin I can give him www.riecoin-community.com and a hosting space for it. Also can dedicate subdomain from riecoin-community.com for different project about the coin (which remind me PttnMe if you want something like pttnme.riecoin-community.com where to upload large bins send me pm on the board)
There are new about the coin, have new wallet (16.3), new miner , new community members , the things happens just the process is slow and will need more time.

Ziiip why do you think segwit is not good for the coin ? It will not hurt to have it like functionality even to not use it or activating it right now ?
The idea with never ending riecoin is cool and I am 100% agree. The unique of riecoin is its algorithm and I think we must not put limits on this. My c++ skills are not good too but I will help you in that.

The future of the coin right now depend on us. We can have voting on the community board about the direction to where the coin should be developed.
1556067574
Hero Member
*
Offline Offline

Posts: 1556067574

View Profile Personal Message (Offline)

Ignore
1556067574
Reply with quote  #2

1556067574
Report to moderator
1556067574
Hero Member
*
Offline Offline

Posts: 1556067574

View Profile Personal Message (Offline)

Ignore
1556067574
Reply with quote  #2

1556067574
Report to moderator
1556067574
Hero Member
*
Offline Offline

Posts: 1556067574

View Profile Personal Message (Offline)

Ignore
1556067574
Reply with quote  #2

1556067574
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
ziiip
Full Member
***
Offline Offline

Activity: 249
Merit: 101

uBlock.it Admin


View Profile WWW
October 11, 2018, 05:17:55 PM
Last edit: October 12, 2018, 03:34:21 AM by ziiip
 #5862


Ziiip why do you think segwit is not good for the coin ? It will not hurt to have it like functionality even to not use it or activating it right now ?
The idea with never ending riecoin is cool and I am 100% agree. The unique of riecoin is its algorithm and I think we must not put limits on this. My c++ skills are not good too but I will help you in that.

The future of the coin right now depend on us. We can have voting on the community board about the direction to where the coin should be developed.

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.

Riecoin Pool http://uBlock.it/
Pon13
Full Member
***
Offline Offline

Activity: 568
Merit: 123



View Profile WWW
October 12, 2018, 09:59:34 AM
Last edit: October 12, 2018, 10:24:13 AM by Pon13
 #5863

Good points you have there ziiip !

I have a different problem. i Try to compile the new wallet following instructions from github (https://github.com/riecointeam/riecoin)
Specificaly i followed this https://github.com/riecointeam/riecoin/blob/master/doc/build-windows.md
Everything went fine till the last command "make"

When i execute the last make command i get the following output
Code:
user@Laptop:/usr/src/riecoin$ make
 cd . && /bin/bash ./config.status Makefile
config.status: creating Makefile
Making all in src
make[1]: Entering directory '/usr/src/riecoin/src'
 cd .. && /bin/bash ./config.status src/Makefile depfiles
config.status: creating src/Makefile
config.status: executing depfiles commands
make[2]: Entering directory '/usr/src/riecoin/src'
make[3]: Entering directory '/usr/src/riecoin'
make[3]: Leaving directory '/usr/src/riecoin'
  CXX      riecoind-bitcoind.o
In file included from ./util.h:19:0,
                 from bitcoind.cpp:17:
./sync.h:94:53: error: ‘recursive_mutex’ is not a member of ‘std’
 class CCriticalSection : public AnnotatedMixin<std::recursive_mutex>
                                                     ^~~~~~~~~~~~~~~
./sync.h:94:53: error: ‘recursive_mutex’ is not a member of ‘std’
./sync.h:94:68: error: template argument 1 is invalid
 class CCriticalSection : public AnnotatedMixin<std::recursive_mutex>
                                                                    ^
./sync.h:103:29: error: ‘mutex’ is not a member of ‘std’
 typedef AnnotatedMixin<std::mutex> CWaitableCriticalSection;
                             ^~~~~
./sync.h:103:29: error: ‘mutex’ is not a member of ‘std’
./sync.h:103:34: error: template argument 1 is invalid
 typedef AnnotatedMixin<std::mutex> CWaitableCriticalSection;
                                  ^
./sync.h:106:14: error: ‘condition_variable’ in namespace ‘std’ does not name a type
 typedef std::condition_variable CConditionVariable;
              ^~~~~~~~~~~~~~~~~~
./sync.h:109:31: error: ‘mutex’ is not a member of ‘std’
 typedef std::unique_lock<std::mutex> WaitableLock;
                               ^~~~~
./sync.h:109:31: error: ‘mutex’ is not a member of ‘std’
./sync.h:109:36: error: template argument 1 is invalid
 typedef std::unique_lock<std::mutex> WaitableLock;
                                    ^
In file included from ./util.h:19:0,
                 from bitcoind.cpp:17:
./sync.h:197:10: error: ‘condition_variable’ in namespace ‘std’ does not name a type
     std::condition_variable condition;
          ^~~~~~~~~~~~~~~~~~
./sync.h:198:10: error: ‘mutex’ in namespace ‘std’ does not name a type
     std::mutex mutex;
          ^~~~~
./sync.h: In member function ‘void CSemaphore::wait()’:
./sync.h:206:31: error: ‘mutex’ is not a member of ‘std’
         std::unique_lock<std::mutex> lock(mutex);
                               ^~~~~
./sync.h:206:31: error: ‘mutex’ is not a member of ‘std’
./sync.h:206:36: error: template argument 1 is invalid
         std::unique_lock<std::mutex> lock(mutex);
                                    ^
./sync.h:206:43: error: ‘mutex’ was not declared in this scope
         std::unique_lock<std::mutex> lock(mutex);
                                           ^~~~~
./sync.h:206:43: note: suggested alternative: ‘putenv’
         std::unique_lock<std::mutex> lock(mutex);
                                           ^~~~~
                                           putenv
./sync.h:207:9: error: ‘condition’ was not declared in this scope
         condition.wait(lock, [&]() { return value >= 1; });
         ^~~~~~~~~
./sync.h: In member function ‘bool CSemaphore::try_wait()’:
./sync.h:213:30: error: ‘mutex’ is not a member of ‘std’
         std::lock_guard<std::mutex> lock(mutex);
                              ^~~~~
./sync.h:213:30: error: ‘mutex’ is not a member of ‘std’
./sync.h:213:35: error: template argument 1 is invalid
         std::lock_guard<std::mutex> lock(mutex);
                                   ^
./sync.h:213:42: error: ‘mutex’ was not declared in this scope
         std::lock_guard<std::mutex> lock(mutex);
                                          ^~~~~
./sync.h:213:42: note: suggested alternative: ‘putenv’
         std::lock_guard<std::mutex> lock(mutex);
                                          ^~~~~
                                          putenv
./sync.h: In member function ‘void CSemaphore::post()’:
./sync.h:223:34: error: ‘mutex’ is not a member of ‘std’
             std::lock_guard<std::mutex> lock(mutex);
                                  ^~~~~
./sync.h:223:34: error: ‘mutex’ is not a member of ‘std’
./sync.h:223:39: error: template argument 1 is invalid
             std::lock_guard<std::mutex> lock(mutex);
                                       ^
./sync.h:223:46: error: ‘mutex’ was not declared in this scope
             std::lock_guard<std::mutex> lock(mutex);
                                              ^~~~~
./sync.h:223:46: note: suggested alternative: ‘putenv’
             std::lock_guard<std::mutex> lock(mutex);
                                              ^~~~~
                                              putenv
./sync.h:226:9: error: ‘condition’ was not declared in this scope
         condition.notify_one();
         ^~~~~~~~~
In file included from /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/condition_variable:39:0,
                 from ./sync.h:11,
                 from ./util.h:19,
                 from bitcoind.cpp:17:
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h: In instantiation of ‘void std::unique_lock<_Mutex>::lock() [with _Mutex = CCriticalSection]’:
./sync.h:128:23:   required from here
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h:267:17: error: ‘std::unique_lock<CCriticalSection>::mutex_type {aka class CCriticalSection}’ has no member named ‘lock’
      _M_device->lock();
      ~~~~~~~~~~~^~~~
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h: In instantiation of ‘bool std::unique_lock<_Mutex>::try_lock() [with _Mutex = CCriticalSection]’:
./sync.h:137:23:   required from here
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h:281:27: error: ‘std::unique_lock<CCriticalSection>::mutex_type {aka class CCriticalSection}’ has no member named ‘try_lock’
      _M_owns = _M_device->try_lock();
                ~~~~~~~~~~~^~~~~~~~
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h: In instantiation of ‘void std::unique_lock<_Mutex>::unlock() [with _Mutex = CCriticalSection]’:
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h:232:10:   required from ‘std::unique_lock<_Mutex>::~unique_lock() [with _Mutex = CCriticalSection]’
./sync.h:144:183:   required from here
/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/bits/std_mutex.h:323:17: error: ‘std::unique_lock<CCriticalSection>::mutex_type {aka class CCriticalSection}’ has no member named ‘unlock’
      _M_device->unlock();
      ~~~~~~~~~~~^~~~~~
Makefile:8411: recipe for target 'riecoind-bitcoind.o' failed
make[2]: *** [riecoind-bitcoind.o] Error 1
make[2]: Leaving directory '/usr/src/riecoin/src'
Makefile:9481: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/usr/src/riecoin/src'
Makefile:748: recipe for target 'all-recursive' failed
make: *** [all-recursive] Error 1

Any suggestion why this is happening would be great.
Thanks in advance.

PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 12, 2018, 10:42:01 AM
 #5864

ziiip, All your arguments are valid, but I think that it is better for now to follow the Bitcoin direction and code, and not take risks by not using something that is working and widely accepted. Then, if Riecoin manages to get to the top 50 coins and attract many more competent developers, here we can start to discuss about alternate choices.

I would personally be glad if Riecoin becomes so widely used that we need fees to use it. But I agree that as long as the network is underused (i.e. far from having full blocks), we should modify the code to allow 0 fee transactions for transactions < 1 KB (you are right, up to 6 inputs). It is a certain advantage over Primecoin that require at least 0.01 XPM fee for every transaction, which is ridiculous!

Voting sounds good for later. The votes could be weighted by balances (with a limit to avoid whales taking all the decisions) or simply require a minimum and significant RIC balance, to get people buying RIC and be involved. It is also better to agree to go to a direction together instead of starting pointless debates and shitforks that split all the efforts...

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
IGJ
Newbie
*
Offline Offline

Activity: 29
Merit: 2


View Profile
October 12, 2018, 04:41:31 PM
Last edit: October 12, 2018, 05:00:27 PM by IGJ
 #5865

To pon13
https://forum.riecoin-community.com/viewtopic.php?f=7&t=16&p=124#p124


---------------------------------------------------------------
Both of you ziiip and pttn are right and have very good logic. I am asking not to produce debates, my point is to understand how everybody sees the things and tell his ideas freely. We need to have 100% consensus and to find the way to achieve that. Now we have newer wallet, and we have to make it usable , to make it usable we all (or at least 90% of us - pools , 24/7 nodes, miners owners and zapple.com of course) have to agree to migrate the network , to make such agreement we have to speak. Then we have to integrate changes in the newer version which will take time and programing resources. After then when all agreement conditions are met and the features are tested we can migrate to the newer wallet version.

Right now we are loosing time and if we keep doing it we may end up with one unused 16.3 which is outdated too, and one more outdated 10.2 running the network. By me our targets now should be to to attract investors and to popularize the coin, I don't know if newer wallet will do this, but definitely 10.2 which is 4 years behind will not. Of course the problems that 16.3 cant be released as official and the official site is out dated still remains. My respects to Gatra but this is not serious , OK he don't have time or don't want to be involved more or he is uneasy because can't pay the bounty , but cant leave us with tied hands.


---------------------------------------------------------------
Pablo, if you worries are about the bounty come and say that and that I have not possibility to pay now what I promised. Nobody will judge you and
I'm sure clo1 will understand and will not eat you. Everybody can be in situation where he can't do what he is promised , but a man must exit from it with honor, and silence is not honor it only looks bad. If you are really so busy delegate somebody you have trust (nobody can't convince me for 3 months don't have 30 minutes to write a word). If you don't want to be involved in this project tell, I will pay you from my personal funds expenses for the domains and for the official github rights and then you can spread them to the community (I don't want them for me, every seriously looking project do not depend on one person only). We have to move forward or this project will end up like the thousands scam coins already nobody remember.
---------------------------------------------------------------


For me no fee transactions are as good as bad. Good because looks more attractive and bad because creating potential attack. If somebody create millions transactions that will flood and block the network, So if we going with zero fees we should have some kind of protecting algorithm in the nodes. I cant get decision for myself which is better. From what I read by now for the problem with transaction version (in same link I posted for Pon13 - first post of the page) If we switch version to 1 we will lost bip68 (RLT) and I am not sure for segwit at all, if we keep it to 2 transactions created from 16.3 will be rejected from 10.2 so for the migration is critical more mining power to start using 16.3.
clo1
Jr. Member
*
Offline Offline

Activity: 34
Merit: 1


View Profile
October 12, 2018, 06:45:05 PM
 #5866

As IGJ mentioned, transaction version 2 indicates support for BIP68. This allows transactions which aren't executed until some time in the future. I don't think there is a problem with temporarily changing this to 1.

I mentioned earlier that transactions that start with 'T' could not be spent and recommended only using legacy addresses. I think the problem is that a witness is being attached, but segwit has not been activated yet so it is rejected. I'll look into why the witness is being attached. You may be able to get around this with prematurewitness=1. I haven't tested this and I'm not sure what 0.10.2 would do with the transaction.

I will also look into allowing transactions with no fee, but not sure if this is good or bad.

I also have no preference regarding segwit. As the code is now, it will never be activated. We would need to change the start and timeout times for it to be capable of being activated.

Yes, I used Pttn's suggestions for prefixes. He won with a vote of 1-0. I think there is one other 'T' transaction about a month ago.

It is good that people are starting to use the new version. Just be aware that BIP65 and BIP66 are set to become active at block 1000000 which should be early December. When this happens, all blocks mined with current miners (other than the current rieMiner attached to a 0.16.3 node) will be rejected by the 0.16.3 code. The block version, which is is different from transaction version, will need to be at least 4 to be accepted. If 0.16.3 doesn't become the official code by then, those who are running 0.16.3 will need to increase the 1000000 to something larger.
cryptapus
Hero Member
*****
Offline Offline

Activity: 608
Merit: 500



View Profile WWW
October 12, 2018, 07:06:28 PM
 #5867

As IGJ mentioned, transaction version 2 indicates support for BIP68. This allows transactions which aren't executed until some time in the future. I don't think there is a problem with temporarily changing this to 1.

I mentioned earlier that transactions that start with 'T' could not be spent and recommended only using legacy addresses. I think the problem is that a witness is being attached, but segwit has not been activated yet so it is rejected. I'll look into why the witness is being attached. You may be able to get around this with prematurewitness=1. I haven't tested this and I'm not sure what 0.10.2 would do with the transaction.

I will also look into allowing transactions with no fee, but not sure if this is good or bad.

I also have no preference regarding segwit. As the code is now, it will never be activated. We would need to change the start and timeout times for it to be capable of being activated.

Yes, I used Pttn's suggestions for prefixes. He won with a vote of 1-0. I think there is one other 'T' transaction about a month ago.

It is good that people are starting to use the new version. Just be aware that BIP65 and BIP66 are set to become active at block 1000000 which should be early December. When this happens, all blocks mined with current miners (other than the current rieMiner attached to a 0.16.3 node) will be rejected by the 0.16.3 code. The block version, which is is different from transaction version, will need to be at least 4 to be accepted. If 0.16.3 doesn't become the official code by then, those who are running 0.16.3 will need to increase the 1000000 to something larger.

Yes, changing the TX version to 1 should work. Once CSV is activated you can change it back to 2 (at least that worked on v0.14).

https://github.com/riecointeam/riecoin/blob/master/src/primitives/transaction.h#L268

There is probably some older activation logic for BIP65 and BIP66, I'll have to look up that but it may have been ~v0.11

website | PGP fingerprint: 692C 0756 E57D 2FA1 7601 3729 010B 717F 231C E7AA | BTC Address: 1CrYPTB1o7QWc8hXqBMP2LtAJh1VMtTFBh
PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 13, 2018, 07:19:48 PM
Last edit: October 13, 2018, 11:05:07 PM by PttnMe
 #5868

I now have my own Riecoin page. There, you can currently find general links about Riecoin, and download Riecoin-Qt Deb64 and Win64 binaries.
You will even find the full blockchain up to Block 968981 for Riecoin Core 0.16.3, to avoid having to sync everything.
If I had more time, I would complete this page to make it more useful. If you wish IGJ, you can make a redirection from Pttn.Riecoin-Community.com to ric.Pttn.me.

Step by Step how I compiled for Windows available here. Some modifications of the code will make many steps unnecessary. I think that we should not use that old Db4.8 anymore and upgrade to 5.3. At worst, this is just a blockchain redownload and a few dump/importprivkeys to do (or just send funds to new addresses).

So everyone, help Riecoin modernize by starting using 0.16.3 now!
I agree with IGJ, we should not take too much time to upgrade to 0.16.3. Then we must be ready to follow future Bitcoin Core updates actively and not end up again with an outdated wallet.
Even if the update is still unofficial, it will eventually happen, so we should not wait gatra and advance our own.

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
clo1
Jr. Member
*
Offline Offline

Activity: 34
Merit: 1


View Profile
October 13, 2018, 10:05:57 PM
 #5869

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
cryptapus
Hero Member
*****
Offline Offline

Activity: 608
Merit: 500



View Profile WWW
October 13, 2018, 10:23:37 PM
 #5870

As IGJ mentioned, transaction version 2 indicates support for BIP68. This allows transactions which aren't executed until some time in the future. I don't think there is a problem with temporarily changing this to 1.

I mentioned earlier that transactions that start with 'T' could not be spent and recommended only using legacy addresses. I think the problem is that a witness is being attached, but segwit has not been activated yet so it is rejected. I'll look into why the witness is being attached. You may be able to get around this with prematurewitness=1. I haven't tested this and I'm not sure what 0.10.2 would do with the transaction.

I will also look into allowing transactions with no fee, but not sure if this is good or bad.

I also have no preference regarding segwit. As the code is now, it will never be activated. We would need to change the start and timeout times for it to be capable of being activated.

Yes, I used Pttn's suggestions for prefixes. He won with a vote of 1-0. I think there is one other 'T' transaction about a month ago.

It is good that people are starting to use the new version. Just be aware that BIP65 and BIP66 are set to become active at block 1000000 which should be early December. When this happens, all blocks mined with current miners (other than the current rieMiner attached to a 0.16.3 node) will be rejected by the 0.16.3 code. The block version, which is is different from transaction version, will need to be at least 4 to be accepted. If 0.16.3 doesn't become the official code by then, those who are running 0.16.3 will need to increase the 1000000 to something larger.

Yes, changing the TX version to 1 should work. Once CSV is activated you can change it back to 2 (at least that worked on v0.14).

https://github.com/riecointeam/riecoin/blob/master/src/primitives/transaction.h#L268

There is probably some older activation logic for BIP65 and BIP66, I'll have to look up that but it may have been ~v0.11

Here is the IsSuperMajority() logic I mentioned, perhaps it might be useful to pull this in temporarily to activate BIP65 and BIP66...

https://github.com/bitcoin/bitcoin/blob/0.11/src/main.cpp#L2971

website | PGP fingerprint: 692C 0756 E57D 2FA1 7601 3729 010B 717F 231C E7AA | BTC Address: 1CrYPTB1o7QWc8hXqBMP2LtAJh1VMtTFBh
PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 13, 2018, 10:56:47 PM
 #5871

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.

Sounds good. I am not against fees when they are such low, and letting everyone decide for the minimum fee is a good solution. Finally, users will probably not even care to pay a few riemanns instead of 0. I think that we can let the default settings as is (but it is really equal to me).

The spamming prevention is a good point, though, but in this case, we would need to increase significantly the minimum fee, else it would still be easy to bloat the blockchain. It seems better to not penalize everyone and hope that no such attack occur before it becomes unpractical to make (if the fees somehow become in practice high enough to make such attacks unpractical, either by a price increase or by people setting higher fees).

What work is remaining before a "ready for productions use" 0.16.3, according to you? Are we almost done, or there is still much work to do?
Would the remaining work be more in the actual code, or more in the new version adoption and softforks/BIPs activation?

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
lebow
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
October 19, 2018, 07:45:46 AM
 #5872

Excuse me, can the old wallet still be used now?
Pon13
Full Member
***
Offline Offline

Activity: 568
Merit: 123



View Profile WWW
October 19, 2018, 08:49:05 AM
 #5873

if you mean v0.10.2.0 then yes

lebow
Newbie
*
Offline Offline

Activity: 9
Merit: 0


View Profile
October 21, 2018, 01:35:04 PM
 #5874

if you mean v0.10.2.0 then yes


Thank you
PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 22, 2018, 12:43:12 AM
 #5875

For beginners here, I wrote a Getting Started page in my Riecoin website.

Additionally, I created a Profitability Calculator.
To use it, you need to get the 2 to 4 tuples/s metrics by benchmarking using rieMiner during enough time.
Do not hesitate to report if you find something flawed in the calculator.

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
toogoody
Jr. Member
*
Offline Offline

Activity: 350
Merit: 1


View Profile
October 28, 2018, 08:07:41 PM
 #5876

List of Riecoin mining pools with live stats & hashrate distribution

https://miningpoolstats.stream/riecoin
xpoolx
Full Member
***
Offline Offline

Activity: 203
Merit: 101


View Profile
October 29, 2018, 10:07:12 AM
 #5877

List of Riecoin mining pools with live stats & hashrate distribution

https://miningpoolstats.stream/riecoin

Nice pools stats page!
clo1
Jr. Member
*
Offline Offline

Activity: 34
Merit: 1


View Profile
October 30, 2018, 02:27:58 AM
 #5878

For beginners here, I wrote a Getting Started page in my Riecoin website.

Additionally, I created a Profitability Calculator.
To use it, you need to get the 2 to 4 tuples/s metrics by benchmarking using rieMiner during enough time.
Do not hesitate to report if you find something flawed in the calculator.

Difficulty scaling should probably be 9th power instead of 6th. The prime checks are proportional to difficulty ^3 so it is constellation length + 3. This is what riecoin uses in computing difficulties.

The primecheck uses multiplications. For multiplication it should be the number of words rather than the number of bits that matters. It's possible you would get more accurate results with:
(d2/d1)^7*ceil(d2/64)^2/ceil(d1/64)^2
I'm only suggesting this for the calculator, not for riecoin.
PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 30, 2018, 03:31:06 AM
 #5879

Difficulty scaling should probably be 9th power instead of 6th. The prime checks are proportional to difficulty ^3 so it is constellation length + 3. This is what riecoin uses in computing difficulties.

The primecheck uses multiplications. For multiplication it should be the number of words rather than the number of bits that matters. It's possible you would get more accurate results with:
(d2/d1)^7*ceil(d2/64)^2/ceil(d1/64)^2
I'm only suggesting this for the calculator, not for riecoin.

Thank you for your remark. Now, I just realize that Riecoin.org also says in its FAQ that the work needed is given by O(log(p)^(n + 3)).
I already noticed that a power of 9 was used to calculate the Superblock difficulty, but did not understand why it was not just 6 instead. So it was because I overlooked the verifying part.
I will update the calculator later.

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
PttnMe
Jr. Member
*
Offline Offline

Activity: 66
Merit: 2

rieMiner (Riecoin miner) developer


View Profile
October 30, 2018, 05:12:06 PM
 #5880

So I tried a power of 9, but the calculation is still very imprecise (for example, taking Standard Benchmark and Easy Benchmark results for a given CPU should give the same earnings, but there is instead always a 2-5 fold difference, either with a power of 6 or 9). There must be something else to take in account.

Considering words instead of bits does not change much the results, the rounding may be negligible when compared to the uncertainties of the metrics.

And after thinking again about it, as I am really extrapolating the average time needed to find a block, it should already take in account the verifying work in some way, so it should actually be valid to directly use the Hardy-Littlewood k-tuple conjecture and a power of 6.

So for now, I will let the calculator as is and mark it as experimental. Any help to fix it is welcome.

rieMiner (https://github.com/Pttn/rieMiner) - Riecoin solo + pooled miner
Pages: « 1 ... 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 [294] 295 296 297 298 299 300 301 302 303 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!