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
(Gnasher)
< 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
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:
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.
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ā¦
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ā¦
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
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?
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ā¦
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 reddcoin.org 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
Iāll also split up my coins into 10 lots of 5MM in different addresses within my wallet and see what happensā¦
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
Gnasher
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ā¦
bmp02050
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
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?
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
