• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

12.1 Testnet Testing Phase Two Ignition

Status
Not open for further replies.
Any specific ideas how?

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.
 
Let's imagine you have monopoly money...

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:

ingie@Dash1:~/.dashcore$ dash-cli masternode debug
Not capable masternode: Specified IP doesn't match our external address.
ingie@Dash1:~/.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?
 
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 :p
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...
 
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...
Well, that went mostly over my head, LOL. But I get the point, aim large, LOL :D Thanks Camo :D
 
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?
 
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.
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.
 
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!?
 
Last edited:
Wouldn't it be simpler to simply require a percentage of small denominations to be maintained? Currently it seems that if you use up your small denominations, it doesn't refill if everything has been mixed (a 100 denom doesn't break up into smaller denoms to refill those used up) Maybe that's what's needed?
 
Wouldn't it be simpler to simply require a percentage of small denominations to be maintained? Currently it seems that if you use up your small denominations, it doesn't refill if everything has been mixed (a 100 denom doesn't break up into smaller denoms to refill those used up) Maybe that's what's needed?

I think dev team really do need to look into this a bit deeper, we can not have users complain about not being able to sent certain amounts through Privatesend that according their PS Balance
should be no problem and then tell them to look into their input amounts, while they are already at 100% mixed and can not do anything about it.

I'm starting to get the feeling now that there is the thought by dev team that mixing / PS works more or less and that it does not need any special attention.
I always thought that after this whole syncing issues that took up a lot of dev team time, dev team would actually look into these mixing / PS problems.
 
Last edited:
I think dev team really do need to look into this a bit deeper, we can not have users complain about not being able to sent certain amounts through Privatesend that according their PS Balance
should be no problem and then tell them to look into their input amounts, while they are already at 100% mixed and can not do anything about it.

I'm starting to get the feeling now that there is the thought by dev team that mixing / PS works more or less and that it does not need any special attention.
I always thought that after this whole syncing issues that took up a lot of dev team time, dev team would actually look into these mixing / PS problems.

Maybe not so much of an issue with 12.1 private account, saving account ect. From what I can gather funds in private account will auto mix and maybe sort this issue at the same time ?
 
...
I'm starting to get the feeling now that there is the thought by dev team that mixing / PS works more or less and that it does not need any special attention.
...
If that would be the case you would see no commits here in 2016 https://github.com/dashpay/dash/commits/v0.12.1.x/src/darksend.cpp ;)

Wouldn't it be simpler to simply require a percentage of small denominations to be maintained? Currently it seems that if you use up your small denominations, it doesn't refill if everything has been mixed (a 100 denom doesn't break up into smaller denoms to refill those used up) Maybe that's what's needed?
Good idea. Probably need to make sure that that's what user really wants however, maybe should make it optional first.
Maybe we should also get rid of 100 DASH denoms completely? $1000 doesn't sound like "cash"....
 
If that would be the case you would see no commits here in 2016 https://github.com/dashpay/dash/commits/v0.12.1.x/src/darksend.cpp ;)


Good idea. Probably need to make sure that that's what user really wants however, maybe should make it optional first.
Maybe we should also get rid of 100 DASH denoms completely? $1000 doesn't sound like "cash"....
Smaller denoms = greater flexibility. Why don't we go all 1's? What's the trade-off? Bigger blockchain? But isn't their a fee for mixing to prevent spamming ?
 
Smaller denoms = greater flexibility. Why don't we go all 1's? What's the trade-off? Bigger blockchain? But isn't their a fee for mixing to prevent spamming ?
You mean remove all other denoms (0.1, 10, 100) and keep 1 (DASH) only? Imo having few denoms is a bit more flexible than that. Otherwise how would you send few bucks via PS for example (currently 0.1 x N)? Mixing few hundreds $$ (currently 10 x N) would take waaay too much time/mixing sessions with 1's only. And when you would finally try to pay someone say 200 DASH with 1's it just not going to fit into 1 transaction because of the huge size.
 
Maybe not so much of an issue with 12.1 private account, saving account ect. From what I can gather funds in private account will auto mix and maybe sort this issue at the same time ?

Private / Saving accounts with possible auto mix are part of Dash Evolution which is still some time in the future, it is not part of update 12.1
 
If that would be the case you would see no commits here in 2016 https://github.com/dashpay/dash/commits/v0.12.1.x/src/darksend.cpp ;)


Good idea. Probably need to make sure that that's what user really wants however, maybe should make it optional first.
Maybe we should also get rid of 100 DASH denoms completely? $1000 doesn't sound like "cash"....

yeah, i forgot the PS improvements eventhough i saw them in pulls .. a bit unfair of me. sorry about that.
Getting rid of the 100 Dash denoms could be interesting to test, see how PS copes with that
and optionally requiring a percentage of small denominations to be maintained sounds like a plan.
 
Last edited:
Status
Not open for further replies.
Back
Top