I'm selling my 2x Knc Jupiter + 2x Corsair AX1200.
Both miner are mining at REAL 1080GH/s +/-20GH/s.
I want for all 85BTC.
Of course escrow could be used. I prefer SebastianJu.
International shipping from germany is inclusive to wherever you live. Express or anything special has to be payed extra.
i'll give 20 for the whole set |
|
|
|
Why so high is because a miner in hand is worth a lot more than something on a slow boat from China. Also a private transaction sold to someone in the EU then you also avoid VAT by declaring it as a used computer. I know genesis block blah blah blah. Have you seen BTC prices? Currently $204 at MtGox. You will get your 30 BTC back in 60 days. At that point if a BTC is worth $400 then you got yourself a nice ROI. All about risk versus potential reward. The one thing genesis block can't predict and no one can is where BTC price will be in 60 days. You can only speculate.
In 60 days if BTC is at $400, then you should have held on to that BTC & you wouldn't be out the extra money from electricity, storage, etc. You say that someone would get 30BTC back in 60 days... Let's assume I use the date of your post (the 22nd)... and the seller gets the 30BTC offer and miraculously ships that same day (since it's a Friday). Uh, no clue how fast/slow carriers are there, but I'll be generous and say it takes 2 business days to arrive, arrives at 8am and is set up instantly. That'd be the 26th. You have approx. one week to mine with this @ current difficulty level, netting you about 2.4 bitcoins (assuming no power outages, no downtime, etc). On the 5th, difficulty changes to ~520m. You have ~10 days to mine at this 520m rate, netting you 2.6 bitcoins. We're at 5 now after 20 days. I'll be generous and say that from this point, difficulty only increases 25% per increment (last five were 32.13, 27.19, 41.45, 46.02, and the upcoming ~34%). So you have about 11 days on this new level of 650m, getting 2.3 bitcoins. The next 11 days you get 1.73 and going forward you get 1.3, 1.04, .98, .74, .56, .42, .32, .24. A little over 14.5 bitcoins after 130 days (then it'd be something like 200 days? until you got 1 more bitcoin). ed: +/- 10% from arithmetic errors. didn't use online calculator Doesn't this thing also use a whole lot of electricity? So the obvious thing to do would be to buy bitcoin, if you think it's going to be $400... |
|
|
|
This thread sounds fishy as hell to me. Didn't have time to set it up. Sounds like a sympathy story, followed by a scam sales pitch.
Any bid over $150 or so seems pretty fishy as well... but since he's taking Paypal, you could always charge back for bitcoin related stuff |
|
|
|
|
I don't see this behavior with a second node that has 50 connections (& same client version as other server), runs p2pool, & has listen=0 ... also doesn't appear on my local node that has a single bitcoind connection & runs p2pool
I am thinking you won't see this message unless these odd peers are connected to you *and* you're running p2pool?
I know it'd be caused by (ed: whatever interaction is occuring with):
p2p.py: self.pinger.start(30)
|
|
|
|
BTW, feel free to PM me if you ever decide that you want to increase that 75% efficiency for example, 84.201.254.19:9332, used to have a 15% orphan rate |
|
|
|
hetzner network was screwed for about 15m, if anyone reads this that was mining on my pool or some other one located on hetzner network oh, and luck over the last 3 days has been good if you include 266856 and onwards  5 blocks in 76 hours, estimated time is 14hr30m but that's with 32.9 thash, and the average over the last 76 hours is probably more like 29-30thash... jaja btw: whoever is using p2pool.org:9332 and paying 2% for 75% efficiency... stop! Oh thanks. I don't think your advice is working tho. 1.60TH/s (13% DOA) at this time. When/if you ever get that hash rate you will see your efficiency drop also. Does everyone on this forum always get jealous and have to attack everyone else? It's ok man, some day you too will have miners, but attacking other people isn't going to work. And another thing, how is your expected BTC in 24 hours increasing when you charge no fee? you truly have no clue. it's quite sad. my advice isn't working? huh? i have been at 1.5thash before, see http://nogleg.com:9332/static/graphs.html?Weekhere: http://nogleg.com:9332/feehttp://p2pool.org:9332/feeget a grip. good job grabbing p2pool.org and preying on the dim, btw. i see that you're up to 0.03 btc from fees yourself. by the way, I charge one millions % in fees that's a lot of monies. ps: the only p2pool I've ever attacked is yours, and that's because it took you two weeks to upgrade to a p2pool client that supported the NewShare... wasting all those poor souls hashes that happen to be at your site. then again, I suppose you *did* have about a 1/1000 chance per day to solve a block. now it's merely on principle |
|
|
|
|
I'd be surprised if it didn't sell... but a month or two or maybe even three months down the line, you'll get that money reversed
Bitcoin hardware + paypal + seller on ebay = owned
|
|
|
|
ZVS, I have pretty decent reputation around here, not sure why it's curiously high when units oneBay are still selling for 6-700 which I find crazy.
$450 seemed reasonable to me, considering what I'll be adding it to.
Unfortunately, that price has since expired since he never PM'd me.
Not sure why it's curiously high? One reason - the seller (unwisely) states he is accepting paypal. So I question any absurd offers on that basis alone.. The other reason - even when you made your offer, there was no chance you were going to get it before the difficulty jumps to 515-520'ish million. So you make about $40 in a week, then a week after that you make $30, and so on. It uses ~300 watts of energy. It takes up space. So maybe you're wagering that bitcoins will jump in price to $1000 within the next month or two, since that seems about the only way that hunk of junk would be worth $450. But then, in that case, you'd be better off spending your $450 on bitcoins right now. |
|
|
|
|
well, i've got a query as well
Why does your pool have so many miners with such a horrible efficiency rate? Both in BTC and LTC. BTC is 75%, LTC is 80%. Not only that, but there's a 2% fee, when if you needed to use a remote p2pool server, you have about fifty to choose from on p2pool-nodes.info .. does charging a 2% fee incur some measure of legitimacy that being free does not? hmm, I think I may be on to something there
oh, you should also upgrade your version of bitcoind, to get rid of those 5s latency times
|
|
|
|
|
Hell, I figured something like that would be obvious
|
|
|
|
I have an unconfirmed transaction from over a year ago. Part of the transaction was an accidental double-spend attempt - leaving the rest in limbo. Anyone know how I can delete this transaction and get access to the BTC again?
*edit: It included a 0.0005 transaction fee
gettxoutsetinfo returns statistics about the unspent transaction output database. gettxout returns information about a specific unspent transaction output. uh, make a backup copy of the old wallet, get your private key, remove it, then rescan or reindex or whatever the entire blockchain. then when that's done, add your key back? |
|
|
|
For bitcoin BTCguild....
Care to elaborate? They're an expensive pool with average features. If reliability is a concern, you can simply set your miner to failover to any number of lower-fee pools giving you the same or better uptime as just mining at one big pool. Why do people seem to think that bigger = better? I stay away from BTCGuild, my profitability is better mining elsewhere. Some have probably been there since 2011.. I guess I could understand that. Not sure why someone new would start there though, esp. when you have a whole bunch of quality 1% pools available, if you don't feel like messing with something like p2pool (I think Eligius might be 0 fee too, not sure). |
|
|
|
@zvs
Ha....ha....ha
"Nigerian BTC P2Pool - "We mine our Bitcoin directly out of other people's wallets!"
i thought it was fitting |
|
|
|
2013-11-03 05:09:44 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:10:14 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:10:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:11:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:11:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:12:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:12:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:13:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:13:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:14:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:14:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:15:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:15:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:16:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:16:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:17:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:17:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:18:02 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
<snip>
2013-11-03 11:33:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:34:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:34:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:35:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:35:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:36:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:36:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:37:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:37:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:38:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:38:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:39:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:39:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:40:03 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:40:33 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:41:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:41:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:42:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:42:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:43:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:43:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:44:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:44:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:45:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:45:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:46:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:46:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:47:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:47:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:48:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:48:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:49:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:49:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:50:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:50:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:51:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:51:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:52:04 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 11:52:34 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
They also all have: ProcessMessage(ping, 0 bytes) FAILED immediately following that message. This is where it started: 2013-11-03 05:11:27 accepted connection 176.9.144.41:32687
2013-11-03 05:11:27 accepted connection 46.4.64.21:56061
2013-11-03 05:11:27 accepted connection 5.9.30.207:42607
2013-11-03 05:11:27 accepted connection 144.76.70.73:54425
2013-11-03 05:11:27 accepted connection 144.76.102.176:30757
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=176.9.144.41:32687, peer=176.9.144.41:32687
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=176.9.144.41:32687
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=46.4.64.21:56061, peer=46.4.64.21:56061
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=46.4.64.21:56061
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=5.9.30.207:42607, peer=5.9.30.207:42607
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=5.9.30.207:42607
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=144.76.70.73:54425, peer=144.76.70.73:54425
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=144.76.70.73:54425
2013-11-03 05:11:27 accepted connection 5.9.110.78:55205
2013-11-03 05:11:27 accepted connection 5.9.245.121:60001
2013-11-03 05:11:27 accepted connection 88.198.41.74:39240
2013-11-03 05:11:27 accepted connection 5.9.203.20:43255
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=144.76.102.176:30757, peer=144.76.102.176:30757
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=144.76.102.176:30757
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=5.9.110.78:55205, peer=5.9.110.78:55205
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=5.9.110.78:55205
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=5.9.245.121:60001, peer=5.9.245.121:60001
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=5.9.245.121:60001
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=88.198.41.74:39240, peer=88.198.41.74:39240
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=88.198.41.74:39240
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=5.9.203.20:43255, peer=5.9.203.20:43255
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=5.9.203.20:43255
2013-11-03 05:11:27 accepted connection 91.121.58.230:55388
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=91.121.58.230:55388, peer=91.121.58.230:55388
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=91.121.58.230:55388
2013-11-03 05:11:27 accepted connection 199.193.117.231:20562
2013-11-03 05:11:27 send version message: version 70001, blocks=267626, us=5.9.24.81:8333, them=199.193.117.231:20562, peer=199.193.117.231:20562
2013-11-03 05:11:27 receive version message: version 70001, blocks=1, us=127.0.0.1:8333, them=0.0.0.0:0, peer=199.193.117.231:20562
2013-11-03 05:11:32 ProcessMessages(ping, 0 bytes) : Exception 'CDataStream::read() : end of data' caught, normally caused by a message being shorter than its stated length
2013-11-03 05:11:32 ProcessMessage(ping, 0 bytes) FAILED
The thing is, I don't want to firewall these nodes as I receive blocks from some of them. Anyone have any clue as to wtf the deal is? Is there a way to stop this w/o firewalling the nodes themselves? Does the message even matter? Can I just ed -s debug.log <<< $'g/ProcessMessage/d\nw' it out of there or what? It's the 'BS Satoshi 0.8.99' nodes. |
|
|
|
Yeah i like stock too
i never understood the fascination with that new design... seems 75% of the pools run it now |
|
|
|
Has this been implemented yet? I'm considering turning my node back on to see if it improves anything..... nothing on git yet... there were two changes, but only affecting litecoins and some other bizarre coin (terracoins?) |
|
|
|
|
you can pay me some monies, lots of monies, and i can use my id and such
|
|
|
|
to find a pool. should have at least one backup, probably two. lower latency isn't always best, check what your DOA rate would be & check the pool's orphan rate. a pool that gets 10% orphans that you have 20ms latency to would probably be lower efficiency for you then a pool that gets 5% orphans w/ 150ms latency (this likely wasn't the case when the shares were 15s apart instead of 30s, but it reduces the importance of low latency)
a few words about latency. there is a perception that 100-200ms latency is batter than 20ms. as it is explained in efficiency thread that because of limiting number of included tx and as well - lower tx fee. That is mistake! 20ms (lower) IS better then 100ms (higher) latency. Let's look. It's true that to reduce latency is used limiting of tx number For example we can include only transaction that have 0.0001 and higher tx fee this way we will filter 'transaction dust' what we loose in this case? avarege number ot transaction in block now is about 300-500, so filtering dust we reject about 0.0001*500=0.05Bbtc fee and it will be only if all 500 transactions have less than 0.0001 fee. Practically it hundreds times less. So rejecting about 0.0005 fee each block we get latency 20ms instead of 200ms and theoretical less amount of rejected shares on pool obviously lower latency is better than higher latency... as in network latency. bitcoind getblocktemplate latency would cause you to have a higher chance to have an orphan BLOCK, but not really a whole lot else (though generally when you have a high gbt latency as in 0.5s+, your whole damn system is strained). already, 1/2 the time or more, these shares that are being 'punished' end up being the ones that become the main chain. the problem with having a lot of transactions on a public node that a lot of people use, is that with 5-10 work requests, it can take 100ms to get these all out if you have a 100kb block, even on something like a xeon e3-1270v2. if i was running a private node w/ just myself, i would set maxblocksize to 500000 i said if you choose a p2pool, the # of orphans that p2pool has is the most important thing to look at. the DOA rate is easy to see, run a miner on it for 10 minutes "82.196.8.44:9333": 3816 so you are running 3816 bytes of transactions atm. i am at 4873 (though I think I'll just go ahead and drop that to 2000 or so) my latency is average of 3.16ms over the last 24 hours, yours is 7.64ms, so you don't need to lecture me about it. i do this so there is less time between work assignments, not for getblocktemplate stats |
|
|
|
|
will pay 15 BTC + shipping
|
|
|
|
|
Show Posts
