[ANN] BTC Guild's Mitigation Plan | Bitcointalksearch.org

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: HellDiverUK on September 23, 2013, 05:42:28 AM

Quote from: kano on September 23, 2013, 02:59:59 AM

Quote from: HellDiverUK on September 23, 2013, 02:24:07 AM

Quote from: kano on September 23, 2013, 12:37:26 AM

Quote from: HellDiverUK on September 22, 2013, 05:45:48 AM

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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

Glad we cleared that up.

HellDiverUK

hero member

Activity: 1246

Merit: 501

Quote from: kano on September 23, 2013, 02:59:59 AM

Quote from: HellDiverUK on September 23, 2013, 02:24:07 AM

Quote from: kano on September 23, 2013, 12:37:26 AM

Quote from: HellDiverUK on September 22, 2013, 05:45:48 AM

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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'?)

junshong

full member

Activity: 192

Merit: 100

Hi!

The hashrate seems good, currently at 31%.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: HellDiverUK on September 23, 2013, 02:24:07 AM

Quote from: kano on September 23, 2013, 12:37:26 AM

Quote from: HellDiverUK on September 22, 2013, 05:45:48 AM

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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?

HellDiverUK

hero member

Activity: 1246

Merit: 501

Quote from: kano on September 23, 2013, 12:37:26 AM

Quote from: HellDiverUK on September 22, 2013, 05:45:48 AM

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: HellDiverUK on September 22, 2013, 05:45:48 AM

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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 ...

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: eleuthria on September 21, 2013, 02:20:13 PM

Quote from: RoadTrain on September 21, 2013, 02:17:14 PM

No offence, just a tip.

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

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.

HellDiverUK

hero member

Activity: 1246

Merit: 501

Quote from: Trongersoll on September 21, 2013, 05:36:31 PM

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.

Trongersoll

hero member

Activity: 490

Merit: 501

Quote from: HellDiverUK on September 21, 2013, 02:23:54 PM

Quote from: os2sam on September 21, 2013, 02:06:53 PM

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

Activity: 1246

Merit: 501

Quote from: os2sam on September 21, 2013, 02:06:53 PM

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.

eleuthria

legendary

Activity: 1750

Merit: 1007

Quote from: RoadTrain on September 21, 2013, 02:17:14 PM

No offence, just a tip.

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

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.

RoadTrain

legendary

Activity: 1386

Merit: 1009

Quote from: eleuthria on September 21, 2013, 02:11:19 PM

Quote from: RoadTrain on September 21, 2013, 02:09:41 PM

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.

Quote from: os2sam on September 21, 2013, 02:06:53 PM

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.

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

eleuthria

legendary

Activity: 1750

Merit: 1007

Quote from: RoadTrain on September 21, 2013, 02:09:41 PM

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.

Quote from: os2sam on September 21, 2013, 02:06:53 PM

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.

RoadTrain

legendary

Activity: 1386

Merit: 1009

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

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: Isokivi on September 21, 2013, 01:51:31 PM

Quote from: os2sam on September 21, 2013, 01:48:24 PM

Quote from: Isokivi on September 21, 2013, 01:41:10 PM

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.

HellDiverUK

hero member

Activity: 1246

Merit: 501

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.

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

Quote from: os2sam on September 21, 2013, 01:48:24 PM

Quote from: Isokivi on September 21, 2013, 01:41:10 PM

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.

os2sam

legendary

Activity: 3583

Merit: 1094

Think for yourself

Quote from: Isokivi on September 21, 2013, 01:41:10 PM

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 us 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.

Isokivi

hero member

Activity: 910

Merit: 1000

Items flashing here available at btctrinkets.com

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.

junshong

full member

Activity: 192

Merit: 100

Hi!

The hashrate seems to be growing, its 39% now. And just now, BTCguild found 4 blocks continuously. Gonna reach 51% soon.

Topic: [ANN] BTC Guild's Mitigation Plan (Read 24845 times)