Topic: Taproot proposal - page 14. (Read 11258 times)

I agreed (in the end) that the "good faith gesture" opening move of deploying Speedy Trial was the best option to start off BIP340-2 activation.

I'm kind of taking the same view on luke's alternative activation client; he thinks giving miners any mechanism to delay activation is a mistake. I'm sympathetic, but disagree.

Not going to get into a discussion about this though, as we've already got people attempting to create hype around it.

In other words another toxic move from Luke who apparently doesn't understand the role consensus plays in bitcoin and has no understanding of the dangers that splitting the bitcoin network has. He did the same thing in 2017 with his BIP148 while hiding the dangers of what he was advertising.

I just hope the malicious software he is advertising this time also ends up using a different user agent so that I can ban all of them easily.

no? wtf.  If anyone is ignoring the community, it's luke:

https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3667#issuecomment-830865897

Luke Dashjr’s recommended client for Taproot can be downloaded from this website, https://bitcointaproot.cc/

I believe the difference is Luke Dashjr’s recommended client goes to USAF/BIP8 if miners fail to signal 90%. Does Bitcoin Core 0.21.1 go back to BIP9 and waits for the miners again, ignoring the community?

No, not even-- they start mining the empty block without even receiving the block by spying on the stratum output of other miners.

That would be nice, but you can look at the published code to see it isn't so.

I think in general, an empty block is probably the result of a miner not validating a block prior to building on top of it. However, updating the UTXO database will take precious seconds from a miner, so it is possible that a miner would have the following workflow:
*Receive block
*Validate block (2)
*start building on top of the validated block that is empty (3)
*update UTXO set
*start building on top of the validated block that contains transactions that spend from the updated UTXO set.

I also suspect that some miners may change the order of 2 and 3 depending on which pool mined the previous block.

---

In the past, miners have lost a lot of coin from mining on top of invalid blocks. I think most of them learned their lesson, especially considering the value of each block currently. I would expect all major pools to have Taproot rules added to their own logic, and will check Taproot rules against newly found blocks before building on top of newly found blocks, even if a miner were to decide to build on top of a block prior to validating it.

The correct way of doing things is that the miner seeing the new block downloads that block and verifies it and updates its UTXO database. Then if it were valid the miner builds the next block on top of that valid block.

Some miners try to save a tiny amount of time by "spying" on other miners. For example they connect a fake miner to the other mining pools and as the other pool finds a new block their fake miner receives that "hash" of that block which is small (32 bytes only) then the "spy" miner builds their next block based on that hash alone without verifying if the block that was found by the other pool was valid or not (which it may not be valid and during a upgrade/fork the chances of it are higher and that would create a longer stale chain with 2 blocks in it, if more miners do the same this stale chain can become longer).

An indication of this type of mining is empty blocks because when the spy miner hasn't validated the previous block it can not update its UTXO database and doesn't know which transactions were in the previous block (and can't be in the block they mine) so they set their next block to be empty first until they update their UTXO database.

Thank you for this detailed explanation! I will upgrade before activation to show my support and help the network filter out rule violating blocks.



I don't quite understand this. It feels like I'm missing prerequisite knowledge about what validation is exactly. I wonder if these empty blocks become stale or are part of the official block chain, and why do miners do it. Where can I learn more so as to decipher the meaning of this?

In many prior activations at some point after the rules became active some broken miner managed to mine a rule violating block and some other miners who weren't broken but were just not updated yet produced blocks that continued after the invalid one.

Everyone who is updated, including correctly upgraded miners*, will just ignore those blocks like they never happened.  So the invalid block and its descendants will all become stale blocks.

If you aren't upgraded you may see confirmations that go away during such an events, and if you're a miner and not upgraded you will lose money by mining on a doomed fork during such an event.

If *many* people don't upgrade such an instance could be disruptive to the ecosystem, with various services accepting transactions on the invalid fork that will be lost when the valid fork overtakes it.

If for some reason you can't upgrade before activation it would be best to make sure your node(s) connect to the public network exclusively via an upgraded node so the upgraded node will act as a bad block filter.  This works for mining too, since older standard software won't introduce invalidity, only follow it if someone else introduces it.

If you can't even do that but are actively accepting payments, then you should require more confirmations before considering a transaction irreversible.  An extra ten might be a good starting point, depending on how quickly you'd respond do an incident.

If you're not accepting payments it's less critical to upgrade, but its still good to do so that your node can participate in helping the propagation of valid blocks and not propagating invalid blocks.

(*) A number of large miners engage in validationless mining-- they will mine empty blocks after a block without validating it. So confirmation by a string of empty or nearly empty blocks shouldn't treated as confirmation.  The emptyness is actually not a fundamental property but its easiest to implement that way so for now its a reasonable indicator that the miner hasn't actually validated anything.

What happens if the soft fork is confirmed and I upgrade after November? Why is it unsafe?

Not at all - although if the soft fork is confirmed you will need to upgrade before November when it activates to be safe.

Although there is a bit of benefit if the pools see lots of node on 0.21.1 might make them more confident to start signalling.

Also note a couple more pools have upgraded. F2Pool (16.3%) and Foundary USA (5.43%). So about 25% of hash power is signalling - 1/3rd of the way there...

How will I benefit from upgrading my node to 0.21.1 if I am not a miner? Should I wait to see what happens with signaling?

Today on Twitter @bitcoincoreorg announced the availability of the Bitcoin Core 0.21.1 release in which the developers included a method for activating the Speedy Trial update https://bitcoincore.org/en/download/                     

nice

This looks your best answer:
https://taproot.watch/miners
Currently only SlushPool is signalling.

But I would give them till end of the week to update their code. As reason they are not signalling may just be that any code change is risky and needs planning etc..

But if they have not started signalling by end of next week (so 13th May) then do switch your miners to another pool. As this process always needs momentum - and if pools who are not voting in favour start losing hash rate it will encourage them to vote in favour.

Correct

Also we have our 1st signalling block!
https://blockchair.com/bitcoin/block/0000000000000000000c5fc4ba692dc2cf016b8f45ec75eea2e12274879945a8

WELLDONE SLUSHPOOL!

Version [bits]
101111100100000000000000000100

The critical "bit" is the 1 3 from the right.

Just now need a few more miners to update their code. But 1st is the most scary as assume they are all concerned the network might reject it costing them over $300k!

So any pool with 11% of the hash can block it correct?

I mine ?ph  hash on viabtc and I love ❤️ taproot as far as I can see on viabtc they are not asking me to vote.

Plus I have no idea what they vote for.

Not that I am blaming viabtc. Or any other pool.

But I would like to know

A ) list of pools for taproot.
B ) list of pools against taproot.
C ) how do I as a miner make sure I vote for taproot.
D ) or how do I as a miner make sure I do not vote for taproot.

For me if viabtc is against taproot it would be a lot of work to switch to another pool.

I have 100 plus miners to reprogram.

Many of us have 1000 plus miners to reprogram.

No I think they could have signalled any time. But today is the 1st time it would have counted. As 24th April was the start date for activation in this Core commit:
https://github.com/bitcoin/bitcoin/commit/cbd64c3a28a7466f421477daadc6e6e6b69b898a#diff-ff53e63501a5e89fd650b378c9708274df8ad5d38fcffa6c64be417c4d438b6dR92

Signalling has to be 90% of blocks in a difficulty reset period. And at 8pm UTC 1st May was when that reset. But nobody in the 1st 19 blocks has signalled - which is not a great start.

But we have till 11th Aug so no need to panic yet!

the most dramatic thing to happen since the last time you brought this up was... you trying to stoke tensions, just now. which was less dramatic (and more boring), because it's the umpteenth time you've tried

What are the latest developments of the Taproot Drama, which was supposed to be a quiet event, after the community, and its “leaders” learned the hard lessons during Bitcoin’s Scalability Debate.

Is May 7 still the date when miners start signalling for Taproot? Follow the current status with this site, https://taproot.watch/