Topic: Taproot activation initiative (Read 482 times)

But that is quite clearly about Taproot activation.
Before Taproot activates, your pool will allow Taproot transactions because it doesn't verify any transactions before it switches blocks after a block change for a period of time.
Once Taproot activates, that wont matter for Taproot, since Taproot transactions will be valid.

Kano can we keep this strictly about taproot activation and not about this pool does that or this, come on!

Please submit a PR here: https://github.com/taprootactivation/Taproot-Activation/pulls

Heh - since KanoPool isn't listed, I'll give you some work to do - add another row

Not sure what LOT means (anything to do with LotR?)
But, yes we will be running 0.21 (or later) well before activation and thus allow Taproot.
Which I guess means 'Y', '1yr', 'TBD'

(currently still running 0.20 since it's never a good idea to switch to a new version before others find the problems with it )

The 'TBD' for the coinbase is pretty much that it doesn't matter with our current pool size - but of course if I manage to get some of the hash rate from large pools such as yours that charge ridiculously high fees, to join such a low fee (but better) pool as mine, it may matter then and I'd add a cb message.
No chance of Taproot causing problems with transactions in my pool, since we validate ALL transactions before switching work to the next block.
That can't be said for most if not all of the large pools.

---

I added two new columns to the taprootactivation.com table. One column for LOT=TRUE or LOT=FALSE and another column EITHER (meaning both TRUE or FALSE are fine).

Thoughts?

Nova

Not looking for better proof, just funny how a comment in twitter is considered binding by some and random garbage by others

Doesn't matter what I support, my pool is currently too small to have any effect.
Even when we were bigger and we were wholly against segwit, it didn't matter even then.
Core's decisions are generally unrelated to the pools anyway, they're driven by the obvious expected: money.
Since your pool makes an excessively large amount of that, why not use some to get core to do something useful

Hey kano, which other pool is signaling taproot?

EDIT: if you would like more concrete proof from the pools you can try asking them yourself and this goes for anyone else that is reading this too. i'll take all the help i can get

EDIT: What should i put down for KanoPool, Kano? Would be nice to hear if you support taproot... or not. thanks!!

Well I will say it is interesting how 'proof of support' is considered 'proof' just by a comment on twitter

Also interesting that there's only 2 pools that are putting /taproot/ in their coinbase, and one of them - poolin - isn't even doing it consistently since some of their blocks do have it and others don't ...

(I have a dump of the cb sig, of every block that arrives, prior to most of the validation, in my version of bitcoin, thus I can easily see this in the debug.log)

---

Antpool added, Taproot: YES
Preferred activation method: BIP8

Luxor added, Taproot: YES
Preferred activation method: BIP9 equivalent

SigmaPool   Undecided               
NovaBlock   Yes   BIP9 equivalent, BIP8(false, 1y)       
ViaBTC    no answer        
Binance Pool   no answer            
Huobi Pool   Yes   
58COIN&1THash Yes


total amount of global hashrate (1 month) in support of taproot is at 73.8%

Like every single pool on the network, we generate a new template on a block change.
Like every single pool on the network, we can tell how many transactions were available for the new work for the block change.


There's the thread you've already read about this that gives you the answer:
https://bitcointalksearch.org/topic/why-not-to-mine-on-pools-mining-empty-blocks-and-why-do-pools-mine-empty-blocks-5251592

You mean this:


Every 30 seconds isn't exactly every second, so there must have been many potential empty blocks that went unnoticed by your KDB code, no? and if I know how to run the cumulative distribution function then 0.166% of all blocks "could" be solved within 2 seconds which is about the reasonable time to download and verify a block which miners are free to bypass and start working on the next block immediately.

I also don't seem to understand why empty blocks are considered "bad", as far as I can see, they make the blockchain longer and more secure, they don't affect your pool or any other pool's chances of finding another block, I also don't understand why would any pool not include any transaction (leave money on the table) if they have enough time to deal with the previous block's transactions, I also can't find the logic behind a miner who would "pause" their potential earnings in order not to mine an empty block even if that was 1ms worth of hash power, I would really appreciate if someone can explain to me why would any rational miner not start working on the new empty block as long as their chances are >0%.

'Necessarily'? No. But alas they all are.

The extra time is under 50ms
I add a few extra log lines to the bitcoin I run. My main server debug.log shows the time from "GetBlockTemplate called" to "CreateNewBlock()" complete to be under 30ms, sometimes close to 10ms.

'All' the large pools do this because they believe that building a block on top the new block work sent out from another pool, before they get the actual block from the bitcoin network, will save them a lot of time (SPV/spy mining)
Alas the work sent out should actually be on par with the block sent out - but the block network time being slower due to being larger.

Yep, you can add in your own transactions to move data around the pool wallet, that would never be seen on the network before being confirmed

To gain an extra 30ms out of a 600,000ms average block time, and assuming without it they could mine 599,000ms i.e. assuming a high 1000ms are always stale doing block changes, would give them an extra 30/599k = 0.005% extra mining time = extra non-stale blocks.

Well when Matt shut down the fibre relay, that gave them an excuse to continue.
I guess he wasn't being paid - the big pools decided they didn't need it due to the SPV (spy) mining?

Edit: oops average block is of course 10mins - I put 5min - corrected.

Empty doesn't necessarily mean the ancestor was not-validated.

It takes a lot more time typically to generate a template than to accept and validate a block-- so it would be completely reasonable to accept a block validate it, and then issue an empty template before revising with a complete one.

Moreover, it's perfectly possible to include transactions while not having validated the prior block though no one has bothered to implement that because that would be hard and would require enough competence that you'd also realize that not validating is a really bad idea.

So while I do agree that it's indicative, it isn't conclusive.

Short of mining an invalid block and seeing if they attempt to extend it I don't believe there is a way to tell for sure.

Sadly, there is no way to prevent miners from doing this.  The amount of time they do it can just be minimized by making block propagation and processing as fast as possible. However, if you run and maintain a full node you'll be protected from ever seeing those junk blocks and if you don't mine at a pool that engages in this stuff then you won't lose mined bitcoin due to it.

Alas pretty much all the large pools still do it, and even Slush has joined them in doing that also.
It's easy to see, since they are generating empty blocks but the mempool isn't empty.
My bitcoin debug.log shows it clearly - for the work generation on a block change.

In the last 8 hours there's 3: AntPool, Huobi and Nova

As I've also mentioned elsewhere, my KDB reports every time empty work is generated by my pool - and that probably amounts to less than you can count on one hand is the past 6 years.
The obvious reason being that transactions are added to the mempool while the work that 'emptied' it is being mined, until the block is found.
Thus you'd average 15 seconds of new transactions for work that's generated and sent to miners once every 30 seconds by a pool.
Of course this could be 1 second or 30 seconds, but again, the mempool being actually empty at the time a block is found is exceptionally rare.

Given the spate of empty (unvalidated) blocks today done by Antpool, Huobi and others, yes. Old and risky habits *do* die hard

BIP340 isn't itself something that gets activated.

BIP-341 is, which incorporates BIP-340 and BIP-342 by reference.

Though there is no activation defined for BIP-341 yet.  I believe the effort neutraLTC is discussing is in part intended to help gain information that will help the community decide on activation details.

No one will do that unless they've disabled/bypassed transaction validation on the transactions they accept as BIP341 uses a not-yet-defined output version.  If they've disabled/bypassed validation then they will potentially produce invalid blocks even completely absent BIP341-- the problem there is extending a chain without validating it.  There is little need for miners to do this anymore due to optimizations, but bad habits die hard I guess.

mining pool operators that wish to upgrade to taproot, make sure to reach out, thank you

This update can lead to an interesting problem caused by the way big pools such as Poolin don't validate block transactions during a network block change.

As is well known in 2015, Bitmain and F2Pool forked off onto an invalid fork for 6 blocks due to code errors in their block validation, back when the Poolin 'leader' was part of Bitmain.
The errors were specifically that they didn't enforce the BIP change that was implemented and allowed a block by a small pool that ignored the BIP change, and Bitmain and F2Pool built on top of that invalid block.

This time, however, it's worse.
Since Poolin doesn't verify the transactions at the start of each Bitcoin network block change, but builds and sends out work to their miners before they verify the transactions, if any pool puts a BIP341 transaction into a block, before BIP341 is activated, Poolin will accept the block and send out new work to their miners, based on the invalid block.

Since most of the large pools do this, you can see this for any pool that generates empty blocks, and have their own coded versions of the rules of: Bitcoin, BIP updates and other such rules, it's not all that improbable to think it can happen again.

Be wary of mining on pools such as Poolin that don't verify block transactions before sending block change work to their miners.
This is highly relevant to BIP changes.

btc.com mining pool added to the list.

removed direct link to poolin thread, please do not delete this thread

Regarding activation - you'd want to point out if core will agree to merge the changes or not.

See - when SegWit was being forced on everyone, the pools all did a coinbase vote for BIP100 and it got over 75%.
The problem was, core wouldn't do it. So It never happened.

Later when the large pools all got together and decided they would go ahead with SegWit, but with some required later additions, SegWit went live.
Alas the later additions were all ignored and core basically told all the large pools to piss off and that was the end of it - the large pools all showed they had no power to do anything except make forks of bitcoin like BitCH coin.

So ... obviously that information about Core's opinion of your change is rather important, and since you've said NOTHING about that, I'd guess this is all a waste of time?

Edit: OK here's the link that your post (and site) is missing:
https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki

Edit2: it also requires Bip340 to be activated first ... which it hasn't yet.
https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki

Hello mining pool operators! Independent miners!

Happy to announce the site https://taprootactivation.com.

---

Taproot is a proposed Bitcoin protocol upgrade that can be deployed as a forward-compatible soft fork. By combining the Schnorr signature algorithm with MAST (Merklized Abstract Syntax Trees) and a new scripting language called Tapscript, Taproot will expand Bitcoin’s smart contract flexibility, while offering more privacy by letting users mask complex smart contracts as a regular bitcoin transaction.

A soft fork is a change to the Bitcoin protocol wherein only previously valid blocks/transactions are made invalid. Since old nodes will recognize the new blocks as valid, a soft fork is forward-compatible.

Soft forks can be activated in several ways. Several of the previous soft forks have been activated using BIP 9, which requires a (super)majority of miners (by hash power) to signal support for the upgrade. A proposed alternative is BIP 8, which could activate the upgrade after some time even without a (super)majority of miners signaling support.

The aim of this site is to assist in the activation of the Taproot soft fork. We have reached out to several Bitcoin mining pools to find out if:

If they support the Taproot upgrade
If so, which activation method they prefer
If they want to insert a coinbase message in a block to announce their preference (even before the actual activation window opens)

---

Please comment here, create a PR here: https://github.com/taprootactivation/Taproot-Activation or reach out through email ([email protected]) if you would like to get added to the list.