Bitcoin Forum

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

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

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

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.

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?

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?

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.

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


There is also Pieter Wuille's typically conservative opinion (https://twitter.com/pwuille/status/1125489454494375937) that consensus changes should be difficult and/or take a long time to implement:

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.

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.

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.

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

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.

I think bitmain just wanted time to dump their covert-AB only hardware on a willing sucker (like, say, Calvin).

Regardless, the complaint most people that had complaints had about BIP148 was that the timeline of less than two months was kinda nuts. That issue wouldn't have remained...

As of my understanding, AsicBoost is not defeated by segwit that much. I don't think on-the-fly transaction re-ordering is necessary at all for AsicBoost  while it is exactly what Segwit makes harder.

A hypothetical AsicBoost-only miner machine basically doesn't need and can't change the header on-the-fly as it is received from the pool operator in the most practical cases. I'd conclude that on-the-fly transaction re-ordering efficiency is just important for solo miners with AB-only machines and even for such miners it is absolutely possible to keep their machines busy mining empty blocks in a few seconds window while their cpus are preparing a well-formed header with hundreds of transactions.

Aliashraf, I'm getting a little tired of your posts that demonstrate almost zero understanding and absolutely zero research.  Please take a few minutes to read up on _covert_ asicboost rather than forcing the derailing of this thread with a pointless and off rehashing of material which has been covered elsewhere in depth. If you still don't get it, make a new thread.


[This post should be removed when the derailment is resolved]

On the contrary, I've done enough research on this issue, why should you attack me or anybody else here? Are you paying me for my contributions or something?
Stop insulting people please, you are a moderator here for the god's sake, not a troll!

SegWit relates to COVERT AsicBoost because it makes it HARDER for ONE VERSION of on-the-fly tampering of Merkle Root (https://bitslog.com/2017/04/10/the-relation-between-segwit-and-asicboost-covert-and-overt/). You claim otherwise? If no, then you owe me an apology.

As of the importance of pools in this regard, and the fact that pool worker machines are not allowed to change Merkle Root, any objections? No? Another apology required!

As of derailing the topic: Was it me or you that started saying things about AB? You? Guess what ... yet another apology required :D

Mentioning something in passing does not derail a topic.  Attempting to focus all the discussion on that thing so that we aren't discussing the original topic anymore is derailing the topic.  Guess which one you're doing.

Please check the previous 2 posts made by Greg then tell me it is 'passing or it is not. People went too far in exaggerating the impact of SegWit on covert AB and I can't help it getting sick with such a superficial discussion in the technical subforum.

By the way, it is a self-moderated thread, the whole derailing thing is up to the original poster to decide about.

To get us back on topic, there's an interview published yesterday with Adam Back discussing Schnorr/Taproot at the ~1:36:00 mark:

https://twitter.com/crypto_voices/status/1231187957832409088


The interviewer specifically asks about any concerns he might have, but Dr. Back didn't seem to raise any.  They briefly alluded to a potential dispute that might arise at some point later in time over where to draw the line over privacy (naturally falling in the "privacy = good" side of the argument), but nothing in regard to concerns over the BIPs themselves.