List it on eBay... I'll buy it.

..... but it'll be faulty, and I'll experience difficulties in returning it, it may take up to a month

i'd give you $5000 for it, but only if it's local pickup

If you have your own ASIC *company*, maybe.

They won't sell them unless it's more profitable for them to do that instead of mining with them

a lot of the MPOS 0% pools will eventually decide to stop paying out and run off with all your coins.

i run 0% p2pools, but they dont tend to stay up for longer than a month or two.  since, well, it's a hobby and it isn't making me any money (running it as a public pool)


it also usually is well below 100% efficiency, haha

i have two bitcoin nodes up right now:

5.9.24.81 and 76.72.171.85.  use maxconnections=1 listen=0...  5.9.24.81 is in Germany, 76.72.171.85 in Philadelphia.   so put connect=5.9.24.81 or connect=76.72.171.85, whichever is closest.

unless this was fixed in the latest version, it's always been 100x faster to download blockchain from one peer.  otherwise you end up getting someone with very little upstream bandwidth and probably annoy the hell out of them too.  i know i hate it when i run dogecoin or something and someone starts DLing blockchain from me with my crappy 768kbps upstream
 

hmm, can p2pool be modified to detect block height?

for example, these doge blocks: 145089, 145086, 145085...  are over 4000 height behind the current block.

It seems like a better way of identifying the blocks?  This way you can penalize shares from blocks that are 2 height below current?

ed: i read the warning about altcoins, so i'm just using doge as an example.  the same could apply to bitcoins

These both trace back to

http://175.139.234.171:22550/static/

(ed: fixed, had one of them wrong)

the other guy;

http://bitinfocharts.com/dogecoin/address/DD9oxPLmvMqds5Y9BixcGyRvkVQWo8vQCB

must be on a firewalled p2pool.. though 3 of the 4 dead-ends pointed to 46.29.154.3

Is there a DOGE blockexplorer somewhere that's on the wrong fork?  I'm curious now

Well, here's your first anomaly for p2pool:

Fri Mar 21 2014 16:26:59 GMT-0500 (Central Daylight Time)   145089   116f880e8dde0570c92eb5a6c2552c4b244ccf43f0b85f20ff64bd6217080429   →
Fri Mar 21 2014 12:22:54 GMT-0500 (Central Daylight Time)   150069   33a9b27d369c75da1bf66535740d4add41383eaabba32d08ba5ff66b1279956e   →
Fri Mar 21 2014 12:11:41 GMT-0500 (Central Daylight Time)   150059   8e3d27e0de0d3602e10e20b6efeec7193f1ac184b5ebca0426fd0e774d56e890   →


DPV4bZipEHnvokMhENm6rJY5wNCjU3oUa8 wins

oh, I just noticed he also had this bogus block:

Thu Mar 20 2014 20:02:00 GMT-0500 (Central Daylight Time)   145085   480b70b17238235eaad5feae0ee3bf4da17329f7b67aa50b4dfcd5e204cf8de4   →

but his payout total is only 800 right now.  given that he's solved two blocks, i imagine the tradeoff of the 60s, 15s share not orphaning automatically is worth letting that dude take his .003%.

probably has 50mh + ?

lol, this one too:

Fri Mar 21 2014 00:56:19 GMT-0500 (Central Daylight Time)   145086   8fcf7244e1ee17f18e2c5eab4aada97e3d0a551b1a048c61f72c1c9a6d58d431   →

DD9oxPLmvMqds5Y9BixcGyRvkVQWo8vQCB

his payout is only 157/250,000

wonder who got blocks 145087 and 145088

About 30 minutes or so worth of addresses that like to orphan valid shares:

DTQZPBDN9jeUB5THwwa8Wyus2ZqXNeWxvB I
D6PcXKN8hHHQj7RyERtaFMhR7hwVn4QBkW I
DCoR1VP2BogJ1ZAx4sBub9bHHN94FFDkrq I
DPV4bZipEHnvokMhENm6rJY5wNCjU3oUa8 II
DQE6By8GoubywZjVjKJ62TcFH6hPCVJcqe I
DNNWnSpvHg1Wk7EuwWWb4X6nQScB99ShJq II
DEcHKjTFAVqawjcTV9JoXVtiC3Zc7gqbba III
DGpZ6c378CTxnq4S8jgTRcumeSDLFZQSGS I
DQwP8icsjokQRyZ6TofwikDVRp3412CMGB I
D7957Y7HyWdBMgyiCPEDw2QCGGPHY1kTpF IIII
DRnnwtyjFFFSZ3u4EZTDSGqRsUm1t41wyW I
D9nmeeeHnbxJZ5pSwmxcR8zQvXAQHxhjRD I
DPs9S7o4VHxmZhsWwdrCXdwXbjQzv8aAjQ II
DKkf4FS373CnhdvGX9jhcVNcBVUuxLvSDm I
D77euB1Jxu3Ww7AR48P6MKYbKYG1EY95mU I
DPGvdkAAQecEbkmY7MA6oz7urAQVzhCU3X I
D5pfGtJvbUyGRVayAz2ommAvB8wdDaAT6z I
DRT1sNS6kXEKPCG1LYHseSq7zjx362qpCU II
DT4MniijNYqbcmtUiE1V72p8eRZMKzKu5z I
D9aC2orwLF8wNnrHbJ6nRWeSmUgVrgX4AW I
DNyASYpTfKgxjKuVJeqVzqEF4wsdWNKUBY I
DPwCdr2uaLFbFsGcydtzm2GiTtTvB7pADu I
DBmVQbVcFyCSm3cEg3QbFwsq6w1tc1ZqBW I
D61No4jTvwQx9qBJKcp947tPsJGbTJ9fUe I
DRAc9pdmCne15j3cTnSgcykRah7G5uBWrs II
D73PVo7rE2eDZPsg7bWJ36gEJDi6uVJZyq I
D9Bjeo1nRWGG4njppv9j2NNHkyWGdBSbYw I
DJRwQqpJyZPFzXkNJGSVAMrpmJkn6LRaZ1 I
DSMSGN9qM1aTFeG7xNTnPjZRUyyNMb4f5g I
DEMMiCAZxW1D8DXDyHhToiskbPgUB5WQTN I
DBggjGyc7igpXByQgB576QvfB5kQiwsCCn I
DNSSFZuLgYPtBVM6YoRvoAdCQFCqNq6oT5 I
DKvhL9zroRNV7D683ze1BRFQdWSw3KhXw6 II
D6SjfjkF796W89fXsLLinDzFH6RYQ3sUhZ I
DDyeKFaC5MePAfMR3TpBe3KLMZSwpKMBnk I
DD9oxPLmvMqds5Y9BixcGyRvkVQWo8vQCB I
D5XaPUqMqN95WMaYPbdzSVzjoLzWCA9sDt I
DE64LbkjVQmTxTb6XB7GybYD3rVr76U9n1 I
DNpnBZArsiPcZ5pRyqb2RMDcEyMnYrTdrn I
D97VQMLQrREgUu2WH5Aspx22rjWZGd3pT8 I
DRAVPnGye7y8rM3cGz821DVaD841ALKNfW I

...

D7957Y7HyWdBMgyiCPEDw2QCGGPHY1kTpF wins, with four successful orphans.  One of them was some 35 difficulty share from DDYWQsoSpWrACHxMgj1Yd8jJt5JBKACe8a.  Great job!  That one certainly improved everyone's efficiency... well, except DDY..  (well, actually this is a list of *attempted* orphans of valid shares, a lot of them ended up orphaning themselves)

ps - switch to a good pool

First set of data is irrelevant to question, just wanted to show dstat before the logfile output & stripping extraneous info

------sockets------ --net/eth0- -dsk/total- ---load-avg--- ----interrupts---
tot tcp udp raw frg| recv  send| read  writ| 1m   5m  15m |  51    52    53
986 810   3   0   0|  23k   17k|   0     0 |0.35 0.32 1.45|  92    74     0
986 810   3   0   0| 594k 7441k|   0   448k|0.32 0.31 1.44|1998  2183     0
986 810   3   0   0| 878k   54M|   0     0 |0.32 0.31 1.44|8278    11k    0
986 810   3   0   0|1062k   63M|   0     0 |0.32 0.31 1.44|9655    13k    0
986 810   3   0   0|1349k   72M|   0     0 |0.32 0.31 1.44|  11k   15k    0
986 810   3   0   0|1232k   50M|  24M    0 |0.32 0.31 1.44|9095    11k    0
986 810   3   0   0| 632k   23M|  44M   60k|0.38 0.32 1.44|4751  6215     0
986 810   3   0   0| 412k   19M|  44M    0 |0.38 0.32 1.44|3383  5325     0
986 810   3   0   0| 472k   17M|  19M    0 |0.38 0.32 1.44|4018  5333     0
986 810   3   0   0| 281k   16M|  16M    0 |0.38 0.32 1.44|2698  4440     0
986 810   3   0   0| 411k   18M|  20M    0 |0.38 0.32 1.44|3845  5218     0
986 810   3   0   0| 438k   18M|  18M    0 |0.35 0.32 1.43|3619  4957     0
986 810   3   0   0| 377k   17M|  12M   64k|0.35 0.32 1.43|3746  4934     0
986 810   3   0   0| 370k   16M|  12M   32k|0.35 0.32 1.43|3559  4908     0
986 810   3   0   0| 369k   18M|  16M    0 |0.35 0.32 1.43|3005  5266     0
986 810   3   0   0| 453k   17M|  13M    0 |0.35 0.32 1.43|3799  5294     0
986 810   3   0   0| 291k   16M|8688k    0 |0.32 0.31 1.43|2423  4368     0
986 810   3   0   0| 275k   15M|9200k    0 |0.32 0.31 1.43|2349  4285     0
986 810   3   0   0| 323k   15M|  15M    0 |0.32 0.31 1.43|2135  4029     0
986 810   3   0   0| 372k   15M|  10M    0 |0.32 0.31 1.43|3383  4571     0
986 810   3   0   0| 563k   12M|  10M    0 |0.32 0.31 1.43|3560  4088     0
986 810   3   0   0| 418k   15M|  14M   16k|0.37 0.32 1.42|3943  4697     0
986 810   3   0   0| 228k   13M|9852k    0 |0.37 0.32 1.42|2258  3587     0
986 810   3   0   0| 373k   15M|  11M    0 |0.37 0.32 1.42|3357  4305     0
986 810   3   0   0| 789k   14M|  11M    0 |0.37 0.32 1.42|2523  4063     0
986 810   3   0   0| 335k   13M|6556k    0 |0.37 0.32 1.42|2242  3832     0
986 810   3   0   0| 357k   14M|7280k    0 |0.34 0.32 1.42|3092  4362     0
986 810   3   0   0| 432k   12M|5376k 8192B|0.34 0.32 1.42|3945  4610     0

^^ This is from Philadelphia node, the other two had the blockchain in ramfs (this was the only node with any significant disk activity).

*****

OK, now this data is all from one block:

Germany (nogleg), an i7-4770 w/ 32 GB of RAM w/ blockchain in ramfs,

(tcp sockets open (maybe a handful or two aren't bitcoind connections), eth0 received, eth0 sent, timestamp (GMT))

629,656147,721483,06-03 04:11:28
629,528982,44778852,06-03 04:11:29
629,1026082,78608445,06-03 04:11:30
629,1108072,92873237,06-03 04:11:31
629,1057960,67983803,06-03 04:11:32
630,460841,28231563,06-03 04:11:33
630,163400,10998207,06-03 04:11:34
630,210372,8074017,06-03 04:11:35
630,126797,7413886,06-03 04:11:36

(capped at 88.57MB, or 93MB if we want to use fake infos, like manufacturers of hdds)

this is Philadelphia, PA, an e3-1270v1 w/ 16GB of RAM and SSD drive:

496,222221,244847,06-03 04:11:28
496,694519,6537351,06-03 04:11:29
496,867406,60435521,06-03 04:11:30
496,979387,67685208,06-03 04:11:31
496,820277,49585630,06-03 04:11:32
496,469354,19855676,06-03 04:11:33
496,126834,5740728,06-03 04:11:34
496,173320,4679675,06-03 04:11:35

This is Houston, TX, which is by far the fastest machine (quad opteron 6274, 64gb RAM -- ~1800c/m yam and nearly 300khash scrypt, hoho) -- blockchain in ramfs.  I don't want to use tmpfs since I'd rather have it crash & burn then start using swap space (so I have to remove disk space check every time since it doesn't work with ramfs.. well, I'd remove it regardless, since it's some small hit to efficiency)

I modified the source to allow 64 scriptcheck threads instead of 16, but unsure if it made any difference (it was "running" 64 threads at least).  the clock on this had a couple of seconds drift.  I took it offline after around 36 hours because of the inadequate upstream.  The rest were shut down at end of day GMT on march 8th.  I started Philadelphia & nogleg back up for approx. 23 hrs on march 12th (wanted to confirm correlating changes in tx propagation times on http://bitcoinstats.com/network/propagation)

Data for Houston, TX server:

530,183301,6583325,06-03 04:11:30
530,277817,12304357,06-03 04:11:31
530,271737,12301635,06-03 04:11:32
530,303381,12300903,06-03 04:11:33
530,298444,12300672,06-03 04:11:34
530,313658,12298154,06-03 04:11:35
529,320124,12292110,06-03 04:11:36
528,288593,12293872,06-03 04:11:37
528,263904,12300140,06-03 04:11:38
528,278275,12303968,06-03 04:11:39
526,281720,12291286,06-03 04:11:40
527,279488,12289710,06-03 04:11:41
527,287642,12291841,06-03 04:11:42
526,290481,12278198,06-03 04:11:43
527,192947,9499450,06-03 04:11:44
527,83951,3973766,06-03 04:11:45

Now my question is...  you can see this is on a 100mbps uplink and that it continued sending at that max speed for maybe 8 seconds or so after the other two had stopped.  I haven't looked through the code (& not even sure if I'd be able to tell if I did) or conducted a test, but would it be possible to delay someone receiving a block by deliberately decreasing your upstream bandwidth (or just by having poor upstream to begin with)?  i.e. I can receive and process any block very quickly, I then limit my upstream to, say, 3mbps.  that should make sure everyone that requests the block from me receives some small amt (~5kb/s).  does this mean they won't request the block from another source? 

I could see it requesting from 2 or 3 sources simultaneously, but more than that & you'd exacerbate the bandwidth issues.  Client should probably determine the best sources over time if it doesn't already.  I'm sure there's some relay in place between major pools (if not, there should be), but I'm guessing at least 1/4th of the blocks come from solo miners or small private pools...   problematic if someone can slow the transfer to a trickle w/o it breaking off request.

I used to think those Swiss nodes were doing that (I had them blocked, the vbitcoin eth zurich nodes, as they never sent data & just received), but maybe not...  or maybe they were, but since they weren't sending any data at all it requested the block from a secondary source semi-quickly?

i think you should stick with windows servers

http://wiki.nyr.be/servidores_dedicados_low_cost

or

http://www.microsofttranslator.com/bv.aspx?from=&to=en&a=http://wiki.nyr.be/servidores_dedicados_low_cost

that's my dedicated server, and it has nothing to do with mtgox

i keep the blockchain in ramfs & disable all logging

yeah, probably right, unless he's messing with the core/memory settings of the card as well

a powered riser should fix that problem

there are a bunch of new BIOSes @ http://www.asrock.com/support/download.asp?cat=BIOS   didn't see one specifically for your model, but H81M-HDS and H81 Pro BTC ?

Uh, if a card "drops out" and doesnt totally freeze or crash your system, that would indicate to me that it's semi-close to being stable, but the settings need a bit more changing.

I would say to check the VRM temps, but that doesnt really make sense if it has more issues (3khash) when you're undervolting it than when you leave it at default (300khash).

so, i guess you are probably changing the core or memory settings?  one of them is moved over too far

or your motherboard might not provide enough power for three cards

No, it takes me about an hour or two to rescan, on an i7.

.. and yeah, you just have to export the private key then import it.... then rescan.

your difficulty adjustments are way off.  +20%?  over what?  a month?

if you look at the last 6 months, the average is more like 60%.

that gives you a little over $1 in 12 months (*or more like $3, it'd be $1 if you started next month)

i was being generous with the difficulty level earlier.   i guess we can be generous again and say that the current difficulty still has 2 more weeks.  you'll make $1.25.  after that, you'll make 0.9375, then 0.70, then 0.53, 0.395, 0.296, 0.22, 0.167, 0.125, 0.093, 0.07, 0.053, 0.04, etc.  So, no, you never make your money back.

and even if you did just barely manage it, you'd be better off investing in something else.

(& just looked at first 8 days of current diff level, looks like a 20-25% hike to me)

get a PSU with a 14 gauge cord,  most household sockets in the US at least are 15 amps

i had a 16 gauge extension cord that melted

err, i was talking about a power supply (*ed: ffs, a surge protector)

get a PSU that's 1200W + and at least bronze cert =p

If blockchain.info shows it, that means it was broadcasted...  but if you sent something with a 0 fee, then you may be waiting a while, since there's some GB+ backlog

https://blockchain.info/unconfirmed-transactions