Jorge Tim贸n [ARCHIVE] on Nostr: 馃搮 Original date posted:2022-03-11 馃摑 Original message:On Fri, Mar 11, 2022, ...
馃搮 Original date posted:2022-03-11
馃摑 Original message:On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim贸n <jtimon at jtimon.cc> wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>
What accusations of bad faith?
You're accusing me of having prosecution complex.
I'm accusing you of ignoring the "yes-users-veto" faction. But that doesn't
require bad faith, you may simply not understand the "faction".
A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr. It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling. That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed. Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot. Firstly, users can
> just not use taproot. Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code. Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>
Since it's about activation in general and not about taproot specifically,
your third point is the one that applies.
Users could have coordinated to have "activation x" never activated in
their chains if they simply make a rule that activating a given proposal
(with bip8) is forbidden in their chain.
But coordination requires time.
Please, try to imagine an example for an activation that you wouldn't like
yourself. Imagine it gets proposed and you, as a user, want to resist it.
As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed. Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>;. I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative. A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>;
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology. But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
>
Thank you, perhaps I'm wrong about this and all his concerns were addressed
and all his suggestions heard. I guess I shouldn't have brought that up,
since I cannot talk for Mark.
_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/0b51b48f/attachment-0001.html>;
馃摑 Original message:On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Mar 11, 2022 at 7:18 AM Jorge Tim贸n <jtimon at jtimon.cc> wrote:
>
>> I talked about this. But the "no-divergent-rules" faction doesn't like
>> it, so we can pretend we have listened to this "faction" and addressed all
>> its concerns, I guess.
>> Or perhaps it's just "prosectution complex", but, hey, what do I know
>> about psychology?
>>
>
> Your accusations of bad faith on the part of myself and pretty much
> everyone else makes me disinclined to continue this discussion with you.
> I'll reply, but if you want me to continue beyond this, then you need to
> knock it off with the accusations.
>
What accusations of bad faith?
You're accusing me of having prosecution complex.
I'm accusing you of ignoring the "yes-users-veto" faction. But that doesn't
require bad faith, you may simply not understand the "faction".
A major contender to the Speedy Trial design at the time was to mandate
>>> eventual forced signalling, championed by luke-jr. It turns out that, at
>>> the time of that proposal, a large amount of hash power simply did not have
>>> the firmware required to support signalling. That activation proposal
>>> never got broad consensus, and rightly so, because in retrospect we see
>>> that the design might have risked knocking a significant fraction of mining
>>> power offline if it had been deployed. Imagine if the firmware couldn't be
>>> quickly updated or imagine if the problem had been hardware related.
>>>
>>
>> Yes, I like this solution too, with a little caveat: an easy mechanism
>> for users to actively oppose a proposal.
>> Luke alao talked about this.
>> If users oppose, they should use activation as a trigger to fork out of
>> the network by invalidating the block that produces activation.
>> The bad scenario here is that miners want to deploy something but users
>> don't want to.
>> "But that may lead to a fork". Yeah, I know.
>> I hope imagining a scenario in which developers propose something that
>> most miners accept but some users reject is not taboo.
>>
>
> This topic is not taboo.
>
> There are a couple of ways of opting out of taproot. Firstly, users can
> just not use taproot. Secondly, users can choose to not enforce taproot
> either by running an older version of Bitcoin Core or otherwise forking the
> source code. Thirdly, if some users insist on a chain where taproot is
> "not activated", they can always softk-fork in their own rule that
> disallows the version bits that complete the Speedy Trial activation
> sequence, or alternatively soft-fork in a rule to make spending from (or
> to) taproot addresses illegal.
>
Since it's about activation in general and not about taproot specifically,
your third point is the one that applies.
Users could have coordinated to have "activation x" never activated in
their chains if they simply make a rule that activating a given proposal
(with bip8) is forbidden in their chain.
But coordination requires time.
Please, try to imagine an example for an activation that you wouldn't like
yourself. Imagine it gets proposed and you, as a user, want to resist it.
As for mark, he wasn't talking about activation, but quantum computing
>> concerns. Perhaps those have been "addressed"?
>> I just don't know where.
>>
>
> Quantum concerns were discussed. Working from memory, the arguments were
> (1) If you are worried about your funds not being secured by taproot, then
> don't use taproot addresses, and (2) If you are worried about everyone
> else's funds not being quantum secure by other people choosing to use
> taproot, well it is already too late because over 5M BTC is currently
> quantum insecure due to pubkey reuse <
> https://nitter.net/pwuille/status/1108091924404027392>;. I think it is
> unlikely that a quantum breakthrough will sneak up on us without time to
> address the issue and, at the very least, warn people to move their funds
> off of taproot and other reused addresses, if not forking in some quantum
> secure alternative. A recent paper <
> https://www.sussex.ac.uk/physics/iqt/wp-content/uploads/2022/01/Webber-2022.pdf>;
> suggest that millions physical qubits will be needed to break EC in a day
> with current error correction technology. But even if taproot were to be
> very suddenly banned, there is still a small possibility for recovery
> because one can prove ownership of HD pubkeys by providing a zero-knowledge
> proof of the chaincode used to derive them.
>
Thank you, perhaps I'm wrong about this and all his concerns were addressed
and all his suggestions heard. I guess I shouldn't have brought that up,
since I cannot talk for Mark.
_______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220311/0b51b48f/attachment-0001.html>;