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.
Topic: Taproot 'concerns' (Read 496 times)
As of derailing the topic: Was it me or you that started saying things about AB? You? Guess what ... yet another apology required 
Mentioning something in passing
By the way, it is a self-moderated thread, the whole derailing thing is up to the original poster to decide about.
As of derailing the topic: Was it me or you that started saying things about AB? You? Guess what ... yet another apology required
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.
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.
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. 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
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]
[This post should be removed when the derailment is resolved]
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).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.
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.
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).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.
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...
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.
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.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.
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?
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.
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 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.
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.
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.
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.
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.
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
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:
Quote from: Pieter Wuille
I really don't care when things activate, or end up in use. Changes like this should be hard.
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.
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?
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
Another group of people trying to start another scenario like the scaling debate again? ELI5, what is the "controversy" this time?
Jump to: