It's called "dead change issue" https://www.dash.org/forum/threads/dead-change-an-anonymity-issue.3019/
12.1 Testnet Testing Phase Two Ignition
- Thread starter eduffield
- Start date
- Status
Why dont we keep things simple and mix using denominations of 1 only, and require all PS to be whole numbers?
Yes the blockchain maybe otherwise bigger but at least all PS amounts would work properly.
Besides, Imo mixing and PS aren't going to be key features anyway. The are other more privacy centric coins out there competing with dash.
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:
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 ?
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 ?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"....
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.
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
yeah, i forgot the PS improvements eventhough i saw them in pulls .. a bit unfair of me. sorry about that.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"....
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:
Dedicated tMN and tLP updated to v0.12.1.0-7e9ad0e and synced nmarley sentinel. Looking pretty healthy so far. Will have more time to test tomorrow.
Are we still arguing to force antiquated IPv4?
I run my remaining MNs on dual-stacks, with IPv6 bindings. They work great as a bridge to pure IPv6 nodes in that configuration. On the same pizza box on a vnet, the latency is sub-millisecond, so it doesn't hurt anything.
If you're going to force something, it should be forced dual-stack.
This is zero burden to people running small numbers of nodes on rented VPSes, since they already come with IPv4 and IPv6 addresses.
It's a benefit to people running larger arrays with limited IPv4.
There is no down side, and at least one up side.
I've seen some people theorize fragmentation, but in observable practice, this does not occur. Especially when the operator of the pure IPv6 nodes is also operating dual-stack bridge nodes on the same pizza box... It's a false concern.
I run my remaining MNs on dual-stacks, with IPv6 bindings. They work great as a bridge to pure IPv6 nodes in that configuration. On the same pizza box on a vnet, the latency is sub-millisecond, so it doesn't hurt anything.
If you're going to force something, it should be forced dual-stack.
This is zero burden to people running small numbers of nodes on rented VPSes, since they already come with IPv4 and IPv6 addresses.
It's a benefit to people running larger arrays with limited IPv4.
There is no down side, and at least one up side.
I've seen some people theorize fragmentation, but in observable practice, this does not occur. Especially when the operator of the pure IPv6 nodes is also operating dual-stack bridge nodes on the same pizza box... It's a false concern.
I updated my tMNs and local last night to the Jan 4 version, Dash Core version v0.12.1.0-7e9ad0e (64-bit) and having just checked on them, they fell off the network.
error: couldn't parse reply from server
section at bottom of debug.log:
My nodes remained locked and I had to restart my servers to get dashd running again.
error: couldn't parse reply from server
section at bottom of debug.log:
Code:
2016-12-26 13:40:48 CMasternodeSync::ProcessTick -- nTick 310165 nMnCount 0 nMnCountEstimated 3584
2016-12-26 13:40:48 CMasternodeSync::ProcessTick -- nTick 310165 nMnCount 0 nMnCountEstimated 3584
2016-12-26 13:40:48 CMasternodeSync::ProcessTick -- nTick 310165 nMnCount 0 nMnCountEstimated 3584
2016-12-26 13:40:54 CMasternodeSync::ProcessTick -- nTick 310171 nRequestedMasternodeAssets 2 nRequestedMasternodeAttempt 0 nSyncProgress 0.250000
2016-12-26 13:40:54 CMasternodeSync::ProcessTick -- nTick 310171 nRequestedMasternodeAssets 2 -- timeout
2016-12-26 13:40:54 CMasternodeSync::ProcessTick -- ERROR: failed to sync MASTERNODE_SYNC_LIST
2016-12-26 13:40:55 CMasternodeMan::CheckAndRemove
2016-12-26 13:40:55 CMasternodeMan::CheckAndRemove -- Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, nDsqCount: 0
2016-12-26 13:40:55 CMasternodePayments::CheckAndRemove -- Votes: 0, Blocks: 0
2016-12-26 13:41:18 CWallet::GetMasternodeVinAndKeys -- Could not locate any valid masternode vin
2016-12-26 13:41:38 tor: Thread interrupt
2016-12-26 13:41:38 torcontrol thread exit
2016-12-26 13:41:38 net thread interrupt
2016-12-26 13:41:38 msghand thread interrupt
2016-12-26 13:41:38 opencon thread interrupt
2016-12-26 13:41:38 addcon thread interrupt
2016-12-26 13:41:38 scheduler thread interrupt
2016-12-26 13:41:38 PrepareShutdown: In progress...
2016-12-26 13:41:38 StopNode()
2016-12-26 13:41:38 Verifying mncache.dat format...
2016-12-26 13:41:38 ERROR: Read: Failed to open file /home/ingie/.dashcore/mncache.dat
2016-12-26 13:41:38 Missing file mncache.dat, will try to recreate
2016-12-26 13:41:38 Writting info to mncache.dat...
2016-12-26 13:41:38 Written info to mncache.dat 0ms
2016-12-26 13:41:38 Masternodes: 0, peers who asked us for Masternode list: 0, peers we asked for Masternode list: 0, entries in Masternode list we asked for: 0, nDsqCount: 0
2016-12-26 13:41:38 mncache.dat dump finished 0ms
2016-12-26 13:41:38 Verifying mnpayments.dat format...
2016-12-26 13:41:38 ERROR: Read: Failed to open file /home/ingie/.dashcore/mnpayments.dat
2016-12-26 13:41:38 Missing file mnpayments.dat, will try to recreate
2016-12-26 13:41:38 Writting info to mnpayments.dat...
2016-12-26 13:41:38 Written info to mnpayments.dat 0ms
2016-12-26 13:41:38 Votes: 0, Blocks: 0
2016-12-26 13:41:38 mnpayments.dat dump finished 0ms
2016-12-26 13:41:38 Verifying governance.dat format...
2016-12-26 13:41:38 ERROR: Read: Failed to open file /home/ingie/.dashcore/governance.dat
2016-12-26 13:41:38 Missing file governance.dat, will try to recreate
2016-12-26 13:41:38 Writting info to governance.dat...
2016-12-26 13:41:38 Written info to governance.dat 0ms
2016-12-26 13:41:38 Governance Objects: 0 (Proposals: 0, Triggers: 0, Watchdogs: 0, Other: 0; Seen: 0), Votes: 0
2016-12-26 13:41:38 governance.dat dump finished 0ms
2016-12-26 13:41:38 Verifying netfulfilled.dat format...
2016-12-26 13:41:38 ERROR: Read: Failed to open file /home/ingie/.dashcore/netfulfilled.dat
2016-12-26 13:41:38 Missing file netfulfilled.dat, will try to recreate
2016-12-26 13:41:38 Writting info to netfulfilled.dat...
2016-12-26 13:41:38 Written info to netfulfilled.dat 0ms
2016-12-26 13:41:38 Nodes with fulfilled requests: 65
2016-12-26 13:41:38 netfulfilled.dat dump finished 0ms
2016-12-26 13:41:44 Shutdown: done
Watching progress on Github, with Feb.5 still 29 days away, I'd say that date maybe not carved in stone, but probably pretty firm. (lol, or 'firmish')
4 weeks to 12.1 show time, but...
- PS completion % is wrong.
- Mixing does not work.
- Sync loops 2 times in the row.
- Masternodes tab date is wrong format again (fixed once: https://github.com/dashpay/dash/issues/796)
- Translations ?
I'm worried...
- PS completion % is wrong.
- Mixing does not work.
- Sync loops 2 times in the row.
- Masternodes tab date is wrong format again (fixed once: https://github.com/dashpay/dash/issues/796)
- Translations ?
I'm worried...
Something went wrong in the last version, and they've been combing through everything to make sure everything is right. When they think they have all issues cleaned up, we'll get the next version. The last messed up version was released on Jan 4th. I'm just waiting for next version because it's pretty useless to work with it right now
As disappointed as I am that this didn't release when originally stated, I realize the massive amount of features that were added which were not on the table at the time. I do hope that the deadline now stated is in fact penciled in. I'm as impatient as anyone, but getting it right should always be prioritized above arbitrary dates, frustration with delays, or capricious demands. We're talking about exploding money. It's almost as bad as an exploding gun right next to your face... You don't want to get it wrong of your users are going to be really mad, or possibly dead. They can't give you any more of their money if they're dead...
masternode start using keepkey + dashd
https://github.com/chaeplin/dash-testnet/tree/master/keepkey_mnb
https://github.com/chaeplin/dash-testnet/tree/master/keepkey_mnb
Last edited:
I see there is a new version, but I can't update at the moment
Anyway, I wanted to point out a problem I have, which I think is ultimately a serious problem. I mine on a pool, but when I lose contact with that pool, my miner mines with my P2pool setup at home. This gives me a lot of dust that I can't deal with. I can't consolidate it. Even if my wallet allowed me to consolidate, it would cost more than the mining was worth. I got a script to consolidate via dashd, but I still have over 200 inputs that are not consolidated (from over 2000) and more came in during the night I'm just going to have to stop P2pool mining, and if that's true for a lot of people, then that centralizes our network even more.
Can't we make a function, where dust can be collected into one input? Only miners need this function, and if only mining rewards could be consolidated this way, maybe it wouldn't overwhelm the system?
Or maybe P2pool could be changed with the upcoming smart contracting system to act like a centralized pool where funds are collected and distributed when the user wants their portion released?
Anyway, I wanted to point out a problem I have, which I think is ultimately a serious problem. I mine on a pool, but when I lose contact with that pool, my miner mines with my P2pool setup at home. This gives me a lot of dust that I can't deal with. I can't consolidate it. Even if my wallet allowed me to consolidate, it would cost more than the mining was worth. I got a script to consolidate via dashd, but I still have over 200 inputs that are not consolidated (from over 2000) and more came in during the night
I'm just going to have to stop P2pool mining, and if that's true for a lot of people, then that centralizes our network even more.Can't we make a function, where dust can be collected into one input? Only miners need this function, and if only mining rewards could be consolidated this way, maybe it wouldn't overwhelm the system?
Or maybe P2pool could be changed with the upcoming smart contracting system to act like a centralized pool where funds are collected and distributed when the user wants their portion released?
Or, just learn a lesson from a failed hoard coin of the early days, from which DASH already learned another trick... PeerCoin doesn't have mining. The network can be secured without it. XVC was forked from PPC, and has real IX already... IT's an abandoned and dying project, and it's still better for vendors than DASH...
Was spiting the dirty, evil republican really worth losing 2 years in your own marketplace invention?
Was spiting the dirty, evil republican really worth losing 2 years in your own marketplace invention?
Ugh, I'm sorry, I can't seem to stop the old dash. pkill doesn't work. I can't start the new version. I have to leave again, no time for rebooting ATM, sorry!
- Apr 8, 2014
- 1,950
- 1,311
- 1,283
Strange that killing the process does not kill it
Change your autostart script path to dashd, reboot the server and update
should wokr - after all put the autostart script path as it was before 
don't have an auto start script in testnetStrange that killing the process does not kill it
Change your autostart script path to dashd, reboot the server and update
BUT rebooting did the trick. Now I have to upgrade again to newest, LOL
Wait, did I already update? are we on Dash Core version v0.12.1.0-5cb6486 (64-bit) ?
How long has it been since you upgraded? January 4 version was broken, and I think the first new one came out on the 9th and another this morning (my time) on the 11th (says January 11 on the site) So if you got yours before or around the 9th it's probably a bad version
Just wanted to ask, whether the same will be available for Ledger Nano S in the nearest future? Ready to donate a reasonable amount.
masternode start using keepkey + dashd
https://github.com/chaeplin/dash-testnet/tree/master/keepkey_mnb
available already (same as KeepKey and TREZOR)
https://www.dash.org/news/starting-today-ledger-nano-s-and-ledger-blue-officially-support-dash/
Chaplin is testing the 12.1 version
Thank you for the link. As far as I understand, this is just Dash support by these wallets. I meant if it would be possible not only to keep coins on Ledger Nano S , but also to launch a masternode when coins are stored within Ledger wallet. I did not find any way, how to bring together Dash Core and Ledger (generate 0 address to send 1000 dashes to, generate masternode private key, etc.). If there is any manual, please help to find it.
- Status