Quote from: kano on May 27, 2020, 02:56:13 AM

Quote from: mikeywith on May 26, 2020, 04:13:21 PM

...
Also, one thing to keep in mind that losing a block due to bad luck and not technical deficiencies has to do how many blocks a pool is subject to find in the first place, Kano pool hardly finds any blocks on the grand scheme of things, I even saw him brag about not mining an empty block in my empty blocks analysis topic , I didn't want to comment on his post in that section to not trigger him there and make members of that section suffer reading his disrespectful replies, it's enough that members of mining board are suffering. Grin

what Kano seems to don't know or ignore is that the probability of him hitting an orphan/empty block is directly related to his chances of hitting a block in the first place, given the tiny hashrate he has compared to the large pools it makes sense why he is unlikely to hit an empty or orphan block, of course, with all technical aspects like having the right code, server, and connection being equal.
...

You post things that you claim

Quote from: mikeywith on May 26, 2020, 04:30:30 PM

...
The rest of my reply is general information for everyone, not pointed directly to you.
...

Please post information you can at least substantiate.

You are ignoring facts and the most obvious of those is the fact that my pool has found 2429 blocks so far.
No empty blocks in there.

In fact, my code reports ANY work generated that is ever empty, of the work generated once every 30 seconds over the years.
Over the life of my pool, that would amount to less than you can count on one hand.
You obviously do not understand how work is generated by a pool and how a block can be empty, without the pool purposely producing an empty block like most of the large pools still do.

You like to ignore the facts when posted, since it doesn't suit your argument, so I'll post it here:

Quote

Most pools, I imagine work the same as here - we do a call to bitcoind to get a template that already includes all the transactions we will mine.
Some pools may manipulate the transactions in their pool code - but we don't.
It is possible for us to mine an empty block under very rare circumstances out of the pool's control.
But that has never happened here for the 2429 blocks we have found.

Those circumstances are: a pool generates work that contains all the known transactions on the network.
That pool (here or elsewhere) then finds a block. During that short time (30s or less) no other transactions are seen on the network.
Thus after submitting the block found, the next call to get a work template from bitcoind will have no new transactions.

I log whenever the work is empty - I think it's happened less times than you can count on one hand in 6 years
Thus during those very few rare events someone would have to have found a block to produce an empty block out of their control.
So yeah maybe less than half a dozen possible empty blocks in 6 years for all pools on the network - the rest are them doing it on purpose.

As I have also stated to you before, I make my bitcoin debug.log report the transaction information for each work it generates, and I can also see in the bitcoin debug.log what is available in the first work after any block change.

Please stop posting like you're an expert, and research what you claim, before you decide to post incorrect information to promote your argument.

There is a lot more to the issue of orphans, again that you clearly do not know or understand, or have ignored

P.S. I'm probably older than you

Edit: the above is of course actually related to this thread.
The reason being that the OP of that other pool is ignoring this information (and the information about orphans that I will reply to him later) and thus increasing the risk to his miners.

Quote from: kano on May 27, 2020, 06:39:05 AM

Quote from: mikeywith on May 27, 2020, 05:22:38 AM

Quote from: kano on May 27, 2020, 02:56:13 AM

You are ignoring facts and the most obvious of those is the fact that my pool has found 2429 blocks so far.
No empty blocks in there.

2429 blocks is NOTHING in the grand scheme of things
...

Well that's if you are simply doing first grade math, counting and comparing block counts to the large pools with many more blocks.
Also a common mistake made by many bitcoin novices about mining pools.

I also understand the statistics of bitcoin and mining more than most people on the forum.
My pool provides more statistical analysis of it's results than any other pool.
I also do more statistical analysis of the pools results to check miners, that would appear to be beyond the understanding of any of the other pools, and many who've argued about pool statistics with me Tongue

Quote from: mikeywith on May 27, 2020, 05:22:38 AM

...
the pools in my analysis each of them probably found 100000% more blocks than your pool did
...

The total number of bitcoin blocks ever found is (at this point) 631862.
That's 25913% more, for the entire network over all time Tongue

No pool has even close to a third of that.
Yaw out by possibly up to 2 orders of magnitude

Even as a guess, that's pretty far off ...
When you go on about your mathematical prowess because you are using one of poisson's formulas that has nothing to do with your argument, I guess it's not odd you'd be ok at throwing out a random, highly inaccurate, uneducated guess, that you suggest is conservative, but is a massive over estimate, in the same post Tongue

Quote from: mikeywith on May 27, 2020, 05:22:38 AM

Quote

You obviously do not understand how work is generated by a pool and how a block can be empty, without the pool purposely producing an empty block like most of the large pools still do.

I understand very well that mathematically empty blocks MUST happen unless the time it takes to download a block, verify transactions, deal with the mempool, build a block =< zero ms, which is not true even if you claim so, even if all pools run on the same LAN with block size being 1byte time will never be =< 0, there will always be empty blocks and there will always be orphan blocks,

Incorrect.
Empty blocks have to do with the time between the last work generation sent to the miner that found the block, before finding a block, and the next work generation once your pool found a block.
The transactions that appear on the network during that time (or unused in the block) decide it ... as I have already stated ... and you clearly ignored or could not understand.

Quote from: mikeywith on May 27, 2020, 05:22:38 AM

Quote

So yeah maybe less than half a dozen possible empty blocks in 6 years for all pools on the network - the rest are them doing it on purpose.

Lol there is no "maybe", if you know the time it takes to download a block all the way to reconstructing it, you can tell EXACTLY how many empty blocks could be found without anyone doing it purposely, people have been studying statistics for hundreds of years not for you to randomly state that "less than half a dozen", i explained in a great detail what is concidered reasonable and what formula to use to figure that out, read the topic again and actually try to learn something.

Quote

Before you decide to post incorrect information to promote your argument.

Well all i did was use Siméon Denis Poisson's formulas, if you have a problem with it complain to him (sadly he passed away a few hundred years back or so)
...

You used it incorrectly, it's not relevant.

The "maybe" statement is correct and also a pretty accurate value, it's just that I've not looked for a while at how many there have been, since it's been so long since I've even seen one.

It doesn't matter how big or how small my pool is, my pool is part of the bitcoin network and sees the same transactions as every other well connected pool on the network - though mine is most likely the most well connected of all pools
(the other pool OP is also misunderstanding what needs to be done to handle this correctly)

When a block change occurs, my pool will ALWAYS see every transaction that was in the block, that's how bitcoin works.
It will also see what transactions were left over and available to use mining for the next block in the new work it will send out to the pool's miners.
This is the time gap/number of available transactions that decides if pools MUST generate an empty block with the new work they send to their miners.
This number is the "maybe" less than half a dozen in the past many years.
Until you understand what that means, please refrain from posting incorrect information about it.

Please research before you post.

What the other pools do, to purposefully produce empty blocks, is to not use a template with transactions generated by bitcoind, but simply generate work based on the hash of the block just found on the network, and nothing more - they cannot include transactions in the work when they do this, since they don't already know which network transactions have already been included in the block they don't want to get the transaction details of.
i.e. they aren't seeing the full block before producing a new block work template for their miners.

This was the cause of the failed/incorrect fork by Bitmain and F2Pool in 2015 - they lost all their 5 or 6 blocks on that bad fork since they built new blocks, on a fork of the network based on an invalid block, produced by another pool that ignored the network rule changes.

You could probably force most of the current large pools onto an invalid fork by mining a block with an invalid transaction in it Tongue

Quote from: kano on Today at 12:44:23 AM

Quote from: mikeywith on May 27, 2020, 06:51:52 PM

Quote from: NotFuzzyWarm on May 27, 2020, 03:21:26 PM

The only time an empty block MUST happen is the very very rare times mempool is empty. Aside from that, generating empty blocks is a conscious decision made by the operators of certain large pools. They are not a random event that any pool might do in the course of normal operations.

This is a misconception spread by Kano to advertise his pool.

Empty blocks MUST happen regardless of everything else, I can go with the technical explanation of why must they happen, but since I have already explained that I'll refer you to aantonop
...

Yet again, ignoring what I have posted here already that is the correct information.

The guy in the video is incorrect from the start.
He starts off on a false premise:
00:16 "It takes 15-20 seconds at least to validate a block"
False - it takes less than 200ms, often a lot less
Ask any of the bitcoin core developers and they will agree that it does not take anywhere near 15-20 seconds.
I'll give info further below that shows this also.

He is using the 15-20 second (false) claim, that the miners would be working on old stale work for an extended period of time before they could provide them with new work, if they waited for the block to be processed.
This ridiculously large time is false.
The whole first five minutes of his explanation is based on this premise which is wrong.
I gave up watching at that point.

Again, it takes less than 200ms from receiving a block in bitcoind, until it can produce a full new block template with transactions.
I have a message in debug.log when the block arrives with a timestamp to microseconds, another when it has been processed, and another when the pool has been sent the new work - yeah that's an extra step also - but the full time delay.

The largest block in the last 8 hours was 631950 it was 1783877 bytes.
bitcoind debug.log shows (as I mentioned)

Code:

2020-05-27 19:07:53.985131 ProcessNewBlock
2020-05-27 19:07:54.025189 Pre-allocating up to position 0x3000000 in blk02094.dat
2020-05-27 19:07:54.107985 UpdateTip: new best=000000000000000000067af76e3e524beabb9557f71413d8db9b88760e445d3b height=631950 version=0x20002000 log2_work=91.982404 tx=533594598 date='2020-05-27 19:07:33' progress=1.000000 cache=36.9MiB(236180txo) warning='75 of last 100 blocks have unexpected version'
2020-05-27 19:07:54.108131 Block 000000000000000000067af76e3e524beabb9557f71413d8db9b88760e445d3b provided by 107.191.117.193:8333
2020-05-27 19:07:54.158265 GetBlockTemplate called
2020-05-27 19:07:54.160724 CNB
2020-05-27 19:07:54.174358 CreateNewBlock(): block weight: 3964486 txs: 122 of 10917 fees: 0.04177550 sigops 20166

Also of interest in this case, it had to extend some disk space for the block.

Total time from when it arrived until the pool got new work 19:07:54.174358 - 19:07:53.985131 = 189227 microseconds 189 milliseconds

As for empty blocks, the one I see in the last 8 hours is 631926 by ViaBTC
I'll include the block before as well for more information:

Code:

2020-05-27 16:36:48.892330 ProcessNewBlock
2020-05-27 16:36:48.913863 Leaving block file 2093: CBlockFileInfo(blocks=99, size=133620045, heights=631826...631924, time=2020-05-26...2020-05-27)
2020-05-27 16:36:48.914006 Pre-allocating up to position 0x1000000 in blk02094.dat
2020-05-27 16:36:48.950898 Pre-allocating up to position 0x100000 in rev02094.dat
2020-05-27 16:36:49.011947 UpdateTip: new best=00000000000000000010dab51e5208c538fce5634104fbd059da24140911efe7 height=631925 version=0x27ffe000 log2_work=91.981925 tx=533547943 date='2020-05-27 16:36:37' progress=1.000000 cache=14.5MiB(52565txo) warning='72 of last 100 blocks have unexpected version'
2020-05-27 16:36:49.012075 Block 00000000000000000010dab51e5208c538fce5634104fbd059da24140911efe7 provided by 107.191.117.193:8333
2020-05-27 16:36:49.071051 GetBlockTemplate called
2020-05-27 16:36:49.071136 CNB
2020-05-27 16:36:49.088969 CreateNewBlock(): block weight: 3964991 txs: 1933 of 17715 fees: 0.18324281 sigops 13534
2020-05-27 16:37:08.482568 ProcessNewBlock
2020-05-27 16:37:08.490710 UpdateTip: new best=0000000000000000000f1b87afb1b95a5e681736ea387b60a8bd150b1ec8bb30 height=631926 version=0x3fff0000 log2_work=91.981944 tx=533547944 date='2020-05-27 17:06:23' progress=1.000012 cache=14.5MiB(52772txo) warning='73 of last 100 blocks have unexpected version'
2020-05-27 16:37:08.568545 CreateNewBlock(): block weight: 3964339 txs: 1903 of 17821 fees: 0.21419789 sigops 13493

In this case firstly, you can see the block before it was 20 seconds before it.
Secondly, in this case the work kano.is generated included 1933 transactions and fees: 0.18324281 BTC
However as can be seen from the next block on the block chain, it was only 315 bytes ... instead of our "block weight: 3964991"
i.e. our work that miners were working on was a full block, but ViaBTC miners were working on an empty block when they found it.

It took 196639 microseconds to process i.e. 197 milliseconds

Seriously, there's no point finding random online videos or random belief in some person (myself as well if you don't want to) about how bitcoin works.

Go run a bitcoind yourself and you can see this information - though you'll have to patch it and recompile it to display the extra information

I've been around in bitcoin since 2011 working on code related to it.
Working on mining code, pool code, and even simple patches to bitcoin itself.

Edit: corrected the 2nd block information - I showed the wrong block Tongue

Edit2: and of course it didn't take 197 milliseconds longer than ViaBTC - they didn't process it in 0ms Tongue