Bitcoin Forum
June 16, 2024, 04:34:34 PM *
News: Voting for pizza day contest
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: [ANN] BTC Guild's Mitigation Plan  (Read 24705 times)
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 21, 2013, 07:03:21 PM
 #81

If BTC Guild is attracting so many miners, then there's an obvious problem.  Most other pools are shit.  The good pools (IE ones that are stable) have a slow hash rate, so blocks take ages to find.  Even a pool with 25TH is taking nearly a day to find a block, which is...well...crap.

If some of the pool operators would get the finger out and sort out their shit, maybe people wouldn't all crowd to BTC Guild.

os2sam
Legendary
*
Offline Offline

Activity: 3578
Merit: 1091


Think for yourself


View Profile
September 21, 2013, 07:06:53 PM
 #82

I think you should refer to your miners as lemmings solong as the pool holds over a quarter of the network hashrate, hope you can incorporate this in to your mitigation plan asap.

Lemmings = People who want a stable mining experience in order to maximize the usefulness of their mining hardware.

That doesn't sound anything like the video game to me.

If you don't like use mining on Deepbit, er I mean BTC Guild then get the Client developers to incorporate Stratum, GBT and User Defined Difficulty into into the Bitcoin-QT so that people with high hash rate ASIC's have a viable choice of where to mine without having to setup their own private pool.
Let me fix that for you:

Lemmings = People who want a stable mining experience in order to maximize the usefulness of their mining hardware. At the risk of putting the entire network and blockchain in constant jeopardy and completely undermining the consept of a decentralized currency.

You completely ignore the reality that this is caused, largely, by the Bitcoin-qt devs refusing to make the client useful for ASIC mining!

This affects solo mining and, I believe, P2Pool mining.  Get me an answer to why that is, plus a viable alternative!  Then *maybe* I'll accept the moniker of lemming.
Sam

Edit: also none of these comments have anything to do with Eleuthria's mitigation plan.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
RoadTrain
Legendary
*
Offline Offline

Activity: 1386
Merit: 1009


View Profile
September 21, 2013, 07:09:41 PM
 #83

blockchain reports 46% of blocks are form BTCGuild in the last 24 hours.
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
September 21, 2013, 07:11:19 PM
 #84

blockchain reports 46% of blocks are form BTCGuild in the last 24 hours.

Yes.  Blockchain reports lots of garbage.  There's a link on the very first post showing you an accurate chart (one that doesn't classify 35% of the network as unknown, and doesn't use a USELESS 24-hour chart).  And for the record, clicking the extra length on blockchain.info's chart doesn't change the data (this hasn't worked properly in close to a year).

BTC Guild is 35.9% of the network over the last 10 days.



Edit: also none of these comments have anything to do with Eleuthria's mitigation plan.

Not to mention it's a necro from 6 months ago when 50% was actually looking like an imminent event.

RIP BTC Guild, April 2011 - June 2015
RoadTrain
Legendary
*
Offline Offline

Activity: 1386
Merit: 1009


View Profile
September 21, 2013, 07:17:14 PM
 #85

blockchain reports 46% of blocks are form BTCGuild in the last 24 hours.

Yes.  Blockchain reports lots of garbage.  There's a link on the very first post showing you an accurate chart (one that doesn't classify 35% of the network as unknown, and doesn't use a USELESS 24-hour chart).  And for the record, clicking the extra length on blockchain.info's chart doesn't change the data (this hasn't worked properly in close to a year).

BTC Guild is 35.9% of the network over the last 10 days.



Edit: also none of these comments have anything to do with Eleuthria's mitigation plan.

Not to mention it's a necro from 6 months ago when 50% was actually looking like an imminent event.
No offence, just a tip. Smiley
And while for some pools blockchain is providing a lot of false positives, for BTC Guild it seems to work well. Smiley
eleuthria (OP)
Legendary
*
Offline Offline

Activity: 1750
Merit: 1007



View Profile
September 21, 2013, 07:20:13 PM
 #86

No offence, just a tip. Smiley
And while for some pools blockchain is providing a lot of false positives, for BTC Guild it seems to work well. Smiley

The issue is 24-hours is too short of a period for a meaningful chart.  I stopped giving a damn about what blockchain.info said the % of network for any pool was a long time ago, because even if the pool+network speeds are steady, you'll see the pool swing 5-15% on that chart day to day for BTC Guild.  Other pools can fluctuate to showing more than double their actual share of the network in a 24-hour period, or more.

RIP BTC Guild, April 2011 - June 2015
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 21, 2013, 07:23:54 PM
 #87


You completely ignore the reality that this is caused, largely, by the Bitcoin-qt devs refusing to make the client useful for ASIC mining!

This affects solo mining and, I believe, P2Pool mining.  

I don't agree with much of what you say, but I wholly agree with this.  p2pool runs like shit when you start pumping a few tens of gigahashes through it, even on a fast machine.  Why?   Because bitcoin-qt runs like crap, and bitcoind is only marginally better.

IF bitcoin-qt/bitcoind were a lot more efficient, then p2pool would perform WAY better, and more people might use it.  Currently it needs a fast machine to run, and it really is too much like hard work to keep it running nicely.

p2pool only barely runs properly on an i3-3220 (dual core 3.3GHz) - I tried it on a slower AMD machine (Sempron X2 190, dual core 2.5GHz) and I was seeing 1-3s getblock latency.  That's only putting 30GH/s through it.
Trongersoll
Hero Member
*****
Offline Offline

Activity: 490
Merit: 501



View Profile
September 21, 2013, 10:36:31 PM
 #88


You completely ignore the reality that this is caused, largely, by the Bitcoin-qt devs refusing to make the client useful for ASIC mining!

This affects solo mining and, I believe, P2Pool mining.  

I don't agree with much of what you say, but I wholly agree with this.  p2pool runs like shit when you start pumping a few tens of gigahashes through it, even on a fast machine.  Why?   Because bitcoin-qt runs like crap, and bitcoind is only marginally better.

IF bitcoin-qt/bitcoind were a lot more efficient, then p2pool would perform WAY better, and more people might use it.  Currently it needs a fast machine to run, and it really is too much like hard work to keep it running nicely.

p2pool only barely runs properly on an i3-3220 (dual core 3.3GHz) - I tried it on a slower AMD machine (Sempron X2 190, dual core 2.5GHz) and I was seeing 1-3s getblock latency.  That's only putting 30GH/s through it.

It is open source, rewrite it to do what you want it to do.
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 22, 2013, 10:45:48 AM
 #89



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
kano
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
September 23, 2013, 05:36:33 AM
 #90

No offence, just a tip. Smiley
And while for some pools blockchain is providing a lot of false positives, for BTC Guild it seems to work well. Smiley

The issue is 24-hours is too short of a period for a meaningful chart.  I stopped giving a damn about what blockchain.info said the % of network for any pool was a long time ago, because even if the pool+network speeds are steady, you'll see the pool swing 5-15% on that chart day to day for BTC Guild.  Other pools can fluctuate to showing more than double their actual share of the network in a 24-hour period, or more.
Which is of course correct - due to bitcoin mining being a random event.

You seem to be implying that random events shouldn't be random when they are.
I guess it's just the wording ...

You cannot overcome random variance without defining it impossible to estimate shorter time frames.
You simply need to understand that the variance exists and also that there is an expected error in the result ... even at 100 days Tongue

However, it is also true to say that the network % is not as important as the block % over a short period of time.
So discounting a high, short-term block rate is invalid.
It is the block % that allows you to do a 51% attack, thus you can indeed do a 51% attack with luck and 45% of the hash rate and also fail to do a 51% attack with bad luck and 55% of the hash rate.
Either way, if the issue is the concern of a 51% by someone taking over your pool, if they do see that the pool can, over a short period, sometimes do the equivalent of a 51% due to variance, then the risk is already there.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
kano
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
September 23, 2013, 05:37:26 AM
 #91



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
Point some out in there that you see ...

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 23, 2013, 07:24:07 AM
 #92



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
Point some out in there that you see ...

You seem to think you have all the answers, why don't you?
kano
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
September 23, 2013, 07:59:59 AM
 #93



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
Point some out in there that you see ...

You seem to think you have all the answers, why don't you?
Your the one who said "I know inefficient code when I see it"
Or where you taking medication at the time?

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
junshong
Full Member
***
Offline Offline

Activity: 192
Merit: 100

Hi!


View Profile
September 23, 2013, 09:43:57 AM
 #94

The hashrate seems good, currently at 31%.

HellDiverUK
Hero Member
*****
Offline Offline

Activity: 1246
Merit: 501



View Profile
September 23, 2013, 10:42:28 AM
 #95



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
Point some out in there that you see ...

You seem to think you have all the answers, why don't you?
Your the one who said "I know inefficient code when I see it"
Or where you taking medication at the time?

When it runs like shit on anything less than a 3.3GHz i3, and still pegs a core at 100%, then it's OBVIOUSLY inefficient code.  Because code makes a program.  If the program runs like shit, then it's obviously the code that's crap.   Bitcoind doesn't do much, there's no reason for it to need so many CPU cycles and half a gig of RAM.  It's just sloppy.

I might not know how a car engine works, but I know when an engine runs like crap.

You're just being obtuse, you know what I'm talking about (see how I used 'you're' and not 'your'?)
kano
Legendary
*
Offline Offline

Activity: 4522
Merit: 1844


Linux since 1997 RedHat 4


View Profile
September 23, 2013, 12:52:48 PM
 #96



It is open source, rewrite it to do what you want it to do.

I'm not a coder.  But I know inefficient code when I see it.
Point some out in there that you see ...

You seem to think you have all the answers, why don't you?
Your the one who said "I know inefficient code when I see it"
Or where you taking medication at the time?

When it runs like shit on anything less than a 3.3GHz i3, and still pegs a core at 100%, then it's OBVIOUSLY inefficient code.  Because code makes a program.  If the program runs like shit, then it's obviously the code that's crap.   Bitcoind doesn't do much, there's no reason for it to need so many CPU cycles and half a gig of RAM.  It's just sloppy.

I might not know how a car engine works, but I know when an engine runs like crap.

You're just being obtuse, you know what I'm talking about (see how I used 'you're' and not 'your'?)
Ah I understand now.
You don't know what yore talking about or what bitcoind does Smiley
Glad we cleared that up.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!