Bitcoin Forum
December 13, 2019, 08:06:14 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 243 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 304 305 306 »
  Print  
Author Topic: [ANN][RIC] Riecoin: constellations POW *CPU* HARD FORK successful, world record  (Read 676086 times)
PttnMe
Member
**
Offline Offline

Activity: 82
Merit: 20

Riecoin developer


View Profile
October 06, 2018, 10:16:26 AM
 #5841

Bounty deadline for the CPU Underuse bug fix extended to November 1 2018, 00:00 Zurich timezone and increased to 2000 RIC, and even 5000 RIC if more work is done! Read this post.

Remember that 5000 RIC was worth hundreds of $ before the crash, and could be much more in the future.

After the deadline, the reward will be reduced to 500 RIC (or 1250 for the complete rewriting) until January 1 2019 00:00 Zurich Timezone, or as soon as the new wallet is officially approved. So please someone try to fix the CPU underuse bug before November. I do not have the time to do this myself until a while.
1576224374
Hero Member
*
Offline Offline

Posts: 1576224374

View Profile Personal Message (Offline)

Ignore
1576224374
Reply with quote  #2

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

Posts: 1576224374

View Profile Personal Message (Offline)

Ignore
1576224374
Reply with quote  #2

1576224374
Report to moderator
1576224374
Hero Member
*
Offline Offline

Posts: 1576224374

View Profile Personal Message (Offline)

Ignore
1576224374
Reply with quote  #2

1576224374
Report to moderator
PttnMe
Member
**
Offline Offline

Activity: 82
Merit: 20

Riecoin developer


View Profile
October 07, 2018, 05:30:40 PM
Last edit: October 08, 2018, 04:20:03 PM by PttnMe
 #5842

clo1, is there any way to send Riecoins without paying any transaction fee like the 0.10.2 (if not, this would in another hand be nice to encourage people to mine, even though only a few hundreds gatras* is not much Cheesy)?

Is it normal that I am not seeing incoming transactions (sent from another 0.10.2) with 0.16.3; I see them only when someone mined them?
Also, transactions sent using 0.16.3 seem not to be broadcasting. They appear in GetBlockTemplate, but not for another wallet. The text "broadcast though x nodes" is not appearing, it only says that it is in the MemPool.
I had to double-spend to get back some coins... I am pretty sure that I am connected to enough nodes...
I might try to mine one such transaction to see what happens. Especially one with the Replace By Fee activated.

* 1 gatra = 10^(-8) RIC, or we could also say 1 riemann too :p

Edit: transactions mined and broadcasted successfully in 966103.
3559bd615e38ec983e0cc1b688a73eed1f82cd3bc4a4a027a88b75229b74f899 used Replace By Fee, as you can see with the 4294967293 sequence value.

Quote
A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).

If nobody used 0.16.3 to send any transaction in the network before, this is the first transaction created by a Riecoin Core 0.16.3 and confirmed in the MainNet Cheesy !
Now, am I the only one that have the transactions not broadcasting, using 0.16.3?
IGJ
Newbie
*
Offline Offline

Activity: 29
Merit: 2


View Profile
October 08, 2018, 06:11:31 PM
 #5843

Greetings,

...
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).
PttnMe
Member
**
Offline Offline

Activity: 82
Merit: 20

Riecoin developer


View Profile
October 09, 2018, 03:43:33 PM
Last edit: October 09, 2018, 04:14:51 PM by PttnMe
 #5844

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 Cheesy ! 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...
xandry
Staff
Legendary
*
Offline Offline

Activity: 1834
Merit: 1246



View Profile
October 09, 2018, 06:51:21 PM
 #5845

This thread now has Russian translation: https://bitcointalk.org/index.php?topic=5038703.0

████████████████████████████
████████▀▀ █▀ █▀ ▀██████████
█████████▄ ▄▄▄▄▄▄███████████
██████████▀     ▀  ▀████████
███████▀ ▀  ▄█▀▀▀█▀▀████████
██████▄      █▄  ▀▀  ▀██████
██████         ▄▄█▄ ▄ ▀█████
█████ ▄         ▀▀ ▄ ▀ █████
██████▌          █▀█▀ ▐█████
███████  ▄▌         ▄ ██████
████████▄█         ▄████████
█████████▀     ▄▄ ▄█████████
████████████████████████████
.JACKMATE'S...........
.
MAJESTIC..
████████████████████████
███████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
████████████████████████
.
..WIN 1 BITCOIN ON EVERY PREMIER LEAGUE MATCHDAY..
████████████████████████████████
████████████▀█▀ ▀█▀█▀███████████
███████████▄ ▄▄▄▄▄▄▄████████████
███████████▀▀▄▄▄▄▄▄▄▄███████████
█████████▀▄ ██▀▄▄▄ ▀ ▄▀█████████
███████▀ ▀█████▄▄▄█▄▄▄██████████
███████▀▄████████▀  ▀█ █▐███████
███████ ▀█████████▄█▀▀██ ███████
████████ ███▀██████ ▄ ██ ███████
████████▌▐▀▄ ██████████ ▄███████
█████████▄██▌▐█████▀██ █████████
████████████▄▀▀▀▀▀▄ ▀▄██████████
████████████████████████████████
.
.JOIN US - IT'S FREE! .
ziiip
Full Member
***
Offline Offline

Activity: 255
Merit: 102

uBlock.it Admin


View Profile WWW
October 09, 2018, 07:02:47 PM
Last edit: October 09, 2018, 07:14:43 PM by ziiip
 #5846

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.  Cheesy

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

Activity: 255
Merit: 102

uBlock.it Admin


View Profile WWW
October 09, 2018, 07:20:18 PM
 #5847

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.

Riecoin Pool http://uBlock.it/
Kriptos
Member
**
Offline Offline

Activity: 532
Merit: 10

Adoption Blockchain e-Commerce to World


View Profile
October 09, 2018, 07:32:02 PM
 #5848

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.

IGJ
Newbie
*
Offline Offline

Activity: 29
Merit: 2


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

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.
ziiip
Full Member
***
Offline Offline

Activity: 255
Merit: 102

uBlock.it Admin


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


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: 631
Merit: 123



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

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.

Bill Hicks was right about....everything
PttnMe
Member
**
Offline Offline

Activity: 82
Merit: 20

Riecoin developer


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

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...
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
 #5853

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: 35
Merit: 2


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

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: 612
Merit: 504



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

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

Activity: 82
Merit: 20

Riecoin developer


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

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.
clo1
Jr. Member
*
Offline Offline

Activity: 35
Merit: 2


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

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: 612
Merit: 504



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

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

Activity: 82
Merit: 20

Riecoin developer


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

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?
lebow
Newbie
*
Offline Offline

Activity: 9
Merit: 0


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

Excuse me, can the old wallet still be used now?
Pages: « 1 ... 243 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 304 305 306 »
  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!