Topic: Taproot proposal - page 8. (Read 11516 times)

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.

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

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.

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.

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.

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

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

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.

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?

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.

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.

Apparently, Marathon is going to signal Taproot Activation:


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

From Marathon Press Release

Better because agreeing 100% is never a good thing.
Anyway, whether they signal or don't, who cares, we don't care.
They're bound to have to adapt to taproot and then I'll be really interested to see how taproot will make life difficult for them on the privacy side.

They might not be actually a “friend” to Bitcoin. Here’s also something the company had done in the past, that should raise some concerns on who these people really are.

https://en.wikipedia.org/wiki/Marathon_Digital_Holdings

i am not surprised but not because of their clean block nonsense but because they are running a very tiny mining pool and from what i remember from last soft fork we had the tiny pools are not going to signal until the very last moment.

I like the recent change that is although not actually any change but just a way to make the result more accurate. The signalling blocks is already 90% but the lock-in is when 1815 signalling blocks are mined. I did the ratio and it is appropriately maximum of 90% signal block that could contain in 2016 blocks. So, it do does not necessarily mean when 2016 blocks are mined, it is when 1815 blocks are mined.

1815/2016 * 100 = 90.02976190476190%

Which is ~90%

It is still very possible MARA Pool will signal. Even if the pool does not signal, it will not affect the softfork lock-in, provided if other mining pools continuing signalling. Currently at 98.33% when 60 blocks have been mined, only one block did not signal which is from MARA Pool. MARA Pool mining hashes is insignificantly in relation the the lock-in if others Pools continuing signalling.

Is anyone really surprised to see that Marathon pool is the only one not signaling for Taproot activation?
I am not surprised at all, but problem is they are growing in hashrate with their new 73,000 miners starting to run in Texas with plan to have total of 103,000 miners with 10.36 EH/s hashrate.
I really don't know what to expect from them after ofac compliant ''clean'' blocks...

That is all correct, but I wanted to point out that the taproot spends are also non-standard under prior releases (e.g. even without segwit), just since your description might have made it sound like they weren't.

Pre-Taproot nodes that support SegWit see the new witness version (version 1) and because by default they have a flag acalled SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_WITNESS_PROGRAM that acts as a standard rule and makes the node reject any transaction containing version 1+ that comes to their mempool. This flag doesn't exist when verifying blocks so they don't reject the transactions but they also don't verify everything about the said transaction.
After Taproot (core v0.21.1+) they will do the same with witness version 2+.

There's nothing missing in the transaction, thanks to segwit. Versions 1-16 segwit are non-standard for older clients, hence not relayed. Version 1 segwit would become standard for newer clients (0.21.1 and up) after block 709632.