Bitcoin Forum
July 16, 2019, 11:24:22 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 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] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2580052 times)
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
May 05, 2013, 10:16:34 AM
 #5241

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
1563276262
Hero Member
*
Offline Offline

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

1563276262
Report to moderator
1563276262
Hero Member
*
Offline Offline

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

1563276262
Report to moderator
1563276262
Hero Member
*
Offline Offline

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

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

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

1563276262
Report to moderator
1563276262
Hero Member
*
Offline Offline

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

1563276262
Report to moderator
1563276262
Hero Member
*
Offline Offline

Posts: 1563276262

View Profile Personal Message (Offline)

Ignore
1563276262
Reply with quote  #2

1563276262
Report to moderator
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
May 05, 2013, 10:24:07 AM
 #5242

going back about 3 or 4 pages

Quote from: zvs
i sent him a custom copy of bitcoind on tues, now he runs around a constant 3.5-4ms latency.  this is on some cheap $40 OVH machine.  8GB RAM and some semi-junk CPU.   this was accomplished essentially by just raising the tx fee to 100000.  at that rate, you'll only get tx'es that'll clear out on the next block.   he's also set to 5000 max blocksize.   though, you'd start to notice the ramdrive a lot more once you start raising the blocksize.  the problem I have with it is that it also increases the # of orphans..

i think it'd be much better if the block solver got all the TX fees instead of however the reward system works now (and, no, this isn't favoring someone that's 60ghash, because like the share difficulty, in the long run it would all even out).

it does bother me when people have the maxblocksize set to <1000, though.... because occasionally you will get that transaction with the 5 BTC fee and it only takes a few KB to get it in a block...  lenny solved one of those just about a week or two ago (block was worth 33, I believe)

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

...
Yeah, so there's really no reason not to just change it over to the TX'es.     Add them to your blocks, take the risk of having a few more orphans, but get the whole TX amt if you solve it
Except that is the exact opposite of the BTC design.
BTC design is to halve every 4 years coz transaction fees will 'supposedly' cover this over time.
So doing it that way means to head in the direction of giving all the reward to the block finder ... i.e. the opposite of being a pool.

so obtuse

i'm not helping propagate your share full of transactions, because it gets orphaned

if a large amount of transactions still cause shares to have an increased chance of being orphaned and assuming people still use p2pool when this may matter, in 4, 8, or 12 years, then i suspect it would be wise to then do a rethink. 

oh, assuming the issue w/ the increased orphans isnt solved by then, in a decade or whatever.

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 10:37:36 AM
 #5243

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;





3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 10:39:43 AM
 #5244

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
zvs
Legendary
*
Offline Offline

Activity: 1610
Merit: 1000


House Nogleg


View Profile WWW
May 05, 2013, 10:42:40 AM
 #5245

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 10:45:39 AM
 #5246

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

I've been asking that to be done for months now.......as you know.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
Subo1977
Sr. Member
****
Offline Offline

Activity: 344
Merit: 250


Flixxo - Watch, Share, Earn!


View Profile
May 05, 2013, 11:06:59 AM
 #5247

WOW! How?

1) actual bitcoin from git ( moves  variables ...Fees.. from main.h to main.cpp)
 2)  set in src/main.cpp the parameters to
int64 CTransaction::nMinTxFee = 1000000000;    # Override with -mintxfee
int64 CTransaction::nMinRelayTxFee = 1000000000;


3) compile bitcoin

EDIT:
Or.. not tested:  set  -mintxfee  -minrelaytxfee to 1000000000  without editing main.cpp
 

4) in bitcoin.conf:
blockmaxsize=5000
blockprioritysize=0
blockminsize=0

Greets
Basically your saying that pool mining is 100 times better for bitcoin than your p2pool settings coz some pools can commit up to 100x the transactions that you do.
Transactions are the other part of what is necessary to keep bitcoin alive.
No transactions means no bitcoin.

I wouldn start a discussion over the pro and cons of TX handling with P2pool.

i  would only show the impact of TX integration on the Performance in an actual setup.

No transactions == bad idea.  No discussion needed.

M

+1

I mean, you can all pat yourselves on the back and give the +1's and the high fives for Bitcoin The Way It's Meant To Be Run and glory be to Shitloads of Transactions....

But why not fix p2pool, instead?

I've been asking that to be done for months now.......as you know.

good discussion,
I say'd there must be at  problem but
Everybody say'd theres no problem with p2pool...

Fix the Problem....

X       ▄▄█████████▄▄
    ▄██▀▀         ▀▀██▄
  ▄██▀              ▀██▄
 ▄██     ██▄▄          ██▄
▄██      █████▄▄        ██▄
██       ████████▄▄      ██
██       ███████████▄    ██
██       ██████████▀     ██
▀██      ███████▀       ██▀
 ▀██     ████▀         ██▀
  ▀██▄   █▀          ▄██▀
    ▀██▄▄         ▄▄██▀
       ▀▀█████████▀▀
.flixxo    X▄████████████████████▄
██████████████████████
██████████████████████
████████████▀▀███████
█████▀████░░░░░░▄████
█████░░░░░░░░░░▄█████
█████▄░░░░░░░░░░██████
██████░░░░░░░░░███████
███████░░░░░░▄████████
████▄▄░░░░▄▄██████████
██████████████████████
██████████████████████
▀████████████████████▀
▄████████████████████▄
██████████████████████
█████████▀█▀██████████
██████▀▀▀▀▀████████
██████▄▄░░▄▄▄░░███████
████████░░███░░███████
████████░░░░░░▀███████
████████░░███▄░░██████
██████▀▀░░▀▀▀░░░██████
██████▄▄▄▄▄▄███████
█████████▄█▄██████████
██████████████████████
▀████████████████████▀
X[[]]X
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
May 05, 2013, 11:43:47 AM
Last edit: May 05, 2013, 12:06:44 PM by mdude77
 #5248

good discussion,
I say'd there must be at  problem but
Everybody say'd theres no problem with p2pool...

Fix the Problem....

I was using p2pool for the last couple weeks with no issues whatsoever with my measly 7.6gh.  On a different coin atm.

EDIT: I'm of the opinion that p2pool is more bandwidth constrained that one might think.  I was running below pool stale rate the whole time by running p2pool and bitcoin on an SSD and having ALL port forwarding turned off, default settings everywhere else.  The only time my stale rate started to climb is when I was downloading something for an extended period of time that saturated my bandwidth.  I have 3mb down and 768kb up (adsl).

On the other coin I'm using atm, I'm seeing the same, I'm below pool stale rate, regularly significantly lower.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
May 05, 2013, 12:08:36 PM
 #5249

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

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
Searinox
Full Member
***
Offline Offline

Activity: 140
Merit: 100


Do you like fire? I'm full of it.


View Profile
May 05, 2013, 12:35:41 PM
 #5250

I always find it weird how my P2Pool hashrate keeps fluctuating even in idle, sometimes reaching as high as 280Mh/s or dropping as low as 110Mh/s. I have my miner set up as recommended for my card. Is there anything I can do about it or is this not the miner/setup's fault and rather p2pool's?

daemondazz
Sr. Member
****
Offline Offline

Activity: 448
Merit: 250



View Profile
May 05, 2013, 12:42:27 PM
 #5251

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

In any event, you do not need to rewrite the entire application in C/C++, just the module(s) that are time critical and then you can import the compiled C/C++ module into Python using Swig.

Computers, Amateur Radio, Electronics, Aviation - 1dazzrAbMqNu6cUwh2dtYckNygG7jKs8S
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 12:45:27 PM
 #5252

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

With respect, you've never seen any problems. That does not mean that there aren't any.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
mdude77
Legendary
*
Offline Offline

Activity: 1540
Merit: 1001



View Profile
May 05, 2013, 12:47:38 PM
 #5253

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

I mine at Kano's Pool because it pays the best and is completely transparent!  Come join me!
PatMan
Hero Member
*****
Offline Offline

Activity: 924
Merit: 1000


Watch out for the "Neg-Rep-Dogie-Police".....


View Profile WWW
May 05, 2013, 12:51:35 PM
 #5254

Agreed. One shouldn't have to start tampering with the transaction settings to get p2pool working optimally, but at the detriment of bitcoin itself, it should just work properly out of the box. I believe if p2pool was rewritten in C or C++ it would not only be more cross platform compatible than python, but it would also definitely make it easier to pinpoint the stratum issue that I have been banging on about ever since it's introduction, simply because it is more widely understood and used by programmers/coders. Of which I am not one  Wink

I don't see any problem with Python. The current line of discussion is about bitcoind latencies, which is... programmed in C/C++.

There is also an issue with p2pool not being to work properly with ASICs, even as small as a jalapeno.

M

Which highlights the desperate need of a complete rework.

"When one person is deluded it is called insanity - when many people are deluded it is called religion" - Robert M. Pirsig.  I don't want your coins, I want change.
Amazon UK BTC payment service - https://bitcointalk.org/index.php?topic=301229.0 - with FREE delivery!
http://www.ae911truth.org/ - http://rethink911.org/ - http://rememberbuilding7.org/
Amph
Legendary
*
Offline Offline

Activity: 2226
Merit: 1003



View Profile
May 05, 2013, 01:07:54 PM
 #5255

still the best duo for me is cgminer 3.0.1 and p2pool 11.2, much more efficiency and less reject than other
maqifrnswa
Sr. Member
****
Offline Offline

Activity: 454
Merit: 250


View Profile
May 05, 2013, 02:54:38 PM
 #5256

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu


This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.
gyverlb
Hero Member
*****
Offline Offline

Activity: 896
Merit: 1000



View Profile
May 05, 2013, 03:15:11 PM
 #5257

regarding custom compiled bitcoind for "optimal" p2pool operation

he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu


This is an interesting point: should p2pool be changed so that we take away a miner's freedom to choose what transactions to accept in order to help the bitcoind network?

Summary: by custom tweaking bitcoin code, you can create 0 transaction blocks with tiny p2pool latency. That is great for the individual miner that does it (higher efficiency) but horrible for the bitcoind network (and for other p2pool miners who are "honest"). Galvin Anderson did some calculations to show that the 0 tx strategy is not profitable compared to accepting transactions for solo (or regular pooled) bitcoind mining. I wonder if it's true for p2pool...

Whether it was written in C or python (or intercal), this would be a problem and is a fundamental question.

Simply fix bitcoind instead of focusing on p2pool. Giving a block template for p2pool to use should be nearly instantaneous. The problem seems to be that bitcoind rebuilds the whole block template from scratch on each request instead of preparing it in the background. Fix that and nobody will have to tune bitcoind anymore.

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
Amph
Legendary
*
Offline Offline

Activity: 2226
Merit: 1003



View Profile
May 05, 2013, 05:38:42 PM
 #5258

the pool is growing pretty well
wtogami
Sr. Member
****
Offline Offline

Activity: 263
Merit: 250



View Profile
May 05, 2013, 08:10:12 PM
 #5259

A mean average of 0.1 went up to a mean average of over 0.3.....

Which measure is this, the "Bitcoind GetBlockTemplate Latency"?  11.4 here with a mean of 0.0606s over the past 24 hours.

If you appreciate my work please consider making a small donation.
BTC:  1LkYiL3RaouKXTUhGcE84XLece31JjnLc3      LTC:  LYtrtYZsVSn5ymhPepcJMo4HnBeeXXVKW9
GPG: AEC1884398647C47413C1C3FB1179EB7347DC10D
kano
Legendary
*
Offline Offline

Activity: 2856
Merit: 1181


Linux since 1997 RedHat 4


View Profile
May 05, 2013, 09:11:56 PM
 #5260

...
he can run his pool the way he wants to.  right now, that's the best way to run a p2pool pool.

you can either a) fix p2pool so that having a bunch of transactions doesn't cause you to get double, triple, or quadruple as many orphans, b) implement a stop-gap like i proposed, or c) stfu

Of course he can.

But it also means that what is best for bitcoin is to NOT use p2pool.
The opposite of what is commonly argued.

As the thread title says: Decentralized, DoS-resistant, Hop-Proof pool

Pool mining on a pool that has a block size limit of 500k or 5k, which is better for bitcoin?

So the answer to that is ... it is better for bitcoin to NOT use p2pool since p2pool seems to require it's users to restrict transactions dramatically.

It's a very simple argument.

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!
Pages: « 1 ... 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] 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 ... 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!