There are hundreds of P2Pool nodes (my node has heard of 292 active in the past day). Does any pool have a network link that can sustain multiple gigabits per second? Eligius's last DDoS was over 30 gbit/sec. It didn't stop until we overcame it. |
|
|
|
Uh, what? p2pool is more susceptible to DoS than other pools... Would you mind explaining how/why? I usually think of a typical DDoS attack against a public mining pool address, perhaps you are referring to a different DoS method that I'm not considering. It's trivial to get the IPs of every p2pool miner, and spread the DDoS across them. Many (most?) mining pools can withstand far more bandwidth being thrown at them, than the equivalent in miners' connections, so the DDoS will require less bandwidth to pull off. Furthermore, since such a DDoS takes out the miners' connection, it effectively prevents any failover including solo mining. To contrast, not only do other pools have higher DDoS resistance in terms of bandwidth, but they generally keep their miners' IPs private, so when/if the pool goes down, the miners are free to failover to another pool. |
|
|
|
Explain it like I'm 10 please  "You really want to upgrade ASAP..." |
|
|
|
For anyone who is unaware, Forrest is the creator of the decentralized peer-to-peer mining pool p2pool - which will now be even more DoS resistant. Uh, what? p2pool is more susceptible to DoS than other pools, and this fix to bitcoind/Bitcoin-Qt does nothing to change that. |
|
|
|
- We should not use the official Bitcoin client because it's very hard to secure it without large investments and affecting instant withdrawals in large amounts. No harder than any other automated money transfer... don't go trying to blame bitcoind for your incompetence... it has issues, yes, but this isn't one of them. |
|
|
|
So in reality it would look like this?
Original transaction:
Input: 4.99 BTC from Alice's address(es) to 1someaddress
Output: 4.99 BTC to 1someaddress (= Bob)
Stuck in limbo, would need 0.01 BTC fee likely.
New transaction:
Input: 4.99 BTC from 1someaddress and 0.01 from either 1someaddress (ideally) or another address under the control of Bob to 1someaddress or another of his addresses
Output: 4.99 BTC to 1someaddress (= Bob) or another of his addresses (he could also just output 4.98 BTC and spend the 0.01 on miner fees)
Net fee: 0.01 BTC to miner
The miner then includes both to get the fee on the second, which is only valid if the first one went through. It is either possible to let fewer BTC arrive at 1someaddress and paying the differnece to miners or to have the 4.99 BTC arrive at 1someaddress and pay the miners from existing other funds.
^^^
Is the above correct or did you only implement the case where fewer BTC than planned arrive at the address in the end?
That would work, but there's not really any point to adding inputs IMO, except if you're sending to someone else at the same time. |
|
|
|
Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?
No. Input: 5 BTC to 1someaddress Output: 4.99 BTC to 1someaddress Net fee: 0.01 BTC to miner Maybe: Original transaction: Input: 4.99 BTC to 1someaddress from Alice Output: 4.99 BTC to 1someaddress Appended transaction Input: 4.99 BTC to 1someaddress from Alice appended Input: 0.01 BTC from someone who really wants to get these 4.99 BTC to 1someaddress, presumably the address owner total new Input: 5.00 BTC to 1someaddress Output: 4.99 BTC to 1someaddress Net fee: 0.01 BTC to miner Only the person who controls 1someaddress can create such a transaction, so there's no reason for him to add an outside input - unless it's a regular transaction going to someone else (in which case the same privacy methods apply). |
|
|
|
Doesn't this eliminate some of the anonymity of the system by advertising who the receiver of a transaction is?
No. Input: 5 BTC to 1someaddress Output: 4.99 BTC to 1someaddress Net fee: 0.01 BTC to miner |
|
|
|
So username is my wallet? Right. I'm considering mining on this pool with cgminer, seems like the website is down so I'll try later. Sounds like you have network issues  |
|
|
|
|
On further thought, duplicates might also indicate network issues making cgminer think the first submission failed. It's possible these same network issues could add some unknown amount of latency to other submissions, making them stale. I wonder if the difference is IPv6 vs IPv4? Could you try mining on ipv4.mining.eligius.st, and report how that does? Another thing we could test is DNS timing: try ttltest.eligius.info and ttltest.eligi.us to check that.
|
|
|
|
@Luke-Jr
I see very high reject-rates with my ztex board on your pool.
Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%
To compare:
Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%
ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%
Any idea why?
Looks like you're doing some kind of weird hopping. That might be related (in the sense that you may be spending more time mining Eligius when stales are more likely). You've also got a lot of duplicate shares. That's a bug in your miner software or FPGAs. Made some further tests: cgminer version: 2.4.1. 1 cgminer for GPU 1 cgminer for ZTEX Pools tested: Eligius, ABCPool, pool.itzod.ru (small SMPPS pool). Eligius: (pointed only the GPU cluster, no weird hopping!) 3 hour average: 7170 shares valid, 4 duplicates, 234 stales = 3.21% invalid shares. ABCPool: (GPU and ZTEX cluster): 0.19% invalid shares itzod.ru: (GPU and ZTEX cluster): 0.58% invalid shares I get the duplicates only with Eligius. I experience around 2.5% invalid shares using Eligius, although I point only the GPU cluster. Conclusion: it's better to mine on another pool for me. Eliguis is now a backup backup pool. Will check every while if things get better on Eligius. Why didn't you point the ZTEX cluster at Eligius too? Duplicates are a miner bug, so I'm going to have to guess that's a problem with your GPU(s) and/or cgminer's OpenCL driver. As for the high stales, could you try pinging each of the 3 servers? There's another guy who also gets high stales with the same pings as me, so there's probably something going on, but I haven't been able to figure out what or why it only affects some miners (I consistently get well under 1% stale myself). If anyone with this issue persistent is willing to provide Linux SSH access to me for debugging for a few days (I can keep it mining on your address), I'd be interested in investigating it further... |
|
|
|
Would you describe how this would be implemented for the user?
i.e., I presume this would allow me to create a 0 BTC spend transaction for the address that is an output in a transaction that I'm waiting on it to confirm. Is it voluntary up to the miner to take this transaction and then include the earlier transaction, or could the miner just take this "re-fee" transaction and still ignore the earler transaction? Miners can't include transactions without first making sure their inputs are confirmed. Therefore, consuming an output of a transaction you want to confirm, in a new "change only" transaction (and including a fee on that) can be used as an incentive to include the original transaction. This code will treat the dependent transaction the same as it would by itself, but with a larger data size including the one it depends on. So if your new transaction is 500 bytes, and the one it depends on is 2000 bytes, the new transaction is treated as if it were 2500 bytes until the first one is confirmed - so your new transaction should include a fee assuming it is 2500 bytes, and its parent will get pulled in with it. |
|
|
|
I seem to recall people offering bounties for this functionality. I've implemented the miner side, so if you offered a bounty for this, please post and/or send here when satisfied: 123R1562U9BNAjh7h2QHNiJ44YTSx1oa8P Note this is mostly untested still, and I don't recommend mining with it until I've given it more sanity checking and had some peer review.I don't intend to implement the receiver-wants-to-explicitly-add-a-fee side, at this time. If people start offering bounties for that, I might change my mind.  |
|
|
|
@Luke-Jr
I see very high reject-rates with my ztex board on your pool.
Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%
To compare:
Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%
ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%
Any idea why?
Looks like you're doing some kind of weird hopping. That might be related (in the sense that you may be spending more time mining Eligius when stales are more likely). You've also got a lot of duplicate shares. That's a bug in your miner software or FPGAs. |
|
|
|
@Luke-Jr
I see very high reject-rates with my ztex board on your pool.
Ztex-Quad (BTCMiner or cgminer): 4.53%
GPU (cgminer): 1.8%
To compare:
Deepbit:
Ztex-Quad: 0.18%
GPU: 0.21%
ABCPool:
Ztex-Quad: 0.22%
GPU: 0.29%
Any idea why?
What address? |
|
|
|
|
So as the maintainer of stable bitcoind/Bitcoin-Qt series (0.4.x and 0.5.x), how do I participate in getting the RCs out to testers?
My about-every-month next-test combination builds should also continue to help to bring pullreq testing to common Windows users.
|
|
|
|
next-test is a branch of the mainline bitcoind & Bitcoin-Qt with as many pull requests merged as possible, to aid in testing them. This branch can be used to test many pull requests in your daily Bitcoin use. The goal is to help pull requests get the testing they need to be merged into the main tree, so once you test a change, please comment in the relevant pull request (ideally with details). Please note these might possibly corrupt your wallet. No warranty of any kind of provided. BACKUP YOUR WALLETToday's next-test includes the following pull requests (green are merged now; red are disputed): Bugs found: |
|
|
|
NEW VERSION - 2.4.1, MAY 6 2012While Kano continues to try rewriting his own hashrate measurements for CGMiner's Icarus driver, BFGMiner's Icarus driver was already (and still is) more accurate. I did take the opportunity to give it even more specific calibration, though. As BFL+Icarus owners might have known, BFGMiner has worked with both devices together from the start. Finally, Kano recently injected RPC API code through the device driver API in CGMiner. While I made an attempt to sanitize it upstream, Con didn't merge it in time for 2.4.1; BFGMiner of course includes this cleanup, since it is important to a sane (and secure!) device driver API. Human readable changelog:- --benchmark won't crash
- A pool will only be disabled if it rejects shares for at least 3 minutes in a row. Then it will be checked every longpoll to see if it is accepting shares, and if so, will be re-enabled.
- More accurate hashrate on Icarus
- Ztex quad 1.15y support
- Extra device stats in RPC API
Full changelog- Icarus: Calibrate hashrate yet even more accurately
- In the unlikely event of finding a block, display the block solved count with the pool it came from for auditing.
- Display the device summary on exit even if a device has been disabled.
- Use correct pool enabled enums in api.c.
- Import Debian packaging configs
- Ensure we test for a pool recovering from idle so long as it's not set to disabled.
- Fix pool number display.
- Give BFGMiner -T message only if curses is in use.
- Reinit_adl is no longer used.
- API 'stats' allow devices to add their own stats also for testing/debug
- API add getwork stats to BFGMiner - accesable from API 'stats'
- Don't initialise variables to zero when in global scope since they're already initialised.
- Get rid of unitialised variable warning when it's false.
- Move a pool to POOL_REJECTING to be disabled only after 3 minutes of continuous rejected shares.
- Some tweaks to reporting and logging.
- API support new pool status
- Add a temporarily disabled state for enabled pools called POOL_REJECTING and use the work from each longpoll to help determine when a rejecting pool has started working again. Switch pools based on the multipool strategy once a pool is re-enabled.
- Removing extra debug
- Fix the benchmark feature by bypassing the new networking code.
- Reset sequential reject counter after a pool is disabled for when it is re-enabled.
- ztex updateFreq was always reporting on fpga 0
- Trying harder to get 1.15y working
- Specifying threads on multi fpga boards extra cgpu
- Missing the add cgpu per extra fpga on 1.15y boards
- API add last share time to each pool
- Don't try to reap curls if benchmarking is enabled.
|
|
|
|
|
Show Posts
