Bitcoin Forum
June 26, 2022, 05:55:28 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 236
1  Bitcoin / Pools / Re: the best pool on: May 11, 2017, 08:56:07 AM
Of the pools you listed BTC Guild was definitely the best.  All you need to mine there is an ASIC and a Time Machine.

2  Alternate cryptocurrencies / Pools (Altcoins) / Re: 「魚池」BTC:270 Phash/s - LTC:500 Ghash/s - Mine 1 BTC, Get 10 NMC, only at F2Pool on: March 16, 2016, 07:22:52 AM
So ... I gotta ask: why did this happen?
Height Miner Time Size
402864 Unknown 17 seconds ago 934.6 kB
402863 Kano CKPool 4 minutes ago 983.1 kB
402862 DiscusFish / F2Pool 5 minutes ago 266.0 bytes
402861 BTCC 6 minutes ago 623.4 kB
402860 AntPool 17 minutes ago 488.3 kB
402859 KNCMiner 25 minutes ago 290.5 kB
402858 DiscusFish / F2Pool 29 minutes ago 407.9 kB
402857 Bitfury 33 minutes ago 230.5 kB
402856 AntPool 33 minutes ago 223.0 bytes
402855 AntPool 35 minutes ago 667.7 kB

You see what happened is BTCC gets a 623kB block ... and 2 seconds later F2Pool gets an EMPTY block.
BUT, 69s later we got a block at ... 983kB
Yeah maybe there's a reason for smaller blocks after a block change ... but EMPTY?

Because they're still SPV mining and will continue to do so just like every other Chinese pool.
3  Bitcoin / Pools / Re: Bitminter bitcoin mining pool - Pays TxFees, Merged Mining, Fair PPLNS rewards on: February 18, 2016, 07:10:45 PM
Very Interesting information about which is the BEST POOL:

Go to the 3rd one:  February 14th 2016 Mining Pool Statistics and scroll down to the charts Past Week, 4 weeks, 26weeks, 52 weeks.
That data is such a minor snippet though- February 7th-through February 13th (not even a full week). How is 6 days worth of mining relevant to performance anywhere? Need at least one whole months worth of data to gather what is really happening currently. Case in point, BC monster solved one block february 6th and one february 15th,  Im sure even more for the bigger pools as well.

February 7th through 13th is a full week.  Feb 7, 8, 9, 10, 11, 12, 13.  7 days.  And as stated in the post:  Scroll down and the very next chart is 1 month, then 6 months, and 12 months.
4  Bitcoin / Pools / Re: [40+ PH] SlushPool (; World's First Mining Pool on: February 18, 2016, 07:07:39 PM
Maybe you noticed the pool website now redirects to The URL is legit, we've been lucky enough to obtain this nice domain and we just moved there from more complicated "". Back in 2010 I did not realize how big the mining industry will became, so I choose just a subdomain of my Czech bitcoin blog :-).

This is just about the website, no change in miner settings is needed as we keep all mining URLs to work normally.

Hello Slush,
Thank you for that but maybe you have most important things to do,... like auto-detecting block withholding for exemple!

If I'm not mistaken it was you who designed the stratum protocol?

I'm not very knowledgeable of how it works, but I asked myself the following question:
Is it possible to send a job that has already won a block to all the miner (the same work) for example once a day to check that every miners solve the solution. it only cost a few seconds but would help to find block withholding problems?

This isn't possible.  In Stratum, each miner has a unique ExtraNonce1 value which means giving every miner the exact same job (which is what Stratum does already) will result in different hashes from every miner.  There is no way around this, since if  you added a feature to Stratum that forced an ExtraNonce1 change for work verification, the withholder would KNOW they're being tested.
5  Bitcoin / Pools / Re: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: December 09, 2015, 07:54:59 AM
The pool is now completely shut off, 177 days after the initial closure announcement.  This is 87 days more than was promised in our Terms of Service, the FAQ, and forum posts in the past about our closure process.  I had been extending the shutdown process to give more time for those who don't pay attention, but problems this evening have forced me to finally stop providing extensions and finish the shutdown.

After the pool removed its servers from colocation, the frontend was rewritten to provide a reduced functionality version that could run on a single temporary webserver to continue allowing withdrawal requests.  This rewrite required significant removal of checks that used to be done between multiple servers and DDoS protection scripts used to identify brute force attacks.  Since the site was no longer active, I assumed these shouldn't be required anymore since if somebody DDoS'd the site, it didn't really affect anything other than delaying withdrawals for a few hours/days until the attack stopped.

Unfortunately, this inadvertently removed the site's brute force protection on logins.  This evening, approximately 400 accounts (out of over 1 million) were logged into and had attempts to change the addresses.  Accounts that had no email setup for authentication were immediately changed, while those with emails setup received emails with a confirmation link.  Locked accounts obviously had nothing available to them.

Knowing that stripping out many layers of site functionality may have inadvertently added attack vectors, I removed automatic payout processing, leaving it as a fully manual process after the server move.  This allowed me to catch the fact that this happened and prevent the attacker from getting a payday (even if the total amount wasn't even half a Bitcoin).


Please remember going forward:  Don't re-use your usernames and passwords on multiple sites.  There are databases out there with tens of millions of username+password combinations.  There are likely over a million just from Bitcoin sites that have been compromised over the last 5 years.

EDIT:  To be clear, there is no evidence that this brute force attack was anything other than login attempts using usernames/passwords from a non-BTC Guild source.  If the attacker had information from BTC Guild's database, or the ability to modify it, they certainly wouldn't have hit ~400 accounts with a combined balance of less than 0.5 BTC.  All account wallet changes were done through the website (indicating no ability to modify the database), and was completely random in which accounts were affected (indicating no ability to access database information).
6  Alternate cryptocurrencies / Pools (Altcoins) / Re: 「魚池」BTC:140 Phash/s - LTC:570 Ghash/s - New Server in U.S. on: December 06, 2015, 10:11:40 AM
Mining on stratum headers is just one innovative contribution among many others from us. And we are happy to see this innovation has been adopted not only by us but also AntPool and BTCC.

"Innovative" is hardly the word for it.  Dangerous and stupid are far more accurate ways to describe it.  You've contributed absolutely nothing.
7  Bitcoin / Pools / Re: SPV Mining and how to slow it down ... if you care to ... on: December 03, 2015, 10:44:13 AM
Well, I run a pool as some people know Smiley
I've also been involved in bitcoin for a little while (since July-2011)
and I also write some code here and there.


You have been moved to our blacklist. You will not see these IP addresses connecting to your pool and waste your pool resource anymore. Thanks.

Fun to see the a pool that is _DOING THE WRONG THING AND HURTING THE NETWORK_ is "blacklisting" somebody.
8  Bitcoin / Pools / Re: A dream of having a new pool on: November 28, 2015, 10:18:01 PM

However, on the pool that I would like to have, the share is being used to get the proportional BTC reward for the miners. So I hope all miners will approximately get the same payout for the same mining period, regardless of their hashrates. The different will be that the miners who mine in longer time will get more payout than the ones who mine in shorter period. Has this kind of method been used so far? More importantly, does that make sense?

This is the dumbest thing I've ever heard.  So you think the people who spent thousands of dollars on modern and high speed equipment shouldn't get paid more than the people running 2-year old bargain bin ASICs and/or GPUs?  This isn't elementary school where just participating will get you credit.
9  Bitcoin / Pools / Re: A dream of having a new pool on: November 28, 2015, 08:07:19 PM
How does a minimum difficulty of 512 make a pool not "fair"?
Because I would submit more shares on lower difficulty. Or am I wrong on this?

Every single pool that uses difficulties greater than 1 (AKA: all of them) multiplies your share submissions by your difficulty.  So yes, you'll submit 4 times more work at 128 diff, but it would be the same payment as somebody submitting a single piece of work at 512.  Minimum difficulty has zero effect on your payout over any reasonable period of time.
10  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 27, 2015, 07:38:29 AM
Good job AntPool, continuing to mine absurd numbers of empty blocks and contributing to backlogs on the network!  You just mined 2 empty blocks in under 10 minutes.  The fact that miners continue to feed you hashpower when you do this shit so often is appalling.

Eleuthria, you were usually a calm, cool and relaxed guy. I don't think I have ever seen you curse at all. You ok? Have the NY laws moved into the wrong direction as you predicted? I usually don't follow the law like that, since I don't run a pool.

I'm normally a bit more controlled when posting on the forum (IRC is another story entirely).  I've definitely cursed on the forums before, but normally I would edit my comments before anybody had a chance to read them.  Now that my pool is closed, I'm not so concerned about it.  Especially on this particular subject, where the largest pools on the network won't even do their damn jobs of processing/confirming transactions.  They continue to engage in SPV mining after causing a network fork earlier this year, and people continue to point their miners at these greedy and incompetent fools.
11  Bitcoin / Pools / Re: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: November 25, 2015, 06:07:44 AM
I just voted in the Coindesk "Most influential People of BTC in 2015". It looks like someone at Coindesk forgot to put BTC Guild on the list so I'm sure a few of you, from here,  can find their way to use the write in at the bottom like I did.  HINT..ef'n..HINT!!!

Thanks for the mention, but I'm certainly not an "influential" person in Bitcoin.  I ran a good pool, kept things running smoothly for 4 and a half years, and decided to gracefully shut down the service (and give people 6 months to clear old accounts) to make sure it ended on a positive note and under my own terms, not as the result of legal action or even worse, malicious actions.

When I hear influential, I think of people that are actually "doing something" for Bitcoin.  Either by pushing adoption, working on improving usability, working on improvements, or trying to inform/direct legal authorities into making decisions that will do the least damage if they insist on doing anything at all.  All BTC Guild really did that fits into any of that would be BIP32 support and then voicing opinions on BIP 100/101 and my agreement that block size should be increased.  But that's the real limits of influence:  Suggestion/confirmation.  I don't make myself an advocate and preach the benefits of them.  Oh, and my continued assault on  SPV mining done by pools like AntPool, BTC China, and F2Pool, meaning over 50% of the hashpower on the network isn't even doing their damn job properly.
12  Bitcoin / Pools / Re: [14000Th] Eligius: 0% Fee BTC, 105% PPS NMC, No registration, CPPSRB on: November 25, 2015, 12:53:16 AM
Those numbers really reinforce my thinking that there is something in older hardware that is not submitting winning shares (either by intentional design, or due to cutting corners and screwing something up when it comes to really high difficulty).  Especially when the only large pool that is right where you'd expect them to be regarding luck is the one that makes their own hardware and runs a massive private farm.
13  Bitcoin / Bitcoin Discussion / Re: Cut future block chain? on: November 08, 2015, 01:17:38 AM
these days people buying the entire series of World of Warcraft uses more data than bitcoin

This one isn't valid anymore, just FYI.  A full Bitcoin node uses much more space than World of Warcraft's installation.  Almost double actually.
14  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 07, 2015, 06:47:33 AM
This is excellent information, I appreciate it and your time! There are some misconceptions regarding how empty blocks come to be and without some general education we won't be able to facilitate change needed to squelch them.

Finally addendum:  SPV mining isn't the *sole* cause of 1tx blocks.  But it's the main cause of them.  Some pools with poorly made/slow pool software, or slow hardware, might send out a pre-baked work template without any transactions when their node sees a new block because it takes their pool more time to actually build a new block with transaction.  They are still relying on their full node seeing and validating a block, but are shortcutting the time it takes to build work in order to make sure they update to the newest block as fast as possible.

I know BTC Guild and ckpool didn't suffer from this.  That might be because BTC Guild and ckpool used low level (C and C++) languages.  The time difference in building/pushing out work for an empty block and building/pushing out work for a block with 500-900kb of transactions was negligible for BTC Guild.
15  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 07, 2015, 06:25:15 AM
EDIT: - F2pool/Discus Fish publicly stating that even after SPV mining by chinese pools caused a fork in 2015, they had no intention to stop doing so, and don't believe that Antpool or BTC China will either.  You can see clearly that all 3 pools are still doing it just by looking at the sheer number of empty blocks they mine each week.

I'll stop thread-jacking, but I've got one more question if you would be so kind.  Under what circumstances could an empty block be mined "legitimately?"

A few years ago (I'd say anytime within the last 2 years this wouldn't apply), there were periods of slow network activity (1 tx every few seconds rather than 1-2/sec).  If a pool got really lucky, the following events could happen:

1) Pool pushes out work to a miner that includes all transactions the pool knows about.
2) Miner happens to solve a block almost instantly after receiving this work and sends a winning share back to the pool.
3) Pool verifies the share and pushes out a new block, and has not yet received a single transaction, thus meaning the pool is not aware of a single unconfirmed transaction to include.
4) Pool pushes out new work with no transactions because it isn't aware of any.
5) Pool solves another block before it has sent out updated work with transactions in it.

Those events could only happen if the pool *just* created work and the miner solved it almost instantly, and the two were very low latency from each other.  Obviously, the further back in time you go, the larger the window of opportunity, since transaction activity was significantly lower the further back you go.

Today, there's pretty much only one way a 1-tx block could legitimately happen:

1) Pool restarted its bitcoin node, which wipes out its knowledge of any unconfirmed transactions on the network
2) Pool software created a unit of work before the bitcoin node was notified of a single transaction.
3) Miner solves this unit of work before the pool has sent out new work that includes transactions.

I can't think of any other legitimate reason for a 1-tx block today.  The network is *so* active at all times, that the odds of a pool being able to actually fit every transaction it knows about into a block, sending that work to a miner, and a miner solving that block before the pool has seen a single other transaction, creating a new block without transactions (because there aren't any), and then solving another block off that work, should be a once every few months occurrence  (edit:  and that's a VERY GENEROUS estimate of frequency).  Not a multiple times in a single day occurrence like we see from the SPV mining pools.

Just going from my own evidence:  BTC Guild, as far as I'm aware, did not have a single 1 TX block to its name from mid-2013 until it closed in June 2015.  That includes a multi-month period where it was 35-45% of the network, had multiple chains of 6+ blocks in a row solved by its own bitcoin nodes, and multiple block solves that happened within seconds of each other.  I'm trying to find the data somebody put together of pools with 1-tx blocks, I believe BTC Guild was 3 out of over 32,000 blocks, and I'm fairly certain those blocks were from 2012.
16  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 07, 2015, 05:45:11 AM
Thank you for your prompt answer!  I appreciate someone with your experience chiming in--it appears to me that there is a fair amount of misinformation regarding the subject.  I would like to have a full understanding of the issue so that I can help educate others.  Could you point me towards the right direction, e.g. documentation of the mechanisms?

The exact implementation isn't publicly documented as far as I'm aware.  All we know is that they will begin mining blocks before their own full nodes have actually seen them.  Who they are connected to, how many sources they wait to see the block from before switching (assuming more than 1), etc., are not publicly stated by any of the pools engaging in this activity (its referred to as SPV mining).

EDIT: - F2pool/Discus Fish publicly stating that even after SPV mining by chinese pools caused a fork in 2015, they had no intention to stop doing so, and don't believe that Antpool or BTC China will either.  You can see clearly that all 3 pools are still doing it just by looking at the sheer number of empty blocks they mine each week.
17  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 07, 2015, 05:17:32 AM
the bad thing is that this pool is one of the pools that is contributing to the slowness of confirmations by mining empty blocks with bad code..

Precisely. It's a little amusing to see miners who support a pool that doesn't contribute to the network complain about how long transactions take  Cheesy

I was having this same conversation with someone on Reddit earlier this week.  Pool _choose_ to submit empty block, am I wrong?  Bitfury has not posted a single empty block in the last week, while Antpool has posted ... 21 total empty blocks last week.  BitFury and Antpool averaged 22 and 28 blocks last week, respectively.

Am I wrong to conclude that the pools have a choice in the matter?

They have a choice.  It's extremely unlikely that any time in the last 2 years there has ever been a point where there was not a single valid and non-spam transaction waiting for confirmation even at the exact time a block was solved.

EVERY chinese pool currently is making the choice that is bad for bitcoin.  The excuse is that internet connectivity in China to the outside world is shit.  The workaround is to not rely on their full bitcoin node to see the newest block on the network, and instead use active listening connections to other sources to see a new block header (not the whole block).  If they see a new block header, they'll immediately push out new work using that as the previous block, without doing any validation (because their node hasn't seen the full block yet).  The only way to do this is by making a block without any transactions because you don't know what was actually confirmed in the previous block.

Even after it was clearly shown this is a bad idea (see the soft fork earlier this year the chinese pools caused), they have stated they have no intention of stopping this activity.  So now the rest of the network has to live with pools that don't do their fucking jobs, causing longer transaction confirmation times, because miners are too stupid to stop mining on pools that are actively hurting the network.
18  Bitcoin / Mining / Re: Empty blocks on: November 05, 2015, 11:01:42 PM
It doesn't matter if the blocks were found within seconds of each other unless you're looking at pre-2013 blocks.  I doubt there has never been a point in the last 2 years where there were 0 legitimate unconfirmed transactions on the network.
19  Bitcoin / Pools / Re: [CLOSED] BTC Guild - Pays TxFees+NMC, Stratum, VarDiff, Private Servers on: November 05, 2015, 06:16:11 PM
I'd like to publicly thank eleuthria for not only running one of the greatest BTC pools ever, but also for personally taking care of my withdrawal in a timely fashion.

After the recent bump in the BTC exchange rate, I went to log into BTC Guild where I knew I had a few coins stashed. I read the closure notice, much to my dismay. To further my dismay, my account was deactivated.

After reaching out to eleuthria, he reactivated my account and manually approved the transfer.

Thanks for your professionalism and integrity, eleuthria!

Just don't do it again on another online service!  We're not wallets/long term storage, and the odds of any other Bitcoin service continuing to deal with account withdrawals 18 weeks after they shut down their services is extremely low.
20  Bitcoin / Pools / Re: BITMAIN announces Antpool on: November 05, 2015, 03:24:40 AM
Good job AntPool, continuing to mine absurd numbers of empty blocks and contributing to backlogs on the network!  You just mined 2 empty blocks in under 10 minutes.  The fact that miners continue to feed you hashpower when you do this shit so often is appalling.
I built a thing for this, F2Pool is almost as bad....

All the chinese pools do the same shit, and continue to do so even after they caused a fork event.  Nice to see you made it easy to visualize just how terrible they are.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 236
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!