|
is there some logical reason that (any) share found directly before a new block is orphaned?
i have my node set to ignore the 'punish', since otherwise it'd be penalized for being fast.
all i can think of is to prevent these nodes that have the huge getblocktemplate + network latency from spitting out invalid shares based on the old block? what other reason would there be to punish a share that is made before the new block (and thus valid) ?
|
|
|
|
Hy, i mine now for 5 days with 14 GHs. And i become no shares in the p2pool network... so i think p2pool is not for little miners. A friendly user from the german part of bitcointalk mine with 450 GHs on my node . about 20, 30 min. to create a share, to show, that my node can make shares  To become shares a miner needs 100 GHs.. or more... So i let open my node. but i dont mine on the network... 14ghash should get you around 2 a day i think i didnt get a batch 1 avalon, so i havent mined in a long ass time |
|
|
|
|
SHORT SELL THAT PRICE ASAP
|
|
|
|
Hy, i setup a node on my server but i become no shares 2013-10-25 22:40:36.266435 P2Pool: 17310 shares in chain (8866 verified/17314 total) Peers: 6 (0 incoming)
2013-10-25 22:40:36.266739 Local: 1395MH/s in last 10.0 minutes Local dead on arrival: ~1.5% (0-5%) Expected time to share: 5.5 days
2013-10-25 22:40:36.266872 Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: 0.0000 BTC
2013-10-25 22:40:36.267438 Pool: 27516GH/s Stale rate: 16.1% Expected time to block: 11.6 hours
What is wrong here? And, how can i fix this error: 2013-10-25 23:14:38.767354 New work for worker! Difficulty: 0.999985 Share difficulty: 148533.577062 Total block value: 25.048938 BTC including 189 transactions
2013-10-25 23:14:40.574594 > in handle_share_hashes:
2013-10-25 23:14:40.574763 > Traceback (most recent call last):
2013-10-25 23:14:40.574829 > Failure: twisted.internet.defer.TimeoutError: in GenericDeferrer
2013-10-25 23:14:40.576598 Lost peer 46.127.137.233:9333 - Connection was aborted locally, using.
2013-10-25 23:14:40.576820 > in download_shares:
2013-10-25 23:14:40.576888 > Traceback (most recent call last):
2013-10-25 23:14:40.576952 > Failure: twisted.internet.error.ConnectionAborted: Connection was aborted locally, using.
2013-10-25 23:14:40.577275 Requesting parent share 36b4bdfb from 37.200.67.186:9333
2013-10-25 23:14:40.766768 Processing 16 shares from 37.200.67.186:9333...
2013-10-25 23:14:41.380464 > Error while processing Event callbacks:
2013-10-25 23:14:41.380622 > Traceback (most recent call last):
2013-10-25 23:14:41.380684 > File "/opt/bitcoin/p2pool-master/p2pool/node.py", line 135, in download_shares
2013-10-25 23:14:41.380743 > self.handle_shares([(share, []) for share in shares], peer)
2013-10-25 23:14:41.380802 > File "/opt/bitcoin/p2pool-master/p2pool/node.py", line 48, in handle_shares
2013-10-25 23:14:41.380859 > self.node.set_best_share()
2013-10-25 23:14:41.380915 > File "/opt/bitcoin/p2pool-master/p2pool/node.py", line 297, in set_best_share
2013-10-25 23:14:41.380973 > self.best_share_var.set(best)
2013-10-25 23:14:41.381251 > File "/opt/bitcoin/p2pool-master/p2pool/util/variable.py", line 74, in set
2013-10-25 23:14:41.381311 > self.changed.happened(value)
2013-10-25 23:14:41.381367 > --- <exception caught here> ---
2013-10-25 23:14:41.381423 > File "/opt/bitcoin/p2pool-master/p2pool/util/variable.py", line 42, in happened
2013-10-25 23:14:41.381517 > func(*event)
2013-10-25 23:14:41.381574 > File "/opt/bitcoin/p2pool-master/p2pool/node.py", line 96, in broadcast_share
2013-10-25 23:14:41.381632 > peer.sendShares([share for share in shares if share.peer_addr != peer.addr], self.node.tracker, self.node.known_txs_var.value, include_txs_with=[share_hash])
2013-10-25 23:14:41.381692 > File "/opt/bitcoin/p2pool-master/p2pool/p2p.py", line 291, in sendShares
2013-10-25 23:14:41.381749 > assert tx_hash in known_txs, 'tried to broadcast share without knowing all its new transactions'
2013-10-25 23:14:41.381806 > exceptions.AssertionError: tried to broadcast share without knowing all its new transactions
2013-10-25 23:14:42.451184 New work for worker! Difficulty: 0.999985 Share difficulty: 141878.358327 Total block value: 25.048938 BTC including 189 transactions
2013-10-25 23:14:42.452693 ... done processing 16 shares. New: 16 Have: 17485/~17280 I dunno really about the error, except it sounds like it'd fix itself... you were still processing the most recent shares, or so it says 1.4ghash isn't much... you can see it says expected time to share: 5.5 days.... so about 15% chance each day to get a share Thanks, but I'm looking for merge mining p2pools. waste of resources, |
|
|
|
oh, re: the stuff I said earlier 2013-10-28 23:47:36 received block 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa
2013-10-28 23:47:36 Committing 6844 changed transactions to coin database...
2013-10-28 23:47:36 SetBestChain: new best=000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa height=266620 log2_work=73.28903 tx=26163172 date=2013-10-28 23:47:57 progress=1.000002
2013-10-28 23:47:36 ProcessBlock: ACCEPTED
2013-10-28 23:47:36 getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 limit 500
2013-10-28 23:47:36 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:36 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266618 to 00000000000000095f2b79ac211d800ca268f58d2429b049d2fd64e68ba8db3c limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:37 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:38 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
2013-10-28 23:47:39 getblocks 266619 to 000000000000000177422a58c0204921623eaff044b88d8a0dc4eeeb1e133cfa limit 500
another nice example, when one checks block 266619 normally you'd just get some getblocks -1 to 0000000000000000000000000000000000000000000000000000000000000000 in there, not all the requests for block 266619 and 266620 (and in some cases 266618, 266619, and 266620) needs changing on handling of block requests i would think |
|
|
|
Whats a spying node?
Are you suggesting that bitcoin nodes exist solely to watch the blockchain? To watch transactions as they occur?
They may, BC.i runs nodes that do this. I've seen other aggressive connectors in the past, and surveillance is one of the possible explanations for them but for most of them it's impossible to know for sure. There are more benign explanations though. For example, some people erroneously believe that connecting to large numbers of nodes is in their interest e.g. they're miners and they think it will improve their block propagation, in fact because the relaying is sequential it generally tends to hurt your block propagation to do this... and they go around addnode=ing hundreds of nodes. I've spent a fair amount of time trying to figure out how the network can discourage this kind of behavior and don't have any great general solutions. So far the best I can do is prevent mass-connectors from DOSing the whole network. For anti-spying the best I can suggest right now is moving your nodes behind tor. Well, this leads to something interesting, I guess. I usually run with ~500 peers connected & I noticed all those eth zurich nodes, so I did a bitcoind addnode on all 31 of them. After that, I noticed I started getting quite a few block orphans.... re: I'd never receive block 1.. I'd end up getting block 2 and block 3, before finally getting sent block 1. This hasn't been a problem since I firewalled 129.132.0.0. If you look at blockchain.info, you'll notice that on a lot of these blocks "discovered" by 129.132.x.x, they'll propagate quite slowly. I put one example here:  block 266494, zero transactions, 2.6kb is size... this is 2m after block was first seen. I've never spent much time looking at the code, but my guess is that nodes request the block from them & they answer this request but never send the block? I guess I could *also* note that when I had all 31 as peers, I never received a block from any of them. (ed: not a huge impact on the major pools, since they're all pretty much linked, but I guess a solo miner might get dinged) |
|
|
|
I was having some, err, issues, and had to take the pool down. If it was more active, I'd put it back up, but only a couple of people were using it at this point, anyway. Anyway, due to lack of warning and what not, and because I'm a nice guy  ... I'll take the payout from the last block found (removed myself): QRPFckhPyhs3npbNL5vNyED9sioGJCUeYL: 0.06634 QM3vc2GnZ37TsqN791Qeg3bt37wrTXghs7: 0.16007 QNYyRMETQz5uV9xCC2QM3BhRjxpzbh7R3y: 1.54193 Qe3eZL6TTBNNbwMtfgDYPhZwpyKJ1zRf3L: 1.96433 Qbfz1htJ4Ykh8nco66joxnTSWnt8xLLPmw: 2.29055 Qa4gRRhbDD3aB85L6Er5kWKhJ9JxGiHPn1: 5.37003 QXhMSKx4ahbpj7M5APh6SoBjtmssR9HuEW: 10.3912 Qj2gPtBJgNDbKrzsJUA13TnFxqvpuxhrfq: 99.09948 and send 3x that amount to each of those addresses sometime when I get time in the next day or two... (as shutting down essentially robbed you of shares from the last 24hrs or so) |
|
|
|
Is there some purpose to these nodes? They all connect within a few seconds of me restarting bitcoind & appear to do absolutely nothing {
"addr" : "176.9.144.41:15326",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839970,
"bytessent" : 155341,
"bytesrecv" : 1843,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "5.9.245.121:37328",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "5.9.30.207:37102",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "5.9.203.20:20099",
"services" : "00000001",
"lastsend" : 1382839968,
"lastrecv" : 1382839968,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "144.76.102.176:22515",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 155341,
"bytesrecv" : 1843,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "5.9.110.78:60995",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 155341,
"bytesrecv" : 1843,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "144.76.136.138:40528",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "144.76.70.73:51414",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "46.4.64.21:45435",
"services" : "00000001",
"lastsend" : 1382839969,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "88.198.41.74:29099",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839970,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "91.121.58.230:49681",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839969,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
{
"addr" : "199.193.117.231:23601",
"services" : "00000001",
"lastsend" : 1382839970,
"lastrecv" : 1382839970,
"bytessent" : 1916,
"bytesrecv" : 1782,
"conntime" : 1382838949,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 1,
"banscore" : 0
},
|
|
|
|
|
In my log file I'll occasionally get something like this:
log:2013-10-26 08:42:53.003554 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.015818 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.029308 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.038270 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.293668 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.307047 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.321228 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.355749 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.587437 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:42:53.603913 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
p2pool has been up for 12 days.
I'm positive that it's just happening for one person & doesn't occur all that often
right now, it's at:
log:2013-10-26 08:58:10.006940 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:58:10.017284 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:58:10.028608 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:59:11.588038 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 08:59:11.601600 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
log:2013-10-26 09:00:12.743830 > Couldn't link returned work's merkle root with its handler. This should only happen if this process was recently restarted!
with no other errors in the past 5 minutes or so (during that time the miner I'm referring to had a hashrate swing of about 15ghash/s right when it started & then gradually increasing back to the norm). The messages lasted from about 08:42:30 'til that last one at 09:00.
I'm guessing this is something related to the equipment being used to mine and not something locally on my p2pool?
Anyone else seen this? Any setting or something I can change locally to make it not happen or happen less frequently?... or is it something that is totally out of my control?
|
|
|
|
A last question  What happens if some of the manually added nodes become not available? They just don't get added. I think it tries a max # of times based on the setting in p2p.py |
|
|
|
Just a quick update on my 10GH processing via P2pool with my BE. I guess Ive been lucky as everything has always worked perfect for me on P2Pool, until this last difficulty rise. I used to get payouts in virtually every new block found. Ive been told by respected members of the forum I will still get my fair payout, and so I am continuing to processes via P2Pool even though I have not had a payout in around four solid days. I trust the members that have given me this advise. I will ofc feel happy when I see a payment again....... ty all again.
UPDATE After around 1 week of solid processing at 10 gh/s via p2pool network I received 0.00337845 BTC; after missing 16 block payouts in a row. I'm sorry to say this can't be giving me my fair share for my work done on the p2pool network so I have moved off it. it isn't giving you your fair share if you are mining at something like p2pool.org |
|
|
|
ETH Zürich has some guys researching Bitcoin.
yes, just like with the node that didnt verify blocks ed: i did addnode on the 31 i know about about 30m before I posted that, since they were showing up pretty late on the block propagation charts on blockchain.info {
"addr" : "129.132.230.70",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 5190397,
"bytesrecv" : 1050137,
"conntime" : 1382655549,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.75",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694502,
"bytessent" : 8231722,
"bytesrecv" : 1047979,
"conntime" : 1382655557,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.73",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694497,
"bytessent" : 3397740,
"bytesrecv" : 1030244,
"conntime" : 1382655559,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.71",
"services" : "00000001",
"lastsend" : 1382694503,
"lastrecv" : 1382694497,
"bytessent" : 5937946,
"bytesrecv" : 1032114,
"conntime" : 1382655572,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.72",
"services" : "00000001",
"lastsend" : 1382694503,
"lastrecv" : 1382694499,
"bytessent" : 5789238,
"bytesrecv" : 1044581,
"conntime" : 1382655580,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.74",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 5528807,
"bytesrecv" : 1024535,
"conntime" : 1382655581,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.76",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694497,
"bytessent" : 7259878,
"bytesrecv" : 1026325,
"conntime" : 1382655583,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265839,
"banscore" : 0
},
{
"addr" : "129.132.230.77",
"services" : "00000001",
"lastsend" : 1382694503,
"lastrecv" : 1382694502,
"bytessent" : 7164951,
"bytesrecv" : 1054956,
"conntime" : 1382655585,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.78",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694500,
"bytessent" : 7033160,
"bytesrecv" : 1057455,
"conntime" : 1382655586,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.79",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 7762812,
"bytesrecv" : 1054750,
"conntime" : 1382655588,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.80",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 5631047,
"bytesrecv" : 1036927,
"conntime" : 1382655591,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.81",
"services" : "00000001",
"lastsend" : 1382694503,
"lastrecv" : 1382694499,
"bytessent" : 6531105,
"bytesrecv" : 1028454,
"conntime" : 1382655788,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.82",
"services" : "00000001",
"lastsend" : 1382694500,
"lastrecv" : 1382694501,
"bytessent" : 7684608,
"bytesrecv" : 1047876,
"conntime" : 1382655788,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.83",
"services" : "00000001",
"lastsend" : 1382694503,
"lastrecv" : 1382694501,
"bytessent" : 633808,
"bytesrecv" : 860529,
"conntime" : 1382655788,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.84",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694498,
"bytessent" : 6493116,
"bytesrecv" : 1019175,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.85",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694496,
"bytessent" : 7309569,
"bytesrecv" : 1035387,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.86",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 6275205,
"bytesrecv" : 1053915,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.87",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694498,
"bytessent" : 6141238,
"bytesrecv" : 1029365,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.88",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 4826677,
"bytesrecv" : 1049668,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.89",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694498,
"bytessent" : 4583074,
"bytesrecv" : 1020827,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.90",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 5577976,
"bytesrecv" : 1002644,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.91",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694500,
"bytessent" : 7511889,
"bytesrecv" : 1058499,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.92",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694498,
"bytessent" : 4798618,
"bytesrecv" : 1027198,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.93",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 6760987,
"bytesrecv" : 1017669,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.94",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 4894180,
"bytesrecv" : 1060215,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.95",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694498,
"bytessent" : 5966016,
"bytesrecv" : 1041092,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.96",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694500,
"bytessent" : 3915213,
"bytesrecv" : 1030510,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.97",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694502,
"bytessent" : 6033589,
"bytesrecv" : 1039128,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.98",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694502,
"bytessent" : 6909276,
"bytesrecv" : 951783,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.99",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694502,
"bytessent" : 7378810,
"bytesrecv" : 1045283,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.100",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 6404674,
"bytesrecv" : 1060138,
"conntime" : 1382655789,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : false,
"startingheight" : 265840,
"banscore" : 0
},
{
"addr" : "129.132.230.72:50373",
"services" : "00000001",
"lastsend" : 1382694502,
"lastrecv" : 1382694499,
"bytessent" : 704308,
"bytesrecv" : 721208,
"conntime" : 1382657820,
"version" : 70001,
"subver" : "/Satoshi:0.8.99/",
"inbound" : true,
"startingheight" : 265844,
"banscore" : 0
}fun times, a couple may be missing by now & I noticed that one is incoming |
|
|
|
Okay I changed a little bit my configuration. It will load on next restart What is the right configuration for several nodes? --p2pool-node x.x.x.x:1234,y.y.y.y:1234, etc. or --p2pool-node x.x.x.x:1234 --p2pool-nodey.y.y.y:1234 --p2pool-node etc. second one is correct, though the port only needs to be entered if it's not standard if you are in germany then go to www.nogleg.com:9332/pings, they should be similar. ofc there are some you may want to keep even at 250ms -- nodes hashing at high speeds, or if you don't have any other node in Asia etc |
|
|
|
|
Are there any of these that charge a listing fee? The whole +0.00000000001 stuff over and over gets annoying when I don't have it automated, like the other 3 or 4 people.
|
|
|
|
|
eh, that's a lot of swiss nodes
129.132.230.70 8333 168.27 CH (Zurich) vbitcoin-01.inf.ethz.ch
129.132.230.74 45606 191.75 CH (Zurich) vbitcoin-05.inf.ethz.ch
129.132.230.77 55486 51.60 CH (Zurich) vbitcoin-08.inf.ethz.ch
129.132.230.78 37142 80.95 CH (Zurich) vbitcoin-09.inf.ethz.ch
129.132.230.79 53164 59.93 CH (Zurich) vbitcoin-0a.inf.ethz.ch
129.132.230.81 60287 15.05 CH (Zurich) vbitcoin-0c.inf.ethz.ch
129.132.230.83 55054 43.25 CH (Zurich) vbitcoin-0e.inf.ethz.ch
129.132.230.84 46816 32.85 CH (Zurich) vbitcoin-0f.inf.ethz.ch
129.132.230.85 46846 30.87 CH (Zurich) vbitcoin-10.inf.ethz.ch
129.132.230.86 56112 34.03 CH (Zurich) vbitcoin-11.inf.ethz.ch
129.132.230.87 52520 26.70 CH (Zurich) vbitcoin-12.inf.ethz.ch
129.132.230.88 34230 145.58 CH (Zurich) vbitcoin-13.inf.ethz.ch
129.132.230.89 33692 2.12 CH (Zurich) vbitcoin-14.inf.ethz.ch
129.132.230.91 50123 64.12 CH (Zurich) vbitcoin-16.inf.ethz.ch
129.132.230.92 48314 22.68 CH (Zurich) vbitcoin-17.inf.ethz.ch
129.132.230.93 38011 189.43 CH (Zurich) vbitcoin-18.inf.ethz.ch
129.132.230.95 35183 69.72 CH (Zurich) vbitcoin-1a.inf.ethz.ch
129.132.230.97 39092 24.58 CH (Zurich) vbitcoin-1c.inf.ethz.ch
129.132.230.98 48489 8.93 CH (Zurich) vbitcoin-1d.inf.ethz.ch
129.132.230.99 57714 13.55 CH (Zurich) vbitcoin-1e.inf.ethz.ch
|
|
|
|
how can i raise my connections? all ports are open
there was a little maintenance today so i had to restart p2pool.
Maybe the connections will raise if p2pool stays longer online?
well, despite what someone else might tell you , it's better to set a few yourself. if bandwidth was a problem, you could eliminate the random outgoing connections altogether by changing that to 0. if it's not a problem, you should retain at least some of those. use the --p2pool-node toggle to add some specific pools. they don't count as part of your 'outgoing pools' amt... so if you had it set for 4 outgoing pools & added 6 more via --p2pool-node (that were up and working), you'd have 10 outgoing connections. the default 40 incoming connections is too much, you should lower than to ~20, esp with the additional outgoing connections if you rely on random connects, you'll get unlucky sometimes and get stuff like that, w/ many having high latency. i've been connected to one before that was 2000ms+ |
|
|
|
let's hope they come from here http://p2pool.org:9332/static/is that the pool op doing all that mining? or are people just giving him away money for 80% efficiency?... and it's been like this for half a year or longer.. how bizarre oh.. if you keep mining with just these connections: {"188.227.176.66:9333": 231.96005821228027, "94.242.205.6:40173": 159.54113006591797, "185.9.34.66:9333": 24.988174438476562, "46.170.233.26:9333": 44.91591453552246, "67.18.176.77:9333": 122.69306182861328, "84.75.252.230:9333": 429.15916442871094, "72.201.24.106:9333": 183.8970184326172, "75.151.76.105:9333": 248.20399284362793} you will get many orphans |
|
|
|
Once I give him/her my bitcoins, I am now able to see how much he/she has in that particular wallet
No. You are now able to see how many XBT are on that _address_. Which is why there is a recommendation to always employ a new address for every transaction. Thanks J, that's what I meant, you can now link that person to a specific address (not his entire fortune, just that specific address), and now see what he does with that money. Even if he's going to use different wallets to do different things, at some point he will use that money.. Let's imagine I give to a friend 1BTC because he sold to me his old laptop.. now there are two possibilities: 1. he will never mix the money in that wallet with the other BTC he has, but he will spend it someway and I will be able to see where the money goes.. 2. he will mix that coin with other he already has (maybe to buy something more expensive than 1BTC) in a transaction.. now I am able not only to see where those bitcoins went, but also to link other address(es) to him and see where he got that money from, how much money he had in that address, other expenditures he had, etc. Sure you can use a different address for each payment (ok, not so sure, read below) but at least I will be able to see where the money I sent goes. On a larger scale, this will be an issue also when/if a company pays the salary to an employee in bitcoins.. they will be able to monitor his transactions. Maybe he will use a different address each month, but the point is the same! Last point, we can expect a person with an average/good computer knowledge to take precautions like changing address for every transaction, not from everyone. And my point is exactly that I see this as a possible obstacle to a larger adoption of Bitcoin. What I want to understand is if this is a known issue which has been already addressed by the guys working on the protocol or by some kind of software.. I hope my thoughts are clearly explained! Thanks for your comments and help! i can't think of anyone that I know personally that cares too much about the anonymity of bitcoin. why would your average joe that knows very little about computers care about this? we can assume he's not mining bitcoins or anything like that, so it wouldnt be for purposes of evading income taxes. maybe purchasing drugs or firearms or something? |
|
|
|
|
fees have been mandatory for a very long time except for 'priority' transactions when block is < 27000 bytes.
these still exist
if you're trying to send some amount below a certain threshold it's doubtful any mining pool would ever pick it up, so you still wouldnt be able to send it. maybe run your own p2pool or something
|
|
|
|
|
Show Posts
