...
I suspect you have deeper concerns for DarkSend than that and it's good you keep poking the thread so that we can get the best product available. Technological criticism is good. We've had discussions in the past where someone could say "oh DarkSend is broken" (that's when it had quite different specs) and the price would tank (ok it would drop, not tank), but we are somewhat past that point now due to more people understanding that something in development can actually "shapeshift" into new forms that deal with prior problems, before it solidifies as a final product. And even then it can (and will) be improved.
....
Well, I agree with your analysis. These are problems that Evan can and will solve it will just take time. I just need to relax and have faith that in the end we will think of all of the possible issues and that all will have viable solutions. Sometimes when I discover an issue with the logic and I can't immediately think of a solution I assume there is no solution - but after some time someone thinks of a solution. This happened in an earlier post, Evan thought of an ingenious solution (denominating change, sending to multiple addresses), which solved the problem that I presented. Requiring 1000 coins for a darksend of 101 had me in a similar panic. I actually think this issue will be easier to solve than the last issue, but it will require quite a lot of coding on evan's part (ie the masternodes will need to determine when the amount of complexity in the pool is sufficient to ensure anonymity is maintained, just starting the mixing after a certain # of inputs will not be sufficient). Combined with chaeplins idea I think we have something viable, still not perfect but viable. Oh that was not my idea. It's written on White paper.
http://www.darkcoin.io/downloads/DarkcoinWhitepaper.pdfImproved Anonymity
An anonymity enhancement to the generic CoinJoin implementation is added by only allowing
inputs of the same size into the DarkSend pools. These sizes are referred to as “denominations”
and are in powers of ten (for example, 1DRK, 10DRK, 100DRK, 1000DRK). This allows the
inputs from all users to be virtually the same. Outputs per user must add up to the denomination
size.
Users that send less money than the denomination size will use a second “change” output.
These outputs are new addresses not connected to their identity. This implementation allows for
amounts of any precision to be sent without a negative impact in the quality of anonymity.
All users entering a DarkSend transaction pool have an equal chance of becoming the master
node. All participant nodes know which node is the current master by way of an election
algorithm. Master nodes also have a collateral transaction that is made out to the payment node,
which can be cashed if they misbehave in any way.
In the case where a master node loses internet connection or is a bad actor, the collateral
transaction of that node will be cashed and a slave node will be elected in it’s place. Due to the
trustless nature of DarkSend, there is no risk of lost money from the master node being a bad
actor as a slave node would be elected to replace the master node and the collateral would be
forfeited to the network.
Actually it was your idea - Evan had intended a darksend of 101 coins to be combined with 899 coins from the sending wallet and submitted to the 1000 coin pool. The 899 coins would come back as change. |
|
|
|
Why is it that when you want to Darksend 101 coins, Darksend uses the 1000 pool, rather than breaking the transaction and using the smaller pools?
Because if you send all 101 coins to the same address it will be obvious that 101 coins left your address and 101 coins appeared at another address some time later - regardless of how much mixing occurs in between. Assumption, can't be a legal proof. Each Darksend need at least 3 input from others. Yea, I guess that is true - there is still some uncertainty provided by the pool, especially if transactions go through multiple darksend "washes" before they arrive at their final destination. We might be able to infer who sent who what, but it would be impossible to prove with mathematical certainty that it was true. |
|
|
|
...
I suspect you have deeper concerns for DarkSend than that and it's good you keep poking the thread so that we can get the best product available. Technological criticism is good. We've had discussions in the past where someone could say "oh DarkSend is broken" (that's when it had quite different specs) and the price would tank (ok it would drop, not tank), but we are somewhat past that point now due to more people understanding that something in development can actually "shapeshift" into new forms that deal with prior problems, before it solidifies as a final product. And even then it can (and will) be improved.
....
Well, I agree with your analysis. These are problems that Evan can and will solve it will just take time. I just need to relax and have faith that in the end we will think of all of the possible issues and that all will have viable solutions. Sometimes when I discover an issue with the logic and I can't immediately think of a solution I assume there is no solution - but after some time someone thinks of a solution. This happened in an earlier post, Evan thought of an ingenious solution (denominating change, sending to multiple addresses), which solved the problem that I presented. Requiring 1000 coins for a darksend of 101 had me in a similar panic. I actually think this issue will be easier to solve than the last issue, but it will require quite a lot of coding on evan's part (ie the masternodes will need to determine when the amount of complexity in the pool is sufficient to ensure anonymity is maintained, just starting the mixing after a certain # of inputs will not be sufficient). Combined with chaeplins idea I think we have something viable, still not perfect but viable. |
|
|
|
Why is it that when you want to Darksend 101 coins, Darksend uses the 1000 pool, rather than breaking the transaction and using the smaller pools?
Because if you send all 101 coins to the same address it will be obvious that 101 coins left your address and 101 coins appeared at another address some time later - regardless of how much mixing occurs in between. |
|
|
|
pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1 --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1 ---> need 100 + 10 coins , not 1000
Need more smallest pool's size.
Isn't it ?
If there is 1 coin pool, just need 1 coin more.
Evan claimed that the 1000 coin pool would be used for any amount between 101-1000 Your solution is pretty good IMO. But there are problems.. If you want to send 221 from address A to address B: 2 entries into the 100 coin pool 2 entries the 10 coin pool 1 entry into the 1 coin pool So on the blockchain it would show address A -221 coins ... some time later
Address B +221 coins - so it would be easy to determine that A sent coins to B
Yes total is -221. But transaction would be -100 + -100 + -1 It doesn't matter how the transactions are broken up, it will be obvious looking at the blockchain that Address A drops exactly 221 coins and a few minutes later Address B increases exactly 221 coins. If someone need Darksend 221, wallet could do 1) Darksend largest(or second or ..) pool size coin first --> 100 + 100 2) after random number of confirmation( 1 ~ 6), Darksend second largest or smallest 3) after random number of confirmation( 1 ~ 6), Darksend remains. But I will prefer exact pool size Darksend. Yea I thought of this solution too but you still run into the same problem Address A (slowly loses) -221 coins Address B (slowly gains) +221 coins The only difference is that this would occur over a couple of hours instead of a couple of minutes. :/ I think the only real solution is to send denominated amounts to multiple receiving addresses instead of a single receiving address. |
|
|
|
pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1 --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1 ---> need 100 + 10 coins , not 1000
Need more smallest pool's size.
Isn't it ?
If there is 1 coin pool, just need 1 coin more.
Evan claimed that the 1000 coin pool would be used for any amount between 101-1000 Your solution is pretty good IMO. But there are problems.. If you want to send 221 from address A to address B: 2 entries into the 100 coin pool 2 entries the 10 coin pool 1 entry into the 1 coin pool So on the blockchain it would show address A -221 coins ... some time later
Address B +221 coins - so it would be easy to determine that A sent coins to B
Yes total is -221. But transaction would be -100 + -100 + -1 It doesn't matter how the transactions are broken up, it will be obvious looking at the blockchain that Address A drops exactly 221 coins and a few minutes later Address B increases exactly 221 coins. |
|
|
|
Wow you sold 7k DRK for that  lol !! That's some panic  I still have a lot left, but I do think my concerns are warranted. I asked the same question earlier today and got no good solution from anyone, chaeplin's solution is good but not perfect (as far as I can tell). This will be a big drawback if Zerocoin is launched with no such limitation. |
|
|
|
pool : 10, 100, 1000
darkssend 10.1 coins --> 10 + 0.1 --> need 10 + 10 coins, not 100
darkssend 101 coins --> 100 + 1 ---> need 100 + 10 coins , not 1000
Need more smallest pool's size.
Isn't it ?
If there is 1 coin pool, just need 1 coin more.
Evan claimed that the 1000 coin pool would be used for any amount between 101-1000 Your solution is pretty good IMO. But there are problems.. If you want to send 221 from address A to address B: 2 entries into the 100 coin pool 2 entries the 10 coin pool 1 entry into the 1 coin pool So on the blockchain it would show Address A -221 coins ... some time later Address B +221 coins - so it would be easy to determine that A sent coins to B I like your idea of using the 10 coin pool to handle the extra 1 coin, so only 230 coins are needed. If you want to send 221 from address A to address B (assuming the wallet with Address A has 230 coins): 2 entries into the 100 coin pool 3 entries into the 10 coin pool Address A -230 coins ... some time later Address B +221 coins This still might be enough to prove that A is the sender to B - depending on how many other entries are entered into the 100 coin pool. It's going to be a big issue in practice because when someone has exactly 221 coins, and they want to darksend 221 coins, they are going to get an error message that they need 230 coins to send 221, so instead they will submit a 220+1 to the same address, which will out them (see example above). |
|
|
|
So I have a bit of a confession to make. Maybe you guys already knew this but... Today I figured out that you cannot darksend 101 coins unless you have 1000 coins in your wallet. Just to clarify: when you send 101 coins from address A to address B, you submit 1000 coins into the 1000 coin pool, address B recieves 101 and you receive 899 back at a change address C. Same goes if you want to darkssend 10.1 coins, you need 100 coins in your wallet. If you want to darksend 1.1 coins you need to have 10 coins in your wallet. So back to my confession - when I discovered this issue I panicked a bit and sold 7,000 coins and tanked the market  . Now for the good news, if anyone can come up with an ingenious solution to this problem I'll buy back all of these coins in an instant. Put your thinking caps on  |
|
|
|
Any benefit from using the latest SPH-sgminer vs a slightly older one that supports less of the X11 coins? It looks like the latest version may only add support for the newest X11 coins. Is that correct or is the latest version faster than a version 2 or 3 back?
I don't think it makes a difference but I could be wrong. |
|
|
|
I think it's great you are trying to improve the code but SPH-SGminer already gives 2.3Mhash per 280x.
Afterburner overclock settings: memclock: 1800 coreclock: 1180 power limit%: +20 My gigabyte board would freeze on anything higher than 1500/1100. I'm unable to test the code on those conditions! (i'm really impressed on this asus one)! I only get 1.9mhs out of 280x's. Even when overclocked the sgminer updates with lag and the hashes vary wildly from 2.1 to 1.6 and they push past 70 degrees. What are the optimal settings in an sgminer bat file are you using and which sgminer? Thanks. This link will help  https://docs.zoho.com/sheet/published.do?rid=12cbm2fe8ce55abb2476daa0f8c576b442d40&mode=htmlIf you have Asus card you can see my post on the last page for good settings. The Asus 280x is superior to the other brands from my testing. |
|
|
|
•https://mega.co.nz/#!uAp12DYa!vhfp1wDb43mB1KCo_5ZfwXehYhBXeKcVYWbmkTB2ldg (DRK + Q2C + QRK + MYR + FC + INK + ANI + GRS + SIC + TWE + MARU)
is this the one?
Yes, make sure to download it from this post https://bitcointalk.org/index.php?topic=475795.0 |
|
|
|
This wouldn't be accurate either. The correct phrase should be: I used some of the code from sph_miner with some of the code from cpuminer and some improvements of my own... As for getting the speeds people are getting with their 280x, thay are overclocking really high. My hardware does not support that, so i cannot test with the same settings as them. The best i can do is 2.5Gh/s with 1100/1500 OC.
So basically, you got code from free software, tweaked it around, and want to sell it ? .!. I'm happy with my 5x 280x Vapor-X doing 2.2mh/ each, totalling 650w (at the wall). You still havent answered, how much does your rig consume? This is mining p2pool with I=18... on MPOS I use I=19 and get 2.2 - 2.3 MH/s  -k darkcoin -o http://q30.qhor.net:7903 -u Xdeq6pcN3cPsZtta6jsA286N4jbuwVn51D+0.00254200 -p x --auto-fan --gpu-fan 40-85 --temp-cutoff 92 --temp-overheat 88 --temp-target 64 -I 18 -g 1 -w 128 --lookup-gap 2 --thread-concurrency 8192 --gpu-powertune 20 --gpu-engine 1100 --gpu-memclock 1500 Try lowering the intensity - the reject rate is hurting your profits. |
|
|
|
Just agreed to do it through PM. He is putting together a windows build for tomorrow. I have a meter which I will connect up.
Yea same - waiting for the windows build. Glad to hear you have a meter. |
|
|
|
+1 I'm doing a test on 2 x R9 290s.....Simcom is the top tester for this given the spread of GPUs that would represent a wider spectrum of the community. Sadly I don't have a wattmeter - so I won't be able to test power consumption. I could give a pretty accurate measure of hashrate though. Any results with the 290s? |
|
|
|
which miner can the most out of 290 and 270x gpu?
phm-sgminer - after optimization it will give 2.5mhash for 290 and 1.4mhash for 270x. |
|
|
|
You actually wrote: "I made some speed improvements in the GPU miner listed on the first page."
The GPU miner listed on the first page is sph-sgminer, not the cpuminers.
The correct phraseology would be something like "I tweaked the cpu miners on the first page to work with openCL and now I'm getting better speeds than even sph-sgminer" (which from I gather from those posting their 280 results is not really slower).
This wouldn't be accurate either. The correct phrase should be: I used some of the code from sph_miner with some of the code from cpuminer and some improvements of my own... As for getting the speeds people are getting with their 280x, thay are overclocking really high. My hardware does not support that, so i cannot test with the same settings as them. The best i can do is 2.5Gh/s with 1100/1500 OC. Yeah well, this is cryptoland... you know how things go. Sorry I can't check your code to see if it works (I lack the skill) + I've uninstalled my GPUs due to rising temps.
That's ok, i'll keep looking for someone who can test it and has the trust of the community. I am willing to test the miner on my asus cards - I suspect I will get higher than 2.3 if you are able to get 2.5 with an 1100/1500 OC. In addition to asus 280x I also have several: gigabyte 280x msi 270x gigabyte 290 msi 290 here is my 6 year reddit account http://www.reddit.com/u/SimcomMod of /r/Drkcoin and head mod of /r/Nyancoins I am also extremely active on this thread, contributing to technical discussions - https://bitcointalk.org/index.php?topic=421615.msg6459044#msg6459044 etc. |
|
|
|
in the following charts: https://bitcoinwisdom.com/markets/mintpal/drkbtchttps://bitcoinwisdom.com/markets/cryptsy/drkbtcThe "depth" section (the green/red lines between the chart and the order list) are poorly scaled. This is a very active market and there are typically orders of thousands of coins, but it only takes an order of ~350 coins to create a horizontal depth line, which makes it nearly impossible to gauge depth via this chart. If you could re-scale it so that an order of ~3000 coins was enough to create a full horizontal line I think that would help tremendously. |
|
|
|
I think it's great you are trying to improve the code but SPH-SGminer already gives 2.3Mhash per 280x.
probably so with adequate tweeking, i guess. Could you please tell me the settings with which you get that speed and i'll try to use them on my code to see what the improvement will be. Thanks. Sure. I have Asus 280x cards - 2.341 avg Mhash (running stable since last reboot(60 hours)) 2.1% reject rate Afterburner overclock settings: memclock: 1800 coreclock: 1180 power limit%: +20 SPH-SGminer device1.conf settings: "kernel" : "darkcoin", "lookup-gap" : "2", "intensity" : "13", "worksize" : "256", "thread-concurrency" : "8192", "failover-only" : true, "scan-time" : "1", "device" : "1", "gpu-threads" : "2" .bat contents: setx GPU_MAX_ALLOC_PERCENT 100 setx GPU_USE_SYNC_OBJECTS 1 sgminer.exe --config device1.conf |
|
|
|
|
Show Posts
