Taproot 'concerns'

[TheNewAnon135246]

I have a question regarding the 'anonymous group of developers' that expressed their concerns regarding BIP 340-342 in the Bitcoin dev mailing list. Although I understand the basics of Schnorr/MAST/Taproot my technical knowledge isn't sufficient enough to see if their concerns are valid or if it's an attempt to cause divisiveness (or spread FUD). Can anyone help me out?

The emails in question: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017618.html

[1713930909]

1713930909

[1713930909]

1713930909

[1713930909]

1713930909

[1713930909]

1713930909

[Last of the V8s]

Smacks of a butthurt Mark Friedenbach, yes basically spreading f.u.d.

[100bitcoin]

Smacks of a butthurt Mark Friedenbach, yes basically spreading f.u.d.

Why would Mark Friedenbach spread FUD about Taproot?

[TheNewAnon135246]

Smacks of a butthurt Mark Friedenbach, yes basically spreading f.u.d.

What would Mark Friedenbach spread FUD about Taproot?

Afaik he is more focussed on MAST, not Taproot. I don't see why he wouldn't just share his concerns instead of pretending to be an anonymous group of developers.

[aliashraf]

OP,

I found the e-mails you linked as being original and legitimate no FUD out there, especially I liked the incremental approach proposed there. I don't know why they have decided to run it anonymously nor I'm curious about it, let's stay focused on the text instead of the author.

[Last of the V8s]

..., let's stay focused on the text instead of the author.

ok. fine. whatever. of course.

listen to this pretty measured critique of the issues and implications https://youtu.be/BQo-j3wB8L0?t=1669

[aliashraf]

..., let's stay focused on the text instead of the author.

ok. fine. whatever. of course.

listen to this pretty measured critique of the issues and implications https://youtu.be/BQo-j3wB8L0?t=1669

Just checked it out, thank you.  

I don't know whose voice is it (you maybe?)... Anyway, I think the main objection he got is about timing and the fact that the person(s) behind the mailing list post has issued it just after it has passed the discussion phase ...

Well, IDK but don't you think it is because of the part related to packing MAST and Schnorr in one (Taproot) fork or not packing them has not being discussed enough, if not at all, before?

[Wind_FURY]

Another group of people trying to start another scenario like the scaling debate again? ELI5, what is the "controversy" this time?

[squatter]

Another group of people trying to start another scenario like the scaling debate again? ELI5, what is the "controversy" this time?

The group's concerns re: privacy and efficiency aren't necessarily malicious. Either way, I think they were adequately addressed by these replies:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017621.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017623.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017630.html

[Wind_FURY]

Another group of people trying to start another scenario like the scaling debate again? ELI5, what is the "controversy" this time?

The group's concerns re: privacy and efficiency aren't necessarily malicious. Either way, I think they were adequately addressed by these replies:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017621.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017623.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017630.html

Tinfoil hats on, what if that "group", who might only actually be an "individual", wants seperate proposals only because it sets each for another scenario for contention.

OR, what if someone wants Schnorr+Taproot blocked like how Jihan Wu wanted Segwit blocked because it disables an exploit/covert-ASIC-boost?

[figmentofmyass]

OR, what if someone wants Schnorr+Taproot blocked like how Jihan Wu wanted Segwit blocked because it disables an exploit/covert-ASIC-boost?

segwit specifically broke bitmain's covert ASICboost scheme. is there a similar parallel here? i don't think so.

i think segwit established that BIP9 is an inferior activation method. miners should be able to accelerate activation but not block it. a BIP8-style flag day activation---done on a reasonably long time frame vs BIP148---seems appropriate.

i do hope we can avoid another recklessly hasty fork like BIP148.

[squatter]

The group's concerns re: privacy and efficiency aren't necessarily malicious. Either way, I think they were adequately addressed by these replies:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017621.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017623.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-February/017630.html

Tinfoil hats on, what if that "group", who might only actually be an "individual", wants seperate proposals only because it sets each for another scenario for contention.

OR, what if someone wants Schnorr+Taproot blocked like how Jihan Wu wanted Segwit blocked because it disables an exploit/covert-ASIC-boost?

Conspiracy theories aside, it would already be prudent to prepare for that possibility:

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

There is also Pieter Wuille's typically conservative opinion that consensus changes should be difficult and/or take a long time to implement:

I really don't care when things activate, or end up in use. Changes like this should be hard.

[Wind_FURY]

OR, what if someone wants Schnorr+Taproot blocked like how Jihan Wu wanted Segwit blocked because it disables an exploit/covert-ASIC-boost?

segwit specifically broke bitmain's covert ASICboost scheme. is there a similar parallel here? i don't think so.

i think segwit established that BIP9 is an inferior activation method. miners should be able to accelerate activation but not block it. a BIP8-style flag day activation---done on a reasonably long time frame vs BIP148---seems appropriate.

i do hope we can avoid another recklessly hasty fork like BIP148.

Miner-signalling is only for that purpose, to signal that they're ready for an upgrade. It was never intended to be a political tool to exert control for themselves, and what they want for the network. BIP148 was merely a reaction from the community.

[figmentofmyass]

i think segwit established that BIP9 is an inferior activation method. miners should be able to accelerate activation but not block it. a BIP8-style flag day activation---done on a reasonably long time frame vs BIP148---seems appropriate.

i do hope we can avoid another recklessly hasty fork like BIP148.

Miner-signalling is only for that purpose, to signal that they're ready for an upgrade. It was never intended to be a political tool to exert control for themselves, and what they want for the network. BIP148 was merely a reaction from the community.

nevertheless, BIP148's timeline was dangerous and conducive to a network split. it may have been proposed on the mailing list a month or two prior, but the UASF campaign essentially began ~2 months before flag day. that was very little time to amass full node support and thus pressure miners to prevent a network split.

i'd like to see a 1+ year timeline for a UASF. miners can activate earlier if they want to, but that seems like a reasonable minimum given the risks.

[Wind_FURY]

i think segwit established that BIP9 is an inferior activation method. miners should be able to accelerate activation but not block it. a BIP8-style flag day activation---done on a reasonably long time frame vs BIP148---seems appropriate.

i do hope we can avoid another recklessly hasty fork like BIP148.

Miner-signalling is only for that purpose, to signal that they're ready for an upgrade. It was never intended to be a political tool to exert control for themselves, and what they want for the network. BIP148 was merely a reaction from the community.

nevertheless, BIP148's timeline was dangerous and conducive to a network split. it may have been proposed on the mailing list a month or two prior, but the UASF campaign essentially began ~2 months before flag day. that was very little time to amass full node support and thus pressure miners to prevent a network split.

i'd like to see a 1+ year timeline for a UASF. miners can activate earlier if they want to, but that seems like a reasonable minimum given the risks.

That's "blockchain governance" for you. Miners wanted something, the community/economic majority wanted something else. I believe it would always follow the path of the community/economic majority. It's the community that creates the demand for blocks.

[figmentofmyass]

That's "blockchain governance" for you. Miners wanted something, the community/economic majority wanted something else. I believe it would always follow the path of the community/economic majority. It's the community that creates the demand for blocks.

great, we've already established that.

if the "community" tries to UASF on a recklessly hasty timeline like BIP148, i certainly won't support it. next time someone tries to UASF on a 2-month timeline, i say fork them off. people who prefer to risk a network split because they can't wait some additional months for safe implementation are like impatient children. we shouldn't be caving to their demands.

[DooMAD]

Tinfoil hats on, what if that "group", who might only actually be an "individual", wants seperate proposals only because it sets each for another scenario for contention.

OR, what if someone wants Schnorr+Taproot blocked like how Jihan Wu wanted Segwit blocked because it disables an exploit/covert-ASIC-boost?

Even if there were games at play here, I can't see it being anywhere near as fractious this time because there's not much left they can do.  They know now that getting a bunch of random companies to sign an "agreement" achieves basically nothing.  They know now that going ahead with a fork-coin just creates a weak and inferior chain that will likely need another emergency difficulty adjustment just to even barely survive the first day.  They can probably tell that all the users who weren't fooled last time clearly won't be fooled this time either.  We've got our FUD-busting skills refined and ready to deploy against any misinformation campaigns they might attempt.  What's left for them to try?  There will be absolutely no need for a small sub-set of users to react and start foaming at the mouth over another silly user-activated-stalled-flop.

[Wind_FURY]

That's "blockchain governance" for you. Miners wanted something, the community/economic majority wanted something else. I believe it would always follow the path of the community/economic majority. It's the community that creates the demand for blocks.

great, we've already established that.

if the "community" tries to UASF on a recklessly hasty timeline like BIP148, i certainly won't support it. next time someone tries to UASF on a 2-month timeline, i say fork them off. people who prefer to risk a network split because they can't wait some additional months for safe implementation are like impatient children. we shouldn't be caving to their demands.

I believe we should consider what the situation was. Segwit would not have activated if the risk of the UASF wasn't taken. Segwit was running out of time.

BUT, I'm not saying you're wrong.

[gmaxwell]

I believe we should consider what the situation was. Segwit would not have activated if the risk of the UASF wasn't taken. Segwit was running out of time.

That's a misstatement of the station though one advocates of BIP148 were promoting.  No proposal that people are still interested in can run out of time. If the window on the bip9 signalling had closed a new one would have been started.

[Wind_FURY]

I believe we should consider what the situation was. Segwit would not have activated if the risk of the UASF wasn't taken. Segwit was running out of time.

That's a misstatement of the station though one advocates of BIP148 were promoting.  No proposal that people are still interested in can run out of time. If the window on the bip9 signalling had closed a new one would have been started.

Thanks for the clarification.

But would Segwit have activated without the initialization of BIP148, or would the miners have continued blocking it?

I believe "another UASF" would have come.