Taproot proposal

[Wind_FURY]

Apparently, Marathon is going to signal Taproot Activation:


https://twitter.com/michael_saylor/status/1399407493839732744?s=21

From Marathon Press Release

“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,” said Fred Thiel, Marathon’s CEO. “Over the coming week, we will be updating all our miners to the full standard Bitcoin core 0.21.1 node, including support for Taproot. By adopting the full standard Bitcoin core node, we will be validating transactions on the blockchain in the exact same way as all other miners who use the standard node. We look forward to continue being a collaborative and supportive member of the Bitcoin community and to realizing the vision of Bitcoin as the first decentralized, peer-to-peer payment network that is powered by its users rather than a central authority or middlemen.”

hahahaha

Are they going to just temporarily behave well or go back into dumbass mode when it seems opportunistically beneficial to them.. .. time will tell.. and yeah, there are likely some miners who are not exactly committed to the "core tenets of Bitcoin" even though they will talk the talk for a while and even walk the walk in order that might be able to wait for a better time to fuck around with their own dumbass sucking up to the PTB values that might be deeper within them...  Hey, but bitcoin was built for the ability to tolerate friends and foes from within and surely the incentives may well beat up upon some of the ones who play around too much.. .  We will see.. we will see.  

Nice to hear the statement though (even if it might not be their true feelings and thoughts).. so don't get me wrong about that.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

[1714815746]

1714815746

[1714815746]

1714815746

[1714815746]

1714815746

[1714815746]

1714815746

[1714815746]

1714815746

[1714815746]

1714815746

[fillippone]

“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”

I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

It's more likely investor realize censorship (by excluding certain address/transaction) isn't very profitable.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

First of all, the full node software must have feature to detect who mine block. However, i don't know any full node software which have such feature, so i guess it's not possible (at least for now).

My feeling is that stock price has little to do with this back-pedalling.
Sure, MARA stock has been lagging the market recently, but I. Guess their performance is highly correlated with bitcoin price.

I would rather point to the appointment of the new CEO: Fred Thiel has been nominated CEO since April 26th.

So he has been at the helm of MARA for a little bit more of one month.


Still,  I cannot figure out if this change in policy is the effect or the cause of this new appointment.
But I think this analysis, albeit very interesting, is quite off topic in this thread.

[Karartma1]

“Marathon is committed to the core tenets of the Bitcoin community, including decentralization, inclusion, and no censorship,”

I wonder if their stock devaluation had anything to do with this considering that it has been dumping ever since its April pump. Maybe seeing $19.66 after reaching $56.56 was a wake up call that the investors don't like malicious miners.

It's more likely investor realize censorship (by excluding certain address/transaction) isn't very profitable.

I have always thought about something like this, but I’m not so sure about the possbility, “What if a majority of full nodes manually adds a misbehaving pool in their ban list”? Would a threat like that be effective in discouraging censorship by a mining pool?

First of all, the full node software must have feature to detect who mine block. However, i don't know any full node software which have such feature, so i guess it's not possible (at least for now).

My feeling is that stock price has little to do with this back-pedalling.
Sure, MARA stock has been lagging the market recently, but I. Guess their performance is highly correlated with bitcoin price.

I would rather point to the appointment of the new CEO: Fred Thiel has been nominated CEO since April 26th.

So he has been at the helm of MARA for a little bit more of one month.


Still,  I cannot figure out if this change in policy is the effect or the cause of this new appointment.
But I think this analysis, albeit very interesting, is quite off topic in this thread.

What if it's just a way to take time, comply with the bitcoin governance and secretly planning for counteroffensive? I always look for the motives behind the actions, I'm a kind of action-reaction guy. They have an agenda but for the time being it's not clear what they'll do but I guess we'll know soon.
Thanks for the info stallion

[franky1]

i know its gonna get deleted but oh well..
once activated... pools can still fill blocks with native transactions.
all that happens is a pool not analysing every byte in a block may end up accepting a block that other pools reject.
EG if a malicious pool X:
(1)makes a broken taproot tx
(2)puts it into a block
(3)manages to be first to broadcast the solved block...
the pool Y not analysing all the data would just blindly accept it because they dont know the new taproot rules. and as such. would fork themselves as they would then be building on the wrong chain. as the other95% of pools would have rejected a block instantly as they have upgraded and seen its a broke tx and not include it.
the pool Y not analysing all the bytes might build on that block to create their own chain. or they orphan it off a few blocks later once they see other nodes orphaned that block

a pool cannot just push in a block with a duff transaction and think it will last. unless all the other pools dont know the ruleset.
hense needing solid majority to have upgraded. before even allowing a new tx format

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms

though i have no use for taproot atleast this time its a fair voting system with no backdoors to force it in. so if it activates. it activates

[gmaxwell]

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms

Agreed, though the merchant in that case can be protected against an unupgraded miner by the merchant themselves upgrading.  If the merchant is upgraded they won't see the invalid confirmation.

A miner that intentionally produces an invalid block can cause non-validating clients to see a false confirmation is always true, not unique to taproot.  It is, however, a pretty expensive attack.

The high hashrate means that any invalid confirmations will go away quickly, and confirmations that go away after a block or two is already a thing people need to be prepared to handle due to reorgs.

So if you're upgraded you're protected by your upgrade, and if you're not-- you're still protected by the high hashpower.   If you're not validating at all, you're only protected by high hashpower, taproot or not.

One wrinkle in this is that right now many (most?) hashpower spends part of their mining time mining on non-validated work, because this is an easy 'optimization'.  I don't think it's a rationally justified optimization because you can get the same speedup from other approaches without losing validation but not validating has a low upfront cost.  This can cause short chains of invalid blocks where otherwise there would just be a single invalid block.  It really hurts the security assumptions of lite clients.  Fortunately, for the moment these non-validated blocks also contain no txn except for the coinbase, this isn't fundamental either but again its the easiest thing to do,  so wallets should probably not count chains of consecutive empty blocks as confirmations for confirmation counting purposes.

[PrimeNumber7]

the only risk is if a merchant/service/exchange is relying on the unupgraded pool Y as a chain source where by the merchant sees the temporary block and think its valid. and if a user that done (1) may have a oppertunity to double spend.
which is another reason why merchants should not accept 0-2confirms

Agreed, though the merchant in that case can be protected against an unupgraded miner by the merchant themselves upgrading.  If the merchant is upgraded they won't see the invalid confirmation.

A miner that intentionally produces an invalid block can cause non-validating clients to see a false confirmation is always true, not unique to taproot.  It is, however, a pretty expensive attack.

A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules. A delay between a soft fork being “locked in” and when it is actually implemented reduces the risk that invalid blocks will be propagated by major pools.

A pool that doesn’t implement a softfork they oppose after said fork has been locked in can be compared to someone burning money. Any blocks they mine that violate the softfork rules will be orphaned by other miners.

[pooya87]

A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules.

This is unlikely because the bitcoin network (ie. full nodes verifying everything) by default won't propagate invalid transactions. New nodes because they validate Taproot and reject if it is invalid and old nodes because they see it as non-standard so even if they receive an invalid Taproot tx they simply won't relay.
The miner (or the pool) is also running a full node that doesn't accept version 1 witness program on its old node since it would see it as non-standard.

The only possible outcome of not upgrading is building on top of an invalid block. This is also unlikely because as I said above miners won't include anything they can't validate so it is already unlikely to see an invalid block.
A malicious miner could mine an invalid block intentionally but it costs a lot of money (wasted) and again we have the same arguments about propagation, the nodes won't propagate the block to reach the other miner to build on top of.

[cygan]

the minerpools arkpool and okkong mined their first blocks signalling for taproot readiness


https://twitter.com/hampus_s/status/1399960827374063616

mara pool is still missing...
https://taproot.watch/miner/MARA%20Pool

[PrimeNumber7]

A hypothetical miner that strongly opposes taproot is going to upgrade very shortly after taproot is locked in, as not upgrading means that other miners will potentially reject their blocks if their blocks violate taproot rules.

This is unlikely because the bitcoin network (ie. full nodes verifying everything) by default won't propagate invalid transactions. New nodes because they validate Taproot and reject if it is invalid and old nodes because they see it as non-standard so even if they receive an invalid Taproot tx they simply won't relay.
The miner (or the pool) is also running a full node that doesn't accept version 1 witness program on its old node since it would see it as non-standard.

The only possible outcome of not upgrading is building on top of an invalid block. This is also unlikely because as I said above miners won't include anything they can't validate so it is already unlikely to see an invalid block.
A malicious miner could mine an invalid block intentionally but it costs a lot of money (wasted) and again we have the same arguments about propagation, the nodes won't propagate the block to reach the other miner to build on top of.

How do you think an invalid block would be mined in the first place? After a softfork, a miner including an invalid transaction in their block will result in an invalid block.

The miners' nodes are also more-or-less all connected to each other because the miners all want to be able to start mining on top of the most recent block as quickly as possible and waiting for blocks to naturally propagate throughout the network can take precious seconds (or longer) that a miner would be spent on building on top of what is not the most recent block. This means that any block that is propagated by a major miner, valid or otherwise will generally be seen by the other miners.

[kano]

Alas there is a bigger issue, that the large majority of the mining hash rate doesn't verify any transactions when they first generate work after a block change.

Since this small window exists, there is the quite reasonable chance of another pool finding a block on top of an invalid block.
If this next block is valid, the questions follows of what do all these pools do when they see this valid block built on top of an invalid block?

History shows that they just continue on when this happened once before.
The issue being how tightly is the pool work generation tied into a full bitcoin daemon that would reject both of these blocks?
... and unless every large pools just copies code from every other large pool, there will no doubt be many different answers to this question.

[NotATether]

The issue being how tightly is the pool work generation tied into a full bitcoin daemon that would reject both of these blocks?

Given that pretty much all the pools are using stratum that means this is a question of how often the stratum servers are querying bitcoind. Mining hardware can't stop hashing while it waits for bitcoind to do its verification because it doesn't even know when and at what rate it's running.

If this next block is valid, the questions follows of what do all these pools do when they see this valid block built on top of an invalid block?

History shows that they just continue on when this happened once before.

If a pool submits a block immediately without doing any verification, then eventually when a split happens and the pool's chain is outrun then its mining rewards will be invalidated. And if a pool risks verifying before submitting the block then another pool might submit a block before them and they lose out. So there isn't really a benefit for pool to push for either case, so naturally, most go for the short-term route of submitting the block as quickly as possible, which means that there's always going to be cases of invalid blocks sneaking into the chain at least temporarily.

[gmaxwell]

can't stop hashing while it waits for bitcoind to do its verification

Actual validation typically takes under 50 milliseconds or so-- and even faster on hardware with sha-ni--, typically because almost all the validation is cached. During that amount of time you might as well stay on the prior block because you have a non-zero chance of winning on the prior block anyways in a race, and not including transactions will greatly reduce your income.

But the validation isn't the only, or largest, source of delay.  E.g. constructing a block template takes time.  Miners could instead always mine on already validated tips, but include a very suboptimal block (including empty) on the initial work they generate on a new block, but that would take more work to implement than just monitoring other miners and mining whatever other header they mine on.  It also avoids worrying about various other block propagation DOS vectors.   But it really trashes the security assumptions of SPV pretty bad.

It's kind of a circus, eventually some miner going to do that is going to get a SPV user robbed, and since all the miners are helpfully identifying themselves, they're going to get sued for damages by the robbed user and it's going to turn into a complete circus.  Years ago I talked a major exchange out of attempting to sue miners that mined txns which weren't the same ones the exchange saw first... took some real effort to get them to understand that just because they saw the other spend first that didn't mean the miner did.

Fortunately, you can opt out of the exposure by running your own full node and keeping it up to date, or by treating high value transactions from untrusted parties as unconfirmed until they have a dozen confirmations or so.

[nibor]

gmaxwell - do you think that many pools are reliant on patched bitcoind nodes to maximise their profits (since most are pps - it is their profit not the miners that is impacted by orphans/empty block trade-off).

Those 20 pools are arguably the most critical users of bitcoin core. And should it not include every possible optimisation (even if at expense of SPV) to ensure they run vanilla code. As that then ensures that future soft/hard forks go smoothly as those 20 users just have to do an upgrade from version 2x ->2y - rather than having to try to merge in some old patch and try to test it works as expected.

Or is issue that those patches are proprietary and what gives them their competitive advantage.

I guess since the pools are operating off 2.5% margin on pps - it magnifies by a factor of 40 P&L impact of orphans.

[gmaxwell]

Or is issue that those patches are proprietary and what gives them their competitive advantage.

It's mostly not patches but external mining software. Some of the less good things they do are done because thats whats easy to do outside of the daemon. Not so fun to reimplement consensus rules, so why bother?

The viabtc mining code is public and you can see many such approximations.  E.g. they decide if an incoming block meets the target by the deriving a number of leading zeros off the floating point difficult number rather than an accurate target test.  So if you make a block with a lot of leading zeros but still doesn't meet the target, that code will temporarily switch to it and mine children that will be ignored by every bitcoin node an wallet.   There is no meaningful computational cost in doing the test accurately-- it's just more implementation effort for an external codebase. The fact that it's fairly easy to attack (mining hardware ordinarily returns sub target work, so it would be easy enough to filter that for work that met the relaxed test but not the real target... Presumably they'd fix it once they noticed they lost blocks to it.

I guess since the pools are operating off 2.5% margin on pps - it magnifies by a factor of 40 P&L impact of orphans.

One thing to consider is that 2.5% PPS is pretty much guaranteed to go bankrupt per kelly criterion with a reasonable bankroll.  Computationally bounded rationality can be a problem when your system's assumptions depend on rational self interest.

One place where Bitcoin suffers is that it's very stable, and you can keep running old versions. As a result multicryptocurrency pools spend a lot of attention on trashfire altcoins that needs constant emergency fixes, and less on Bitcoin. There have been problems with stuff like newer bitcoin needing a compiler no less than 3 years old but some large miners have much older operating systems.  I don't think there is any real fix except increasing the rate of change-- it's a point I've raised in disagreements that argue that Bitcoin's conservative approach is safer. To a point that's true, but there is a point where being too slow to introduce changes introduces its own risks.

Hopefully taproot marks the end of a one time dry spell and with renewed confidence that clear improvements can be activated without disruption more will be written.

[franky1]

just to clarify many above posts

pools= servers that collate the transactions and make blocktemplates and thus the hash to give asics
miners=asics that never see a tx. they only see a hash(+nonce range +difficulty) and send back a new hashsolution meeting a difficulty threshold.

pools arnt miners. miners arnt pools
pools which manage multiple coin use different servers per coin. thus upgrades of one coin dont affect/delay other coin upgrades. (different men in different office.. not banging heads together)

miners(asics) dont send every attempt back to a pool. an asic is provided with hash, nonce range and difficulty target. if they run out of nonce range allocated to them. they just request another nonce range
they wont send a hash back unless it meets the threshold

..
anyways
(although most tx are prevalidated during tx relay prior. some blocks include new tx not pre relayed thus requiring nodes to request the tx during the block checks.. its actually this tx request delay that extends block validation delay alot of the time(exploitable))

when a blockX is propagated headers first.
the <2min timespan of propagation, analysis difficulty of solved hash, see tx list, see which tx are missing. fetch missing tx, valid fetched tx.. sha the block, make sure it matches the hashs announced earlier.confirm a block.
(i dumbed down the entire process. dont knitpick)

pools have 3 options during this <2min window from header first to confirm/reject result of blockX:
1.([ethically] start a empty block)
   it takes miliseconds to add previous hash, sha template, send hash to asics with nonce range and diff
   hoping that theeir workers can get a block solve in 2minutes or less while pool validates blockX.
   once blockX has been analysed.
   a. if faulty.
       i. return back to their own blockX at last nonce range and finish off their own blockX hash race
       ii. start new blockX from 0nonce again
       iii. if another pool propagated a blockX in that interval start a empty blockY on the other blockX until analysed
   b. if valid
       i. continue with empty blockY
         (usually empty blocks only spotted on network <2mins after previous block)
         (only roughly 280blocks of 58k are empty(2020stats). so its not that often<0.5%)
       ii. start a new blockY including unspent tx *

2.([ethically] continue blockX)
   this is where a pools sees the header but needs time to fetch&analyse tx list and other checks
   so they continue their own blockX
   once propagated blockX has been analysed
   a. if faulty
       i. no fuss. they just continue on with their own blockX effort.(rejecting the propagated blockx)
   b. if valid.
       i. they create new blockY with unspents included*

*(block template takes a few seconds to collate new unspent list, to hash it,send hash to asics with nonce range)
(this is usually the case in 99.5% of pool strategies)
(some pools have a template ready with transactions in. and just remove spents (half filled blocks))
(some pools wait until all spents of prev block are discounted, then make block from scratch(full block))

3. ([intent or ignorant] build on first propagated blockX no matter what)
    this is where a pool sees the header and just builds on it no matter the content validity
    this case in regards to TR activation is (after activation) the 5% pools not fully validating
    a. if faulty.
       i. they build on faulty block X with their blockY.
         if they solve blockY first. the 95% of pools would orphan blockY because they already rejected blockX
         (orphan because child is rejected by society because parent is lost)
       ii. continue with a blockZ even though 95% already orphaned blockY = pool created its own altcoin
          which 95% pools will keep orphaning off until ban hammering nodes propagating such blocks
    b. if valid
        i. pool is part of the network for now. but just doesnt know what is fully in the blockX

..
the chance of a orphan heavy scenario due to 3.a.i&ii is not just under 5%. but also under 0.5% of that 5%
the only way to up that 0.0025% chance is if the pool in question has more then 5% hashpower.. and on top of that they are intentionally making faulty blocks. and ontop of they willing to build on those blocks
.. but over all its like a 0.0025% risk generally
so dont be too worried about orphan drama.

but as i said the only real risk is merchants accepting payment with 0-low confirms from single blockchain source peer. as its the block source from multiple peers that is the extra mitigating factor that avoids following the wrong blocks for too long

[gmaxwell]

as its the block source from multiple peers that is the extra mitigating factor that avoids following the wrong blocks for too long

I'm aware of no SPV wallet that looks to multiple sources, and it would be almost certantly a waste of time to do so--- it's cheap and easy for an attacker to outnumber the honest hosts on the network (that's part of why it's used for consensus!), if an attacker can be one of your peers he can be multiple without much more difficulty.

SPV wallets are strongly predicated that miners validated the block and are honest, to that extent that isn't true, SPV is just not particularly secure.

[franky1]

we both know the network layout

its in tiers like:
pools
Fibre network/ merchants
user fullnodes/lite wallet servers/aws servers
spv wallets/phone apps

no top line fullnode in the first 3 categories/tiers will waste one of its peer slots on a small SPV user
they want to be well connected to secure nodes with static IP and have full blockchains.

so by the time blocks have propagated hop by hop down the layers of nodes and reached an SPV. most of the duff blocks have already been rejected by the nodes up the layers and so spv wallets wont even get to see them

spv wallets are for the bottom tier of the network that come and go off/online sporadically even more so than user fullnodes.

its like torrents(analogy)
pools are the seeders.. spv are the leachers
pools wont want leachers attached to them direct.
heck even merchants dont want leachers

SPV leachers rely on the many tiers to have been the buffer of removing unwanted junk.
much like torrent leachers wait until there are many seeds before downloading because they want their seeders before them to have weeded out the files that contain trojans/viruses.

again there would be a risk if a spv was direct peer to a intentional malicious pool. but the way the network has self regulated and chosen its peers with white listing and ban hammers over time.
a SPV wont be found connected to a pool direct. and a merchant wont then be connected to a spv(as spv dont retain block data to pass along)

so there is no pool->spv wallet->merchant scenario
a merchant will never leach from a spv for obvious reasons.

[kano]

pools which manage multiple coin use different servers per coin. thus upgrades of one coin dont affect/delay other coin upgrades. (different men in different office.. not banging heads together)

A merged mined (mm) coin requires supporting that in the coinbase of the Bitcoin work sent to the miners.
Thus the Bitcoin work generation requires code changes when supporting any scamcoin or when the scamcoin changes anything related to that.
Each Bitcoin work generation also requires access to the scamcoin so that the mm information in the coinbase is accurate.
Most pools do this (look for a larger coinbase sig with the letters 'mm' in it)

If instead you are talking about a scamcoin being directly mined on a pool, well that's off topic here anyway

miners(asics) dont send every attempt back to a pool. an asic is provided with hash, nonce range and difficulty target. if they run out of nonce range allocated to them. they just request another nonce range
they wont send a hash back unless it meets the threshold

The miner is in 2 parts:
1) the asic processing the work the miner software sends to it
2) the miner software talking to the pool or bitcoind and talking to the asic
Using stratum, as every Bitcoin mining pool does, they wont exhaust the nonce range, the mining software can generate an exceptionally large amount of work from a single stratum work item sent to it by the pool.
The limit is only ever possible to approach when using a poorly configured proxy, sitting between the pool and a very large number of miners.

anyways
(although most tx are prevalidated during tx relay prior. some blocks include new tx not pre relayed thus requiring nodes to request the tx during the block checks.. its actually this tx request delay that extends block validation delay alot of the time(exploitable))

It's very rare to have delays with a block change, unless you're bitcoin network management is not at the level of a well setup pool
i.e. you may have this issue if you are a typical home user doing home solo mining or using a poorly configured pool

It also makes no sense for a large pool to hold transactions until they submit their block.
This will mean that they are competing against the whole bitcoin network accepting their new block, vs everyone on the network trying to find the previous block as a replacement for their block, during the delay this causes.
Of course the coinbase transaction does not fall under this, since it must be transferred with the block header (and thus the smaller it is the better)

when a blockX is propagated headers first.
the <2min timespan of propagation, analysis difficulty of solved hash, see tx list, see which tx are missing. fetch missing tx, valid fetched tx.. sha the block, make sure it matches the hashs announced earlier.confirm a block.

This time frame is milliseconds, not even seconds.
If you are taking seconds to do this, you can expect a much higher chance of lost blocks due to either:
1) being stale - no one else on the network will accept it and the only way to not lose the block would be for you to get a fast 2nd block on top of your own
2) orphaned and likely to lose the orphan race due to not getting your block out to the majority of the network, if you were only a few hundred milliseconds behind someone else, not seconds

This incorrect assumption means you need to redo your 3 options.

*(block template takes a few seconds to collate new unspent list, to hash it,send hash to asics with nonce range)

Only milliseconds.

3. ([intent or ignorant] build on first propagated blockX no matter what)
    this is where a pool sees the header and just builds on it no matter the content validity

The majority of large pools do this - they build on the header without verifying the merkleroot - which means without verifying the transactions.
It would seem that over the last few years they finally realised they could speed this up a little by sending their miners new work as soon as they had verified the transactions.
Thus the time they are working on a possible invalid block has reduced.
But alas, this is still the large majority of the bitcoin network.

Fibre network/ merchants

Alas the public fibre network is no longer in existence for quite a while.
Any pool or solo miner needs their bitcoin connected directly to, or at most 1 step away from, the large pools.
Each step will slow down the propagation of any blocks you find.
If you want to compete in the Bitcoin world on your own, you need a network configuration able to compete with the large pools.

[franky1]

for the point about pools.
il use one example.
slushpool has 3 servers for btc. and another 3 for zcash
thats 6 different instances separated by physical space so no butting heads.
they may seem like its a single pc becasue of brandname "slushpool" not being plural.
but i guarantee you they have separate machines

talking about solo mining is 2012 era stuff
as for saying mining is 2 parts being the asic and the pc connected to a bitcoind or a pool.. thats 2013 era stuff

solomining aint a thing anymore and asics these days dont connect via a PC they just have a network cable direct to a router.

seems your knitpicking for knitpicks sake.
shame its based on 8+year old scenarios

as for the bit about 'why would pools not pre-broadcast their private tx before block..
i said most pools do broadcast.. but alas nothing is forcing them.
thus its an exploit that could be used.
previously.. much much more recently than 8+ years ago i have seen pools do just that.
and yes the amount of times nodes have had to request tx's because they are not in their mempools has been a factor in the confirmation process.
it is good practice to broadcast tx's before block has propagated. but its a known thing that it is not a 100% case that good practices are followed


anyway..
all my points in this post and posts prior of this topic are just to show that while some are worried about chainsplits/orphans and even spv issues to the network(facepalm) solomining issues(double facepam) if/when taproot activates. those risks are not even 1% risk.. not even 0.1 nor 0.01% risk. so relax

[kano]

for the point about pools.
il use one example.
slushpool has 3 servers for btc. and another 3 for zcash
thats 6 different instances separated by physical space so no butting heads.
they may seem like its a single pc becasue of brandname "slushpool" not being plural.
but i guarantee you they have separate machines

You seem to have missed my reply about that. Read it again - the first reply in my post.

as for saying mining is 2 parts being the asic and the pc connected to a bitcoind or a pool.. thats 2013 era stuff

This is today as well as 8 years ago.
They tend to call it a 'controller' - it's a computer separate from the asics mining, sitting inside the box for some miners and outside for others, connected to the hash boards, usually running linux.

seems your knitpicking for knitpicks sake.
shame its based on 8+year old scenarios

Everything I've said in my previous post is how it currently works.
The only uncommon part is people solo mining to their own bitcoin, though people still do this for what's called 'lottery mining', but it is indeed a risky venture also.

as for the bit about 'why would pools not pre-broadcast their private tx before block..
i said most pools do broadcast.. but alas nothing is forcing them.
thus its an exploit that could be used.
previously.. much much more recently than 8+ years ago i have seen pools do just that.
and yes the amount of times nodes have had to request tx's because they are not in their mempools has been a factor in the confirmation process.
it is good practice to broadcast tx's before block has propagated. but its a known thing that it is not a 100% case that good practices are followed

Indeed nothing but logic is forcing them to.
The risk of losing a block, and thus lose a few hundred $k, does help most of them to make that best decision.
It will not be common, to not have a transaction before a block arrives, since the pool who found the block will have seen the transaction before even sending the work to the pool's miners, so although it is indeed possible by accident and not by design, it wont be common.
For well connected pools I'd suggest that it should be rare.
I'd take a guess around 1 in 100 blocks (or better) since 21st Dec