- Aug 6, 2014
that did it Miner237 ... thanks
If each one of us just CPU-mine from our wallet, will that help enough? We don't need too much hashrate but a steady low hashrate will keep the testnet network running, correct?Just let me know if difficulty gets too high again it will take even longer to return to cpu miner levels.
Correct i was just putting some gpu on evans pool per his request took it down a notch we are rolling through the blocks smoothlyIf each one of us just CPU-mine from our wallet, will that help enough? We don't need too much hashrate but a steady low hashrate will keep the testnet network running, correct?
2015-01-14 07:19:41.084178 0 tails: 2015-01-14 07:19:41.084315 0 heads. Top 10: 2015-01-14 07:19:41.084491 Desire 0 shares. Cutoff: 1.0 days old diff>0.00 2015-01-14 07:19:45.074739 POLL 8287 START is_long_poll=False user_agent='cpuminer/2.3.2' user='yGYURHHDQG42sJE282TQJMSCLMirzWFff3' 2015-01-14 07:19:45.080601 > Squelched JSON error: 2015-01-14 07:19:45.080739 > Traceback (most recent call last): 2015-01-14 07:19:45.080865 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1099, in _inlineCallbacks 2015-01-14 07:19:45.081009 > result = g.send(result) 2015-01-14 07:19:45.081130 > File "/home/ubuntu/git/p2pool-drk/p2pool/util/jsonrpc.py", line 95, in _handle 2015-01-14 07:19:45.081228 > result = yield method_meth(*list(preargs) + list(params)) 2015-01-14 07:19:45.081328 > File "/home/ubuntu/git/p2pool-drk/p2pool/bitcoin/worker_interface.py", line 20, in rpc_getwork 2015-01-14 07:19:45.081415 > return self.parent._getwork(request, data, long_poll=self.long_poll) 2015-01-14 07:19:45.081501 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1237, in unwindGenerator 2015-01-14 07:19:45.081587 > return _inlineCallbacks(None, gen, Deferred()) 2015-01-14 07:19:45.081668 > --- <exception caught here> --- 2015-01-14 07:19:45.081761 > File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1099, in _inlineCallbacks 2015-01-14 07:19:45.081849 > result = g.send(result) 2015-01-14 07:19:45.081932 > File "/home/ubuntu/git/p2pool-drk/p2pool/bitcoin/worker_interface.py", line 84, in _getwork 2015-01-14 07:19:45.082034 > x, handler = self.worker_bridge.get_work(*self.worker_bridge.preprocess_request(request.getUser() if request.getUser() is not None else '')) 2015-01-14 07:19:45.082126 > File "/home/ubuntu/git/p2pool-drk/p2pool/bitcoin/worker_interface.py", line 129, in get_work 2015-01-14 07:19:45.082212 > x, handler = self._inner.get_work(*args) 2015-01-14 07:19:45.082297 > File "/home/ubuntu/git/p2pool-drk/p2pool/work.py", line 296, in get_work 2015-01-14 07:19:45.082395 > base_subsidy=self.node.net.PARENT.SUBSIDY_FUNC(self.current_work.value['bits'].bits, self.current_work.value['height']), 2015-01-14 07:19:45.082488 > File "/home/ubuntu/git/p2pool-drk/p2pool/data.py", line 183, in generate_transaction 2015-01-14 07:19:45.082575 > raise ValueError() 2015-01-14 07:19:45.082669 > exceptions.ValueError: 2015-01-14 07:19:45.174502 > Unhandled Error 2015-01-14 07:19:45.174739 > Traceback (most recent call last): 2015-01-14 07:19:45.174890 > File "/home/ubuntu/git/p2pool-drk/p2pool/main.py", line 578, in run 2015-01-14 07:19:45.175020 > reactor.run() 2015-01-14 07:19:45.175154 > File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1192, in run 2015-01-14 07:19:45.175288 > self.mainLoop() 2015-01-14 07:19:45.175416 > File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1201, in mainLoop 2015-01-14 07:19:45.175566 > self.runUntilCurrent() 2015-01-14 07:19:45.175655 > File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 824, in runUntilCurrent 2015-01-14 07:19:45.175755 > call.func(*call.args, **call.kw) 2015-01-14 07:19:45.175863 > --- <exception caught here> --- 2015-01-14 07:19:45.175950 > File "/home/ubuntu/git/p2pool-drk/p2pool/bitcoin/stratum.py", line 39, in _send_work 2015-01-14 07:19:45.176058 > x, got_response = self.wb.get_work(*self.wb.preprocess_request('' if self.username is None else self.username)) 2015-01-14 07:19:45.176251 > File "/home/ubuntu/git/p2pool-drk/p2pool/bitcoin/worker_interface.py", line 129, in get_work 2015-01-14 07:19:45.176359 > x, handler = self._inner.get_work(*args) 2015-01-14 07:19:45.176458 > File "/home/ubuntu/git/p2pool-drk/p2pool/work.py", line 296, in get_work 2015-01-14 07:19:45.176558 > base_subsidy=self.node.net.PARENT.SUBSIDY_FUNC(self.current_work.value['bits'].bits, self.current_work.value['height']), 2015-01-14 07:19:45.176669 > File "/home/ubuntu/git/p2pool-drk/p2pool/data.py", line 183, in generate_transaction 2015-01-14 07:19:45.176769 > raise ValueError() 2015-01-14 07:19:45.176880 > exceptions.ValueError: 2015-01-14 07:19:45.900973 P2Pool: 0 shares in chain (0 verified/0 total) Peers: 0 (0 incoming) FDs: 6 R/0 W 2015-01-14 07:19:45.901214 Local: 0H/s in last 0.0 seconds Local dead on arrival: ??? Expected time to share: ??? 2015-01-14 07:19:46.085049 0 tails: 2015-01-14 07:19:46.086680 0 heads. Top 10: 2015-01-14 07:19:46.086888 Desire 0 shares. Cutoff: 1.0 days old diff>0.00
"Darksend is disabled" had been submitted in JIRA-143, and was fixed by Evan in this version 11.0.5. So far I haven't seen it happen. I think you need to create a new, fresh wallet.dat with this new version and send coins to it, then see if the problem doesn't happen again.hi guys & girls.
After upgrading on 11.0.5 (linux-64bit) I could not mix anymore with my test wallet.dat.
Tried to "clean" the wallet and send all bucks to the faucets so I got zero tDRK again.
after recieving new faucet tDRK I could not use DS anymore. If I switch on DS the status shows "enabled" but at the bottom stands "Darksend is disabled". And nothing happens.
11.0.5 works here as it should with a clean new wallet - but the old seems to be unmixable.
if someone like to take over the wallet.dat to take a close look, please send me a message.
ps. a day ago I did some --reindex with the old wallet just for testing purpose (btw. it took forever and a day) could this mess up something?
thanks moli. with a clean wallet it works as expected, as I wrote.... So far I haven't seen it happen. I think you need to create a new, fresh wallet.dat with this new version and send coins to it, then see if the problem doesn't happen again.
What's "a unmixable (tm) wallet" ?thanks moli. with a clean wallet it works as expected, as I wrote.
but I'm able to reproduce this with the fresh wallet.
a reciept for a unmixable (tm) wallet:
first mix some coins...
then try to clean up (for new mixing tests) by sending all to a new recieving address in the same wallet.
Select all the coins through the coin expert feature manually because of some well known message that the transaction was rejected (annoying) and send them without DS.
After a confirmed payment to yourself you should not be able to mix them again - if it works that way like here.
there is just a fresh tDRK block in the my wallet, but darksend don't care about.
// linux 64 bit wallet // DS 1000 drk / 7 rounds
Flare, do you mean we don't see 16 rounds until the next version? I saw this a few hours ago but don't know what it means:This is a limitation in v.5 - will be fixed in v.6
CorrectFlare, do you mean we don't see 16 rounds until the next version? I saw this a few hours ago but don't know what it means:
Does it mean we'll get to have 17 rounds?
I've had similar issues since the beginning of the idea that darksend would pre-mix stuff...I funded the wallet with two transactions, one for 2983.9xxxx and another for 11.xxxxx, plus there was a <1 bit of change in there. Only the 11.xxxx chunk is getting Darksent.
Settings are 2000/16 rounds, the 11.xxxxx chunk is at 8 rounds, so I'll change settings to 2000/8 rounds and see if that persuades it to start on the big lump.
Haha nope, that just reset all the 8 round DS'd amounts to zero and it's starting again just on the 11 DRK chunk.
...a wallet where I could not use DS anymore.What's "a unmixable (tm) wallet" ?
I'm not sure what you mean in this post. Do you mean you have an amount of tDRK that will not split up? Can you post some screenshots here, that might help explain what's going on.
can you reproduce this or did that only happen once?Whenever I try to send anything close to my total balance to a new address in-wallet I get this:
This is with a freshly synced blockchain, no conflicting txes shown in tranasaction tab and no locked inputs.
When I manually select all the inputs it works fine.
Well the client is doing a couple of checks before it broadcasts the tx. Seeing this message means the final step failed and is in general no problem. If this happens more frequently and makes creating transactions a pain, we should look into that again....had this too. So I think it is reproduceable.
I've reproduced this numerous times - give the wallet more than one initial input, one larger than the other, and it gets in a tangle and grinds to a halt.I'm going to post a few screenshots to show the results of my testing on v.11.0.5, Windows 32bit, fresh wallet, funded with about 1906 tDRK as shown in the following screenshot:
View attachment 789
At first the smaller amount of the coins (about 255 tDRK) was split up and anonymized nicely with 9 rounds. But the larger amount 1650 would not split up until later. Then it got split up and denominated, but it seemed the denominated amounts of the 255 sum were mixed again; I noticed their "9 rounds" were gone, and it seemed each amount started back from round 1.
The wallet was left running all day, most of the coins were split up and anonymized 9 rounds, except an amount of 140.3 tDRK that has been locked and would not unlock for a while now. Then another amount of 832 tDRK became "n/a" with no Darksend Rounds... (Has it been de-anonymized and now has to start over?) It seems the mixing keeps going from one round to the next and then starting over like a Liquid Provider client.
EDIT: Strange... the locked amount got unlocked after I restarted the wallet!
View attachment 790
The status bar went from starting to 70%, then back to 50% or so, and now back to 29%:
View attachment 791
My previous test on a smaller amount with 8 rounds went great and fast, but with this larger amount, something isn't going smoothly.
Or we just have to wait for the next version.
Completely agree. Make mixing the default behaviour up to 8/16/whatever rounds and then have every wallet act as a liquidity provider after that, get rid of the buttons, only have a CLI switch/conf option to disable DS.I've had similar issues since the beginning of the idea that darksend would pre-mix stuff...
It seems to care about the original inputs in an unpredictable way. Send the whole wad in one big chink to a brand new wallet and it might work for a while, but then, it starts to clog up and the big chunk just sits there... You might get a few more denoms out of the smaller chunks, but then the whole thing grinds to a halt and it'll sit there for weeks never denominating anything, not even 0.1DRK.
I've mentioned it before, but only got screamed at for daring to say so. Screaming because a problem might drive the price down doesn't make it go away... It's bAAAAAaaaaaack....
Trying to fight two problems at once is hard. Is the denom failure because no other submissions? Hard to find the problem when you can't narrow it down to chasing just one problem at a time. I have a suggestion for a significant change to how denomination works that would make denomination a whole lot better in general, while also removing it from the troubleshooting so this can be split down and solved like real troubleshooting does...
Darksend is still an on-demand service. You have to find pairs, or in this case, triplets, that are temporally proximal. In this fashion, it is no different from using coinjoin as implemented by blockchain.info. Sure, the fact that coinjoin doesn't do a good job of privatizing the TX is solved with DRK, but the fact that we have a hell of a lot fewer usrs means the temporal proximity issue still remains and is a massive stumbling block. DRK has fixed half of the problem.
Darksend needs to make all coins perpetually available. Not by bloating up the blockchain by running on every damn block, but by tracking the chain depth of the process. Mix immediately for the first 4 rounds. Then submit only 50% of the blocks for the next 4. Then submit 25% of blocks once 8 deep... Once 16 deep, submit only 10% of blocks. Randomly choosing where inside of that 10% it would land. Once 32 rounds is reached, submit at 5% until 64 rounds are reached. Then submit at 1% blockrate until 128 rounds reached....
That's just an example pattern. The point being, if all coins are available all the time, or at least enough of them to keep the ball rolling, we can beat the temporal requirement by having at least a portion of all coins showing up to be mixed at any given moment. We no longer have the temporaly proximity dependency, and both of coinjoin's problems are beaten. We also don't bloat the crap out of the blockchain because as the denom gets deeper, it submits at a slower, but completely random rate. No bloat because it's not happening all the damn time on every block. It's just EVERYONE falling into a totally random pattern, so at least someone is showing up to match the pairs/triplets. The random submission pattern based on chain depth assures nothing ever syncs up while enhancing anon even further.... Every holder is gaining anon, and also contributing to liquidity enhancement at the same time. They get more anon simply by making themselves available for anon. Wouldn't need all the buttons anymore. Darksend would jsut happen in the background and merely advise the user of what's going on. No more picking round depth, no more trying to make it stop at a certain amount... It just keeps going, but pulling back as it does, remaining totally random within the scale it has reached. New TXes anon quickly to an acceptable level, older once continue to gain more anon, but not at the same speed, not even close, thus preventing bloat...
Then it'll be a lot easier to chase the denom bugs, too., because you can rule out lack of pairing as a false positive. You've now fixed the other half f the denom problem while also making it easier to fix the bug finding problem, and you added anon, and you added user-friendly bullshit that enhances adoption among the unwashed masses... Please find a way that this is not ultra-win? It's makes so many things better, and has no drawbacks... It's killing about 6 birds with one stone instead of just 2...
No off button. If some moron wants to opt-out of continuous mixing because he/she doesn't understand that it has no downside, just close client... Becomes easier for stupid people, doesn't have useless features for the stupid people to get mad about... It's either running or it's not, just like the BTC client... The dumb-masses should be able to adopt the crap out of that... The only difference is a progress bar or tab or something with more detailed darksend data. They don't have to look at it if they don't want to. They can stay just as dumb as a DOGE/LTC/BTC/PPC bagholder, but gain DS and ITX, in a coin that might possibly have a future; DRK.
The example scale I made above, I think, has way too much mixing in it. It should scale back much faster. It's just another appropriate paradox... Hashrate goes up? Increase diff. Greed exceeds supply? Price goes up. Mix depth gets deeper, submit to a lower percentage of blocks rate based upon the blocks themselves, thus preventing bloat while keeping a piece available all the time from someone, somewhere. I think the scale should be much more exponential after 8... It would chase adoption, too, and become a self-solving paradoxical ruleset. Once implemented, never have to think of it again, it handles itself. Call it the camosoul paradox if you really, really want... Everbody hates me, but the one thing they can't call me is; wrong. Mmmm... Paradox. No, don't call it that. I'm not serious...
A few hours after making that post, I realized I had 16 rounds on instead of 9. I think Darksend and the Progress bar were confused trying to get more than 9 rounds.. or something... After changing to 9 rounds it showed my wallet was almost done and now it's done, I'm going to post it next.I've reproduced this numerous times - give the wallet more than one initial input, one larger than the other, and it gets in a tangle and grinds to a halt.
And the progress bar is just going to continue to make no sense to most people. A simple Darksent/Total would be better if we're sticking to a 1d graphic.