Bitcoin Forum

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html

Fillippone just  a pawn in the game of Bitcoin, I have enormous amount of respect for Bitcoin developers, and the following statement doesn’t absolutely mean to disrespect the huge work behind this proposal: I fully endorse and how will evolve in a Bitcoin protocol enchantment.
Writing this disclaimer because I got misunderstood in some previous discussions.

The more you build on bitcoin protocol, the more it is difficult to change the protocol itself.
With L2 solution (LN and  Liquid) being more and more widespread, and impacting Btc ecosystem, and L3 solutions peeking over the horizon (see my monthly recap (https://bitcointalk.org/index.php?topic=5106432.msg50841890#msg50841890)),  I guess those are the last possible chances to get something done at protocol level.
Protocol immutability is a feature, not a bug.
Nobody in her right mind would change the TCP/IP and Bitcoin is the TCP/IP of the internet money.

Absolutely disagree. Although making an analogy between bitcoin and TCP/IP is void and meaningless it would be worth mentioning how a semi-decentralized infrastructure like TCP/IP was ruined by L2 protocols like SMTP and HTTP giving birth to Internet giants like Google, Facebook, Netflix, YouTube, etc.

It is easy to make void analogies and waste your and other people's valuable time by advocating for L2 and L3 garbage that have nothing to do with basic ideas of cryptocurrency, among them decentralization and anti-censorship. Every shallow minded junior software engineer is able to make fantasies about layers above layers of protocols, feeling smart to understand protocol stacking. They are always prone to this class of mistakes, using design patterns as templates that are applicable to every problem without gap analysis.

There is a gap between bitcoin and a networking protocol like TCP/IP: bitcoin is a decentralized application while TCP/IP is a semi-decentralized transport protocol, a good engineer should beware of this gap and avoid stupid analogies between the two.

What is hard, the real challenge of bitcoin is improving it in consensus level such that it can accomplish its original mission as a p2p electronic cash system in a scalable fashion without compromising security and decentralization measures. Bitcoin Core developers has escalated this hurdle to an upper level by discouraging (even fighting against) hard forks. Unlike them, I don't see any reason to be such dogmatic about chain splits and hard forks, actually I see a handful of good reasons to have an overhaul every one decade or so.

My first impressions about Taproot proposal:

• A good, still conservative step, forward.
• So many critical problems not addressed.

Let's read the details and discuss later.

I am not a software engineer, so I am no way qualified to judge your more technical remarks.
For sure i can criticise the analogy with Facebook, but I won't indulge in that because if the basic analogy Bitcoin (protocol) <=> TCP/IP is not good, every derivate analogy will be bad too.

The point is I always say Bitcoin as a protocol, not as an application, as I said, I am not a software engineer, so I will dig more into this.

Yes

Lightning channels have 2 scripts branches ("update" and "close"). If one were using these proposed taproot enabled segwit v1 outputs, the update branch will only ever be processed when the channel is open, and does not need to be written to the blockchain at all when closing the channel. Conversely, the close branch is not written to the chain when opening the channel.

This not only optimises space usage on-chain, but also makes lightning open/close transactions more closely resemble regular transactions, and so improves fungibility. I think it's possible with taproot and signature aggregation (which is not in this proposed fork) to make channel open/close tx's indistinguishable from regular tx's on chain (and potential changes to aid scaling of lightning routing will mean that only a small subset of LN nodes will be aware of the existence of a given channel, so knowing where and when BTC enters and exits payment channels will be a much more difficult problem to solve)

Edit: it's better than I thought, it seems only a specific form of sig aggregation ("cross input aggregation") is not in this fork proposal, but the basic type is (where signatures in a single transaction are summed together). No idea how cross input form differs from the basic type, still reading...

Sure, I agree on that, but what I mean is that if you build multiple protocol layers over the fundamental layer of Bitcoin protocol, if you modify anything on the lower one, the risk of getting something wrecked in the upper layers increases dramatically.
So when you build many layers over Bitcoin protocol, this get “compressed as a Jenga piece” and becomes immutable, as the risk of touching it and wrecking something somewhere becomes too high.

Thanks for detailed explanation :)


Can't disagree with that, but :
1. That's why we always wait years for new improvement, due to through-full testing
2. Many improvement add new feature rather than modify existing feature, such as creating P2SH address for scripting and Bech32 for SegWit.

The Bitcoin protocol has specific carve outs for extension. New extensions are done using these carve-outs. This largely avoids impact on things not using the new functionality.

One can not guarantee a complete lack of interaction-- after all, things built on bitcoin could be full of terrible bugs just waiting to be exploited, and any new behaviour might trigger one of those bugs--, but nothing new shows up in transactions that wasn't permitted all along which at least guarantees that nothing changed that some party couldn't have unilaterally done to you.

The reason technical commentators don't express your concern isn't because it hasn't occurred to them, it's because it has occurred and is largely addressed.

I find it kinda frustrating that no one bothers mentioning concerns like this in the crazy "bitcoin should hardfork once a quarter" threads. :( -- why must this kind of concern be conserved for sane proposals where it doesn't really apply?

But every junior developer could also feel smart, and make fantasies of a perfect blockchain-based cryptocurrency too, without any regard for externalities, or without any regard for the risks in messing up the consensus layer.


Says who?


That's your opinion. An opinion that many in the community do not share.

I hope it wouldn't cause more frustrations but I think both Ethereum approach (hard-forking like quarterly) and yours (do it never ever) to cryptocurrency governance should be categorized as extremism and need to be reconsidered.

Above-thread I objected to @fillippone not to the problem he has brought up but to his solution. He pushes your extremism to its limits and its destiny: leave bitcoin as is! When you abandon radical improvements they need to be implemented on upper layers and besides the centralization and censorship threats involved there will be always a push like that: Don't touch my infrastructure please!

I am against L2 solutions, I think both mining/state-verification in a decentralized ecosystem and on-chain scalability of bitcoin are not achievable without applying revisions in some crucial choices Satoshi made from the first beginning: winner-takes-all approach to mining and linear structure of the blockchain. There is no soft way to do such revisions and no L2 solution would ever solve both scaling and centralization.

Issuing anathema statements against radical improvement proposals that typically involve hard-fork requirements is nothing less than condemning bitcoin.

And senior developers, (like you and Greg  :P) should remain open to such proposals and use them at least as an inspiration to confront the real problems instead of sticking with false analogies with a networking protocol and being happy with minor improvements, Right?

right, and you make up your own facts

("miners broke the SHA-2 algorithm" which is demonstrably nonsense)

This is an act of trolling,  :D
@Wind_Fury started it by asking for ethos instead of logus and now you are accomplishing his job by directly questioning my right to say anything about bitcoin. Very interesting.

If you are mentioning my criticism about ASICs, it is indisputable. PoW is a cryptographic problem, it hates efficiency, any cryptographic scheme does. bitcoin basically was designed for owners of commodity devices with almost average efficiency who join and leave the network freely and voluntarily and pay fairly for blocks they mine:

I think a better practice would be making your own argument about what I said above-thread:

As a pro you might have noticed that I'm directly questioning Buterin's claim about the existence of a trilemma (https://github.com/ethereum/wiki/wiki/Sharding-FAQ#this-sounds-like-theres-some-kind-of-scalability-trilemma-at-play-what-is-this-trilemma-and-can-we-break-through-it) and suggesting that refuting this claim is the most important job of any serious bitcoin developer and the main agenda for any development project.

What do you think?

Can y'all please stop derailing this thread?

Sorry.

aliasharf let's continue in this topic, https://bitcointalk.org/index.php?topic=5140929.0

It's a shame this thread derailed.
Is this still the current proposal or has the discussion on this moved elsewhere?

Best Regards,
-Xi

A Pull Request from Sipa (Pieter Wuille) for Taproot/Schnoorr consensus rules has been opened on the Bitcoin Core repository:
 [WIP] Implement BIP 340-342 validation (Schnorr/taproot/tapscript) #17977 (https://github.com/bitcoin/bitcoin/pull/17977)


This is the first step toward  the most important protocol change since Segwit, I dare to state.

Excellent news.  I suspect a number of people will be watching with keen interest.  Have there been any elaborations on timescales?  Or are the waters still a little murky for that with so much stuff to figure out on the technical side?  Obviously with a significant change like this, they'll be treading carefully.

big news indeed.



the pull request is marked WIP (work in progress), so my guess would be no. I think sipa is just soliciting early feedback on his implementation of the BIPs (the details of which we can assume are essentially final)

Officially BIP!
Pieter Wuille on Twitter:
https://twitter.com/pwuille/status/1220502956023283718?s=21

EDIT:
For the non technical and casual reader an article surfaced on Coindesk:
Bitcoin’s Privacy and Scaling Tech Upgrade ‘Taproot’ Just Took a Big Step Forward (https://www.coindesk.com/bitcoins-privacy-and-scaling-tech-upgrade-taproot-just-took-a-big-step-forward)

This would clearly be the biggest Bitcoin update since Segwit on 2017. Are there some people within the community who are against it?

I hope no more drama ensues. Haha.

very positive that BIPs 340-342 are progressing, however mundane that is! I think though that the door is not shut on amendments, but this is still a milestone nevertheless.

I might add that I consider the Taproot soft-fork to be more significant than segwit, the improvement to BTC's money properties and the consequential impact to the overall bitcoin economy are far more substantial than the changes conferred by BIPs 140-144 (despite segwit providing several prerequisites that make taproot possible)

I am not the most technical user on this board but I have the feeling this time everyone is well aware of how this improvement is for bitcoin protocol and segwit adoption path drama is a lesson learned on how to manage the BIP process: keeping everyone onboard and proceeding step by step is a way of gathering consensus on the proposal.
do you share this view?

I'd anticipate that any conflicts would be purely verbal/written and not even remotely a threat to implementation.  I doubt we'll see any alternative codebases popping up in opposition or anything like that.

The usual detractors will follow their predictable routine of trash-talk and stirring the pot, but I suspect that's about as far as it'll go.

really, I think that it's unfair to everyone to discuss attempts to de-rail this proposal before any such attempts have occurred. it's certainly ironic considering this thread has already been drawn into personality clashes, which the OP was unhappy with seeing as this is the dev & technical board (for which I share some responsibility, regrettably)

Point taken.
I wasn’t in any case suggesting anyone to derail anything or clash to anyone.

How far are we from rendering efforts like "chainanalysis" useless? As it stands, interacting with fiat exchanges is a risk by default. Most of us are regular people, we aren't criminals, yet, what those blacklisting services do is basically putting yourself into the insane liability of ending up in a risk linked to criminal activity because some of your addresses once pertained to an address that it's on their blacklists. On a long enough timeline, everyone's chances of having coins that are "tainted" increase to the point that it's absurd putting your coins in an exchange.

Every single wallet should be sending transactions that by default obfuscate things so no one is liable of this bullshit idea of having "tainted coins", in other words, actual fungibility. Until then, how is one supposed to deposit coins on exchanges? Again, as of right now, you are playing a sick lottery in which your coins may or not have traces of being tainted, and as time goes on and coins move, everyone's chances just keep going up.

obviously, schnorr signatures are on deck. that'll allow for cross-input aggregation to make coinjoins indistinguishable from regular transactions. that's a pretty massive development given that exchanges are beginning to target coinjoin users. estimating based on segwit's activation timeline, that could happen by early 2021 or maybe even the end of this year, optimistically.

but "useless"? that's quite a strong word. :-X

confidential transactions (CT) to obfuscate transaction amounts seems like an attractive next step. but my understanding is it requires extension blocks or a hard fork. so.....probably not gonna be implemented at the consensus layer. there's always sidechains though. liquid (blockstream's sidechain) supports CT for example.

But, without intending to derail, what would be a good technical debate against this proposal? Is there one? I believe there's none, or else we would already hear about it from people like franky1.

Looking at the title of BIP 341 (Taproot: SegWit version 1 spending rules), does that mean we'll see address with prefix bc1p?


Not only hardfork, but CT have bigger size compared with regular transaction (even if you combine CT with Bulletproof, just like what Monero did), so i doubt it'll gain massive support.

yes. in a Bech32 encoding when you set the witness version to 1 the first character after the separator (ie. 1) is going to become letter "p".
BIP 173 doesn't mention this but it is easy to use one of the libraries to encode an arbitrary length byte array to see what the first character is. https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki
empty 32 bytes= bc1pqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqqq5us4ke

has there been discussion about cross-input aggregation and when it might be implemented? i was under the (apparently mistaken) impression it was gonna be included with taproot. it does not appear to be included anywhere in BIP 340-342.

It's mentioned in BIP 341 as essentially not being ready yet:

The main problem for cross input aggregation is that normally you can just soft-fork in new signature types (e.g. including new sighash types) just by creating a new checksig operator (or having a pubkey of a different length).

But a new signature type added in a backwards compatible softfork couldn't be aggregated with other signatures even if the underlying crypto is the same.  This is especially relevant because there is a current interest in adding some new sighash types, also graftroot which is also effectively a new sighash type.

Aggregation could have been done for basic taproot alone, and then any new types would have to be separately aggregated... but probably along the way we'd come up with different optimizations in how aggregation works, and then the consensus rules would have two implementations of aggregation. Worse, if taproot originally has aggregation people will probably upgrade slowly to a later tapgraftroot since mixed transactions would have higher overhead from the inability to aggregate them both, and fungibility would be hurt by the slow upgrade.

There are also some ideas that could allow for better backwards compatibility.  In particular,  if a new witness-like p2p extension were made that allowed transmitting the concrete sighash values as witness data to old nodes that don't know how to generate those sighashes (but otherwise not keep them in blocks),  then aggregation could be preserved even with future softforked in sig hashes.   But witness-like p2p extensions are a real pain to design and deploy, and no one seemed particularly eager to do that work right now. If one is done it should probably pick up some other improvements other than just backwards compatible aggregation.

So essentially, aggregation is conceptually ready but there are very strong incentives to deploy it in combination with other features which are not currently ready.  Trying to do everything at once is just too big an engineering project to pull off safely, and we're likely to learn a lot from actual usage of taproot which would help improve the design of other features (particularly of graftroot/g'root).

Right now I don't think the current amount of engineering interest in Bitcoin is particularly healthy.  Many long time contributors, including myself, have essentially stopped contributing for a variety of reasons (including uncertainty around political disruption of deploying even fairly boring new consensus changes, concern that too much bitcoin hashpower is controlled by bitcoin adversarial parties who would attempt to block protocol improvements, etc. on top of more generic factors).  Lightning is also easier, faster, and often more interesting to work on and so it has diverted a lot of new blood.

These things have to run at layer 0 to get any traction imo. We should have had better fungibility since day 1. Things should be mixed by default, what should be optional is making a clear A to B transaction. If we are going to have privacy, we want it to be as close to default state as possible. The internet went throught this already. We would have avoided the spying clusterfuck that it has become if it ran private by default. Only now ages later Tor is becoming more known as well as VPNs, but thats far from ideal. It's still nothing in the grand scheme of things.


Can't regular bech32 addresses begin with a p?

The bips 340 341 and 342 if there is in the community a large consensus for their implementation, will in my opinion be one of the most important upgrades to Bitcoin. However, this implementation will also be a test of the community and its future, because if Bitcoin was already advertised by governments as a facilitation of money laundering, as well as the financing of criminal and terrorist organizations, with this upgrade, we will see strong attacks by political power.

Regarding to the hashpower, the new stratum v2 protocol, aims to further decentralization and break, in part, with the pools decision-making regarding to block protocol improvements.

I don't know what you have in mind when you say "regular address".
Bech-32 encoding is a rather simple encoding of any data that takes an octet string (8 bits) convert it to 5 bit chunks and then converts each chunk to one of 32 characters defined by BIP-173 (that is qpzry9x8gf2tvdw0s3jn54khce6mua7l).
For an address we add the witness version as its first 5-bit chunk without needing any conversion so when it is 0 you choose the first char that is "q" and when it is 1 you choose the second that is "p" and so on.
they are all "regular addresses" with a different version.

By regular I meant what you point to be as bc1q. So bc1p is it for the new one. I didn't realize it was bc1q, but bc1 then random string. Im not a segwit user myself, still only use legacy. There's no way in hell the regular average joe user will notice any of these changes. That's why I insist: we need everything to be "mixed by default" somehow, and optional would be the clear transactions, ideally. What I mean is, the end user should just have to click "send" and that would be by default a mixed transaction. Then have some box you can check to not mix it optionally. This would be the standardized functionality of all wallets. That's how we reach proper fungibility. Otherwise we are going to start seeing horror stories regarding chainanalysis and innocent people ending up with BTC that was "tainted" attached to their names when they deposit in exchanges and whatnot. The only way to avoid this is that everyone by default mixes coins.

taproot/schnorr will run at layer 0. CT could in theory too but there are strong reasons it won't (bloat and lack of support for consensus change).


taproot offers the beginnings of that. amounts and output linkability are still unaddressed at this time, but basically everything under the hood of a transaction can be hidden. cross-input aggregation (once implemented) will further provide strong fee incentives to drive users towards schnorr-based coinjoin and/or adaptor signature-based mixing transactions. wallets could offer these as automatic/default mechanisms. if most of the network is using taproot, these are pretty huge privacy gains for everyone.

unfortunately, we can't approach this issue as if it were day 1. as gmaxwell pointed out, there is uncertainty around being able to deploy even mundane consensus changes---let alone ones that are actually contentious.

What will be interesting to see is how exchanges and businesses react to this, as well as governments. The only reason governments are allowing Bitcoin to stay legal, or even neutral, is due the fact that they think they have the means to control it with efforts such as chainanalysis. Once/if BTC reached a point of actual fungibility in which the costs of trying something like chainanalysis are bigger than simply outlawing it, that is what I would predict would happen (that governments outlaw it and go into a full front attack), which will only make other governments become tax havens for BTC holders. Ultimately the price would most likely be pushed upwards but there would be an awkward period of, once again, "Bitcoin is dead" all over mainstream media.

I think it is worth noting that chainanalysis is based on very weak heutistics.
The reality is there is nothing linking an address to another one. (taking to the extreme, even a transaction with one input and one output).  And each steps those heuristics become weaker and weaker every step down the chain analysis.
 
I am afraid the "chainanalysis stuff" is nothing would hold in a serious trial.

By the way batch transactions (output aggregation) togheter with coinjoin (input + output aggregation) are the best practices to transact over the bitcoin protocol. The fact that these techniques aren't implemented in "basic" wallets is not relevant. Everyone should always transact this way for every of his transaction.

indeed, there are layers upon layers of deniability baked in. there are other privacy pitfalls that could play a role, like browser/cookie analysis (https://arxiv.org/pdf/1708.04748.pdf) and IP address/bloom filter analysis by adversarial nodes. even then, the notion of getting a jury to convict based on this kind of chain of evidence is a tossup at best. blockchain analysis companies are generally working off a huge number of assumptions and that will become obvious to any jurors studying their protocols.
 

in theory (actually this is arguable since coinjoin transactions are always currently more expensive).

in practice, most coinjoins are very obvious on-chain, and some exchange customers are paying the price for it. (https://bitcointalk.org/index.php?topic=5221894.msg53742524#msg53742524) taproot, cross-input aggregation, and less obvious coinjoin mechanisms will mitigate this in the future, but for now all i can say is, be careful of your proximity to exchanges and AML/KYC enforcing services when engaging in coinjoins.

When an exchange harms your privacy applying weird heuristic to your transaction before or (worst) after using them, just stop using it.
I started a thread on this exact fact: [PAXOS+COINJOIN]Your privacy is a threat to exchange business?#deletepaxos (https://bitcointalk.org/index.php?topic=5221633.msg53731059#msg53731059)

people should absolutely "vote with their money" and leave such exchanges, if that's a viable option for them.

that doesn't address the larger issue though. we need to consider what people actually do by default. think about why the maker/taker fee model is so prevalent: because the vast majority of market participants are liquidity takers. further, there is zero indication that privacy is a priority for most of them. they will continue seeking out the highest liquidity exchanges, who all seem to be ratcheting up their AML standards one by one.

so while i agree with you, i don't think that's a viable solution long term. privacy advocates will just have less and less services at their disposal, with worse and worse liquidity. what we need are better coinjoin solutions so that we can slip through unnoticed with the the rest of the masses---so we aren't at a constant disadvantage re liquidity. this will take some time.....probably years.

wasabi wallet was groundbreaking as a first step, but its coinjoin implementation obviously puts its users at a great disadvantage re existing blockchain analysis heuristics. that's a problem we can't afford to ignore.

Nice article by Aaron Van Wirdum to non-technically sum up all the recent development in Taproot and how  Payment Pools could be used as as Layer 1 scaling solutions and privacy feature.

I don't want to cross-post, so I am linking it here (https://bitcointalk.org/index.php?topic=5207455.msg55025356#msg55025356).

Pieter has posted about changing BIP340 to us a different R tiebreaker: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018081.html

This is some signature algorithm behavioural minutia. Basically BIP340 did an unconventional thing because we believed it was faster enough to be worth a small increase in implementation complexity but it turns out that our belief was based on a both a broken benchmark and a supporting (wrong) assumption and it's not actually faster and might, in fact, be slightly slower in the long run.  Changing to the more conventional thing would simplify implementations and make them somewhat faster.

He tells me that he's received a bunch of positive commentary on it, so I expect the change will be made soon!

The above mentioned improvements have been applied and now the BIP340 support for libsecp256k1 is ready to be merged: https://twitter.com/pwuille/status/1300572711312265218

Honestly thought this news deserved a little more attention than it seems to be getting.  A hardy "Good work!" to all involved.  Is the lack of fanfare purely because people are more excited about the aggregation part that isn't quite ready yet?

it's now merged: https://github.com/bitcoin/bitcoin/pull/19944

:)

(and this is the secp256k1 subtree merged into the bitcoin core repository, it now looks that 0.21.1 will very likely include the taproot/schnorr activation code)

There's no drama from the trolls/big-blockers so far. Here's to hoping that this is activated as smoothly, and quickly as possible. Onward!

I wasn't expecting any.  It's not particularly controversial and there aren't really any coherent arguments to be made against it.

we may well see some


The most important point:

taproot only hides things that do not even happen. The script that is executed always appears on the blockchain when BTC is sent from a taproot address


stick to that argument, i say

(the troll reply is obvious: "no, the taproot secret script is encrypted with SHA256, not even Einstein and Hawking together could crack it and tell what's in the secret script. and money launderers, and Kazakh warlord gangsters. and people smoking Tide pods". Or something to that effect)

we also have a new BIP 340-342 pull request to github.com/bitcoin/bitcoin (which makes small adjustments to the older pr): https://github.com/bitcoin/bitcoin/pull/19953 (https://github.com/bitcoin/bitcoin/pull/19953)

positive comments are accumulating already, the case for taproot activation code in 0.21.1 just became that little bit more promising 8)

it's now merged 8)

the schnorr/taproot code will be in 0.21.0, so it's almost certain that activation parameters will be released as a part of 0.21.1 :)

That would be really cool, but I dunno that it's almost certain.  One thing you can be certain of is that they'll be ready when they're released.

So let me see if I got this right: after Taproot is activated will it be possible to know if a payment is the opening/closing/mutual closing of LN channel? As far as I understand this, it will be impossible to distinguish if such payment is, let's say, me opening a LN channel. Which is cool.
Right?

This might be another big trial for the network and its participants after the scaling debate in my opinion. Let's wait, and see if some entities from the mining-cartel play nice.

no-one's voiced any objections up to now. You keep saying it's going to be a problem though, like maybe 5 times already?


why would anyone care about a new scripting type that prevents choices in those scripts from being written to the blockchain?

• everything that _actually_ happens is written to the blockchain, for all to see
• everything that _does not_ happen is unrecorded

I'd be fascinated to hear the arguments that could possibly be mounted against excising unused script paths from transactions, all it does is make multi-path scripts more economical. Secondary effects of this don't change the fact that the chosen script path is still publicly available.

---

ot: You're very negative/pessimistic these days WindFURY, are you feeling ok?

I suppose, given the lengths certain trolls are prepared to go to in causing drama, it's easy to get paranoid about this sort of thing.  But honestly, it would be too obvious they were clutching at straws if they tried to oppose such an obviously beneficial change.  Playing devil's advocate, what argument against it would you expect them to give?  I can't think of any downsides.

Miners, I figure, would be indifferent at worst.  There are no negative impacts on them that I'm aware of.  If anything, once aggregation is implemented later, it potentially allows them to earn a tiny fraction more in fees if we're making more efficient use of space within blocks and can occasionally squeeze in a few more transactions.

Now the implementation is merged into the reference client, activation discussions slowly restarted on IRC (`##taproot-activation` on freenode).
Here is a wiki page (https://en.bitcoin.it/wiki/Taproot_activation_proposals) (thanks to David Harding) summing up the "main" different activation methods proposed so far, as well as a rationale and pros / cons for each of them.

I'm never pessimistic about Bitcoin, but I don't trust the mining-cartel.

Or maybe I'm just excited for another drama, and proved right that full nodes control the consensus rules, not the miners. 8)


What are the miners proposing? 8)

Let's see what happens has a truly encouraging name  ;D
Anyway, I asked this before and it would be nice to have an answer to see whether I got it right or not.
Thanks

I believe you will only be able to distinguish the lightning transactions if they are non-cooperative.  Openings and cooperative closures should be indistinguishable from ordinary single key payments.

[I say I believe because I'm not super well versed in lightning details, but this is indeed the idea.]

Ok, cool. I will look into it more. However, the simple fact that openings and cooperative closures will be indistinguishable from ordinary single key payments is great in my opinion. That's a very good step forward. Eagerly waiting for it.  ;)

I want to add just a comment. Some people may be mistaking that Taproot will be able to make CoinJoin transactions harder to see, although, Taproots hide scripts and making multisig indistinguishable but it does not directly do anything for CoinJoin.” So, what I know for now about taproot is that it will make multisig transactions to look like single key transactions.

And I will like people to know that Bitcoin’s Taproot is ready now, only remaining it to be included in bitcoin core, but it's unlikely to be included in the next release. The Bitcoin Improvement Proposals 340 through 342 were merged into the Bitcoin codebase on Thursday, signaling that the anticipated Taproot upgrade is ready.

https://cointelegraph.com/news/bitcoin-s-taproot-is-ready-to-go-but-it-s-unlikely-to-be-included-in-the-next-release
https://cointelegraph.com/news/bitcoins-taproot-upgrade-wont-help-privacy-where-it-matters

there will be no benefit to Coinjoins from BIPs 340-342. Originally, "cross-input signature aggregation" was vaunted to be included in the Schnorr implementation, but in the end was left out (to simplify the changeset IIRC). All that would have enabled is to make Coinjoins cheaper, they would be equally recognizable on-chain as they were before schnorr sigs



right, or anything using a hash-embedded script (including Lighting channels opens/closes)

this is why Coinjoins don't gain any privacy with Taproot, as a Coinjoin transaction is not script hash based

I think that's not quite the case:  There is a privacy benefit in that single key, multisig, and channels will be less distinguishable, eventually improving the anonymity set for all transactions.  Specifically for coinjoins it means that you could have a single key and a multisig using party coinjoining and you couldn't distinguish them.

Though this is more of a long term benefit once the new style is the most common, initially privacy will be reduced somewhat through the proliferation of more address types.

You're absolutely right though that some people are confusing the aggregation benefits discussed previously with something taproot provides.

I am writing it mostly to merge the content into my head......

• Not all Bitcoin addresses and transactions are equal since we have different address types: addresses starting with “3” are scripts, meaning that they imply multiple keys or implement segregated witness
• Taproot gets rid of the 1/3 address type distinction. As said before, all txs look just like regular transactions from one person to another, no matter how many people participated

Example: let's imagine a payment channel that Alice and Bob opened on the LN. Once they are done, they want to close the channel and take their BTC back. Before Taproot, the channel’s closure implies the creation of a bulky tx, which would reveal too much about what happened. Enter Taproot, this action between A&B would appear as a regular transaction distributing funds to Alice and Bob, as if a third-party had sent them coins.

Sounds cool to me

just to clarify, schnorr sigs are also needed to remove the distinction between single-sig and multi-sig, as signature aggregation (not possible with ECDSA sigs) reduces all the signatures from separate parties in a Multi-sig address to one (the signatures _are_ calculated separately, but the participants then literally add the signatures together to produce a single signature that validates the transaction)

without schnorr's sig-agg, multi-sig txs would still require the minimum quantity of sigs defined as the threshold minimum in the scriptSig, and more than one signatures necessarily means more than one signer ;) (unless you're using multi-sig as a security measure where you sign with 2+ devices, taproot/schnorr protects that kind of user from revealing their security practices also)


but yes, in essence, the net effect of BIPS 340-342 will remove the distinction between "script hash" addresses (beginning with a "1" character) and "public key hash" addresses (beginning with a "3" character). They will appear identical as addresses encoded on the blockchain, and when multisig is used with the typical scripting opcode sequence (1 input, 2 output, locktime set to current block at signing time). Because Lightning opens and co-operative closes are exactly that kind of transaction, they will also now look identical to these pedestrian tx types too (but not for Lightning uncooperative closes, which require a future locktime)

But atypical scripts will still be just as noticeably different as before, the only difference being that alternate paths (i.e. OP_OR sections within the script) will not be recorded to the blockchain, only the path that is actually used to spend the output from the address is written to chain.

Terminology danger!

Signature aggregation refers to the case where the verifier (the blockchain) knows a bunch of different pubkeys and you prove that they all approved a transaction using a single aggregated signature.  This is the often talked about thing that taproot doesn't include that would help make multi-input transactions much smaller.

Threshold signatures and _key_ aggregation are where some participants cooperate to produce a single key which some threshold of them can sign for, but which to the network just looks like a single party signing.  Taproot allows this, and it's what allows you to make multisig like usage which is indistinguishable from single key.

So taproot removes the distinction between single party spends and multisig too (which can include lightning input spends which don't actually use CSV/CLTV, even if they have it available).  Indistinguishable threshold signatures may not, however, be usable for all multisig usage because the threshold signature requires a little more interaction between signers and because in some cases you really want the public record to reflect which participants out of the threshold actually participated.


Yes, but almost always you can restructure a script as "[All the parties agree]  OR [Complicated script thing]". If you can do this, you can put an N of N pubkey at the top, and if the parties cooperate, the parties can cooperate and just sign and and the fact that "complicated script thing" exists at all will not be exposed.

The only time the existence of a complicated script would be exposed is if some parties don't cooperate (E.g. because they're offline).
 

Of course, and that's actually a very elegant way to put it. Thanks gmaxwell, keep contributing here for us to really get into all-bitcoin-tech-things. And, really, thank you both for your two posts as now I believe I have a much clearer picture regarding what Taproot activation would mean. Thank you so much!

Will there be any taproot related tests added to the src/test/data ?

There are vectors at https://github.com/bitcoin/bitcoin/pull/19953/files#diff-6794e4c8edce5f4dd1a21181a91f0c166f34c876809e40f015e5926ee3d6a126

Some Bitcoin tumblers and Wasabi/Samourai should start developing/testing, and see what they can build for "offchain mixing". I believe that could give a lot of users a very valid reason to start using Lightning.

I only found test vectors in bip340_test_vectors.csv - but they seem to be only checking sign_schnorr() and verify_schnorr() functions.

Are there any new test for entire scripts and transactions?

Am I getting it wrong thinking that "schnorr" is just an improved way of doing EC signatures, while "taproot" is an extension to the scripts interpreter?

Because reading some publications (and this forum topic), one could get an impression that schnorr and taproot are synonyms, whilst for me they are two different features. Although, I understand that they are planned to be deployed and activated together.

Schnorr without taproot isn't really that useful: it makes it simpler and safer to write threshold signatures but that's it-- you can already threshold signatures using burdensomely complicated client software.  And threshold signatures by themselves don't even do that much-- they let you make signatures somewhat smaller but only when you don't need to be able to tell which parties signed.   It's better --- but perhaps not worth the trouble of a consensus change by itself.

Taproot without schnorr isn't really that useful: without threshold signatures, which are burdensomely complex to write software for without schnorr, it only lets you have a single party key at the top (which is pretty useless.)

There is a third logical part of taproot,  which is the merkelized script. This part is probably the most useful of the three on its own, but it's much more useful in combination.  With it you can use trees of N of Ns to make thresholds work usefully even when you need to be able to tell which parties signed, and  N of Ns are much easier to deal with than arbitrary thresholds, because the latter requires interactive secret key generation.

In order to have the property where arbitrary complex scripts are normally indistinguishable from one-of-one payments you need all three.  They also can't just be independently implemented: taproot changes the pubkey that goes into schnorr verification to commit to the merkelized script.

There were other techniques proposed, including graftroot (allows you to add scripts to an output after someone has already paid to it), and improved signature flags--  but those were possible to implement independently without leaving the rest not very useful.  There were also a number of next steps like signature aggregation which would have been best implemented in combination but were still left out because the three main features of the taproot bip were still useful without it.

Looks like all the new testing is done with the python framework. I'll prod Pieter to add old style vectors.

They are over here: https://github.com/bitcoin-core/qa-assets/blob/master/unit_test_data/script_assets_test.json

There are three mining pools which have started to signal support for Taproot/Schnorr activation. Poolin, Slush, and BTC.com.

BTC.com? Isn't that Roger Ver's pool?

Tracker, https://taprootactivation.com/

That's a small start: currently, those three pools contribute an overall of 25% of global hashing power. By the way, BTC.com is from Bitmain.
It's interesting to notice the already very different approaches of the first three pools signaling the upgrade:

• Poolin - BIP9 (the same BIP for SegWit that went through tough times where the upgrade need to be activated before a specific time reaching a set threshold)
• Slush Pool - BIP8 (UASF that would also activate the upgrade at a specific future date or block height no matter the threshold reached)
• BTC.com - BIP8 + BIP9

Let's see when other pools join the party.

 

From another perspective 2 of them (Poolin & BTC.com) are 2nd & 3rd with biggest hashrate, which is good start IMO.

 Another summary from BTC Times:

Mining Pools Poolin, Slush & BTC.com Announce Support for Taproot (https://www.btctimes.com/news/poolin-slush-btccom-signal-support-for-taproot)


Also nice link to https://taprootactivation.com/

https://talkimg.com/images/2023/05/16/blob532990574d6aa444.png

Another Chinese pool, F2Pool, has started to signal for activation as well. One of the largest pools with BTC.com, part of the mining cartel.

It might be a smooth process without any drama and politics, but Slush's BIP8 for insurance. 8)

Bitcoin mining pools representing over 54% of the network’s current hashrate have signaled support for the scaling and privacy protocol upgrade Taproot, merged into Bitcoin Core last month.

https://i.imgur.com/xi3BLyl.jpg

https://www.coindesk.com/bitcoin-miners-taproot-schnorr-support

AntPool signaling BIP8 like SlushPool, that's some news now! :) Perhaps, I've been too critical a few weeks ago when I was expecting some skirmish from miners regarding the upgrade. If that's the pace of miners activating Taproot we should get there in a reasonable amount of time.
Some of them eventually had to recognize which is the one and only bitcoin that rules.

I'm working under the impression they're treating it like any other software update.  Some will opt to do it sooner, some a bit later.  I don't get the sense there are any political motivations involved in the decision.  More a question of simply when it's convenient timing to upgrade.

I could be wrong, but I think it might just be a case of people expecting drama when there may not be any.

Luxor says count me in. Another mining pool has joined the race and will be activating the Taproot upgrade through BIP9.
With this a total of 6 mining pools have already signalled towards activating Taproot.

https://talkimg.com/images/2023/05/16/blob5cb9815d99ea143b.png

Are we going to see new P2TR address format with this Taproot proposal update or there is no change for this and we keep well know formats?

No wonder that Binance pool is rejecting Taproot, and they are now one of the largest mining pool.

The malicious lie underpinning this question was already addressed here: https://np.reddit.com/r/Bitcoin/comments/jwgbu0/mining_pool_operators_independent_miners_i/gd46yy1/

That isn't true. Coindesk ran an article saying that binance pool was the only top-5 mining pool that hasn't made a public statement of supporting it, I'll never stop being surprised at the level of dishonest narrative spinning that happens in this "industry".

I guess for you it has a completely different meaning and I can sympathize with your mood. Let Coindesk be Coindesk, what can we expect from a media company which completely dismissed bitcoin for almost 4 years in favour of the infamous Blockchain Technology?
Like everyone they had to put their heads down and recognize that the only thing that matter is, of course, bitcoin.
 ;)

P2TR? Pay to Taproot? Taproot uses Witness version 1 and it's Bech32 address have prefix bc1p

See https://en.bitcoin.it/wiki/BIP_0341 (https://en.bitcoin.it/wiki/BIP_0341)

Asking a sincere question here: which is the dishonest narrative you are referring here? How would you have described the situation?
I am not seeing any dishonest narrative here, so I am asking because if you say differently, I am surely missing something here.
Thank you.

uh. The way coindesk did-- binance pool haven't commented on it.  It's more surprising that any pool has: there isn't even published software enabling it yet.

It is absolutely dishonest to characterize having said nothing about it as rejecting (as several Bitcoin "news" sites that plagiarized the coindesk article but with the additional "rejecting" claim, or the poster above who was probably regurgitating them data).

If someone published the headline "The Pope rejects the assertion that fillippone is a human being with a soul deserving of life" would you consider that dishonest?  ;D

Well, Coindesk stated:

https://www.coindesk.com/bitcoin-miners-taproot-schnorr-support

Looks a more "neutral" comment about the matter, "not support" is very different from rejection.
The "reject" part might be something added by other news let, or readers mis interpreting the news.

Ok, I might agree the reporting on those issues must be very cautious and accurate. "Caution" and "accuracy" are two very important qualities for a journalist, yet very seldom found in journalists!

Enough for the case, btw. Back on topic now!


I would like very much to be considered an AI life form, indeed!

I'm with gmaxwell. Plus the fact that the word "notably" was used, I believe Zack wants us to react as if there was some controversy behind Binance's absence of comment/show of support.

Coindesk is owned by Barry Silbert, initiator of the New York Agreement. ::)

Sorry, I somehow created confusion.

fillippone asked "How would you have described the situation?", and I responded "The way coindesk did.".  Unbeknownst to me it seems people thought I was complaining about coindesk and so my response wasn't clear enough.

I think coindesk's reporting was well within the ordinary range of exaggeration that we've come to expect from the media. I don't have any particular problem with it.

At least 5 other media outlets are running rehashes of the coindesk story with headlines like "Binance Controls the Only Major Pool Rejecting Bitcoin’s Taproot Update (https://archive.is/aBEIM)" (I didn't want to link them to reward their sleaze with traffic, but it seems I have to link an archive just to resolve the confusion). This is the same dishonest spin notblox1 repeated (I assume it was picked up from one of these articles). This is what I was complaining about, not coindesk.

And sure... It is misleading that the coindesk singled out binance pool as if there was something going on there but only slightly.  I mentioned coindesk only to point out "No, their article actually they just hadn't made a statement, not that they were rejecting anything".  An article which is only slightly misleading is really the best we can hope for.

Regardless, I for one welcome our new AI overlord.

Nice, the site https://taprootactivation.com/ added a column which shows the current hashrate of every pool signalling Taproot. The total amount of YES is well past 60% as we speak, which is very good.
Let us see the positive side of the story and let the media talk.
 ;)

The better and more correct spin-free version of that is "60% of those responding vote yes".
That is far different than 60% of all pools... As with Binance and ViaBTC, for now some are simply neutral on the matter.

no, it's 60% of global hashrate.
At the moment it's 61.2%.

I was not pointing at some sort of dishonest narrative actually. I was relating more to the point that after a long time of dishonest blockchain-not-bitcoin narrative they finally have to give bitcoin related news the right amount of coverage.
All good though, more and more pools are supporting the upgrade and that's all that matters.

Is it actually a "vote"? I thought pools signalling for support for the activation is merely to tell everyone in the network that they are ready for the upgrade, not a vote.

I guess there are a few distinctions, particularly when it comes to softforks.  With a "vote", participants are generally bound to honour the outcome, even though they might disagree with it.  Whereas the outcome of Taproot activation is effectively an ongoing 'opt-in'.  There is nothing that mandates its usage.  It's more analogous to an invitation to an event with no end date.  A "take it or leave it" kinda deal.

But the question is "is it actually a vote", not "is it perceived as a vote".

OK, "A miner signalling activation for an upgrade is not a vote, but merely telling the network that it's ready". Is that statement wrong?

it's "none of the above", as there's no version of Bitcoin Core released yet with any activation logic.

The pools/miners can suggest their preference for the activation parameters, and the devs can code their choice of activation parameters into the core bitcoin daemon, but if the users running network nodes don't like it, it's all moot.

Another day, another support (so, don’t call it vote):
We are now at almost 75% of the total hashpower.

https://talkimg.com/images/2023/05/16/blob2b1f70f454d7dc05.png.

You can expect a heavily funded effort to obstruct this and any further improvements to Bitcoin to start in earnest now.

You pessimist!!!!

 :P

You say pessimist, I say realist with foresight.  The community has made it clear that scamcoin conflicted bad actors like Bitmain will not be permitted to obstruct this directly -- so the next obvious move is a proxy war.


https://twitter.com/nikzh/status/1332246112196063232

I think market wants this upgrade. 75% of hash rate is supporting it.
If there were a future on activation, how do you think it will quote?

I do remember in SegWit/NYA agreement battle that was the NYA agreement future trading at 0.1 that made the fork fail as the miners realised the huge loss they would have incurred in. I think the same will happen here: sooner or later the “rebels” will eventually cede to the majority of nodes, who have the power to make an unwanted token fail trough economic disincentive.

Follow the link, the apparent strategy is to use astroturf to convince the market that the market doesn't want it.


My belief that there will be a fight is not a belief it won't activate. :)

At the moment I would only bet against activation to the extent that I could do so to hedge a position that bitcoin's price would be sustained and increased in the future.  (Because I do think it would be a negative sign for bitcoin's long term success if an attack on taproot is successful).

Holy crap! Why on Earth there needs to be politics in everything?
I sincerely cannot stand another segwit feudal fight, really. I hope you are wrong on this one gmaxwell, I truly want, for once, that you are wrong.
On the tweetstorm, slide 31, we read:
If someone advises me to do my own research then I will do as I feel correct while he is blatantly advising to block the upgrade.
They have their own useless playground called BCH: they should stay in there.

It is a pathetic attempt to block a very much needed upgrade. Maybe, they can't cope with the fact that they have created and supported a fork which nobody wants to use.
https://bitinfocharts.com/comparison/transactions-btc-bch.html#3y
It looks dead to time, the world wants the best protocol to transact with, no matter the price. Otherwise, there is always an excellent Dogecoin to be used. Much space, such cheap.

The main thing to remember is that they have no technical arguments against Taproot.  It's just a lame attempt at social manipulation.  Entirely hollow.

And even if we did allow them to turn it into a popularity contest, I'm pretty sure they'd still lose. 

if the information reported on poolin's old fashioned poll (https://github.com/taprootactivation/taproot-activation) (well, seemingly twitter threads at least) is accurate, then pools representing 82% of hashrate are broadly in favor.

Is it feasible that 5% can be found to oppose it? The chance of a BIP91/BIP148 re-run is high if such a high number were signalling once any activation period begins, I sense that miners will not risk getting caught mining blocks that could get orphaned for at all long, safest action would be to prepare your node then start signalling

That was the point. Signalling wasn't meant as a vote, but only literally what it's called, " a signal for readiness to the update". I believe BIP148 taught us this lesson.

What if Binance pool is trying to get some self esteem here like "hey guys we know almost 82% of the bitcoin mining pools are ready for the upgrade but, you know, we are binance we need to be recognised as those that allowed the upgrade to be implemented".
If you really think about it, binance is now controlling whether the threshold gets reached or not (I don't see any other pool having so much hashing power).

If all the other pools were signalling for a proposal except one, then the only thing that one pool controls would be how much of their hashrate they are going to lose because the miners connecting to them (in this case the 10% of the total hashrate connecting to Binance pool) will switch to another pool that is going with the majority.

So much?!
1. F2Pool        21.09 %
2. Poolin        12.54 %
3. BTC.com       11.24 %
4. Binance Pool  10.25 %
5. AntPool       9.75 %
Granted it is up there in the list but 10% isn't really called "so much". And it's a pool so they don't really "control" the hash power.

No wait : I guess I was not clear enough because I was referring to the rest of the undecided pools being Binance the largest. Thanks for pointing that out, I supposed it was clear what I meant. My message is valid, even if as you say they don't really control the hash power as a pool with that % they have some "power".

There have been a few updates on https://taprootactivation.com/ while total hashrate (1 month average) in support of Taproot floats @ 79.82 %
Also small miners and pools have been added.  On a small side note, there is the growth of some unknown miner @ 2.3%.

What's the drama with Binance Pool? All the big pools are currently signalling their support except them. From what I know of CZ, he will probably want to get some attention again and be "the savior?

Yep, that is exactly what I thought earlier.

Considering the latest CZ tweet about implementing SegWit (soon, soon) https://twitter.com/cz_binance/status/1339897009885466626
I guess there is no real conspiracy behind their current lack of support: they are being just slow  ;D

A question:
the current hardware wallets (like Ledger Nano, Trezor, ... ) don't support taproot and schnorr signatures.

Will a software update be enough?

Yes, though the fact that some use their own custom crypto libraries due to altcoin support and it may take them a little while to get around to writing it.

I just came across this tweet (https://twitter.com/bitentrepreneur/status/1343142666536681472) that Binance said yes to Taproot.

https://pbs.twimg.com/media/EqPKmq1XMAYkdt_?format=png&name=small

How much more is needed before it's activated? Is 91.05% not enough?

there is nothing to activate until nodes begin to run using code that implements BIPs 340-342, there is currently a tiny number of nodes (less than 100 out of 60-70,000) running the 0.21.0 release candidate, and as far as is publicly known, no-one (working on either Bitcoin Core or at the pools/miners) has what anyone considers a final version of activation logic either. So I agree, activation is rather doubtful before the release of a final version of Bitcoin 0.21.1, let alone Bitcoin 0.21.0

as far as 90% being enough to activate, I suspect it will be for the same reasons that I thought 80% would be: miners will take the conservative route of signalling the fork, so long as nodes adopt 0.21.0, not doing so carries the risk of getting any blocks they solve being orphaned from the blockchain using the BIP91 logic that is a part of BIP8 (the candidate activation logic for new soft forks for Bitcoin)

However, to have now a big majority of pools signalling some sort of support towards the upgrade can be considered a good sign. While we wait for the right release for the activation, we might enjoy some mining pools consensus  :)

Progress here is waiting on the deployment of 0.21.0 which is delayed, I think because it was discovered at the 11th hour that some P2P protocol update caused all existing BTCD software to instant-disconnect due to it erroneously hanging up on unexpected messages.

After 0.21.0 is out and stable then a 0.21.1 could be done with taproot activation.

0.21 is out, as widely anticipated Schnorr/Taproot code is now included, albeit not yet activaded.

We read the release notes. (https://lists.linuxfoundation.org/pipermail/bitcoin-core-dev/2021-January/000097.html)

On his usual new release review:

Bitcoin Core 0.21.0 Released: What’s New (https://bitcoinmagazine.com/articles/bitcoin-core-0-21-0-released-whats-new)

Aaron van Wirdum describes for the less technical of us: 

Come on, then! Let's get 0.21.1 underway so that this very much needed update can get finally activated.
I see in the release notes many Tor improvements too, which is good. Cool.

46% of nodes already upgraded to 0.20.1:

https://i.imgur.com/nLpkC0h.jpeg

oops, my fault, I read "News: Latest Bitcoin Core release: 0.20.1 [Torrent]" in the header and I tough it was the most recent version.

0.21.0 it's at 8th place (about 2.9% of nodes):
https://i.imgur.com/C2okqxA.jpeg

When Taproot+Schnorr becomes activated, will we need to create new addresses to benefit from the privacy? Will old addresses that broadcast transactions benefit? Will using the features provided by the upgrade be automatic or will we have to specify when creating transactions?

For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.

After your wallet supports it, new addresses will use it.  Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).

Unrelated,  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html

Appreciate the insight, thank you.

For power users of Bitcoin I understand that creating a new address for every txn is common sense, thus new upgrades will apply to them. Can you expand on how these upgrades affect people who required assistance making a paper wallet and only use one address as a "savings account"? These types of users don't follow or understand fully the protocol and it's relevant upgrades. All they know is they have a QR code to load the address whenever they buy and a private key or seed under lock and key. Even if you explain protocol to them, they tend to forget. If I'm interpreting your response correctly, these users won't benefit from upgrades like this when they spend their coin unless they transfer their savings to a new address first.

Are there significant downsides to these users using the same address every time they buy from an exchange since the exchange already has their KYC info? Hopefully this last question isn't too off topic here.

one significant downside should perfectly align with the incentives of such a user (who presumably is only interested in the value of their BTC savings): if they want to send an amount that's bigger than the largest unspent utxo, then it's more expensive to do so, because they need more than one tx input to do so. and there are also the obvious privacy issues (which harm everyone's privacy to a lesser extent).

Ideally, custodial services (e.g. exchanges) would permit BIP79 transactions for client withdrawals (and also use them for client deposits). This would save transaction fees, as well as defeat passive analysis of the blockchain to track utxo ownership. A few (not many) custodial services support BIP79 (aka P2EP/Payjoin), hopefully more will in future. Wallet support is also lacking, so it's a chicken & egg problem

If they are sweeping the entire balance from the exchange with no utxo, would this be irrelevant?


Even if the paper withdrawal address doesn't change, as long as it's segwit, can these types of users benefit from BIP79 transactions without taproot+schnorr? I don't see it as a requirement on the pull request.


I think these users can share an interest in value alongside an interest in BTC being good for the world. They can remember banks=bad and freedom=good, but not protocol details. They can remember how to use a hot wallet on their phone, but not how to re-setup their cold storage.

2.9% of nodes listed on bitnodes.io which they claim are "reachable nodes" not all full nodes. Also a lot of their 0.20 nodes are fake.

According to https://luke.dashjr.org/programs/bitcoin/files/charts/software.html there are 6776 nodes running 0.21 out of 83327 core nodes (8.1%). Although it doesn't provide any IP list so it can not be validated.
There is also an increase in number of existing nodes (near 2x rise) in January from around 46k to 85k which seems interesting.

Running wallet software on their daily driver is a solution, but risky. This type of user runs a major hacking risk by storing large amounts on an online wallet capable of generating new addresses. For an example, lets use the parents of a friend I help with computer stuff. They have been phished multiple times, not learning from their mistakes. Even though they understand Bitcoin is freedom, banks are bad, and custodial risk is real, it doesn't make them better at computers or evaluating attack vectors.

They could use a linux USB to generate new wallets/addresses offline and have a watch only wallet on their daily driver. But they would need someone to help them every time there is an upgrade that requires user action. Doing it on their own is as unreasonable as asking them not to get hacked or figuring out a hardware wallet.

This is the biggest problem I see with protocol upgrades that require user action. Non power users will either fall behind without consistent help from someone, or their coins will fall subject to hacker/custodial risk. Maybe this is unsolvable or maybe in the future it will be easier for them to generate new addresses from their online computer without risk. Am I missing something?

I agree with you, but this problem apply to technological change/development in general.


Risk always exist, but it could be mitigated if future OS is designed with very strict security. Android already take first step by enforce sandboxing and permission.

https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298 (https://medium.com/blockstream/cat-and-schnorr-tricks-i-faf1b59bd298)

Interesting, particularly where the author himself ask a revelant question here
After reading that article I remember a discussion I read on that specific matter on the bitcoin dev mailing list that can be found here
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016996.html
Would be interested to read a few comments on this by some of you guys.

Is it not amusing to read Taproot related news on Coindesk's main page? Interesting recap for the non-technical fellows like myself about the latest dev meeting on taproot and its activation.
https://www.coindesk.com/taproot-bitcoin-upgrade-activation-update

This part was the most interesting and I do hope we will not have to see such a detrimental scenario.

Part of what got decided was to use BIP 8 instead BIP 9 -- I tried to understand what the advantage was and I guess its because they don't want a repeat of the activation controversy brought on by segwit? I'd be grateful if somebody could explain the difference between the two as I think I'm missing the significance. Thanks in advance.

During 2017, miner-signalling for activation was used as a political tool to hostage/stop the network from doing an upgrade that the community wanted. BIP8/UASF is a method of activation wherein the full nodes decide, not the miners. The miners simply follow.

BIP8 is for activating changes by block height, so that the new rules apply only after a specific block has been mined. It is better than using BIP9 which also activates some delay after a specific block number but the version bit for it expires and can be reused some time, usually a year, after its activation where they assume everyone has moved to that fork.

The problem related to segwit's activation were that there were a bunch of miners/nodes who did not follow through this activation so this bit might have expired and be used for something else without everyone fully following it. There were special BIPs made for segwit activation just to address this problem (BIP91).

Here’s a good Bitcoin Magazine explanation about BIP9 and BIP8, the differences, and why BIP8 COULD be better for soft fork protocol upgrades. It’s written by respected Bitcoiner, Aaron Van Wirdum.

Read it, before believing the trolls who say that it’s the miners that enforce the rules.

https://bitcoinmagazine.com/articles/bip-8-bip-9-or-modern-soft-fork-activation-how-bitcoin-could-upgrade-next

1. BIP8 uses blockheight, as opposed to timestamp. This is so that the fork can still go ahead if:

• an activation is at the "locked-in" stage (i.e. block signalling is above the threshold)
• ...but the _overall_ hashrate is falling (i.e. the necessary 2016 blocks of lock-in won't occur before the timestamp when the 12 month activation period expires)

BIP8 solves that problem by not using 12 timestamped months, but 12 months of blocks (which comes with a different trade-off: it's unlikely to be 12 actual months, and for the taproot softfork, will likely be faster, due to continuing hashrate growth). The 12 months part is just a convention, it could've been more or less (and may be in future), I think 12 was chosen simply because the segwit and CSV softforks also aloted 12 months.

2. BIP8 has a "lock-in on timeout" parameter

This means that the fork activates regardless of miner signalling level at the point the activation period expires (12 months in this case).


The continuing discussion on activation for the taproot fork revolves around whether Bitcoin 0.21.1 should be released with auto lock-in (or "LOT") set as true or false, but also whether LOT can be set as user configurable (like an enforcing version of people putting "uasf" in their user agent string during segwit activation). IMO, 0.21.1 should be shipped with LOT=true, but I understand the arguments against also. At the least, it should be possible to set in the config file.

xmready, why do you keep posting that image?

Excited to see how many nodes are running 0.21.0

Which has what to do with this thread? :)

I was excited to know taproot activation is coming soon, which will be this year. But, there is a question in the link that 'what happens if the mining pools don’t signal to activate Taproot?

Taproot will ship by BIP8 in late March and activation is slated for July, so this question will have to be answered within the month.

https://www.coindesk.com/bitcoin-taproot-upgrade-july-finer-details-not-finalized



 

Doesn't 0.21.0 contain the code for Taproot?

This thread is about Taproot implementation, Taproot was introduced into Bitcoin core in October 2020, but not yet implemented as the implementation is a gradual process. On December 01, 2020, Bitcoin Core version 0.21.0 was released in which Taproot's code was  available for testing. If you scroll up, you will see a post where fillippone posted about it the day Bitcoin Core 0.21.0 was available.

Not in a meaningful sense.

When new consensus changes are added to bitcoin they are added in advance, completely deactivated and inert.  Later a version will be produced that doesn't change anything except arming the activation.

This avoids the risk that activation will be interrupted by unrelated issues in a new version.  It also gives more time for developers to test the fully integrated version and reduced risk that issues introduced by merging will go undetected.

So 0.21.0 doesn't have taproot support and will continue to not have any taproot support even after taproot activates.

Thanks! Does activation just mean a node is running 0.21.1 or do they have to take extra steps after the the upgrade to 0.21.1?

Put simply...

Either:

• Miners activate the fork. This happens when a certain % of miners are making blocks with a special "taproot ready" flag embedded in their mined blocks. This % of blocks must continue for ~2 weeks (for 2016 blocks)
• Users activate the fork. This happens when the timeframe for activating the fork expires

It's a little more complicated than though. Not much.

As of yet, the % for triggering the 2016 block lock-in stage hasn't been decided. Suggested figures are 90% or 95% of blocks (95% was used for some recent fork activations). The overall timeframe is also not exactly decided, but 1 year (measured in blocks...) seems to be a popular suggestion.

Is this flag a default behavior of 0.21.1 or do they set the flag manually?

They have to set it manually and Bitcoin Core doesn't set any flags of blocks on its own. Miners use the submitblock RPC call with the flag set in the block they submit.

There probably won't be a 0.21.1. There's a migration[1] scheduled on Github that will transition from 0.21.0 directly to 22.0. It's named that instead of 0.22.0.

---

[1]: https://github.com/bitcoin/bitcoin/issues/20851

No, you're confused.  The next major version after 0.21 will be 22, but consensus changes are not activated in major releases (as they contain lots of extra features that might make some users unable to upgrade or force them to downgrade).


Development works like this:


0.19.0 --> 0.20.0 --> 0.21.0 --> 22.0 --> ...
     \          \          \
     |->0.19.1  |-> 0.20.1 |-> 0.21.1
     |->0.19.2  |-> 0.20.2 ...
     |->0.19.3  ...
     ...


So the minor releases are all forked off an earlier copy of the software and have fixes back ported to them.

The post you were seeing was discussing dropping the "0." in the master branch.

FYI, lukejr regrets adding LOT to BIP 8 (https://bitcointalk.org/index.php?topic=5320857.msg56465183#msg56465183)

This upgrade is becoming more, and more complex than I thought. I was just trolling “in hoping” to see another drama between the miners, and the community again. I am starting to regret that Haha.

Here’s an link about LOT by Bitcoin Magazine, it’s confusing, https://bitcoinmagazine.com/technical/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation


Why didn’t the developers keep it simple, and have LOT=true as the default? Close to 90% of the miners already support Taproot, https://taprootactivation.com/

Chris Belcher is making the case for flag day activation.
https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/ (https://old.reddit.com/r/Bitcoin/comments/lwvg78/making_the_case_for_flag_day_activation_of_taproot/)

Didn’t we already learn from BIP148/UASF that an intolerant minority could still end with the overwhelming majority of the hashing power? I thought the upgrade was LOT=true from start to end, I was surprised that there was another political drama starting, with a “LOT=false” vs. “LOT=true”.

Shaolinfry, give us the wisdom to find the path forward, https://bitcointalk.org/index.php?topic=1805060.0

I'm still not convinced of that.  It's not necessarily accurate to say that a UASF can't be contentious.  I'm of the view that any time one "side" is trying to force the hand of another "side", then it's contentious.  Bitcoin depends on users, devs and miners working in unison.  Power struggles aren't conducive to that aim.

That’s the ideal path, but men/women being political creatures, never forget that Jihan Wu, and his friends used signalling as a political tool to hold Segwit because it would disable covert ASIC-Boost.

I believe without BIP148, Segwit would be delayed, and delayed, and delayed. Plus this is what decentralized governance is. There will be discord.

What exactly is LOT standing for?  

Can't seem to see anywhere what the word LOT actually references.

** Edit **

Found it..

lockinontimeout (LOT)

This is BIP8. If you want to know more about it, you can check BIP8 on GitHub. It  specifies an alternative to BIP9 that corrects for a number of perceived mistakes. Block heights are used for start and timeout rather than POSIX timestamps.

https://github.com/bitcoin/bips/blob/master/bip-0008.mediawiki

It is about to force an upgrade or not to force an upgrade based on timeoutheight. 

BIP8 (true), also know as LOT=true, this mandate upgrade after 2016 block height has been reached.

BIP8 (false), also know as LOT=false, this makes upgrade to fail after 2016 block has been reached.

I would be grateful if someone could answer the two questions below. + Can anyone point me to where I can read about these events? (and it would be great if someone could point me to key links to the scaling debate that started in 2017).

• Why Insane Price Lowers Engagement in the Taproot Debate?
• Under what conditions can Taproot create backward compatibility issues?

...it mandates upgrade regardless of how many are signalling for the upgrade.

This is wrong, LOT=false simply disables LOT, it doesn't do anything to fail/pass the upgrade. The upgrade can go ahead as before when it reaches the threshold of how many should signal for it (ie. 95% of the blocks).

Russell O'Connor has proposed an interesting BIP8 false "succeed or fail fast" alternative.
https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09604.html (https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg09604.html)

We now have three different threads on Taproot and its activation path and since we are talking about the same subject I am mostly doing this for myself for further reference and to have quick links to jump from one thread to the other.
Apart from this one, which is the main thread, we are having further specific discussions on the points below regarding taproot activation

• Taproot softfork "Speedy trial" activation (https://bitcointalk.org/index.php?topic=5322012.0)
• Taproot softfork lukejr removing option to lock-in on timeout...  (https://bitcointalk.org/index.php?topic=5320857.0)

;)

Sorry If I am rewinding the discussion a little bit, but I only recently found this article that describes quite well what the LOT=ture discussion is all about.

LOT=TRUE OR LOT=FALSE? THIS IS THE LAST HURDLE BEFORE TAPROOT ACTIVATION (https://bitcoinmagazine.com/technical/lottrue-or-lotfalse-this-is-the-last-hurdle-before-taproot-activation)


The article dated a few weeks back, so a few bits might be already obsolete, but of course, these are difficult topics, and a good "recap post" is often needed for the less technical plebs, like me.

---

It is trivial to create an unlimited number of full nodes, and the cost of doing so is near zero. It is not trivial to purchase and operate a miner, and the cost of mining is far from zero. The miners have a real economic incentive to do what is best for the long term interests of bitcoin.

The above does not mean that miners should have absolute veto power over changes to consensus rules, but it does mean that miners should first be consulted before changes to consensus rules are made. It will always be best to get the miners to agree to changes to consensus rules, and if they do not initially agree, substantial effort should be put into trying to convenience the miners that said changes are in the best long term interest of bitcoin (and the miners' long term business interests). Rejection of changes to consensus rules by the miners should be given significant consideration and the community should consider if it is best to move forward with changing consensus rules without the consent of the miners.

To put the above a different way, a BIP should be first attempted to be implemented via gaining the consent of the miners. If the miners do not agree to implement a BIP, a USAF can be considered, but significant weight should be placed on the fact that the miners do not believe the BIP is in the long term best interests of bitcoin. A USAF implementation of a BIP will be contentious, and it is always better to implement a BIP via non-contentious means.

Then here we’ll have another governance problem, another stalemate. What if the economic majority/community/users/developers want an upgrade, but the miners hold the network hostage by not signalling for the upgrade? I believe the UASF proved that miners follow the full nodes that which creates a specific demand for the miner’s “product”. Blocks.

I would view a USAF change as contentious, and contentious changes should be avoided when possible.

I think it is best to attempt to get the miners to agree to an upgrade first, and depending on the feedback the miners give, a USAF change can be considered if the miners do not agree to a change. There is a big difference between a single miner with 10% of the network hashrate opposing a BIP, and a single pool with 5% of the network hashrate in favor of implementing a BIP. If it is the former, this is probably a miner holding the network hostage as you describe, and a USAF should be considered, while this is probably not the case for the latter.

It is very easy to fake economic activity and nodes. It is also difficult to tell if two people claiming to be two different people on the internet are actually two different people. What cannot be faked are found blocks. As I mentioned before, the miners have long-term incentives aligned with that of the long-term health of bitcoin.

Then which fork currently is the real Bitcoin? Definitely not the one with Segwit if you believe UASF was “contentious”.


OK, before the developers propose something to improve upon the protocol, they should meet with the miners first to see if they agree, then post it in the Bitcoin Mailing List, IRC, and the forum?


https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality

SegWit was implemented after the miners agreed to the upgrade. A USAF upgrade was threatened, but this threat was never carried out. Read the article (https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality) you posted, especially the last several paragraphs.

BIPs should be implemented the same way they are implemented now. Once a BIP is agreed upon and put into the codebase by the devs, the miners should signal support or opposition to a BIP via their found blocks.

The UASF was starting to pick up, with some developers, and exchanges beginning to support it, that’s why the miners only started to agree with the update. Without UASF, they would have continued to hold the network hostage.


What if the miners hold the network hostage again by not signalling readiness for an upgrade the community wants?

Translation:  "No one is allowed to do anything unless I say so".

So much for permissionless, I guess.  Unless of course, everyone simply ignores you, which they will.

If you have an issue, raise it on GitHub.  That's what it's there for.  Have all the discussion you want.  They're not begging for your approval, though.

This is speculation. What ultimately matters is the economic supermajority.


I previously discussed (https://bitcointalk.org/index.php?topic=5140134.msg56581607#msg56581607) this possibility. If a BIP is not receiving support from the miners, the community could consider implementing a USAF, while taking into consideration the amount of support the miners gave. As I mentioned before, there is a difference between a small minority of miners supporting a BIP and a miner basically using veto power to oppose a BIP. The community should also consider alternatives to a USAF, such as lowering the activation threshold or modifying the BIP in a way that makes the miners more comfortable.

As I previously stated, the miners are the only entity that cannot fake their level of support. It is trivial to run an arbitrary number of fakes nodes, it is trivial to create an arbitrary number of online personas, and it is trivial to send many transactions to yourself to make it appear your business has a lot of economic activity, when your business does not have any customers.

The point you're trying to make is a valid one, but your expression of it isn't technically correct.  Miners can easily fake their 'support' for any flag, and they often have in the past-- e.g. signaling BTC1 when they weren't running it and had zero intention of ever running it.

So while it's true that miner signaling is sybil resistant,  the mining pools signaling flags don't necessarily have much skin in what they signal, so fairly little incentive to do so honestly.  This is particularly true because the parties with an investment in hardware are hashers (whom don't control the flags) and not pools (who do control the flags.  Many pools have significant altcoin investments and it's not too hard to imagine a kickback or altcoin play making fake signaling in a pool's interest.  Even hashers can move hashpower to altcoins that might gain value if Bitcoin had issues.

You could imagine a scheme where people pay _ethereum_ into a black hole to vote for bitcoin proposals. ... it would be an unfakable measurement, but if anything it would be anti-correlated with the wants and best interest of the Bitcoin community. :)

More generally,  we should always be careful when we're substituting what we can measure with what we need.  Measuring hashpower is probably only a reliable proxy when people haven't realized that they can game it, and we know for a fact now that they have.

The real unfakable metric is the eventual market price of the asset -- but we can't know that in advance, only make educated guesses.

I didn't know that one of the most interesting ways to find an agreement on how to possibly implement a bitcoin upgrade could have been the old fashioned coin toss! ;D
https://www.coindesk.com/final-taproot-activation-specifics-chosen-bitcoin-blockchain-coin-toss
Is that really what happened? Isn't that awesome, uh?

It actually wasn't, the timing was just unfortunate. AJ and I agreed on the method to use, and the PR to close prior to the coin toss. However, it happened to be that I posted my comment with the resolution of that discussion at around the same time the coin toss occurred. Since that resolution was also what the coin toss came up with, it gives the appearance that this was decided by a coin toss, but it really wasn't.

It doesn't look like anyone mentioned the article I just read by Mark Friedenbach, so I thought I would mention it here. If it was discussed, I apologize.

It's this one:
https://freicoin.substack.com/p/why-im-against-taproot.
He discusses Taproot and reasons why he is against its activation.

Mark fears that exposing the public key within the output on the blockchain downsizes Bitcoin's quantum protection. If and when quantum computers that are powerful enough to attack secp256k1 are created, they could (potentially) calculate the private key from a public key. The way Bitcoin works now, public keys are exposed when the coins are spent. With Taproot, they are exposed right away after an output is created.

According to Mark, it's quite possible that a quantum computer that can become a treat to Bitcoin can see the light of day by the end of this decade:

The article goes on to mention that 6.25 million bitcoins in 2019 were kept at addresses whose public keys are known. If the algorithm gets broken, it's those coins that become vulnerable. Another good reason not to reuse addresses. 

When Taproot gets activated (because I assume it will), what is currently being done on improving the security of the network where the public keys will become exposed as soon as an output is created (if I understood Mark's concerns properly)? Quantum computers could be something we have to worry about in 10-20 years, but what if the technology becomes available sooner? We will have Taproot, but how soon can quantum-resistant solutions be built?

Does Mark have valid concerns or is he wrong? I read somewhere that the exposed public keys with Taproot could get hashed preventing possible private key calculations in that way. Is that the way to go or what happens next?

I see, thanks for clarifying. I understand that from a press point of view it is very clickbaity and juicy to use such wording and avoiding to be specific. Shame on them as usual.
Now, whatever the way we should move on, let's get this upgrade on its way.

The argument is flawed because security of Bitcoin is not defined based on individual outputs but as a whole system. If some day the technology advances enough to be able to reverse a 256-bit public key to get its corresponding private key that means Bitcoin as a whole becomes insecure and whether or not Taproot is using public key is not going to change that.

I suspect major mining pools are running their own custom implementations of bitcoin for broadcasting, receiving, and validating blocks. 

In 2017, there were many "futures" markets that allowed market participants to price the value of various fork-coins, and the owners of mining equipment ("hashers") likely saw that mining on the NYA/BTC1 would not be in their best interest.

The mining pools earn income from the blocks they mine, and they need to invest in infrastructure to allow their pool to operate. If a pool has fewer hashers, it will have less income. It is also trivial for hashers to move their miners to pools that are signaling for or against a proposal that is in line with the long-term best interest of bitcoin. If a pool is signaling for or against a proposal that is not in bitcoins best interest, it will lose customers.


I would have to disagree with the bolded part of your statement. The altcoins that can be mined using ASIC miners that can also mine bitcoin have a very low network hashrate as a function of the hashrate of the bitcoin network. If 1% of the hashers (measured by hashrate) currently mining bitcoin were to move to bitcoin cash, the difficulty would more than double, which means the price of bitcoin cash would need to more than double for the hashers to have the same amount of revenue. This is simply not something that will scale for enough hashers to oppose a bitcoin proposal whose failure would benefit bcash. Even if it did scale, once these hashers start mining bcash, any proposal whose failure would benefit bcash could subsequently be implemented.

I mentioned futures markets for various fork-coins above. Any futures market would need to either be centralized, or run on an altcoin blockchain, such as etherum in order to be reliable.

My position continues to be that it is best to get miners' consent prior to implementing a fork (soft or hard). If there is a BIP proposal that is receiving pushback from the miners (based on what they are signaling), or if the miners are signaling support for a "bad" BIP proposal, a good next step would be to encourage reputable exchanges to open futures markets for both "for" and "against" forks for a BIP, and hope that the result will change minds.

It wasn't because of the futures fake markets but because they saw that going ahead with the hard fork part of SegWit2x would split bitcoin and it was not in their best interest. Believe it or not miners have a bigger stake in bitcoin since they both invest in equipment and bitcoin at the same time. Unlike nodes ore regular users who many not even own any bitcoin (anything at stake).

Proposals should be discussed and then approved/rejected based on their merits not based on what the
market (day traders who only care about their short term profit) think. Keep in mind that it is very easy to manipulate the market price on a centralized exchange specially when not enough people turn to that option.

That’s a good point, but does that mean that most/the majority of the community during 2017, that included users, exchanges, merchants, within the Bitcoin network were against Segwit? Or there was a chance they didn’t support it? I believe not.

Wells I guess I would ask how would one know if something is in the best interest of bitcoin? I could give my opinion based on my own expertise, but doing something because an "expert" says so is anti-thetical to bitcoin. If an exchange is reputable (or even better, if multiple exchanges are reputable), and are neutrally offering a particular market, the ecosystem can take the information into consideration. This is especially true if reputable exchanges allow for holders of bitcoin.current_implementation to exchange into BIPxxx.yes and BIPxxx.no and vice versa, to allow for arbitrage.

I believe a lot of the bitcoin ecosystem did not initially support SegWit. I think it is difficult to argue otherwise. Over time, arguments were made in favor of SegWit, including the various failures of alternate scaling implementations, and the signaling of various futures markets.

In other words, over time, minds were changed after additional data was understood. This is exactly how bitcoin should be improved. A BIP can be proposed that has initial opposition, and those in favor of the BIP should make a compelling argument as to why others should support the BIP.

That's true and the author made several suggestions. He proposes switching to SHA-512 instead of SHA-256. He would like to see Merkle trees be based on SHA-512, which seems to be something that is not easily achievable right now according to the article. But before that is possible, he thinks users should know the dangers of exposing their public keys in outputs, and in the best-case scenario move their coins to new addresses that haven't been reused.

He explains it much better than I do. If you are interested, read the bottom part of his letter (beginning with What can we do to fix this?). 

That’s what I said.


But you replied that it was only speculation, https://bitcointalk.org/index.php?topic=5140134.msg56707724#msg56707724

The UASF, and its other forms in the future will never be something “bad”, in fact, I believe it’s required to counter-balance governance issues.

SHA512 is the same exact algorithm as SHA256 (both referred to as SHA2) and in fact SHA512 is faster than SHA256 on modern computers and if the algorithm were weak it would be weaker for the faster one regardless of its bigger size. Increasing the digest size is not the way to increase "quantum resistance" (although quantum computing doesn't do anything to hash algorithms but that's a different discussion). An entirely different algorithm has to be chosen (like version 3 of S.H.A.).

P.S. Changing hashing algorithm to something that harms scalability of bitcoin and DSA used in Bitcoin to quantum resistance one are not arguments against Taproot!

USAF is a strong-arm tactic, it is coercion. That is not what I was referring to. I was referring to the proponents of SegWit 'selling' the benefits of SegWit to bitcoin's various stakeholders using persuasion. 

But a strong-arm tactic against who? Most of the Core Developers were neutral, some that supported the UASF was not the “official” stance, the market wanted it, it was just Jihan Wu, and thr Mining Cartel that didn’t want it because it would kill ASIC-BOOST.


Someone said that the biggest mistake was selling Segwit as a scaling solution, I believe that’s true. If it wasn’t sold that way, I believe it would have been activated with no drama.

but SegWit was a scaling solution, it increased the maximum capacity by 4 MB weight which currently is capped at 1.6 MB size. it also doesn't stop there, it paved the way for more scaling to come. for example implementation of Schnorr using SegWit is a lot easier and doesn't need a hard fork and is another capacity improvement.
it also made Lightning Network a lot easier by fixing some remaining malleability issues. which is another scaling solution.

I never said that Segwit didn’t improve transaction throughput, I said it was the way it was sold. I believe Segwit was mainly a malleability fix and other benefits you posted, not a scaling solution, but was sold as a scaling solution to please the miners. But I might be wrong. Let’s wait for gmaxwell or achow to post the facts.

I don't think nobody sold anything. SegWit proved to be a necessary upgrade and let's avoid to bring politics always in.
SegWit meant lower fees, more tx throughput, LN etc.
With Taproot it's the same, it's a necessary upgrade to me.

If you ask me, “Sold” = Way it was communicated to the community. It was communicated to the community mainly as a “scaling solution”. I believe if it was communicated as a malleability fix, it would have activated without drama.

BUT, Segwit as a soft fork disabled ASIC-BOOST, the drama might have been nevertheless unavoidable.


No one said it wasn’t, except for the big blockers.


I believe that’s the wrong take. Gavin Andresen was the “succesor” to whom Satoshi left the keys of the kingdom to, would you say that we should have followed him to hard fork Bitcoin to Bitcoin XT just to avoid politics?

So, steering the conversation back towards Taproot, is that being "sold" the right way?  Is there anything people could conceivably object to?  The communications so far all seem on point to me.

Besides the part that with Taproot the public key will be exposed before an output is spent, there doesn't seem to be any major objections. Even this doesn't seem like an issue as pooya87 explained in one of his previous posts. The article I linked to hasn't created confusion or uncertainty in regards to whether or not Bitcoin should go ahead with Taproot activation. If we arrive to a point where SHA2 is not quantum resistant, an exposed public key is the least of our problems.   

there's always some angle to be had for a committed axe-grinder, but no-one's made any credible claims that taproot/schnorr will be detrimental to Bitcoin.

In a weird circular reference loop, let me report here this Bitcoin Magazine Article:


SPEEDY TRIAL HAS BEEN MERGED INTO BITCOIN CORE, POTENTIALLY SETTING PATH TO TAPROOT ACTIVATION (https://bitcoinmagazine.com/technical/speedy-trial-merged-into-bitcoin-core)

I believe none. The drama/issue will be in “LOT=TRUE or LOT=FALSE”. There will be some actors in the network who might take advantage, and divide the community again. The Core developers are neutral, except for lukedashjr, who wants LOT=TRUE?

No, that's really been resolved with the Speedy Trial initiative (it was one of the reasons to take that route).

(note: I'm not entering into a conversation with you, please don't reply)

My role on this thread is to provide a news flows for the less technical readers, so we don’t hassle knowledgeable people with silly, or already answered questions.

I point you to this piece by Aaron Van Wirdum:

THERE ARE NOW TWO TAPROOT ACTIVATION CLIENTS, HERE’S WHY (https://bitcoinmagazine.com/technical/there-are-now-two-taproot-activation-clients-heres-why)

I found the following Taproot 101 on the latest Jimmy Song article. This is a pretty damn good taproot explanation and I wanted to leave it here for you all.
https://river.com/learn/what-is-taproot/
I didn't know about this River Financial before, looks good to me. They do bitcoin-only!

Interesting read. The article you shared mentions:

What requirements within the Merkle Tree need to be satisfied exactly to be able to spend from P2TR? Being one of the parties that has his signature aggregated is one I assume. What else is there?

This is the first time I read that sending bitcoin to a P2TR output will become more expensive than sending to standard legacy or native segwit addresses. But spending those P2TR outputs will be much cheaper.   

Since the P2TR outputs seem to be using SHA256 hash, they are only smaller than P2PKH, P2SH and P2WPKH but they take up the same space as a P2WSH output. This difference is only 12 bytes though (32 byte hash versus 20).

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/

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

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!

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.

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!

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.

nice 8)

Today on Twitter @bitcoincoreorg (https://twitter.com/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/                     

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?

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...

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

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.

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?

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.

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.

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. :)

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? wtf.  If anyone is ignoring the community, it's luke:

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

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.

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.

following

I don't know if some people find it more exciting when there's perceived drama, but this is just software development and economics.  It's not a meant to be a soap opera or so-called "reality television".  If you're looking for such lowly, base entertainment, there are better mediums to find that sort of thing.  We don't need to amplify every little disagreement or clash of personalities that occurs.  Discuss the technology, not the people involved.

Do miners do this to try and get a head start on finding the next block and getting a reward? Do these empty blocks live on the shared blockchain if they don't become stale?


I've seen luke on reddit getting angry at laymen for not understanding complex coder concepts. Seems nice.

There are two major possibilities:

Activate a rule without hashpower enforcement which may create a second incompatible forkcoin blockchain with fair probability, causing millions of dollars cumulative cost to the part of the industry that handles third party bitcoins (exchanges, etc) when they may be forced to allow withdraws of the fork (or sued when they don't),  with high probability creates long reorgs  (>6 blocks) that will be visible to a portion of users, potentially allowing double spending theft.  Notably none of these costs are costs to miners (other than indirectly through dropping the Bitcoin price), and an additional fork gives miners the potential for greater profit (because more total coins are issued but difficulty is split).

Or have a system that waits until a super-majority hashpower will enforce the rule, so that a second competing chain cannot persist.  A consequence of this is that miners can delay activation.

Those are the choices.  The details of the parameters can influence the severity of the negative effects-- e.g. longer to upgrade can make fewer users effected by reorgs,  or a shorter activation period can reduce the maximum delay miners can cause,  but that fundamental issue remains.

If you make a non-hashpower enforcement take *years* to activate then ubiquitous enforcement by users might eliminate the forks/reorgs/etc. But in that case you've created *years* of delay instead of months of delay, so the goal of not being delayed fails.  "YOU CANT DELAY US IF WE DELAY OURSELVES!!!" :)


Checkout the HN taproot thread (https://news.ycombinator.com/item?id=27021690) and the long discussion I had with someone who was *convinced* that taproot was going to create a spinoff chain.  The only reason it almost certainly won't is miner activation.

Now, if miners are legit blocking a deployment against the communities will, then the significant costs and risks of a forced activation may be well worth it.  Or if it's already blocked, making the forced activation happen years out wont be any more delay.  Or if the change is a non-urgent fixup, then delaying it years to begin with may not be a problem.

But if there is no particular reason to think they are going to block something, why the heck would we either add huge activation delays or the risk of splitting the chain (requiring preparatory costs, even if it doesn't happen!) just in case they might?   If they do it can be dealt with then, with the full benefit of information about how the obstruction went, how widely and quickly the users deployed the update, etc.

To give a concrete example, say we learned that 20% hashpower obstructed for no good reason and users upgraded about as fast as they normally do during an initial attempt.  Then it mike make sense to deploy with a 70% activation threshold and a flag day that activates regardless after 3 years,   This way it'll probably activate quickly with minimal disruption but users still have adequate time to upgrade before a disruptive hard cut if the blocking miners grow.   Or maybe we learn that user uptake was extremely fast for this upgrade, in which case cutting the 3 years to 2 might make sense.

So yeah, sure miners being able to delay stuff isn't good.  But you can't just wish it away, it comes with a phenomenal benefit-- one that is a competitive advantage against constantly hardforking scamcoins-- and one that allows us to activate new consensus rules much *faster*.   If we find miners actually blocking something, then the benefit may not be worth it.  Considering that plenty of users don't anticipate using any specific new feature-- so it has no benefit to them-- a potentially disruptive activation means that some otherwise desirable features would be legitimately opposed by users: why should they take cost and risk for some feature that won't benefit them?

Skipping over the miner activation only looks attractive if you ignore the costs of not using it-- Significant risk of spiting and/or destabilizing the network, years of additional delays, or both.

If you don't like delays you should prefer hashpower triggered activation, except when hashpower wont activate something quickly.  If delay isn't an issue, simply having a flag height set a few years out is probably best.

The right way to think about this is that a consensus rule upgrade naturally takes 2-5 years to do so with low risks.  Using hashpower signaling we can safely bring that down to months, but hashpower might not bother to (or active choose not to) cooperate and then we're stuck with riskier or slower approaches.

Besides,  I proposed taproot in January 2018, assuming it activates at the earliest opportunity via hashpower it'll be almost four years since I proposed it.  These folks that are now so worried about the risk of a few months of delay by miners...  Where were you all these years?   Or is delay only something you care about to the extent of angrily retweeting some hashtag (https://www.youtube.com/watch?v=JeXX_zwhmi8) and not enough to bother helping with the work to make something real?

Yes and Yes.
Since mining in Proof of Work is based on luck, they could get lucky in that few seconds and find a new block to get the reward before others do which is why they do it.
You can find such blocks on the blockchain, here is a block explorer link you can use to see said blocks that are empty (only have the mandatory coinbase transaction): https://blockchair.com/bitcoin/blocks?q=transaction_count(1)#

+Poolin - so another 10% - up to about 35% out of the 90% of hash power needed...
https://blockchair.com/bitcoin/block/681823

So we have 4 out of the top 10 pools signalling - probably need all of them though.

From what I see at https://taproot.watch/ Antpool was not signaling it at block 681853, but it does at block 681854?!
Can we say +Antpool?

Yes plus antpool!
https://blockchair.com/bitcoin/block/000000000000000000098395525a9cedb2d58fec5e99335d778d96663c16cf9d

That is a big one as they could have blocked it...

So over 50% now - just need the 5 mid-sized pools and done.

Good, with Antpool onbard we'll get there eventually. Jimmy Song predicts we'll have it activated by Thanksgiving; what do y'all think? Before or after?
I can't wait for improved fungibility, better tx speed, increasingly difficult analytics and indistinguishable transactions.
MBBA
Make Bitcoin Better Again ;D

this case is overstated


it's only going to be the 'base case'/'cooperative case' that will become indistinguishable, e.g. Lightning channel opening transactions and cooperatively closed channels, because Schnorr "additivity" (which is not a real word :P) makes such transactions appear the same as a regular [1 (or more) inputs -> 2 outputs] tx, because there is only 1 aggregated signature (because additive signatures, despite 2 parties signing the tx). Currently, spending outputs from that kind of transaction reveals it to be a 2 of 2 multisig that had alternate script paths, not so with the same tx script using Taproot/schnorr.

But, uncooperative closes are still distinguishable from regular [1+ in -> 2 out] transactions, because of the atypical script they use will (necessarily) be revealed if they are broadcast/confirmed in a block. I know, uncooperative channel closures are not common, but they will still sometimes happen when using Taproot/schnorr based channels/contracts.

And so, all other atypical scripts will still be distinguishable from regular transactions too. It's just nice that the construction of many contracts involve using the [1+ in -> 2 out] regular pattern as their base case.

Possibly another stupid question from me here, but can the Lightning Network then be leveraged as a use case for tumbling/mixing/hiding our UTXOs after the upgrade?

I love new words, mainly if the are not real ones.  :D
Always great to have your take on all things bitcoin, much appreciated. You clarified that very nicely.

Isn't it that way already?  8)

The only downside is that you must leave the channel reserve in a channel.


Workflow is as follows:

1. Open 2 Lightning nodes; one with outgoing liquidity and the other with an equal amount of incoming liquidity (minus the 1% reserve + ln fees)
2. Send everything from the node with 100% outgoing to the 100% incoming node

You just did an ad-hoc Coinswap over lightning.

n.b. I think eltoo channels remove the reserve requirement, so that would mean you could perform this without the "loose end" constituted by the reserve balance left over on one node


However, a 'real' coinswap is better. It's probably less traceable (at least than HTLC based Coinswap-over-LN) and the LN technnique might spark a trend of people closing both channels and both nodes once they finish the swap (which is a little anti-social, payment channels are intended to be long lived).

This is perhaps ignoring the forest for the trees, those distinguishable lightning txn are relatively uncommon.  2 of 3 multisig and various multisig or timeout keys are about half of all transactions.   Taproot should eventually allow most of those to look just like single key wallets.  It'll also let users improve their security by using multisig without increasing their fees or making their transactions stand out at all.

It's hard to reason about all the benefits because it also makes possible some things that aren't possible today so we don't know how common or how valuable they'd be.  For scripts with a compatible structure taproot increases the maximum script size a factor of 10^43 or so...   If you happened to know a pubkey for every resident of california you could make an output with taproot that could be claimed by any of them.  The signature would just be a few hundred bytes.   Without taproot that would take a 1.3GB transaction.

yep, i mentioned that



strangely, Taproot re-defines what "the script" actually means. In your example, which is the script? The whole tree, paying to any pubkey of every californian, or the script that gets redeemed on the blockchain? A taproot script is potentially an entire litter of Schrodingers scripts, only one of which becomes an observable cat on the blockchain o_O

the answer is, of course, that there is a "script tree" and an executed "script leaf", where the script tree is never publicly known.

46.80%, https://taproot.watch/miners

How much time does it typically take before those other miners start to signal for an upgrade? Do they take their time until the last, maybe 500 blocks, before we see 90%? Or can anyone tell that for this round, it is slow?

I don't understand what is Poolin doing. They signal Taproot in certain blocks and don't signal it on other blocks.
I guess that they have more than one pool and not all those are upgraded in the same way, but I still find it odd...


Switch to the main tab and it'll tell that we're already late for this 2016 blocks period, since over 90% of the blocks should be signaled and it's not longer possible.
Somehow we should rise awareness, maybe more pools join before the next difficulty period.

Seems a lot of pools are doing that. There was even one block from btc.com that did signal - all others did not.

I like you assume they have multiple setups and have only partially upgraded - and btc.com was just a test before putting live?

As you say this period is already a no. And next is looking unlikely unless the other 4 big pools upgrade and the existing ones that are signalling start signalling with all their bocks in the next few days.

90% is a high threshold - so unless we are up to almost 90% at the start of the next period on 13th (ish) May unlikely to lock in during that period either.

big mining pools always have more than one server that are located in separate locations so they operate separately also. sometimes their coinbase transactions also includes the name of that particular server alongside the name of the pool (something like Antpool.Server1, Antpool.Server2). this is why some of their blocks have the change and are signalling while others don't.
they did the same thing during segwit activation in 2017.

Just wild guessing: smaller pools want to wait until the end only to be able to then unlock the upgrade and be remembered before going back to the void  ;D
Anyway, if that's the case about having separate locations, they need to get the ball rolling and start signalling everywhere they operate.
I'm hoping Jimmy Song was right about Thanksgiving...

The script is the rules that specify the conditions required to spend the coins.  Taproot makes it so that most of the script doesn't need to be published-- which is often a scalability improvement sometimes a massive one,  just like P2SH made it so that the script didn't need to be published until spending time (and never published, in case you happened to lose the keys :) ).

You already know how we can raise awareness. 8)

https://bitcoincore.org/en/download/

BUT as gmaxwell has already said in the topic, we first wait for the miner’s true intentions. With most of the Bitcoin Core developers remaining neutral, there should be a user-led campaign for the upgrade.

How is the signaling calculated on that website, the Ok sign, not the percentage?
Pollin with 35/118 and 1Tash with 8/35 are a no and SBI Crypto with 2/11 is green?
Or it is based on the status of the block mined?

Well, at least the only ones big enough block that hasn't done a thing yet don't have that much hashing power of their own, so miners could switch to another pool for an epoch, I must say I'm pretty surprised to find out AntPool was one of the first to change. If ViatBtc is the next one the surprise would be complete.


Switching miners away from silent pools would work better, unfortunately a few hundred th/s are a drop in the ocean.  :(

You say a lot of weird stuff. :)  Bitcoin Core developers pushed this out, they're not "remaining neutral", that would be a terrible abdication of their responsibility as technical experts.

From my point of view during the Segwit “Saga”, when the call for the USAF was obviously becoming very necessary, most of the Core developers were neutral because of the risks. But reading your reply makes me very confident for the UASF for Taproot, if it’s necessary.

We are over 20% Taproot signaling blocks and I am not surprised seeing that one of the largest pool Binance is doing nothing so far with 0/113 blocks.  ::)

SatoshiLabs team wrote a nice article explaining how Taproot will benefit hardware wallets and it is easy to understand it even if you are not a tech expert.
Size of transactions with Taproot will be reduced resulting in more transactions per block, and it is especially important when there are higher number of inputs and outputs that will save a lot of time for something like coinjoin transactions and mixing coins.
For example if we have 100 inputs and two outputs time for transaction could be reduced up to 90%!
Multisig prvacy will also be much better with Taproot, but important thing is that more people need to use it if we want to have more benefits.
https://blog.trezor.io/how-taproot-will-benefit-hardware-wallets-fa43c0b6123e

Agreed. I have been watching this and assumed Sat Labs would be onboard big time.  I read through the website before coming here and I was going to post the same thing you did, LOL!

USAF SegWit is not the same as SegWit. The former is a "forced" change, while the later is a change that was achieved via consensus. It is totally reasonable for the devs to advocate for Taproot to be activate, expected actually. For them to advocate for Taproot to activate without clear consensus is another story.

For now, Bitcoin it is update to full Taproot already or not yet?

Bitcoin, as in the protocol, does not yet have Taproot because the fork has not yet taken place. We have to first reach majority support (ie. 90% of hashrate or more precisely the blocks that were mined to signal their acceptance of it) then it activates. The signalling was just started.
The bitcoin core (reference implementation) has the code for it and is ready to accept the new blocks containing Tapscripts.

Shouldn't that apply to all wallets after taproot takes place? You know I'm no geek but I understood that those improvements are for, basically, any wallet. In the end, the functioning is the same for any wallet.
Great read BTW, it's always nice to stack more knowledge on the matter. (now i'm going to stack more sats. no pun intended)

The users/economic majority will have no right to demand for the type of blocks they want, if the miners will not signal readiness for the upgrade? From your point of view, the network should always be under the mercy of the mining cartel? If miners won’t signal for Taproot, we simply accept?

Just about to start next period with about 40% support..

Unless Binance, ViaBTC, BTC.com and Huobi all jump on board in next few hours not going to lock-in in the 2nd period either.

Which is a worry - as they have all had 2 weeks to schedule updates (and many months to prepare) so indicates they have one of:

• Major technical issues with this update
• Actively disagree with it
• Other revenue generating development work (adding new coins etc...) that they regard as higher priority
• Total apathy to it all

If you are a miner using one of these pools I would encourage you to move to one of the others that are supporting it (see https://taproot.watch/miners - any pool with a green tick).

That should help if issues is 3rd or 4th on above list, and increase hash rate of a signalling pool.

Maybe LukeJr was right ::)..

At least give polite discussions a chance first before we start making "demands" .  If you start seeing everyone as your enemy before they've done anything wrong, that's a great way to create tension and halt any progress you could have made by working in cooperation.

Remember, this is a collaborative network that functions optimally when everyone is in agreement.  It's not constructive to go looking for a dispute that might not exist until you cause it.

“Demand” was the wrong word to use, I am sorry, but I believe you understand what the situation is. If the community came into consensus that it wants Taproot, then it should be activated. The miners can’t expect everyone to sit, and wait forever.

Well, miners have a few more months left to support the update, so the main question is not "if they support" but "when will they support". In addition, I am almost sure that there is no chance that the activation will be disrupted given the share of Chinese pools, (unless someone has some pretty compelling political reasons). Although I'm not entirely sure whether a rollback is advisable in this case, given that against the background of an increase in the hash rate, such actions will lead to a loss of profit, (in the sense that Chinese miners are unlikely to favor pools with an ambiguous position).

Of course, many of us regular users would like something like this regular taproot upgrade to just go through quickly, since there really have not been any descriptions of reasons to be opposed to it - unless you might just be against anything that might make bitcoin better - which we should anticipate that there are some miners in the space that are of that opinion, whether they add up to more than 10% to cause a failure to reach consensus might be another question.

So surely, I have heard of various giving the benefit of the doubt to miners and mining pools regarding the first difficulty period, but with the passage of time, if we are not really even coming close to 90% signaling, then there could develop decent amounts of frustration that seemingly obvious upgrades are either being gamed in a dickering around kind of way or even that there might be some incompetency in terms of some miners/pools figuring out how to signal in order that the 90% can be achieved and we can move on to the next stage. 

I do appreciate some activism from miners, node operators and even users in this matter, that may well result in some miners just getting pissed off (fairly early.... if we call "now" early) and to demand explanations or to join pools that are signaling for taproot.  Don't fuck around with these pools who are either passive aggressively failing to signal, incompetent to signal or not providing some kind of reasonable explanation why they are currently not signaling. 

If such non signaling pool is able to provide some reasonable and plausible explanation regarding their failure/refusal to signal and to provide a date, such as June 1 or some other date that they will start to signal, then sure, maybe no need to punish such pools, but otherwise, I would think that regular joe blow miners would want to get this update in place ASAP rather than fucking around (or is the expression "dickering"?) with some mining pools who are not being clear about why they have either not already been signaling or provided some kind of explanation with a signaling projection date that it fairly soon in the future.. giving some benefit of the doubt that there might be "other things" going on in the lives of mining pools (and regular peeps involved) blah blah blah..

At this point (only a few weeks into the "ability to signal"), two weeks^tm (or possibly slightly longer) seems reasonable and acceptable to confirm that the poole is going to start signaling for taproot. 

Miners are also part of the community, an important part too since they are the ones signalling for the forks not the "social media participants" who may not even own any bitcoin!

As far as signalling goes we know the hashrate percentages but here is the node percentages:
According to https://bitnodes.io/ only 7.60% have upgraded to 0.20.1
According to https://luke.dashjr.org/programs/bitcoin/files/charts/software.html only 0.9% of all nodes upgraded to 0.20.1

If you are looking for a reason why miners aren't yet jumping on board in this first adjustment period maybe that's the reason.

Did Taproot decrease lower the fees?

I think bitcoin now still high fee, if Taproot make fee to low is will better and very great to use often

If so, there might be a miscommunication.  The minimum activation height exists because it's known that it takes MONTHS for a substantial fraction of the network to upgrade even when there is some urgent bug.  Plus, the primary advantage of having soft forks triggered by a super-majority hash rate is that they're safe to activate even if relatively few nodes have upgraded (so long as the super-majority hashpower has upgraded).

Maybe it wasn't your point-- but there is no particular reason to wait for nodes.  And, actually 16.2% of listeners on 0.20.1 already sounds pretty fast to me!

Yeah, I understand the point of contingency planning and being prepared for all eventualities.  But at the same time, we don't want to alienate anyone in the process.  If you start talking as though this is a foregone conclusion, miners could conceivably interpret that to mean you have no respect for their opinion, since you haven't really made an effort to find out what their opinion is yet.  If miners aren't supporting it, the first step is to open a dialogue to find out why.  It's a little premature to start talking about options like UASFs.  That sort of talk comes across as unnecessarily hostile.

My point was to say that it is not just miners who take time to upgrade their backend and start signalling, it is also the "community" running full nodes.
I've also made a small mistake and reported the wrong percentage, it is actually 7.6% of listening nodes running 0.21.1 (the 16% was for 0.20.1) which is still good for this short time. The other one is also 0.9% which is not as good.

FWIW, 22% of my peers claim to be running 0.21.1 or 21.99.0 (master), may be because I ban a massive amount of fake spy nodes which may be diluting the figures.  I also have tor inbounds which may tend to be more frequently updated.

(To be clear, I don't claim that this little sample is representative, just adding a bit of color)

Yes, because Taproot transaction size is smaller on many cases, although only noticeable on transaction with script which have multiple condition or have many inputs.


IMO Taproot won't bring much impact towards transaction fee, besides it'll take few months to years before wallet supporting Taproot.


Additional information would be great,
1. What's the number of peer/incoming connection? 10? 100? 1000?
2. How do you ban fake spy nodes? A fixed list from someone else, automatic detection or manually created list by yourself?

They are, but signalling for an upgrade is simply signalling their readiness, not if they want to allow, or not to allow to upgrade. It’s not only up to them.


That’s why I believe there should be a fierce campaign for community awareness.

Are you OK if miners won’t signal for the upgrade?

BTC.com has also started signaling, this time more convincingly (5/20), probably that lonely block the previous period was indeed a test. With them on board, the problem list is down to two pools that could reach 10% on their own. Binance and ViaBtc, and I'm not surprised at all by the second one.
We're not going to reach 90% this period either, so next one, I just hope we won't have to wait one period/pool.

Agree this period looking unlikely.

Other scenario though is that miners start moving from the non-signalling to the signalling pools. Which for them is a relatively minor change.

Fair point but a miner must be extraordinarily committed to bitcoin and its underlying values to switch from non-signalling to signalling pools. This would be a great sign anyway, any shift in this sense will be like an act of war towards the pool which refuses to signal the upgrade.
In the end it depends if the miners are here for the cash or the vision (because any pool works for getting cash). On the other side, if non-signalling pool see a decrease in their HP, well, they should get in line and update or they can prepare themselves to lose money.
I like it

BTC.com, ViaBTC and Huobi have all mined one block that is signalling. So if we assume they are in the testing phase and will be onboard in next week all looking good.

Now we just need Binance Pool! (And the testing pools to signal on all bocks).

So looking positive for period 3.... so Mid June....

Just as ETFbitcoin explained, it depends.

You can try to make use of the transaction size or weight tools calculator (https://jlopp.github.io/bitcoin-transaction-size-calculator/) to calculate legacy, nested segwit, native segwit and taproot transaction fee, you can also make use of the public key per input and signature per input to calculate P2SH multisig transactions. If used correctly, you will be able to know the differences in vbytes of each which will determine how transaction fee can be.

I do not have to tell you how legacy address transaction fee will be almost twice that of native segwit addresses and as native segwit transactions have the lowest fee for now, so I will be comparing native segwit transactions with that of taproot.

If you check the transaction vsizes or vbytes of both native segwit and taproot, they are almost the same, but segwit is slightly lower which can be very insignificant. Which means for transaction that require 1 public key, the transaction fee will be almost the same for both native segwit and taproot transactions.

But taproot make use of schnorr signature to make multisig transactions indistinguishable from transactions that require just only 1 public key (normal bitcoin transactions). Multisig transaction fee is higher than normal single wallet transactions, the higher the number of public key required in a transaction, the higher the transaction fee. If segwit transaction is low, but the more the the public key still required for a transaction, the higher the fee, but the fee will be much lower if compared to legacy addresses, but taproot makes the multisig transactions indistinguishable by making use of key aggregation in which the transaction will look like single payment wallet. Which means, increase in the number of public key needed in a transaction still will require the same amount of transaction fee as that of single payment wallet.

Which means taproot reduces the fee of multisig wallets, and making its transaction indistinguishable from other Bitcoin transactions.

We aren't facing any kind of deadline after which bitcoin ceases to exist if it hasn't upgraded yet! We are also just in the second week after the release of v. 0.21.1 and I'd rather everyone upgraded naturally specially miners who run modified software not just bitcoin core as is.

Thank you
yes, I use  legacy address , that make fee feel high
if use segwit addresses send, when sent will get lower fee right?
and in case if use segwit addresses for receive , that will help sender to paid fee lower too or not?

If using native segwit instead of legacy address for transaction

• There will be 42% fee reduction for 1 input 2 output
• There will be 50% fee reduction for 10 input 2 output
• There can still be up to 52% reduction as the number of input increase

You can read this (https://bitcointalk.org/index.php?topic=5320216.msg56441031#msg56441031) to know more about how to minimize Bitcoin transaction fee. (https://bitcointalk.org/index.php?topic=5320216.msg56441031#msg56441031)

1. Increasing privacy
2. Blockchain data bulid up will be reduced if compared to recent multisig
4. Non-malleability, ECDSA signature malleability was addressed in BIP62 (https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki)
5. MuSig, that can make private smart contracts outside of the blockchain possible
6. Creating way for generalized taproot (G'root) which would be a transition from key aggregation to cross-input, making CoinJoin possible (but not sure or certain this will be allowed).

Never mind me generalizing the importance of taproot. In lowering transaction fee, taproot will focus on key aggregation in a way to favour multisig transactions, making it not distinguishable and with low fee as I explained above. As I calculated its transaction weight with that of segwit, there was only slight difference if comparing it with segwit single payment wallet.

One block from Binance! So we have just enough pools to activate in the next period.

We just need all the pools who have signalled with one or more blocks to be singling 100% of the time (and a bit of luck) and will activate in mid June.

So now likely that Speedy Trial will be a success.

OK, plus the upgrade is not facing fierce resistance from the mining cartel. You’re right, if everyone is cooperative, the network should do a regular Miner Activated Soft Fork, and minimize the risks.

Cartel surely does not seem to be a correct word to describe bitcoin mining.. even though there seemed to have been some common interest (resistance) in the 2017 forkening drama.. but even then the factual play out of those events do not really seem to rise to the level of cartel then, and maybe even less so now.

cartel just seems like a misleading term that exaggerates and hardly describes with very much accuracy.

1st signalling block from BTC.TOP. So now there is a clear margin of over 90% of hash power that has voted in favour.

So mid June looking highly likely assuming all pools who have signalled once start signalling with all their blocks before end of May.


Wonder if that will help Bitcoin regain its dominance - as fallen to 40% recently. As a successful soft fork shows current governance processes are at least functional!

Taproot won’t be activated in this period.

https://talkimg.com/images/2023/05/16/blob3f629cbe4adc52d4.jpeg

We all knew that, but now it is official.
Support is growing amongst miners, and the hash power of pools that signalled activation in at least one block is now well above 90%.
Sound promising.

Yes bro, they are getting there: looking at the stats, one thing was a bit odd, Binance pool had only one block signaling taproot over 40. There are a few pools which are behaving in a weird way but maybe that is me that I do not know very much about how the whole thing works.
As I write we are above 78.08%: only 12% missing. Not so bad  ;)

Binance pool has 2 signals over 44 now, but it is truly somehow, but I remember when mining pools were to show support for Taproot, Binance pool got me annoyed as it does not show support for Taproot earlier, but it later showed support. I think Binance pool will still also show green signal but it can take time as the pool like delaying.

It does not seem correct, but Jihan Wu and his Chinese friends imposing their will on the network surely did make the community feel that way, and there was the New York Agreement. Am I exaggerating? OK, but the UASF was a victory for the community more than most people would admit.

Assumption has been that the pools do a test block - to check it works OK (which we guess this is). Then they slowly roll out to their infrastructure - so next we might see 25% of blocks signalling from them then 50% then 100%. Or however it is they roll it out. But I think they said on Twitter were hoping to be at 100% by end of this week.

BTC.TOP signalling too - so now all of the top 12 pools have signalled one or more blocks - so if they all signal full time up at about 95%.

I did not know that, thank you for the clarification.
After the latest addition by btc.com, unless these miners go nuts taproot can be activated during the next round since 95% is enough to get this upgrade done soon!
cannot wait for it

we can slowly put the hats on 8)

https://pbs.twimg.com/media/E1oqfUvWEAIGaUh?format=jpg&name=smallhttps://pbs.twimg.com/media/E1oqfUpXMAEi6pu?format=jpg&name=small
https://twitter.com/BitcoinMemeHub/status/1394473764365217795 (https://twitter.com/BitcoinMemeHub/status/1394473764365217795)

If my OpSec IRL wouldn't require any mention of my crazy bitcoinery I'd absolutely wear that amazing hat but given the fact that I'm almost paranoid as fuck, I'd never wear it in public.
Great design and good news, taproot can come sooner than I imagined.

There is nothing to test since they are not changing anything about the block itself just a single bit in the block header version field!
It is either because they have different remote servers that operate separately and have to be upgraded one at a time or the change is interfering with something else they are doing such as using ASIC boost!

Is the purported "ASIC's boost" overt or covert or just difficult to know what is happening? 

And how speculative is such an "ASIC's boost" practice that you mentioned?  I heard that covert ASIC boost was a "thingie" in 2017-ish, but I thought that segregated witness removed such possibilities to engage in such practices, at least in terms of how it was understood to be being carried out in early to mid-2017.

It is speculation.
As for SegWit it didn't remove ASIC boost, it just made it harder since it requires witness merkle root in coinbase. Otherwise the "boost" is mostly about how you compute the 3 block compression that is required in computing the double SHA256 of the 80-byte message.
I believe the version manipulation (which would make them hesitate to upgrade soon) is categorized under Overt AsicBoost.
Here are two references:
https://arxiv.org/ftp/arxiv/papers/1604/1604.00575.pdf
https://blog.bitmex.com/graphical-illustration-of-a-bitcoin-block/

I think we are there!

All 11 of the top 11 pools are signalling with all blocks. As are 3 other smaller pools.
So voting over 94%.

Assuming no pool changes its mind, and there is no shift in miners to non-signalling pools then lock-in around the 11/12th June is certain to happen.

https://www.coindesk.com/when-will-bitcoin-taproot-upgrade-lock-in (https://www.coindesk.com/when-will-bitcoin-taproot-upgrade-lock-in)

Indeed.
It's nice seeing the "community", in a broad sense, cooperate on a hugely non-controversial update, even more on a difficult time for bitcoin, that is under attack on many fronts.But signaling for activation in the third or fourth or any other period of the speedy trial won't change the timeline.

btc.com is still not fully signaling. My monitoring of them indicates that they are only issuing work that signals for Taproot on 1 out of 4 of their stratum servers. This is consistent with the number of signaling blocks that they have been mining too, as most of their blocks do not signal.

I agree with that. From Block 684317 that was mined 10 hours ago to the recent block mined when I posted this, Block 684368. It would be noticed that BTC.com is not fully signalling. Also if Rawpool can signal and fully signal, it will almost make all new blocks mined to be part of blocks that signal for taproot activation.

Block that did not signal right from block 684317that was mined ten hours ago to block 684368 that was mined few minutes ago before I posted this.
Block 684317: BTC.com
Block 684327: Rawpool
Block 684329: Unknown mining pool
Block 684330: Arkpool
Block 684332: BTC.com
Block 684333: Rawpool
Block 684350: Rawpool
Block 684367: BTC.com

Everyone can slowly wear their masks on too, https://taproot.fish/

What is wrong with BTC.com? They signalled for Taproot, then they stop signalling? Is this just a simple problem with not fully upgrading all their servers/nodes, or something else? There are 85% of miners signalling, BTC.com holds 10% rounded off.

https://taproot.watch/miners

Most probably yes.
Some mining pools seem to be slow at rolling out the upgrade to all their servers and end up only updating one at a time which is why the numbers are lower than 100%.
It seems like we could get locked_in after the next difficulty adjustment though.

Not every pool is like SlushPool :) However, it could well be that if it's not the actual next period maybe it could be the next one.
From the data available, it doesn't look like miners will not follow and I'm pretty confident we'll have it updated soon. I want to see it in action, as theory-wise is still so foggy to me.

hmm, checking the stats on my node (using bitcoin-cli getblockchaininfo), only 72.5% of blocks have signalled this difficulty period. Maybe I'm reading it wrong?

whatever the true stats are, the number is clearly climbing.

I guess, I could check the computation, but I am lazy, that the website considers a pool signalling for readiness when the last block found is signalling readiness.
When the pool is considered signalling, then 100% of the hash rate of such pool is added to the sum.
So it is quite misleading when a pool signals only a few blocks (because not everyone amongst their miners is actually signalling) as the actual ratio is lower, as your node signals.

But this is too simple for you, maybe I didn’t even understand what you said!

I think you read the statistic incorrectly, if you think "count": 725, means 72.5% block signal Taproot, then it's incorrect. According to "help getblockchaininfo", it refers to number of block which signal taproot. CMIIW.

no, I'm doing 725 / 987 = 0.7345 (see, I told you it was climbing :) )

my interpretation is that "count" signifies "blocks signalling taproot BIP9, in this 2016 block difficulty period" and that "elasped" signifies "total blocks mined out of this 2016 block difficulty period"

I think the difficulty period and the signalling period are synonymous, I'm just trying to simplify the details (plus I'm not sure either :P)

I am not running Bitcoin core or any full node, but with what I calculated from https://taproot.watch/, Carlton Banks is right as it is the same as my calculation here while used 726 signalling blocks and 262 non-signalling blocks.

From the site, I got this data

• 726 signalling blocks
• 1028 upcoming blocks
• 262 non-signalling blocks

But to know the present total percentage of the blocks that signalled, I excluded the upcoming blocks, so I used only signalling and non-signalling blocks for it.

Signalling blocks + non-signalling blocks = recent total blocks mined (2016 height)

726 + 262 = 988

Percentage of signalling blocks = signalling blocks divided by total recent block mined (within 2016 block height) multiply by 100

Percentage of signalling blocks = 726 ÷ 988 * 100 = 73.48

Percentage of recent signalling blocks = 73.48

https://i.imgur.com/SA8k5Ho.png

Percentage of recently (last 144) signaling blocks is 86.8% = 125/144

https://taproot.watch shows the percentage of current period (73.5% right now) above red/green blocks at the right, but for some reason only before it's clear that current period couldn't lock-in (before 202 non-signaling blocks).

I think the percentage on the taproot.watch site is calculated by looking at the percentage of blocks each pool has produced in this period (its % hash rate).

It then sums the % hash rate (over the current period) of all the pools that signalled on their LAST block.

So is effectively forward looking.

But annoyingly BTC.COM has only partly upgraded their infrastructure. So only about 1/3 of their blocks are signalling. They count for about 10% hash rate.

If their last block was a signalling block their 10% is included (so jumps to 94%) if their last block was not signalling they are not included so rate drops to 84%.

I think BTC.com said on twitter they should be signalling full time by end of this week. Assuming they do then is a dead cert for next period - otherwise will be very tight!

hashrate can be added or removed at any time. So maybe. But it looks pretty positive.

---

1006 blocks out of 2016, 741 of which signaled. Looking decent. 74% at near the half-way mark, maybe that will improve.

yeeeeesss... o_O

it's slightly more likely that more hashrate will be added/removed than those things though. slightly

https://pbs.twimg.com/media/E0ZNcDQWUAAyonL?format=jpg&name=small
https://twitter.com/BitcoinMemeHub/status/1388882687755227150 (https://twitter.com/BitcoinMemeHub/status/1388882687755227150)

i think that the whole signaling procedure will find a positive and relatively quick end after all  ;) :D

I don't know if the guys at Taproot.watch read this thread, but today they modified their website like the following:

https://talkimg.com/images/2023/05/16/blobc95e7126d9f2eb8d.png

So now they consider the %age of the hash rate currently signalling. Again, they look only at the last block, and the hashrate is considered all signalling, even if the actual percentage of "green" blocks amongst the ones mined by the pool is reduced. 
The potential hash rate is the sum of all the miners who have signalled at least one block.

Again, pretty creative, but in the end, the result doesn't change much: we are getting there.

It's normal for pools to have multiple servers.  Some have upgraded partially for risk reduction reasons, presumably they'll go ahead and upgrade the rest when they're confident that the upgrade is stable.

Taproot.watch now has a "Potential" field, which counts all partially signaling pools as fully signaling pools all the time (instead of only when their latest block signaled).  It currently reads 95.61% --- meaning if BTC.com & others who are partially upgraded fully upgrade before the next window it is extremely likely that it will lock in during that window.

yay 8)💪👌

https://pbs.twimg.com/media/E2EmFIBWUAgEmfi?format=jpg&name=small
https://www.reddit.com/r/Bitcoin/comments/nj1z6o/yesterday_was_the_first_full_day_with_over_90/ (https://www.reddit.com/r/Bitcoin/comments/nj1z6o/yesterday_was_the_first_full_day_with_over_90/)

in addition, taproot.watch has now created a stats, in which you can better represent the signalling
https://taproot.watch/stats (https://taproot.watch/stats)

Nice addition to taproot.watch (http://taproot.watch)

They now added a "Stats" tab where you can look at the graph of Taproot activation percentage:

https://talkimg.com/images/2023/05/16/blob4614712fa76cf5ff.png

We see percentage hovering around 90%.
This bode well for next period, with all. the known caveats about how this website computes the harshpower!

Looks like we are there!  ;D

BTC.com has signalled with all of their last 7 blocks!

So assuming no miner changes their mind will lockin around the Sat 12th June.

Yes, but as I checked it recently, the percentage is now over 96%

https://i.imgur.com/nd6RAyM.png

I noticed Rawpool are signalling already, also most likely that BTC.com are fully signalling.

It would be important for the bitcoin community (whatever this means) to see universal supporto of a non controversial upgrade, while other subjects propose controversial agreements on different topics.

You seem to be misinterpreting.

.

No one is saying it has locked in already.  They're saying we're on course to achieve lock in next period.

And technically even after it has locked in we have to wait till November before the 1st tx's and so the 1st Blocks with it in.

Up to that point if a majority of the miners downgraded (or never actually upgraded - just signalled) it would not manage to actually maintain the longest chain so if someone published a currently valid tx that was invalid under taproot we would have a chain split... (I think I am right on this?)

So if you enjoy a good conspiracy theory can run with that scenario... which really would be chaos... BitcoinCash/SV all over again but with Core having the lower hash rate - and nobody maintaining longest chains codebase!

The purpose of the delayed activation is to give plenty of time for everyone to upgrade.

Bitcoin doesn't follow the longest chain, it follows the longest valid chain-- and at least to upgraded parties any taproot-invalid chain wouldn't be valid.  So the idea is that it doesn't even matter too much if such an invalid chain is created, as it'll just get ignored and the effect would just be some hashrate vanishing (until the losses cause them to wake up and fix their stuff :)).  And this holds no matter how much hashrate there is...

Of course, parties who aren't transacting and are asleep at the switch might not have upgraded but if they're not accepting transactions in realtime it doesn't much matter what chain they are on. :)

So I think that really takes the wind out of the chaos conspiracy theory. :P  But it's a good reason to get major exchanges and other influential parties that accept a lot of payments to confirm that they've upgraded prior to activation.

Also, "someone published" isn't sufficient.  Pre-taproot nodes (and miners) will not relay or mine taproot spends.  So the only way a block could be created with an invalid spend in it is if some miner intentionally did so (or at least lobotomized the protection out of their node), even if their software wasn't upgraded.

I forget the detail of backward compatibility, so i'll just ask it. Why pre-taproot won't relay taproot-transaction? Is it because the transaction missing witness and the (empty ?) script automatically treated as valid script?

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.

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 (https://github.com/bitcoin/bitcoin/blob/60132382a74506f34d3c7b0b162799772505608c/src/script/interpreter.h#L107-L109) that acts as a standard rule and makes the node reject (https://github.com/bitcoin/bitcoin/blob/v0.20.1/src/script/interpreter.cpp#L1528-L1531) 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+ (https://github.com/bitcoin/bitcoin/blob/v0.21.1/src/script/interpreter.cpp#L1927-L1930).

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.

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...

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%

https://i.imgur.com/rU0BSal.png

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.

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.

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

Better because agreeing 100% is never a good thing. :D
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.

Apparently, Marathon is going to signal Taproot Activation:

https://talkimg.com/images/2023/05/16/blobb5fa54712949f102.png (https://twitter.com/michael_saylor/status/1399407493839732744?s=21)
https://twitter.com/michael_saylor/status/1399407493839732744?s=21

From Marathon Press Release (https://ir.marathondh.com/news-events/press-releases/detail/1244/marathon-signals-for-taproot)

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 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.

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?

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

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

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.

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.

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.

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

https://pbs.twimg.com/media/E22oqUvWQAEbKKr?format=jpg&name=small
https://twitter.com/hampus_s/status/1399960827374063616 (https://twitter.com/hampus_s/status/1399960827374063616)

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

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.

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.

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 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.

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.

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.

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.

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. :P

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.

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

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.

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.

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 :)

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.

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)

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.

Only milliseconds.

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.

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.

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

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

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.

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.

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 :)

I hate to jinx this, but I am going to report anyhow on a seemingly near inevitability that this thingie is getting locked in this period.

Of course, getting the information from https://taproot.watch/

I understand that no one wants to count their chickens before they are hatched, and I am in that same camp.. so I would not be saying anything if I thought that there were some kind of meaningful and material risk that my celebration could be gamed in such a way to show that I am wrong (or to prove me wrong).. because no one is going to give any shits about what I say or think (except maybe my mom).

What I am trying to say is that there has to be some pretty damned extreme changes in miner behavior for this thing NOT to get locked in this difficulty period.. not out of the question.. but still odds?  I am going to say without specifying too much... "quite low".. and that is another reason for this ccccciiiiiiiittttttttteeeeee post.

As I type, we have about 97.85% of the blocks having had already signaled for taproot - more specifically - 1,093 out of 1,117 that have already been mined.

We also have ONLY 899 blocks remaining for the difficulty period and only 722 (which is 80%) have to signal for taproot to reach the 90% threshold.

As I type, I am considering opening up my specially-dedicated champaign right now, and maybe treating myself to an especially-dedicated slurpy too.  #justsaying.. call me premature, if you must.. I don't give no cares.    :P :P    ;) ;)

It would be neat if taproot.watch would add a indicator on how low the signaling would have to fall to block it this period.

You know... it's funny.

I am certainly among those who are happy to see Taproot being activated both so smoothly, and quickly!

But I kind of think there is a bigger story in this taproot activation that we are not quite grasping yet.

That was the fact that this has been (please apply JJGs jinx disclaimer here as well) an absolute tour de force for bitcoin governance.  We have proven that not only can the network be upgraded, but it can be done in a clear, orderly, quick fashion!

It even makes me think that when time and tech converge along with bitcoin network use we *might* even be able to see something more controversial, like a block size increase, be implemented in the same way.  Again, this would be when consensus was there, and all the stakeholders were ready, etc.  If ever. Just saying.

In the aftermath of the SegWit activation I think we may have become overly pessimistic about what we may or may not be able to do insofar as network upgrades/tweaks.  The reason I chose the idea of the block size increase for this statement was because truly I did not think we would have a chance of something like that as the protocol began to be more and more set in stone.  Maybe not?!?

taproot did not impose any force measure.
there were some issues in regards to segwit. such as that it 'increase capacity 2.4x' and 'cheap fee pledges'*, which were obvious empty/false pledges and those 2 things were the 2 things people actually wanted at the time

taproot is different. its not really over promising anything
its not pretending to offer one thing but offer something else
its not attempting to force itself

so there is no controversy or resistance

taproot does not really hurt legacy/native users. if people want to use taproot they first have to move funds into taproot addresses.
segwit did hurt legacy users. eg: (WITNESS_SCALE_FACTOR = 4; (https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h#L21)) means legacy tx became more expensive*

so because taproot devs are not playing these flip flop false promise backstabbing games this year. they are not getting any drama towards taproot

*to name a few

EDIT to answer gmax below....


pre segwit activation blocks reached peak of 2.5k average tx per block..
post segwit activation blocks reached a peak of 2.7k average tx per block..check all time graph (https://www.blockchain.com/charts/n-transactions-per-block)
so gmax misinforms about a +10% coupleday peak.. but 0% 3 year average change as his answer to 'cheap'
but does not acknowledge the 4x premium his friends added to the code that disadvantage 60% of users

witness scale factor is used to make legacy transactions 4x more than segwit
everyone knows that a hard data real byte of legacy is trapped into being recognised as a more bloated 'vbyte of 4x its actual hard drive stored size
its the very reason while the blocks can be 4mb bitcoin code can only store 1mb of legacy per block
search github and you will find this x4 premium in many examples of * WITNESS_SCALE_FACTOR
1 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/consensus/tx_verify.cpp#L140), 2 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/consensus/tx_verify.cpp#L146), 3 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/consensus/tx_check.cpp#L18), 4 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/test/sigopcount_tests.cpp#L139), 5 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/test/sigopcount_tests.cpp#L151), 6 (https://github.com/bitcoin/bitcoin/blob/7fcf53f7b4524572d1d0c9a5fdc388e87eb02416/src/core_write.cpp#L201)

theres more but i limited myself to spending just 20 seconds in debunking gmax. anyone can find these multipliers in 20 seconds.. even gmax
segwit dies not discount transactions. it just avoids a premium.
and not by just a segwit activation giving all bitcoin users a discount/ avoid premium fee.
but only those specifically having a segwit UTXO get this avoid premium fee

gmax. atleast be honest about how your team decided to play around with the fee structure to disadvantage legacy address users and try to promote/incentivise segwit users to try converting people

That isn't true. Segwit increased capacity and as a result lowered fees for everyone, maybe not as much as you would like but that doesn't justify spreading hateful misinformation.

MARA Pool has signaled for two blocks   :)

To be fair we had proven this half a dozen times (maybe more) before the 2017 fork when each upgrade went through smoothly and without any drama or at least very little. BIP16, BIP34, BIP65, BIP66, BIP112 are some of these soft forks that I can think of.

Wrong. The lack of "drama" is simply because unlike 2017 there is nothing to be gained from that drama. For example there is no shitcoin like bcash to be created to make money.

When SW was being proposed, there was a community debate if bitcoin should be hard forked to allow for a max block size increase. SW was an alternative to increasing the maximum block size via the use of signature weights.

There is no alternative proposals to Taproot, and there is no serious technical opposition to it either, that I am aware of. I suspect the delay in signaling support for Taproot by the miners is due to them reviewing the code, running their own tests, and checking for security vulnerabilities.

This is not necessary. I can imagine some future Segwit version with Pedersen Commitments (without hiding amounts to make it small enough). Then, bigger blocks won't be needed if you could deposit your coins to some new address that will allow you to join many transactions together. I think if we have transaction chain A->B->C->...->Z, then there is no need to increase block size. What really is needed is storing A->Z transaction and make it resistant for double-spending attempts.

I wonder if joining transactions could be done with taproot. So far, I have no idea how to make it in a safe way, but if it could be reduced to ECDSA keys, then they could be joined with Schnorr signatures, so maybe there is some way to do so.

Very valid.  Yet I still think it is good, especially for the users who are not as keen about the details of past BIPs as well as development in general needed *this* particular upgrade to go smoothly.  I think it was palpably still tentative feeling out there because of all the drama in 2017.

Seems we are going to be dragging the shitcoins behind us possibly indefinitely, but it's becoming more and more dangerous for them to try to get in front of us.  The weight and momentum of Bitcoin is greater than it was a few years ago.

Here's an update about Taproot (after a distracted comment about price):

I know.  I know.  I know.  Some people are getting depressed about ongoing testing of buy support and wondering how far the low is going to be able to go ...and many (including yours truly) don't want to say anything.. which is understandable - even if we have positive happenings of getting more and more good news about Taproot getting locked in during this difficulty period, that a day ago, I had already asserted, with a wee tiny bit of trepidation, to be in the ballpark of inevitable ... ..

So, since my post from yesterday (see my numbers and link below), we have had 3 blocks signal "no" (1.8%) and the other 167 blocks signaled "yes" (98.2%).

As I type, we have about 97.98% of the blocks having had already signaled for taproot - more specifically - 1,258 out of 1,284 that have already been mined.

We also have ONLY 732 blocks remaining for the difficulty period and only 557 (which is 76.09%) have to signal for taproot to reach the 90% threshold (but who is counting?).

i couldn't figure one thing out here after this period ends assuming that taproot gets locked in are we going to start rejecting those blocks that don't signal for taproot or does it all end and we forget about it until November that it activates then reject them?

They won't start rejecting blocks immediately even though lockinontimeout=true, because the timeout is all the way at the end of October. That's when non-signaling blocks will start being rejected. It will not be activated at the end of a successful signaling period.

hmmm, I thought that the October/November activation simply permits witness v1 spends? (and so any non-upgraded miner will reject blocks containing witness v1 spends, and subsequently find themselves mining a fork)

No blocks will be rejected unless they contain an invalid taproot spend after the lock-in height or are a descendant block of a block that has an invalid spend.  By invalid I mean breaks the taproot rules, e.g. last a signature or has one that doesn't pass validation.

The normal construction of softforks tries pretty hard to avoid creating any conflicting chain, as much as is possible.

as long as this activation does not include code/rule to only accept a new flag number/version number block then no hardfork/no mandatory split will occur.. thankfully
so far no plans to do so.. thankfully this time

as usual and has always been the case
blocks that dont meet the rules of validation get rejected as standard.
as gmax said

meaning and as already said in previous posts.
(unupgraded nodes blindly accept new tx formats)

the only fork risk is if non-upgraded nodes blindly accepts a duff(bad/error/invalid) block which a upgraded node rejects as part of normal consensus.
 
and the unupgraded node is continually getting new blocks that build ontop of the duff block.
but this is like a below 0.0025% chance of occuring. and only affects that small percentage of users in that case. so not a 5% or 50% risk. but a 0.0025% risk. and only to those in that small group

meaning an igornant/intentional pool and a few nodes solely peered to it, will have to intentionally build ontop a duff block for them to make their own altcoin

Alas this is the majority of the Bitcoin hashrate.

While it is only a short timeframe after each block change, the majority of the network hashrate will mine on an invalid transaction for a short period of time after the block change.

As I've mentioned before, the issue is if anyone else then finds a quick block without any invalid transactions in it, on top of the invalid one, what pools will continue on that block, and for how long?

majority of network does not just stop mining their own block attempt when first seeing a new block header.
majority of network actually continues its block effort until a new block is validated.

less than 0.5% of blocks are 'empty blocked' (280blocks of 58k are empty(2020stats))
adding to that the amount of pools that are not signalling for TR is under 5%

so at very max its a 0.5% of 5%. meaning with other factors at play. the end the result is a 0.0025% risk
definitely not a 'majority of network will mine'

so calm down(seems im repeating myself)
um i dont think any would. as the odds are super low
as there is no large economic incentive /positive reason to waste so much cost on doing this intentionally. (standard game theory)
but it seems you believe majority of pools will do this because its your belief that majority of pools do use crappy stratums and spv wallets and do empty blocks as standard.. so maybe you should be asking yourself which pools would be doing this.

No idea who you got that statement from, but it's not true.

Yep, that's the time spent mining on non-validated blocks.
average 600 seconds per block, 0.5% gives an average of 3 seconds per block change.

Not a very small number ... though using your numbers 0.5% times 5% is ... 0.025% :)
As I've made clear before, the issue is what the other pools do on top of the following valid block if it is quick.

Statistics says it doesn't matter how long it took to find the first block, since it's already been found, the next block is the same probability or 0.5% chance of finding a quick block on the empty block and continuing the bad chain.

In the past when this happened, two big pools went off on their own invalid chain, with a hash rate close to half the network, and continued that until FUPool noticed the issue in their discussion channel and I contacted Bitmain.

It has nothing to do with wallets, it's to do with SPV mining - though that term has been modified after it's inception to include something else.

I guess the more recent name is 'Spy-mining' where a pool gets the work change from a miner connected to other pools, and uses the header in the miner to switch to the next block.
Since they don't know what transactions were used to produce the block, they must mine an empty block until they get and verify the full block.
Same can be done with a hacked bitcoind itself and use the header when it's first received before validating the block, and again the same reason: they don't know what transactions where used yet, so must mine an empty block until they verify it.

However, it's simply a case of ignorance, resistance to change and following what the other big pools do.

Edit: if you wish to test this, mine on a large pool that produces empty blocks and look at the 1st work sent each block change.

oh kano...(facepalm)
no the 0.5% is not some time conversion meaning 3 seconds(your premiss)
its actually the blocks that occured throughout 2020 where out of 58000 blocks only 280 of them were empty blocks. its got nothing to do with YOUR "3 second" maths of 600seconds / 5%.

its got everything to do with the small insignificant utility of doing empty blocks

anyway. as for your "not sure where you got that statement from but its not true"
i quoted YOU. infact you quoted me quoting you. thus double obvious where that statement came from

seems your forgetting what you wrote and then spinning a different version of events as if you never said the first version of events you implied even when its clearly been quoted of what you said

one last time.. so take a seat. relax and slowly understand things. have a cup of coffee after and actually let the information be absorbed.
YOU said majority of network would build onto a invalid block..
I SAID no. majority of blocks are NOT built ontop of via the 'empty block strategy'
as proven by only 280 blocks out of 58000 blocks statistic

i debunked you by showing you the under 280 of 58000 stat for 2020. which shows that majority of pools DO NOT build ontop of invalid blocks due to the low amount of empty block strategy being used.

i hope you get it now. accept that empty block strategy is not used as often as you presume

.
now a reminder of the math. for the last time. so please allow it to soak in
0.5% is the number of empty blockers (those who build on a block thats not been validated yet)
5% is the under 5% that have not signalled a desire to upgrade to TR
=under 0.025% that 'could' ignorantly accept an errored block
then with other factors included..(basically assuming a 10% risk/intent) puts it at a 0.0025% risk of an intentional event.

...
so lets just pretend you stepped a few steps forward and realised the chance of it happening is 0.0025%

your then asking what about those that then build on top of that
seriously your talking about "those".. meaning you want to interrogate who the 0.0025% pools are
well it does not matter in the end. as its a small insignificant proportional risk of a insignificant amount that would want to make an alt. and even if they did. so be it. they are an alt.. bye bye moving on

meaning 99.975% have rejected that block and moved on and just accepting normal blocks
yawn. no drama. non event. didnt even notice it happen coz its such an insignificant event
just like all other orphans that have ever occured in the last 12 years that no one talks about or realised even occured unless they specifically went and looked

realise that is like a negligible amount/opportunity that would make their own altcoin if they wished to proceed down their path. and thus it does not impact the rest of the network
..
the orphan rate drama just self regulates it out.
at a risk of 0.0025%
a meaningless number of insignificance

again.. the chances of a pool making an empty block is about 280 out of say 52k+
the chances of a empty block building ontop of a faulty block due to not being an upgraded node is even less
the chance of a pool  normal game theory incentive. and intentionally wanting to cause an error even less

so please stop saying/thinking that majority of the network does the empty block strategy, let alone other false presumptions
because stats show the very opposite.

majority of stratum servers(pools) are NOT SPV nodes making empty blocks

this is the final time im going to repeat myself. because it seems you are not understanding stats and numbers and quotes
step passed your pre conceived notion that majority of pools are amateurs that use crappy stratum software.
as thats not reality.

I've said the exact opposite of what you said:
majority of the network does stop mining their own block attempt when first seeing a new block header. <- they immediately build on a new unverified header
majority of network actually doesn't continues its block effort until a new block is validated. <- it doesn't continue mining the old block, it builds a new empty block on top of the unverified header

i.e. the majority of the network switches to the next block when it sees the block header, before validating the merkleroot/transactions,
i.e. the majority of the network mines on an unverified block every block change for a short period of time

This has nothing to do with it.
The issues is e.g. if anyone creates a block with a taproot transaction before it's valid, the majority of the network will accept it at the point of the block change, because they don't verify transactions before they send their miners a new empty block to mine.

You said 0.5% is the % of empty blocks.
That shows how long, on average, it takes to switch from an empty unverified header to a verified header with transactions.
i.e. 0.5% of the average 10minute block - or 3 seconds.

Really I'm not sure why I'm repeating myself, go read:
https://bitcointalk.org/index.php?topic=5251592.0