New v2.0 Wallet Discussions

Hi, I am creating this topic for discussion on the new wallet.
There are a number of you now testing the wallet, so I welcome any feedback that you may have.
You can make any comment on operational, bugs and enhancements.

I have a running issues list on github with the follow items

  • Enable staking after unlocking wallet <1 Mar, 2016 - RESOLVED - inserted logic to allow staking to start after unlocking wallet>
  • Rejected stakes stay at the top of the recent transactions list <1 Mar, 2016 - RESOLVED - Updated GUI to sort by date (bonus - will display last 5 transactions>
  • Block nVersion validation missing from AcceptBlock() <3 Mar, 2016 - RESOLVED - Corrected missing code for Strict DER Sigs>
  • transaction fee calculation needs checking <1 Mar, 2016 - RESOLVED - Error with GUI not displaying the correct inputted TX Fee>

Bonus changes

  • 1 Mar, 2016 - Updated GUI to display transaction list in date order descending (previously sorting on status)

New Build Available (RC1d) 5 March 2016
The fixes included in this new build (RC1d)

  • Fix some TX calculations
  • Correct display of recent transactions on Overview page
  • increase number items displayed to 5
  • Sort the transaction list by date order decending
  • Enable staking on launch and after unlocking wallet
  • Re-implement BIP66 validation rules and switchover logic
  • update checkpoints for main and testnet

Beta Testers: PM me for details to download

Feel free to comment or add to the list.

Thx John

< EDIT 1 Mar, 2016 > some updates today with wallet development status
< EDIT 3 Mar, 2016 > some further updates of the wallet development
< EDIT 5 Mar, 2016 > Release build RC1d

A bit late to the party but i’d like to chime in! I have several wallets running 24/7 and i’d love to further help with the testing but as of now there are other things that require my attention.

Anyway i’ll list my addresses here and the OS the wallet is running under. The idea is that whoever feels like it, it would be really nice of you to “spam” any/all of my wallets with say 10-20 really fast TXs (just a few RDD will do) - ideally targeting the same block. The OS, per se, should not make much of a difference but please feel free to target whatever system/wallet you feel is more vulnerable. Once/when you do that please let me know either via PM or prefferably post in here; i’ll return you the coins in the same fashion which can also be fun! Stressing the testnet, which is in a rather poor shape (few BETA nodes, uneven distribution, big wallets going suddenly online/offline… and that’s good because that could happen in the main network) is a very important thing to do imho and i think that you’ll agree. And by doing this you also force me to “reply” to you in a rather agressive way - e.g. 100x 1 RDD TXs as fast as i can instead of 1 single 100 RDD one).

Here are my wallets addresses and the OS they’re running under:

  • Windows XP Pro SP3 32bit: n2WV5PbbAcVCjNL3Dk67ac3YZn46oCGjKN
  • Windows Vista Home Basic 32bit: n4JNHfhaYLZ1VBQi8qdiJrQGX6kdUTTyCA
  • Windows 7 Home Premium 32bit: mjSvaVoByx7qdCxreQ9iJuQ3HMT1C8cTNN
  • Windows 7 Ultimate 64bit: n3hNoW7snywYz5MNUPaT2EUYJzWzwsEjzc
  • Windows 8.1 Home 64bit: mo42boEmgBsiw8obtvPrUHTfbTHk6Fe5MX
  • Windows 10 Home 64bit: mh3W3pa7Hui792WpHJNyPNKjvz5En17tzq
  • Ubuntu 14.04 LTS 64bit: mxohWM9aRWxVvADAv8Mk4s6i8Zz5hscRB5
  • MacOS X Yosemite 10.10.1: mt689Y5nhqouc6X2KceReYvP5NZS9SKHSB

Shout out to everyone who is helping John with this… i hope that you all are aware that whithout him, even if this is a temporary “solution”, Reddcoin would probably be considered as a dying - if not dead already - project. So all the help he can get from us is literally priceless.

Also here’s a quick list of the bugs/inconsistencies i’ve found so far so in case you already have replicated them that would be cool to know:

  • Rejected stakes stay at the top of the recent transactions list
  • Inconsistent fees (e.g. a 20MM TX may be free, but a 0.0015 one will charge you a 0.0001 fee which is pretty Bitcoinish if you ask me - the later anyway)
  • Conflicted TXs: John told me that this is a new feature implemented in BTC Core 0.9, and it’s there to try to make malleability attacks harder as far as i can tell. This is a new status (you’ll see an exclamation sign and the TX will show as “Conflicted” as opposed to “Generated but not accepted”) and getting an approximate idea of the chances of it happening, and why, is very important.
  • NOT FOUND (YET): Fees up to 5k RDD. The most i’ve been charged is 0.0002 RDD.

On a side note - but i think that important to know for all testers - is that i’m staking around 150MM 24/7; John has a big fat staking wallet but i think he got it offline. I’m letting you know so you can better estimate if your expected time to stake is accurate enough.


Didi I Moved your post from the other thread.

One thing I have noticed…while syncing, the client seems to get very laggy…as in, if I try to move the GUI around, I get the “Not Responding” text at the top for a dozen seconds or so, and if I try to navigate to any of the File, Setting, Help screens, it delays…

I’m running Win 10 Pro on a AMD 8350 8 core with 16 Gigs Ram…

bmp02050 your machine clearly is not powerful enough. J/K
During the initial block download, there is a few things going on regarding indexing and such.
Whats the CPU/Memory/Disk doing at the time??

I probably wont get too much time to investigate for this release (v2.0) unless it becomes critical. If I recall the Bitcoin guys had made some operationalimprovements in the 0.11, and 0.12 wallets. My goal is to get these 2 releases (and patches if any) rolled in by year end

Gnasher Ignore the ShooterGame.exe, it’s the ARK: Survival Evolved game server I have set up… Also the reddcoin client started at 50Mb and have moved up. Memory leak somewhere? Personally, I doubt it, but I’ll keep an eye out…

bmp02050 Thanks.
After the initial block download memory should settle back. Mine is currently at 80MB

Kraatus No Worries…
Your question is still valid… I think the current version is quite memory hungry, and from what I have seen this new version will also be about the same…

An FYI for my Beta test guys.
The latest build that I am working on will generate version 4 blocks.
This will add and implement BIP 66 validation rules and switchover logic for DER sigs.
This got a bit scrambled in the earlier build and effectively was disabled.

The logic for switching over on testnet will be when 75% of blocks are generating version 4 block.
(On Mainnet it will require 95% of the network to be generating version 4 blocks

In essence this will be a ‘soft-fork’
For mainnet, we will need to communicate effectively to the entire network and wallet operators that they need to upgrade when the time comes.

This effort should be easier in a POS environment, because the onus is on the wallet operators who are also the stakers (miners)

This should not affect your current builds or testing, and I am getting close to pushing out a new release candidate for this weekend
I am testing on the network also with version 1.4.1 which has different parameters that trigger an upgrade at 85/100 blocks.
IMHO this is a very short timeframe (100mins) to trigger an upgrade

Currently I have set the new wallet to

  • 1000 mins on testnet ~ 16hrs
  • 10000 mins on mainnet ~ 7days
1 Like

I noticed that the very first coin I was sent is continuously available and has not yet created a block. It’s been a while, so correct me if I’m wrong, but is each input calculated for it’s own coinage and staking weight? I.E. I have 2 TX’s of 25MM RDD coming in. These two generate quick blocks (as you can see). The remaining 1.00 RDD is the one Gnasher sent me when I set up the wallet. To get the most out of staking, should I send these all to one address to “compile” the coins into one TX? Or does that even do anything? Also, I’d like to do a stress test on the testnet. I’m going to put together a script to send a shit ton of little TXs to addresses as fast as possible and see how the network handles it.
Just need to figure out the best way to do it… C#? PHP? A simple batch file? Any suggestions?


1 Like

Sent a bunch of 1 RDD txs to miLBJwbj35AHogPxxciYhynfdQiNuyMwfZ but they go so slow from reddcoin-cli
Need to find a way to slam them out faster…

EDIT: I also noticed that .00001 RDD tx’s generally charged .0002 to .0003 RDD fees After five independent 1RDD tx’s in quick succession to the same address, it started charging .0001 RDD fees. The first few were free…

1 Like

Keep up the stress testing bmp02050.

gnasher will be up soon - it’ll give him something to think about with his morning coffee :wink:

bmp02050 nice testing
Yes, each input generates its own coinage.
Generally the PoSV coin selection algorithm favours the larger transactions to either combine or divide. It could take some time (long) to consume the 1RDD.
Basically the process will subdivide your coins down to groups about 1.50000RDD and combine to 330000RDD
For testing your best option would be to have them all in the same address

One of my testing i wanted to do at some point was compare the staking occuring between 1 large address, or the same amount split between multiple accounts

Sorry for any slow processing, that was the KGW difficulty in play.
I have been offlining different nodes which put the block generation time out of wack. It should be starting to stabilise now

Gnasher No worries…as for the stress test, is there a way to see the testnet blocks on the website? or do I have to pull that data? I just wanted to see how many little transactions it would take to fill a block…and what size is the V2 block? Still the bitcoin limit or did it get bumped…

I should re-read the reddhead newsletter…LOL :wink:

I’ll also split up my coins into 10 lots of 5MM in different addresses within my wallet and see what happens…

1 Like

bmp02050 it is sounding like I need to consider setting up a block explorer. That will take a bit of time still.
Currently I do it the very manual way by using getrawtransaction & getblock

1 Like

So, the last couple of days staking has been interesting. I think something is quirky with it…Typically, the 2 sets of coins I have (25mm each) generate rather small amounts (1 - 2 RDD) every 8 hours or so. My computer at one point restarted after an update so I had to go back in and restart the wallet. I forgot to re-enable staking and after the coins matured, I hit a 1500 RDD stake. I’m not sure what could be done in this circumstance, but currently, the best way to generate coins is to have your wallet on and not staking for a while, then turn staking back on. Not sure if coinage is still generated while not staking and when re-enabling staking occurs, such large coinage generates big bumps. Also noticed that whenever coins are sent, it restarts the maturity of the coins. I’m sure it’s always been like that, but I never noticed because I had tons of small inputs so coins used to be generated constantly… Description

1 Like

probably looks quirky because your not use to seeing the network operated in quite the same manner. This is really the worse case of how to operate a network.

The number of testnet nodes are quite low (esp with Didi offline at the moment) and the other nodes i am testing, so they get bounced relatively frequently. What you are seeing is probably very worst case scenario on a small network (thankfully the main network is more stable)

Also, I have taken the main node offline which has a large number of coins.
This large number of coins would add a lot of network weight, and staking would slow down on your nodes.
If it is any consolation, i am also staking small count of coins each stake in this mode.

At this point I would say it is expected behaviour…

[Development Update]
I have just finished a number of items that needed to get in before the next build

  • BIP66
  • logging to monitor BIP66 changeover
  • Add checkpoints to mainnet
  • Add checkpoints to testnet

I am testing the checkpoint changes right now.

I hope to compile a RC release this Monday and get this out to everyone

[We are getting very close I feel]

Okay, just checking. I was curious why the network was working like that. If it’s par for the course, I’m not concerned. I’m going to split the coins up today into pockets of 1MM once per hour to see how it affects the staking…


I have 2 unaccepted (orphaned) blocks stuck at the top. I see what you mean now. Which part of the code looks at this and displays it in the GUI? Is there a flag or some sort of select statement that orders by a boolean accepted flag, then by date?

1 Like

bmp02050 I have the solution to the problem for the display order.
I have just finished uploading the latest build (2 days early) which will address this along with a couple of other fixes

Now for orphan blocks… the situation is, I have a node that has a LOT of staking power. And i turned staking back on earlier
It is going to cause everyone else to have orphan because it is operating on a LAN with a couple of other nodes. So the speed of the network and proximity will mean that it is going to get a lot more love than anyone remotely.

The fixes included in this new build (RC1d)

  • Fix some TX calculations
  • Correct display of recent transactions on Overview page
  • increase number items displayed to 5
  • Sort the transaction list by date order decending
  • Enable staking on launch and after unlocking wallet
  • Re-implement BIP66 validation rules and switchover logic
  • update checkpoints for main and testnet

Beta Testers: PM me for download details