Why are these people are not responding to us? Why do they put up a website and ignored us when we need help with their service? I sent 5 btc through bitlaundry to do a test drive and my coins never arrive at the destination address. I sent Mike Gogulski, the owner of bitlaundry, 4 messages asking if he can help me retrieving my 5btc and this asshole is ignoring me. If you guys keep this up, people will lose interest and will definately sell off the bitcoin value because they can't trust the community of bitcoin. I lost 20 btc from mybitcoin and now another five from bitlaundry. This is bullshit and I might as well cash all of coins out and forget that bitcoin ever exist. Get back to me Mike! I can tell you log in and that is how I know you're ignoring me. Thanks
Hi there, You might consider a bit more patience before going and making yourself look foolish in public in such fashion. You sent actually sent three messages requesting support, not four, since 2:30am yesterday my time. I was in Vienna from Tuesday evening, arrived home late last night, slept most of today and then finished reading a book I'd borrowed there until bothering to log in. You actually send 5 BTC to bitcoinlaundry.com, not bitlaundry.com. Same owner, different sites. The reason you experienced a problem is that you told the site you were sending BTC 5.5, but then only sent BTC 5. The system was waiting for you to complete funding it up to the requested amount. I've just released your funds, minus commission, in a manual transaction. Meanwhile, when I came home last night and turned my computer on, several saved browser tabs to the Bitcoin forums were reopened, even though I didn't look at them before going to sleep. That login even would presumably form the basis of the accusation that I was ignoring you. Peace, Mike |
|
|
|
Mike,
I tried testing your service and came up with error messages when it tried to generate an address for me to send a payment to. Any idea why? The amount attempted was 1 BTC.
Dunno, Steve. Which service? What was the error message? Right now, deposit address generation is a one-shot, all-or-nothing deal. If the wallet server isn't reachable from the app.bitlaundry.com app for a few seconds, you'll get: <p>Sorry, but something has gone wrong in creating a new Bitcoin address for you.</p>
<p>Please try again in a little while, and if the problem persists contact the administrator.</p>
Yes, that was the error message. It was received when I tried using both services. Ah. There was a network outage between about twenty and twelve hours ago which put the wallet server offline. Eventually the monitoring alarms woke me  |
|
|
|
Mike,
I tried testing your service and came up with error messages when it tried to generate an address for me to send a payment to. Any idea why? The amount attempted was 1 BTC.
Dunno, Steve. Which service? What was the error message? Right now, deposit address generation is a one-shot, all-or-nothing deal. If the wallet server isn't reachable from the app.bitlaundry.com app for a few seconds, you'll get: <p>Sorry, but something has gone wrong in creating a new Bitcoin address for you.</p>
<p>Please try again in a little while, and if the problem persists contact the administrator.</p>
|
|
|
|
 this should explain a lot. It's likely a bug and will be rolled back. Dude, you got jacked for like $50k in fees! *gulp*  |
|
|
|
What kind of volume are you seeing through your bitlaundry app?
It varies quite a bit. I'm not going to put out exact status, but I can say that on some days I'll see nothing come in while on others I might see 500BTC. Mike, can you give us an example of where the "single hop" would be more advantageous than the other?
Bitlaundry.com (the single-hope service) will basically wait for 10 confirmations on the input send, and then transmit the remainder immediately after taking the fee. That's probably as close to "instant" as I'll make it. The equivalent deposit to app.bitlaundry.com would involve a delay of 10 confirmations plus up to a day. Single-hop services could conceivably be chained together to move coins around rapidly. Mike, I just listened to your interview on AgoristRadio, which was fun. A question for you: something that would be useful--nay, essential--in a laundering service is the assurance that one will receive new coins and not receive back any of the same coins of the original lot. Not any not one! Agreed? Is there any way a user of your system could be assured of this? No, not at present, and that's something I couldn't do without hacking the wallet management code itself, or by taking an "outside-the-system" approach like the Bitcoin mixer running on TOR. If the mods proposed at http://coderrr.wordpress.com/2011/06/30/patching-the-bitcoin-client-to-make-it-more-anonymous/ get included into Bitcoin, though, it should become possible, though still subject to the limitation that someone sending in more coins than the service's pool holds will inevitably get some of their own in return. |
|
|
|
Same here, if I press Q the program displays something and then just hangs.
It says "Satan <3 U", but it's too fast for the human eye to perceive... |
|
|
|
Some weirdness:
- If multiple, identical GPUs are present in the system, the same OpenCL kernel will be compiled for each of them.
No it does not. It compiles one kernel once for all similar hardware and then loads the binary from that point on. Since you have to run cgminer from the source directory currently, that's where it also stores the binary file. So, I think I tracked down what led me to ask these questions. My miner systems run without local disk and obtain everything over via PXE/TFTP/NFS. The directory where mining binaries (including cgminer) is installed isn't writable to the miner node users. Therefore, the binary output file can't be opened and, if I'm reading the source and the debug output correctly, the kernel is getting compiled memory-to-memory multiple times. Building to a temp directory would be one way to solve this. In the process of troubleshooting, I found that adding the -T option to suppress curses output fails in a strange way with the latest linux binary. This works fine without -T, it's just hard to see everything that's going on as stuff scrolls up the curses window (and out of my scrollback): box0202@box0202:/home/syadasti/software/cgminer-1.4.0$ ./cgminer --userpass user:pass --url http://pit.deepbit.net:8332 --debug -T
[2011-07-24 01:02:02] Testing pool http://pit.deepbit.net:8332
[2011-07-24 01:02:02] Successfully retrieved and deciphered work from pool 0 http://pit.deepbit.net:8332
[2011-07-24 01:02:02] Pool 0 http://pit.deepbit.net:8332 active
[2011-07-24 01:02:02] Init GPU thread 0
[2011-07-24 01:02:02] List of devices:
[2011-07-24 01:02:02] 0 Cypress
[2011-07-24 01:02:02] 1 Cypress
[2011-07-24 01:02:02] 2 Cypress
[2011-07-24 01:02:02] Selected 0: Cypress
[2011-07-24 01:02:02] Preferred vector width reported 4
[2011-07-24 01:02:02] Max work group size reported 256
[2011-07-24 01:02:02] Long-polling activated for http://pit.deepbit.net:8332/listenChannel
[2011-07-24 01:02:02] No binary found, generating from source
[2011-07-24 01:02:02] Patched source to suit 2 vectors
[2011-07-24 01:02:02] cl_amd_media_ops found, patched source with BITALIGN
[2011-07-24 01:02:02] cl_amd_media_ops found, patched source with BFI_INT
*** glibc detected *** ./cgminer: free(): invalid next size (fast): 0x000000000125b4e0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x72606)[0x7f6482a69606]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x6c)[0x7f6482a6e33c]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2f2a4e)[0x7f647e11ca4e]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2edd55)[0x7f647e117d55]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x2ede4d)[0x7f647e117e4d]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x109ef6)[0x7f647df33ef6]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x138779)[0x7f647df62779]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x10a44c)[0x7f647df3444c]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(+0x15716a)[0x7f647df8116a]
/opt/ati-stream-sdk-v2.3-lnx64/lib/x86_64/libatiocl64.so(clBuildProgram+0x2aa)[0x7f647df1277a]
./cgminer[0x40dbd6]
./cgminer[0x40af56]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd)[0x7f6482a15ead]
./cgminer[0x4030a9]
======= Memory map: ========
00400000-00437000 r-xp 00000000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00636000-00637000 r-xp 00036000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00637000-00638000 rwxp 00037000 00:19 14778946 /home/syadasti/software/cgminer-1.4.0/cgminer
00638000-00639000 rwxp 00000000 00:00 0
01237000-025ae000 rwxp 00000000 00:00 0 [heap]
7f6474000000-7f6474021000 rwxp 00000000 00:00 0
7f6474021000-7f6478000000 ---p 00000000 00:00 0
7f6478385000-7f6478592000 r-xp 00000000 00:1a 9551883 /opt/ati-stream-sdk-v2.3-lnx64/lib/gpu/builtins-gpucommon.bc
7f6478592000-7f64785c8000 r-xp 00000000 00:1a 9551881 /opt/ati-stream-sdk-v2.3-lnx64/lib/gpu/builtins-evergreen.bc
7f64785c8000-7f64785cd000 r-xp 00000000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64785cd000-7f64787cc000 ---p 00005000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787cc000-7f64787cd000 r-xp 00004000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787cd000-7f64787ce000 rwxp 00005000 00:11 8405097 /lib/x86_64-linux-gnu/libnss_dns-2.13.so
7f64787ce000-7f64787e3000 r-xp 00000000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64787e3000-7f64789e2000 ---p 00015000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e2000-7f64789e3000 r-xp 00014000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e3000-7f64789e4000 rwxp 00015000 00:11 8405095 /lib/x86_64-linux-gnu/libnsl-2.13.so
7f64789e4000-7f64789e6000 rwxp 00000000 00:00 0
7f64789e6000-7f64789f0000 r-xp 00000000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f64789f0000-7f6478bef000 ---p 0000a000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bef000-7f6478bf0000 r-xp 00009000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bf0000-7f6478bf1000 rwxp 0000a000 00:11 8405100 /lib/x86_64-linux-gnu/libnss_nis-2.13.so
7f6478bf1000-7f6478bfc000 r-xp 00000000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478bfc000-7f6478dfb000 ---p 0000b000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfb000-7f6478dfc000 r-xp 0000a000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfc000-7f6478dfd000 rwxp 0000b000 00:11 8405098 /lib/x86_64-linux-gnu/libnss_files-2.13.so
7f6478dfd000-7f6478dfe000 ---p 00000000 00:00 0
7f6478dfe000-7f64795fe000 rwxp 00000000 00:00 0
7f64795fe000-7f64795ff000 ---p 00000000 00:00 0
7f64795ff000-7f6479dff000 rwxp 00000000 00:00 0
7f6479dff000-7f6479e00000 ---p 00000000 00:00 0
7f6479e00000-7f647a600000 rwxp 00000000 00:00 0
7f647a600000-7f647a602000 r-xp 00000000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a602000-7f647a801000 ---p 00002000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a801000-7f647a802000 rwxp 00001000 00:14 8622573 /usr/lib/libXinerama.so.1.0.0
7f647a802000-7f647a835000 r-xp 00000000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a835000-7f647a935000 ---p 00033000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a935000-7f647a93c000 rwxp 00033000 00:14 14033094 /usr/lib/libatiadlxx.so
7f647a94e000-7f647ad50000 rwxp 00000000 00:00 0
7f647ad50000-7f647ad51000 rwxs 22b79000 00:12 5350 /dev/ati/card2
7f647ad51000-7f647adb1000 rwxs 22b78000 00:12 5350 /dev/ati/card2
7f647adb1000-7f647adf1000 rwxs 00049000 00:12 5350 /dev/ati/card2
7f647adf1000-7f647b4f1000 rwxs 00026000 00:12 5350 /dev/ati/card2
7f647b4f1000-7f647b4f2000 rwxs 00025000 00:12 5350 /dev/ati/card2
7f647b4f2000-7f647b512000 rwxs febe0000 00:12 5350 /dev/ati/card2
7f647b512000-7f647b572000 rwxs 22b76000 00:12 5348 /dev/ati/card1
7f647b572000-7f647bc72000 rwxs 00016000 00:12 5348 /dev/ati/card1
7f647bc72000-7f647bcd2000 rwxs 22b74000 00:12 5337 /dev/ati/card0
7f647bcd2000-7f647bd12000 rwxs 00035000 00:12 5337 /dev/ati/card0
7f647bd12000-7f647c412000 rwxs 00006000 00:12 5337 /dev/ati/card0
7f647c412000-7f647c492000 rwxp 00000000 00:00 0
7f647c492000-7f647cc3a000 r-xp 00000000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cc3a000-7f647cd39000 ---p 007a8000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cd39000-7f647cd89000 rwxp 007a7000 00:14 14033101 /usr/lib/libaticaldd.so
7f647cd89000-7f647ce42000 rwxp 00000000 00:00 0
7f647ce42000-7f647ce47000 r-xp 00000000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647ce47000-7f647d046000 ---p 00005000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647d046000-7f647d047000 rwxp 00004000 00:14 8621866 /usr/lib/libXdmcp.so.6.0.0
7f647d047000-7f647d049000 r-xp 00000000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d049000-7f647d249000 ---p 00002000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d249000-7f647d24a000 rwxp 00002000 00:14 8621864 /usr/lib/libXau.so.6.0.0
7f647d24a000-7f647d25b000 r-xp 00000000 00:14 8622561 /usr/lib/libXext.so.6.4.0Aborted |
|
|
|
|
*Very* interesting project!
Some weirdness:
- Startup appears to compile a kernel for each thread for each GPU. In the case of the default number of threads, 2, that's double work for no benefit.
- If multiple, identical GPUs are present in the system, the same OpenCL kernel will be compiled for each of them.
- If there really is a need to compile a specific kernel for each GPU, it might be more efficient to do the compilation within a worker thread, this allowing the compiles to run in parallel on multi-core machines.
- Finally, where do the generated .bin files actually get stored on linux?
|
|
|
|
|
Bump for sheer awesome sauce, and because Sam used to buy beer for me when I was still underage.
|
|
|
|
|
Bravo, MsBitcoin. Bravo.
It's a good thing that the future of Bitcoin, freedom, the universe, et cetera doesn't depend on the continued respiration of the several awful creatures writing awful things on this thread. May they die screaming, alone, in separate holes, on fire.
|
|
|
|
 opps... one of those got tripped, miner's life is full of danger... I like how the ~30A power cables float gracefully from wall to whereever  |
|
|
|
|
Probability's a bitch, and all, but me and my 12GH/s are getting kinda bored here.
With USD/BTC down to 13 in the past few days, I'm running on very slim margins. Unless a miracle block is found by the next time I wake up, I'll be going back to the big pools. Even with higher commissions, predictability beats gimmicks every day.
Still, MrSam, your model has promise. It's just not for me right now.
|
|
|
|
We don't really want to encourage reverse-pool-hopping, either, but I think this idea is a step in the right direction.
Since it has been estimated that pool hopping can deprive dedicated miners of about 12% of their income, what about this:
Every miner who was connected when the last block was found has each of their shares in the new round count as 1.12 shares as long as they remain connected. If they disconnect for more than 10 minutes any future shares they submit during that round do not receive the bonus. This provides incentive to continue mining until the block is found AND to keep mining through the next round.
10 minutes is way too harsh a metric. What about the poor sod subject to a power outage? For example, I had something like 90 minutes of no workers online on one of my accounts last night because we were reorganizing power feeds at the data center and moving my boxes from one room to another. |
|
|
|
|
I got me a jackpotz! Wheeeee!!!!
|
|
|
|
total bullshit - while I agree that botnets should be avoided, I do have myselft about 165 worker machines with CPU and GPUs working. These machines pull out 11MH/s on CPU and 20MH/s on GPUs each. My machines would classify for all of your rules, but they still are not a botnet.
It might seems inefficient to run that amount of machines with stats that bad, however, they run for generator high load stability testing right now, and they simply have to burn electricity.(just because I do know that the next post will state how inefficient this is and all that fuck all over again)
Fair enough. You'd be a false positive on heuristic #2 and possibly on #4 (which is already noted as problematic). Other than saying "total bullshit" (which is important in and of itself, anyway), any ideas? Someone mentioned IP registration, but I think that's a non-starter since a) bad guys can register the external IP of a home NAT or corporate firewall anyway and b) huge parts of the mining public are on dynamic IPs. I don't think Grant's proposal work either, though I haven't thought hard about the economics of it. Pool operators in general are already taking a percentage of generated blocks. The idea of "welcome to blah blah mining co, ltd. please upload your proof-of-age documents and enter your credit card information for recurring billing" is totally repellent to me. Also, getting "inefficient" miners out of the system isn't a goal I'd share. Antares, for example, can do what he likes with his hardware and power. Maybe this is all moot anyway. The smart botherder wanting to mine for Bitcoin might as well set up their own pool server (on someone else's machine(s), of course!), and avoid whatever countermeasures altogether. |
|
|
|
But the problem is that there is often a major count of connections from legitimate workers.
Connections per worker by itself can't be a useful metric. I think I have about 45 workers connected to you on two accounts spread across 2 IP addresses (one for my colo, one for my kitchen). Trying to imagine what botnet scenarios are likely and how to fingerprint them... 1. CPU zombie miners, home computers: <= 3 CPU-level workers per IP address, many IP addresses, all on a single worker account 2. CPU zombies, corporate environment: any number of CPU-level workers from a single IP address, all on a single worker account 3. GPU zombies, home: <= 4 GPU-level workers per IP address, many IP addresses, all on a single worker account 4. GPU zombies, corporate: any number of GPU-level workers from a single IP address, all on a single worker account All but #4 are probably reasonable rules for identifying botnet operators. #4 doesn't work, though, since a botnet infecting a single corporation with mining-capable GPUs is going to appear similar to a large-scale mining operation behind NAT. #1 and #3 could be gamed by the botnet operator setting up a proxy so that the workers all seem to be in the same place. #1 then looks like #2 (still bannable) and #3 looks like #4 (confusion!). Additionally, the operator who sets up many separate accounts with the pools they use could evade this kind of heuristic. Perhaps it is to combat such things that I have seen some pools requiring a CAPTCHA solve to create a new worker, even for a logged-in user. |
|
|
|
gief... block... pppppffffpptttututtffffttt
Believe in 'The Secret' ! You control the universe with your mind (and gpu) Tried that, too hard. It's all I can do to control the damned earth with my tongue and my tool. Please leave my mind out of it. |
|
|
|
Pool operators get their income from a high hash rate! Why should they ban anyone who submits valid shares?
I'll suggest that you are right, but not *entirely* right. The other factors which are included in a pool's profitability (and longer-term viability) include: - payout structure - reliability - customer (ie worker/miner) service - reputation Putting up botnet resistance will be a reputation bonus for pool operators who do so, at least among a certain subset of legit miners. At the same time, banning botnets from one's own pool might decrease load and thereby improve reliability. What are the actual numbers? No idea. I suspect they're big enough to think about, though, especially as pool operators now seem to be in a race to the bottom to attract hash power. Quality differentiation becomes quite important when quantity differentiation falls to the side. |
|
|
|
|
gief... block... pppppffffpptttututtffffttt
|
|
|
|
|
Show Posts
