Bitcoin Forum
June 24, 2019, 02:32:07 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2578981 times)
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 26, 2012, 12:37:46 PM
 #4241

i'm at 188 shares and 1 orphan now, after modifying source to allow more outgoing connections
u see Wink i just improved ur mining alot Cheesy
Well, now I'm at 20 shares and 3 orphans.  Not a huge sample, but..

my conclusion would be that the initial outgoing # is too low.  10 as max is also too low.  you should be able to set it up to 20-30.

but, most orphans come from the size of the blocks.  i did ~250 shares with 2 orphans with a maxblocksize of 10000, essentially making blocks of 5 or 6 transactions... later on I changed that to nothing, so all blocks had just 1 transaction.   that also lowered the "GetBlockTemplate Latency" to a couple milliseconds, as can be seen at:  http://nogleg.com:9332/static/graphs.html?Day

Now I've set it back to a 500kB max block size and am at that 20 blocks w/ 3 orphans.  My GetBlockTemplate latency has also increased, though tbh, I don't find that very relevant.  It's a good diagnostic for spotting out possible issues, like if you have maxblocksize set to 0 and it's taking half a second, then that's a problem, I guess.

That 1/4th or 1/3rd of a second later may matter in 1 out of 500 orphans.  The bigger issue would be network slowness & latency.  A bigger problem for p2pool than the network as a whole, since most pools will be run on dedicated servers on good networks.  p2pool is different, because it has all these people mining w/ many of them on crap connections.  For me to make the most bitcoins, then I should make all blocks with 0 transactions, to limit orphans.  

my block solved w/ maxblocksize of 10000:  http://blockchain.info/tx/971d3109bdc197d1bb8d1334896db2235941b1da884081dee9e94df666a37e84

i doubt getting 25.5 instead of 25.01 would make up for all the extra orphans that are caused by having transactions included (in p2pool)

It seems to me like if you're keen on p2pool, you'd be better off running a private network with a select group of people, rather than losing 5, 10, or 15% of your hashing power due to people with poor connections... or else just set your maxblocksize to 0.  

ps:  i'm changing my maxblocksize back to 0

1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
1561386727
Hero Member
*
Offline Offline

Posts: 1561386727

View Profile Personal Message (Offline)

Ignore
1561386727
Reply with quote  #2

1561386727
Report to moderator
Krak
Hero Member
*****
Offline Offline

Activity: 591
Merit: 500



View Profile WWW
December 26, 2012, 05:35:27 PM
 #4242

my conclusion would be that the initial outgoing # is too low.  10 as max is also too low.  you should be able to set it up to 20-30.
You can already set this with a command line flag (--outgoing-conns). The default shouldn't be raised because with a slow DSL connection, 6 is already pushing it.

ps:  i'm changing my maxblocksize back to 0
This is extremely bad for the network in general and overall unnecessary with transaction pre-forwarding. Seriously, p2pool has had only one orphan in the last 3 months. That's pretty good.

BTC: 1KrakenLFEFg33A4f6xpwgv3UUoxrLPuGn
K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
December 26, 2012, 05:54:44 PM
 #4243

i'm at 188 shares and 1 orphan now, after modifying source to allow more outgoing connections
u see Wink i just improved ur mining alot Cheesy
Well, now I'm at 20 shares and 3 orphans.  Not a huge sample, but..

my conclusion would be that the initial outgoing # is too low.  10 as max is also too low.  you should be able to set it up to 20-30.

but, most orphans come from the size of the blocks.  i did ~250 shares with 2 orphans with a maxblocksize of 10000, essentially making blocks of 5 or 6 transactions... later on I changed that to nothing, so all blocks had just 1 transaction.   that also lowered the "GetBlockTemplate Latency" to a couple milliseconds, as can be seen at:  http://nogleg.com:9332/static/graphs.html?Day

Now I've set it back to a 500kB max block size and am at that 20 blocks w/ 3 orphans.  My GetBlockTemplate latency has also increased, though tbh, I don't find that very relevant.  It's a good diagnostic for spotting out possible issues, like if you have maxblocksize set to 0 and it's taking half a second, then that's a problem, I guess.

That 1/4th or 1/3rd of a second later may matter in 1 out of 500 orphans.  The bigger issue would be network slowness & latency.  A bigger problem for p2pool than the network as a whole, since most pools will be run on dedicated servers on good networks.  p2pool is different, because it has all these people mining w/ many of them on crap connections.  For me to make the most bitcoins, then I should make all blocks with 0 transactions, to limit orphans.  

my block solved w/ maxblocksize of 10000:  http://blockchain.info/tx/971d3109bdc197d1bb8d1334896db2235941b1da884081dee9e94df666a37e84

i doubt getting 25.5 instead of 25.01 would make up for all the extra orphans that are caused by having transactions included (in p2pool)

It seems to me like if you're keen on p2pool, you'd be better off running a private network with a select group of people, rather than losing 5, 10, or 15% of your hashing power due to people with poor connections... or else just set your maxblocksize to 0.  

ps:  i'm changing my maxblocksize back to 0
it depends how "good" the network is, for example:
BTC -> 25 connections are good (0% stale so far for me)
LTC -> 50 connections to get 70 submited, 6 stale (needs more connections).

The Coin got 2 sides, the more connection the more broadcast so send/validate/calc. This may lead to more DOA. so dont use astronomical numbers.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
Schleicher
Hero Member
*****
Offline Offline

Activity: 675
Merit: 510



View Profile
December 26, 2012, 06:14:11 PM
 #4244

If the p2pool client is running on your computer at home then the upload speed is probably the bottleneck for most people.
I have 30 KB/s upload speed for example. A 500KB block would need almost 17 seconds to upload. With 10 p2pool connections this would be 170 seconds.

gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
December 26, 2012, 07:35:15 PM
 #4245

If the p2pool client is running on your computer at home then the upload speed is probably the bottleneck for most people.
I have 30 KB/s upload speed for example. A 500KB block would need almost 17 seconds to upload. With 10 p2pool connections this would be 170 seconds.
I believe p2pool doesn't transfer all the block's content: IIRC transactions are preemptively exchanged between nodes before a block is found and only a shorter representation of the block with references to these transactions should be transfered.

P2pool tuning guide
Trade BTC for €/$ at bitcoin.de (referral), it's cheaper and faster (acts as escrow and lets the buyers do bank transfers).
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 27, 2012, 12:47:15 AM
 #4246

If the p2pool client is running on your computer at home then the upload speed is probably the bottleneck for most people.
I have 30 KB/s upload speed for example. A 500KB block would need almost 17 seconds to upload. With 10 p2pool connections this would be 170 seconds.
I believe p2pool doesn't transfer all the block's content: IIRC transactions are preemptively exchanged between nodes before a block is found and only a shorter representation of the block with references to these transactions should be transfered.
It may not transfer the whole thing, but from my experience w/ the larger block sizes, you get tons more orphans.  

I wish it showed local orphans/DOA on the graphs so that it could be analyzed more quickly..  

I'll dig through my logs later and check the orphan amts compared to block size sometime in the next few days...

I do see the reasoning behind the lower amt of outgoing connections though, it does make sense... since not everyone will be on a dedicated server like a 'pool'.   I still think it'd be nice if it were configurable up to 30 instead of maxing out at 10, though....  I believe the # of incoming connections is default capped at 30?  That should probably be lower, actually..

and I've solved two blocks out of equiv of 200,000 difficulty 1 shares so far....  -48 btc....  sadface

spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
December 27, 2012, 09:05:29 AM
 #4247

ps:  i'm changing my maxblocksize back to 0

please don't, this way you're not processing transactions which is the whole meaning of mining.

give blockmaxsize a low value, like 8kB, so that it does not create too many orphans but still processes transactions.

Btw, orphans that solve a block are as good as any other share you submit.

my 2c

spiccioli
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 27, 2012, 01:24:59 PM
Last edit: December 27, 2012, 01:42:58 PM by zvs
 #4248

ps:  i'm changing my maxblocksize back to 0

please don't, this way you're not processing transactions which is the whole meaning of mining.

give blockmaxsize a low value, like 8kB, so that it does not create too many orphans but still processes transactions.

Btw, orphans that solve a block are as good as any other share you submit.

my 2c

spiccioli

Version: 9.4-22-g9f125de-dirty

Pool rate: 309GH/s (11% DOA+orphan) Share difficulty: 594

Node uptime: 0.108 days Peers: 30 out, 4 in

Local rate: 7.74GH/s (7.2% DOA) Expected time to share: 0.0917 hours

Shares: 31 total (28 orphaned, 3 dead) Efficiency: 0.000%

Payout if a block were found NOW: 0.49253475 BTC to 1Zevusze7BjTpp4srJhx4zkRBxpbgwU4A. Expected after mining for 24 hours: 0.664 BTC

Current block value: 26.55448192 BTC Expected time to block: 11.5 hours


that's fancy

i'm guessing it's because the size of my blocks are too large?  it looks like it's running 900KB atm.



ok, back to 0, heh...


2012-12-27 07:41:57.626431  Shares: 32 (29 orphan, 3 dead) Stale rate: ~100.0% (89-100%) Efficiency: ~0.0% (0-13%) Current payout: 0.4531 BTC
2012-12-27 07:41:57.626457  Pool: 318GH/s Stale rate: 14.9% Expected time to block: 11.2 hours
2012-12-27 07:41:58.047236 New work for worker! Difficulty: 1.792246 Share difficulty: 651.157952 Total block value: 25.000000 BTC including 0 transactions
2012-12-27 07:41:59.128533 GOT SHARE!  6671a2fe prev 0c4a8330 age 1.52s
2012-12-27 07:41:59.167586 New work for worker! Difficulty: 1.776695 Share difficulty: 645.238513 Total block value: 25.000000 BTC including 0 transactions
2012-12-27 07:41:59.176192 New work for worker! Difficulty: 1.776695 Share difficulty: 645.238513 Total block value: 25.000000 BTC including 0 transactions
2012-12-27 07:41:59.591497 New work for worker! Difficulty: 1.826294 Share difficulty: 645.238513 Total block value: 25.000000 BTC including 0 transactions
2012-12-27 07:42:00.638139 P2Pool: 17312 shares in chain (17317 verified/17317 total) Peers: 34 (4 incoming)
2012-12-27 07:42:00.638220  Local: 7367MH/s in last 10.0 minutes Local dead on arrival: ~5.9% (4-9%) Expected time to share: 6.3 minutes
2012-12-27 07:42:00.638246  Shares: 33 (29 orphan, 3 dead) Stale rate: ~97.0% (84-100%) Efficiency: ~3.6% (0-19%) Current payout: 0.4559 BTC

spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
December 27, 2012, 01:32:51 PM
 #4249


ok, back to 0, heh

zvs,

would you mind trying this in you bitcoin.conf?

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

This way you're mining blocks of 32kB max, you can also lower it till you find a good spot, but this way you're still helping the BTC network. Smiley

spiccioli

spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
December 27, 2012, 01:45:54 PM
Last edit: December 27, 2012, 02:42:09 PM by spiccioli
 #4250

BTW,

how much does merged mining influences orphans/DOAs?

If typical p2pool user has a low bandwidth connection (upstream), sharing it with serveral chains does slow them all, doesn't it?

spiccioli

zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 27, 2012, 01:51:06 PM
 #4251


ok, back to 0, heh

zvs,

would you mind trying this in you bitcoin.conf?

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

This way you're mining blocks of 32kB max, you can also lower it till you find a good spot, but this way you're still helping the BTC network. Smiley

spiccioli



would this do it?

        past_shares = list(tracker.get_chain(share_data['previous_share_hash'], min(height, 100)))
        tx_hash_to_this = {}
        for i, share in enumerate(past_shares):
            for j, tx_hash in enumerate(share.new_transaction_hashes):
                if tx_hash not in tx_hash_to_this:
                    tx_hash_to_this[tx_hash] = [1+i, j] # share_count, tx_count
        for tx_hash, fee in desired_other_transaction_hashes_and_fees:
            if tx_hash in tx_hash_to_this:
                this = tx_hash_to_this[tx_hash]
            else:
                if known_txs is not None:
                    this_size = bitcoin_data.tx_type.packed_size(known_txs[tx_hash])
                    if new_transaction_size + this_size > 50000: # only allow 50 kB of new txns/share
                        break
                    new_transaction_size += this_size
                new_transaction_hashes.append(tx_hash)
                this = [0, len(new_transaction_hashes)-1]
            transaction_hash_refs.extend(this)
            other_transaction_hashes.append(tx_hash)


anyway, ok, i'll set it to 50000

i haven't been running merged mining, unfortunately.. i would have liked to have the 100 namecoins

merged mining would cause more DOAs, I'd think....  because you'd have to be running namecoind, ixcoind, whatever else on the same machine as bitcoind...

K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
December 27, 2012, 08:18:00 PM
 #4252


ok, back to 0, heh

zvs,

would you mind trying this in you bitcoin.conf?

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

This way you're mining blocks of 32kB max, you can also lower it till you find a good spot, but this way you're still helping the BTC network. Smiley

spiccioli



would this do it?

        past_shares = list(tracker.get_chain(share_data['previous_share_hash'], min(height, 100)))
        tx_hash_to_this = {}
        for i, share in enumerate(past_shares):
            for j, tx_hash in enumerate(share.new_transaction_hashes):
                if tx_hash not in tx_hash_to_this:
                    tx_hash_to_this[tx_hash] = [1+i, j] # share_count, tx_count
        for tx_hash, fee in desired_other_transaction_hashes_and_fees:
            if tx_hash in tx_hash_to_this:
                this = tx_hash_to_this[tx_hash]
            else:
                if known_txs is not None:
                    this_size = bitcoin_data.tx_type.packed_size(known_txs[tx_hash])
                    if new_transaction_size + this_size > 50000: # only allow 50 kB of new txns/share
                        break
                    new_transaction_size += this_size
                new_transaction_hashes.append(tx_hash)
                this = [0, len(new_transaction_hashes)-1]
            transaction_hash_refs.extend(this)
            other_transaction_hashes.append(tx_hash)


anyway, ok, i'll set it to 50000

i haven't been running merged mining, unfortunately.. i would have liked to have the 100 namecoins

merged mining would cause more DOAs, I'd think....  because you'd have to be running namecoind, ixcoind, whatever else on the same machine as bitcoind...

No, MM is solo Mode and dosnt add Orphans/DOAs.
If you find a share who is higher or equal the diff of the MM AltChains youl simply submit a block to your local daemon (namecoind here) and thats it, only BTC mining is being p2p, MM is solomode.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 28, 2012, 12:58:00 AM
 #4253


ok, back to 0, heh

zvs,

would you mind trying this in you bitcoin.conf?

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

This way you're mining blocks of 32kB max, you can also lower it till you find a good spot, but this way you're still helping the BTC network. Smiley

spiccioli



would this do it?

        past_shares = list(tracker.get_chain(share_data['previous_share_hash'], min(height, 100)))
        tx_hash_to_this = {}
        for i, share in enumerate(past_shares):
            for j, tx_hash in enumerate(share.new_transaction_hashes):
                if tx_hash not in tx_hash_to_this:
                    tx_hash_to_this[tx_hash] = [1+i, j] # share_count, tx_count
        for tx_hash, fee in desired_other_transaction_hashes_and_fees:
            if tx_hash in tx_hash_to_this:
                this = tx_hash_to_this[tx_hash]
            else:
                if known_txs is not None:
                    this_size = bitcoin_data.tx_type.packed_size(known_txs[tx_hash])
                    if new_transaction_size + this_size > 50000: # only allow 50 kB of new txns/share
                        break
                    new_transaction_size += this_size
                new_transaction_hashes.append(tx_hash)
                this = [0, len(new_transaction_hashes)-1]
            transaction_hash_refs.extend(this)
            other_transaction_hashes.append(tx_hash)


anyway, ok, i'll set it to 50000

i haven't been running merged mining, unfortunately.. i would have liked to have the 100 namecoins

merged mining would cause more DOAs, I'd think....  because you'd have to be running namecoind, ixcoind, whatever else on the same machine as bitcoind...

No, MM is solo Mode and dosnt add Orphans/DOAs.
If you find a share who is higher or equal the diff of the MM AltChains youl simply submit a block to your local daemon (namecoind here) and thats it, only BTC mining is being p2p, MM is solomode.

that's not really true (the part about how it 'doesn't add orphans or DOAs')

people started dropping i0coin because it used so much processing power.   namecoin and ixcoin do as well, to a lesser extent.   if you're dealing with a limited amount of bandwidth, it'll also add to that

there's no question that it'll make your bitcoind function slower, though

spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
December 28, 2012, 07:30:26 AM
 #4254

Apart from this that I repeat here for all p2pool users with a standard ADSL connection

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

I'd like to point out that there are p2pools users using an old version of the client

Code:
2012-12-27 11:05:30.775867 Peer 188.252.14.100:37615 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 11:06:46.966781 Peer 199.241.185.82:34124 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 10:06:29.635862 Peer 38.102.67.75:35397 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 15:08:09.930458 Peer 46.105.236.77:34589 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 15:39:22.661182 Peer 67.5.89.140:35547 misbehaving, will drop and ban. Reason: peer too old
2012-12-28 04:32:45.287181 Peer 68.102.86.156:33805 misbehaving, will drop and ban. Reason: peer too old

Please, update your code! Smiley

spiccioli
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
December 28, 2012, 08:09:35 AM
 #4255

2012-12-27 11:05:30.775867 Peer 188.252.14.100:37615 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 11:06:46.966781 Peer 199.241.185.82:34124 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 10:06:29.635862 Peer 38.102.67.75:35397 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 15:08:09.930458 Peer 46.105.236.77:34589 misbehaving, will drop and ban. Reason: peer too old
2012-12-27 15:39:22.661182 Peer 67.5.89.140:35547 misbehaving, will drop and ban. Reason: peer too old
2012-12-28 04:32:45.287181 Peer 68.102.86.156:33805 misbehaving, will drop and ban. Reason: peer too old

LoL, I just checked out one of them:

http://199.241.185.82:9332/static/

you go PoN!

kano
Legendary
*
Offline Offline

Activity: 2856
Merit: 1175


Linux since 1997 RedHat 4


View Profile
December 28, 2012, 09:34:55 AM
 #4256

Apart from this that I repeat here for all p2pool users with a standard ADSL connection

Code:
#Maximum size, in bytes, of blocks you create:
blockmaxsize=32768

#How many bytes of the block should be dedicated to high-priority transactions,
#included regardless of the fees they pay
blockprioritysize=4096

#Minimum block size you want to create; block will be filled with free transactions
#until there are no more or the block reaches this size:
blockminsize=8192

#Fee-per-kilobyte amount (in BTC) considered the same as "free"
#Be careful setting this: if you set it to zero then
#a transaction spammer can cheaply fill blocks using
#1-satoshi-fee transactions. It should be set above the real
#cost to you of processing a transaction.
mintxfee=0.005

...

Please, update your code! Smiley

spiccioli

WTF?

Are you trying to tell everyone that p2pool users are BAD for bitcoin and suggesting they should configure p2pool to be BAD for bitcoin?!?

i.e. if their hardware sux, solve it by restricting BTC block sizes?!?

Sounds like p2pool is a bad idea for bitcoin since people are doing this.

Limiting transaction sizes to 32k means non-p2pool pools are WAY better for bitcoin that p2pool.
I guess everyone now has another reason to avoid p2pool ... with a standard pool we can know what the pool is setting for ALL blocks,
but with p2pool it looks like there are people who are GREATLY restricting the transaction size due to having crappy setups.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
spiccioli
Legendary
*
Offline Offline

Activity: 1377
Merit: 1000

nec sine labore


View Profile
December 28, 2012, 10:23:34 AM
 #4257

WTF?

Are you trying to tell everyone that p2pool users are BAD for bitcoin and suggesting they should configure p2pool to be BAD for bitcoin?!?

i.e. if their hardware sux, solve it by restricting BTC block sizes?!?

Sounds like p2pool is a bad idea for bitcoin since people are doing this.

Limiting transaction sizes to 32k means non-p2pool pools are WAY better for bitcoin that p2pool.
I guess everyone now has another reason to avoid p2pool ... with a standard pool we can know what the pool is setting for ALL blocks,
but with p2pool it looks like there are people who are GREATLY restricting the transaction size due to having crappy setups.

kano,

there are two issues here:

  • users of p2pool with older versions of the client code, these are the ones that need to upgrade
  • users of p2pool which have a standard ADSL and as such need to restrict block size since a 1 MB block that needs to be pushed out through a 64kB ADSL upstream connection can take a long time, even more so if it has to be sent to 50 different nodes.


I don't think that restricting block size is detrimental, I, as a miner, can decide what to include and what not.

I coud, for example, leave unrestricted block size but ask for a 0.01 BTC fee and decide not to process fee-less transactions.

spiccioli

edit: ps. btw, my configuration reserves some space for fee-less transactions and high-priority ones.
kano
Legendary
*
Offline Offline

Activity: 2856
Merit: 1175


Linux since 1997 RedHat 4


View Profile
December 28, 2012, 10:58:21 AM
 #4258

WTF?

Are you trying to tell everyone that p2pool users are BAD for bitcoin and suggesting they should configure p2pool to be BAD for bitcoin?!?

i.e. if their hardware sux, solve it by restricting BTC block sizes?!?

Sounds like p2pool is a bad idea for bitcoin since people are doing this.

Limiting transaction sizes to 32k means non-p2pool pools are WAY better for bitcoin that p2pool.
I guess everyone now has another reason to avoid p2pool ... with a standard pool we can know what the pool is setting for ALL blocks,
but with p2pool it looks like there are people who are GREATLY restricting the transaction size due to having crappy setups.

kano,

there are two issues here:

  • users of p2pool with older versions of the client code, these are the ones that need to upgrade
  • users of p2pool which have a standard ADSL and as such need to restrict block size since a 1 MB block that needs to be pushed out through a 64kB ADSL upstream connection can take a long time, even more so if it has to be sent to 50 different nodes.


I don't think that restricting block size is detrimental, I, as a miner, can decide what to include and what not.

I coud, for example, leave unrestricted block size but ask for a 0.01 BTC fee and decide not to process fee-less transactions.

spiccioli

edit: ps. btw, my configuration reserves some space for fee-less transactions and high-priority ones.

But your restriction says it is better for BTC, for people to mine on any of the big pools like OzCoin, EMC, BTC Guild, etc since they include more transactions in their blocks, and BTC is about committing transactions.

Setting a restriction on transaction size because the pool sux, is not good for BTC it is BAD for BTC.

Luke-Jr did this with Eligius for about 5 or 6 months - his restriction was even worse though, a maximum of 32 transactions per block.

Sorry, there's no argument for doing it other than "I want to be paid more per transaction than the big pools are paid"
There is NO "good for BTC" anywhere in that statement, only "BAD for BTC"

This is again, why I'd like an on-going report about block sizes based on pools - i.e. show which pools are best for BTC - and this argument clearly says p2pool isn't.

Pool: https://kano.is Here on Bitcointalk: Forum BTC: 1KanoPb8cKYqNrswjaA8cRDk4FAS9eDMLU
Discord support invite at https://kano.is/ Majority developer of the ckpool code
Help keep Bitcoin secure by mining on pools with full block verification on all blocks - and NO empty blocks!
K1773R
Legendary
*
Offline Offline

Activity: 1792
Merit: 1008


/dev/null


View Profile
December 28, 2012, 11:08:42 AM
 #4259

WTF?

Are you trying to tell everyone that p2pool users are BAD for bitcoin and suggesting they should configure p2pool to be BAD for bitcoin?!?

i.e. if their hardware sux, solve it by restricting BTC block sizes?!?

Sounds like p2pool is a bad idea for bitcoin since people are doing this.

Limiting transaction sizes to 32k means non-p2pool pools are WAY better for bitcoin that p2pool.
I guess everyone now has another reason to avoid p2pool ... with a standard pool we can know what the pool is setting for ALL blocks,
but with p2pool it looks like there are people who are GREATLY restricting the transaction size due to having crappy setups.

kano,

there are two issues here:

  • users of p2pool with older versions of the client code, these are the ones that need to upgrade
  • users of p2pool which have a standard ADSL and as such need to restrict block size since a 1 MB block that needs to be pushed out through a 64kB ADSL upstream connection can take a long time, even more so if it has to be sent to 50 different nodes.


I don't think that restricting block size is detrimental, I, as a miner, can decide what to include and what not.

I coud, for example, leave unrestricted block size but ask for a 0.01 BTC fee and decide not to process fee-less transactions.

spiccioli

edit: ps. btw, my configuration reserves some space for fee-less transactions and high-priority ones.

But your restriction says it is better for BTC, for people to mine on any of the big pools like OzCoin, EMC, BTC Guild, etc since they include more transactions in their blocks, and BTC is about committing transactions.

Setting a restriction on transaction size because the pool sux, is not good for BTC it is BAD for BTC.

Luke-Jr did this with Eligius for about 5 or 6 months - his restriction was even worse though, a maximum of 32 transactions per block.

Sorry, there's no argument for doing it other than "I want to be paid more per transaction than the big pools are paid"
There is NO "good for BTC" anywhere in that statement, only "BAD for BTC"

This is again, why I'd like an on-going report about block sizes based on pools - i.e. show which pools are best for BTC - and this argument clearly says p2pool isn't.
u get this totaly wrong, some guys did limit it but usualy bitcoind dosnt limit transactions! p2pool itself includes every transactions (even these without fees).
if you would use these bitcoind settings for a centralized pool, the pool would suck too (like Eligius) but this isnt the pools software fault, its the faulty settings u set in ur bitcoind configuration.

[GPG Public Key]  [Devcoin Builds]  [BBQCoin Builds]  [Multichain Blockexplorer]  [Multichain Blockexplorer - PoS Coins]  [Ufasoft Miner Linux Builds]
BTC/DVC/TRC/FRC: 1K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM AK1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: NK1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: LKi773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: EK1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: bK1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
December 28, 2012, 11:14:04 AM
 #4260

kano,

there are two issues here:

  • users of p2pool with older versions of the client code, these are the ones that need to upgrade
  • users of p2pool which have a standard ADSL and as such need to restrict block size since a 1 MB block that needs to be pushed out through a 64kB ADSL upstream connection can take a long time, even more so if it has to be sent to 50 different nodes.


I don't think that restricting block size is detrimental, I, as a miner, can decide what to include and what not.

I coud, for example, leave unrestricted block size but ask for a 0.01 BTC fee and decide not to process fee-less transactions.

spiccioli

edit: ps. btw, my configuration reserves some space for fee-less transactions and high-priority ones.

just fyi, my "standard ADSL" connection has 768k up.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
Pages: « 1 ... 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 [213] 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 ... 814 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!