i gave v0.12.1.0-70b3740 another try today and all my wallets are synced correctly now. Two remarks with regards to this latest build and the mixing : * a lot of Privatesend request incomplete: Session timed out messages, which seems to interfer with a fast and fluid mixing Note : dont get me wrong, there is still a lot of mixing taking place but if we were to fix what exactly causes these messages, i think the mixing sessions would go even faster. * Amount to mix still gets exceeded sometimes when Amount is set to 1000 and there is a higher amount available (1300 / 1400)
What options do I need to set that I can build the latest version on a RaspberryPi? I always get the following error: Code: checking for boostlib >= 1.20.0... yes checking whether the Boost::System library is available... yes checking for exit in -lboost_system... yes checking whether the Boost::Filesystem library is available... yes checking for exit in -lboost_filesystem... yes checking whether the Boost::Program_Options library is available... no checking whether the Boost::Thread library is available... no checking whether the Boost::Chrono library is available... no checking whether the Boost::Unit_Test_Framework library is available... no checking for dynamic linked boost test... no configure: error: No working boost sleep implementation found.
Beside the amount to mix problem there is also a problem with the rounds, when i put the wallet to 8 rounds of mixing and it reaches 100% not all input amounts have actually reached 8 rounds.
I don't understand how qwizzie mixed that much, yet my liquidity provider apparently only managed to help with a single transaction (running with -liquidityprovider=1). All my test nodes appear to be staying synced properly, but maybe some tMNs aren't?
Running 6 wallets at the same time really helps a lot, as they pretty much mix against each other. That is how i normally test the mixing on testnet, so i will be less dependent on other participants on testnet. I also have this suspicious feeling running -liquidityprovider=1 will not help with mixing certain higher amounts, like the 100's.
I've been watching the liquidity provider a bit closer now. The latest mixing transaction was 10 confirmations ago, yet I still see the message "Last successful PrivateSend action was too recent."
Hmm... Why would you expect ALL inputs to reach 8 rounds? Both wallets have 11 inputs 100 DASH each at 8 rounds, which is exactly 1100 DASH you see in private balance, so I'm not sure what's the problem exactly...
You are right, i should not exspect all inputs to reach 8 rounds, only those input amounts that together would form the anonymized 1000 amount. This means the wallet should mix a max of 10x 100 Dash, not 11x 100 Dash or 12x 100 Dash. If i remember correctly from the past mixing, this actually means a breakdown towards 9x 100 Dash and the rest filled up by smaller amounts like 10's and 1's .. which will then all end up getting mixed till they reach round 8. Unless something changed in the mixing process and what is happening now is actually a desired outcome or feature?
@UdjinM6 If user set rounds to 8 and amount to 500 and mixing is 100% complete, then there is also small amount change(s) which does not have 8 rounds, but lower rounds, like 2,3,4, does wallet use these if user is going to send over 500 with PS? It should not, because privacy is lower than 8 rounds, right?
v0.12.1.0-cda28d3 Tested mixing, veeery slow, 30 mins and 11 tDASH done Nov 22, 2016 it was very fast, 800 tDash and 2 rounds, done with in 20 mins!
Dedicated tMN and tLP updated to v0.12.1.0-cda28d3. It is interesting to note that a few hours ago (with the previous build) the tLP was able to do 3 PS denominations within the same minute, which didn't seem likely to occur given recent testing and the fact that LPs don't use multi-session.
It's the other way around - it fills from the smallest to the largest. But the way it selects inputs later isn't linked to the way funds was split, it just tries to select _some_ denomination (that's why your smaller inputs also have non-zero rounds). Not sure why it overshoots, but this shouldn't hurt
I've been running with 2048 and 4 threads just to be fancy. 50GB drives in preparation for dashdrive. Definitely overkill. I don't think a carved in stone recommendation can be made at the moment.
Yep, that's true. Back when 12.0 was released I compared both main- and test-net and the differences in the needed resources were significant.
is anyone expecting we will need more than 512 mb ram for 12.1? I'm currently on 1gb so not sure? does having 2 cores lessen the need for ram? Also, do I need to install 12.1 on my trezor to make it work with Masternodes? If so, I need to find a how to ASAP because I want to be prepared
Testing ... build 755, git commit eddfa5a I have 890 tDash mixed. Tried to send 705 tDash. Both PrivateSend and InstantSend. I get this message: "Unable to locate enough PrivateSend denominated funds for this transaction. PrivateSend uses exact denominated amounts to send funds, you might simply need to anonymize some more coins. InstantSend requires inputs with at least 6 confirmations, you might need to wait a few minutes and try again." Please translate that error message for a mere human. By the way, 700 tDash will go through just fine. As will 710. I would assume that my bucket of PrivateSend included stuff denominated 10 tDash and greater and no .1's or 1's and hence the error. But that message doesn't tell me that. In fact, I am not really sure what it is trying to say. Heh.
I came across that as well a couple of builds back : https://www.dash.org/forum/threads/12-1-testnet-testing-phase-two-ignition.10818/page-6#post-106812 It is a bit of a bummer that certain amounts that are well within the boundries of my Privatesend Balance can not be used for Privatesend because the input amounts limits that somehow.
The algorithm that selects PS inputs needs to be tweaked. IDK if that's a showstopper. Are we on track for Jan 1 release?
Let's imagine you have monopoly money in denominations of ones, tens, and hundreds, and you need to pay someone 705. I think that is analogous. Your goal is to send bills such that you receive the least change (zero change is best -- i.e, exact amount). So you start looking for ones to fulfill the 5 requirement. You don't have enough ones, so you abandon that. Then you look at the tens place and see that by selecting one ten you can take care of the five balance in ones you need. Then you go to the hundreds place and see you need seven of those. So you end up sending seven hundreds and one ten.
The algo actually would work best first examining the hundreds, then the tens, and then the ones, and any case where there is not enough bills, you simply bump up the next highest denomination, and then stop.
Weird. One of my MNs won't start. Here is the masternode debug: [email protected]:~/.dashcore$ dash-cli masternode debug Not capable masternode: Specified IP doesn't match our external address. [email protected]:~/.dashcore$ I checked my VPN my dash.conf and my masternode conf and all show the correct ip plus :19999 I am running 2 masternodes and they are identical except for IP address. From my debug log (on server side masternode) I have: 2016-12-30 19:45:22 CMasternodeBroadcast::Update -- Got UPDATED Masternode entry: addr=216.45.55.246:19999 What can I find that would be of help?
With the plans for network stored data (not just blockchain, but a lot of user data and DAPI), resources are going to scale drastically more with usage than version number. There is going to be a hell of a lot more going on than just propagating blocks a la bitclones. I would STRONGLY recommend not aiming low lest you risk crapping on your proof of service when it becomes a lot more intensive. I'm running what appears to be overkill on testnet. But, I fear it might actually be inadequate if DASH were scaling to the level of Bitcoin. And that's the goal, isn't it? I think 64bit memory space may be needed if DASH ever capitalizes on it's technical capabilities. It is going to become very important to keep an eye on bandwidth, and I hope the devs realize this. Compression streams may need to be a thing...
Anyone have a guesstimate as to when we will be upgrading? Early January, Mid or Late January? Maybe February? LOL Just an idea as to where we stand at the moment?
That's not a problem currently either, it already works. I doubt that you would like to pay 5 DASH fee sending 705 DASH transaction though.
I was thinking you could send the 5 Dash balance back to yourself as change, but maybe that would defeat the purpose of PS!?
