if you mean v0.10.2.0 then yes
Thank you
Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record - page 19. (Read 685387 times)
October 21, 2018, 08:35:04 AM
October 19, 2018, 03:49:05 AM
if you mean v0.10.2.0 then yes
October 19, 2018, 02:45:46 AM
Excuse me, can the old wallet still be used now?
October 13, 2018, 05:56:47 PM
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.
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?
October 13, 2018, 05:23:37 PM
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.
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
October 13, 2018, 05:05:57 PM
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
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
October 13, 2018, 02:19:48 PM
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.
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.
October 12, 2018, 02:06:28 PM
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.
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
October 12, 2018, 01:45:05 PM
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.
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.
October 12, 2018, 11:41:31 AM
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.
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.
October 12, 2018, 05:42:01 AM
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...
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...
October 12, 2018, 04:59:34 AM
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
Any suggestion why this is happening would be great.
Thanks in advance.
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
^~~~~~~~~~~~~~~
./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
^
./sync.h:103:29: error: ‘mutex’ is not a member of ‘std’
typedef AnnotatedMixin 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 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 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 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 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 lock(mutex);
^
./sync.h:206:43: error: ‘mutex’ was not declared in this scope
std::unique_lock lock(mutex);
^~~~~
./sync.h:206:43: note: suggested alternative: ‘putenv’
std::unique_lock 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 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 lock(mutex);
^
./sync.h:213:42: error: ‘mutex’ was not declared in this scope
std::lock_guard lock(mutex);
^~~~~
./sync.h:213:42: note: suggested alternative: ‘putenv’
std::lock_guard 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 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 lock(mutex);
^
./sync.h:223:46: error: ‘mutex’ was not declared in this scope
std::lock_guard lock(mutex);
^~~~~
./sync.h:223:46: note: suggested alternative: ‘putenv’
std::lock_guard 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::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::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::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
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
^~~~~~~~~~~~~~~
./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
^
./sync.h:103:29: error: ‘mutex’ is not a member of ‘std’
typedef AnnotatedMixin
^~~~~
./sync.h:103:29: error: ‘mutex’ is not a member of ‘std’
./sync.h:103:34: error: template argument 1 is invalid
typedef AnnotatedMixin
^
./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
^~~~~
./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
^
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
^~~~~
./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
^
./sync.h:206:43: error: ‘mutex’ was not declared in this scope
std::unique_lock
^~~~~
./sync.h:206:43: note: suggested alternative: ‘putenv’
std::unique_lock
^~~~~
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
^~~~~
./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
^
./sync.h:213:42: error: ‘mutex’ was not declared in this scope
std::lock_guard
^~~~~
./sync.h:213:42: note: suggested alternative: ‘putenv’
std::lock_guard
^~~~~
putenv
./sync.h: In member function ‘void CSemaphore::post()’:
./sync.h:223:34: error: ‘mutex’ is not a member of ‘std’
std::lock_guard
^~~~~
./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
^
./sync.h:223:46: error: ‘mutex’ was not declared in this scope
std::lock_guard
^~~~~
./sync.h:223:46: note: suggested alternative: ‘putenv’
std::lock_guard
^~~~~
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
_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
_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
_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.
October 11, 2018, 12:17:55 PM
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.
October 11, 2018, 05:10:46 AM
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.
October 09, 2018, 02:32:02 PM
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.
October 09, 2018, 02:20:18 PM
Or maybe other miners can start mining using a 0.16.3 wallet, I am the only one for now!
uBlock.it will upgrade to 0.16.3 as soon as it's approved by gatra and is available on the official github. I have started testing it and may mine a few blocks on main net but the pool will remain on 10.2 for the time being.
October 09, 2018, 02:02:47 PM
Imo I wish we would have ditched segwit. It's completely unnecessary for Riecoin. But we're already almost complete with 16.3 so it is what it is.
For fun, I am working on a Bitcoin Unlimited fork of riecoin with no segwit, it will take some time as i'm not very experienced with c++ so don't expect release anytime soon (or ever) but if you see it on the testnet you'll know. we'll see how it goes.
For fun, I am working on a Bitcoin Unlimited fork of riecoin with no segwit, it will take some time as i'm not very experienced with c++ so don't expect release anytime soon (or ever) but if you see it on the testnet you'll know. we'll see how it goes.
October 09, 2018, 01:51:21 PM
This thread now has Russian translation: https://bitcointalksearch.org/topic/riecoin-ric-pow-cpu-bitcoin-5038703
October 09, 2018, 10:43:33 AM
First ever RIC transaction with MultiSig address (with "T" prefix (equivalent to "3" Bitcoin addresses), it seems that clo1 agreed to use my suggested prefixes) mined in 966545 ! 20 RIC were sent to TWaXpZTMJoFAGMzFj5r4uwq7S7kWirtZkp, and another "T" address was used as change. Riecoin is becoming ready for the next decade!
This is so new that Cryptoid is not even showing the addresses correctly, with a "3" as prefix instead of "T".
This also means that rieMiner would already be 0.16.3 ready. Next step will be to test if I can send from such addresses.
News about transactions not broadcasting using 0.16.3 can be found in this topic (also read the end of previous page).
For now, if you want to create transactions with 0.16.3 and get them confirmed, add the IGJ's 78.83.27.28 node, and wait that I find a block (will take about 1/2 day on average currently)... Or maybe other miners can start mining using a 0.16.3 wallet, I am the only one for now!
After fixing this (if possible), we should start to distribute some Deb64 and Win64 binaries to start the transition.
Edit: hmmm, weird... It seems that it is impossible to spend the coins from "T" addresses... The Debug.log says "CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet", so it is not willing to broadcast...
! 20 RIC were sent to TWaXpZTMJoFAGMzFj5r4uwq7S7kWirtZkp, and another "T" address was used as change. Riecoin is becoming ready for the next decade!This is so new that Cryptoid is not even showing the addresses correctly, with a "3" as prefix instead of "T".
This also means that rieMiner would already be 0.16.3 ready. Next step will be to test if I can send from such addresses.
News about transactions not broadcasting using 0.16.3 can be found in this topic (also read the end of previous page).
For now, if you want to create transactions with 0.16.3 and get them confirmed, add the IGJ's 78.83.27.28 node, and wait that I find a block (will take about 1/2 day on average currently)... Or maybe other miners can start mining using a 0.16.3 wallet, I am the only one for now!
After fixing this (if possible), we should start to distribute some Deb64 and Win64 binaries to start the transition.
Edit: hmmm, weird... It seems that it is impossible to spend the coins from "T" addresses... The Debug.log says "CommitTransaction(): Transaction cannot be broadcast immediately, no-witness-yet", so it is not willing to broadcast...
October 08, 2018, 01:11:31 PM
Greetings,
For 16.3
http://download.riecoin-community.com/16.3/riecoind_16.3_openssl_1.1.patch.gz
Revisit the patch and tested , the wallet can be build with libssl 1.0 and libssl 1.1 or up , syncing on the network and seems to work. Tested and build on Debian stable (9 - stretch) and Debian unstable (sid).
...
To: clo1
Couple of weeks ago made this patch:
http://download.riecoin-community.com/16.0/riecoind_16.0_openssl_1.1.patch.gz
At least the wallet can be compiled for openssl 1.1 or up. With it wallet can connect on testnet and all is fine but on main net it have troubles, maybe I missed something. if you have time can check it. I will check it again but my time last weeks are very little.
...
To: clo1
Couple of weeks ago made this patch:
http://download.riecoin-community.com/16.0/riecoind_16.0_openssl_1.1.patch.gz
At least the wallet can be compiled for openssl 1.1 or up. With it wallet can connect on testnet and all is fine but on main net it have troubles, maybe I missed something. if you have time can check it. I will check it again but my time last weeks are very little.
...
For 16.3
http://download.riecoin-community.com/16.3/riecoind_16.3_openssl_1.1.patch.gz
Revisit the patch and tested , the wallet can be build with libssl 1.0 and libssl 1.1 or up , syncing on the network and seems to work. Tested and build on Debian stable (9 - stretch) and Debian unstable (sid).
Jump to: