zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:24:59 PM Last edit: December 27, 2012, 01:42:58 PM by zvs |
|
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
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:32:51 PM |
|
ok, back to 0, heh
zvs, would you mind trying this in you bitcoin.conf? #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](https://bitcointalk.org/Smileys/default/smiley.gif) spiccioli
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:45:54 PM Last edit: December 27, 2012, 02:42:09 PM by spiccioli |
|
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
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 01:51:06 PM |
|
ok, back to 0, heh
zvs, would you mind trying this in you bitcoin.conf? #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](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 27, 2012, 08:18:00 PM |
|
ok, back to 0, heh
zvs, would you mind trying this in you bitcoin.conf? #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](https://bitcointalk.org/Smileys/default/smiley.gif) 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]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 12:58:00 AM |
|
ok, back to 0, heh
zvs, would you mind trying this in you bitcoin.conf? #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](https://bitcointalk.org/Smileys/default/smiley.gif) 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
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 07:30:26 AM |
|
Apart from this that I repeat here for all p2pool users with a standard ADSL connection #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 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](https://bitcointalk.org/Smileys/default/smiley.gif) spiccioli
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 08:09:35 AM |
|
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
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 09:34:55 AM |
|
Apart from this that I repeat here for all p2pool users with a standard ADSL connection #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](https://bitcointalk.org/Smileys/default/smiley.gif) 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.
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 10:23:34 AM |
|
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
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 10:58:21 AM |
|
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.
|
|
|
|
K1773R
Legendary
Offline
Activity: 1792
Merit: 1008
/dev/null
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 11:08:42 AM |
|
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]BTC/DVC/TRC/FRC: 1 K1773RbXRZVRQSSXe9N6N2MUFERvrdu6y ANC/XPM A K1773RTmRKtvbKBCrUu95UQg5iegrqyeA NMC: N K1773Rzv8b4ugmCgX789PbjewA9fL9Dy1 LTC: L Ki773RBuPepQH8E6Zb1ponoCvgbU7hHmd EMC: E K1773RxUes1HX1YAGMZ1xVYBBRUCqfDoF BQC: b K1773R1APJz4yTgRkmdKQhjhiMyQpJgfN
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 11:14:04 AM |
|
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!
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 11:17:16 AM |
|
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 live in a rural area and the best option here until 2 yrs ago was cable that was limited to 256kbps upstream.... that was called the 'business package' actually, if you're trying to sling around 200kb blocks to multiple peers, the best option in that case I guess would be to just eat close to a second of latency from satellite.... well, if you can get satellite i could in texas! (not wireless in this area tho, hah)
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 11:23:08 AM |
|
kano, IMHO the only good thing for bitcoin are: - distribution, p2pool envisions the original idea of a distributed network - fees should in the end replace block reward. mining has different costs in different parts of the world and not everyone can have a T1 at his/her home. So, restricting block size/imposing a fee are legal ways to handle such differences. If a p2pool user has a fiber connection, for example, he could mine a much bigger block. BTW, if you see here http://blockchain.info/blocksyou'll find out that block sizes can be a lot lower than 32 kB even for big pools. spiccioli
|
|
|
|
spiccioli
Legendary
Offline
Activity: 1378
Merit: 1003
nec sine labore
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 11:33:42 AM Last edit: December 28, 2012, 12:17:45 PM by spiccioli |
|
just fyi, my "standard ADSL" connection has 768k up.
M
mdude77, I was talking about 64kB (or 640 kbits ), so it really makes little difference if you have a 200kB block to send around. spiccioli
|
|
|
|
forrestv (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 04:41:11 PM |
|
Complete blocks are never sent over the P2Pool network; the most you should ever have to burst upload when you get a share is ~2kB to every peer. If decreasing the block size helps your stale rate, it's more likely a latency issue within the P2Pool codebase that can be fixed, instead of a result of your internet connection. zvs, what kind of hardware were you running P2Pool on when you got this? 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...
Having every single share orphaned is a sign of bitcoind being broken or some other misconfiguration, not any fixable latency. Did reducing maxblocksize to 0 help? BTW, Stratum support is finished and will be released later today.
|
1J1zegkNSbwX4smvTdoHSanUfwvXFeuV23
|
|
|
rav3n_pl
Legendary
Offline
Activity: 1361
Merit: 1003
Don`t panic! Organize!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 28, 2012, 07:38:03 PM |
|
TRC pool is forked? I`m playing witch some changes in code on windows, and when I delete shares graph shows pool rate as about 600MH then after few minutes drop to less than 200. From my linux node it seems that I`m inly active TRC miner ~150MH + 2 or 3 users that make about 50MH total. I also see total 4-5 nodes tops.
|
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 29, 2012, 03:47:49 AM |
|
BTW, Stratum support is finished and will be released later today.
Great. I just released a new version of cgminer, 2.10.4, as a hotfix to ensure it works with p2pool stratum.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 29, 2012, 06:08:38 AM |
|
BTW, Stratum support is finished and will be released later today.
Great. I just released a new version of cgminer, 2.10.4, as a hotfix to ensure it works with p2pool stratum. FWIW, the cgminer problem here was fixed in BFGMiner 2.9.2 (Nov 5, 2012), so there should be no need for a new version to use p2pool + stratum.
|
|
|
|
|