📅 Original date posted:2022-03-30 📝 Original message:@Pushd > Speedy trial ...

Billy Tetrud [ARCHIVE] /

npub1xqc…cnns

2023-06-07 23:06:21

in reply to nevent1q…8s38

📅 Original date posted:2022-03-30
📝 Original message:@Pushd

> Speedy trial makes it worse by misleading lot of bitcoin users including
miners to consider signaling as voting and majority votes decide if a soft
fork gets activated

No it does not. This narrative is the worst. A bad explanation of speedy
trial can mislead people into thinking miner signalling is how Bitcoin
upgrades are voted in. But a bad explanation can explain anything badly.
The solution is not to change how we engineer soft forks, it's to explain
speedy trial better to this imaginary group of important people that think
miner signaling is voting.

We shouldn't change how we engineer Bitcoin because of optics. I completely
object to that point continuing to be used.

On Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> > Any case where a flawed proposal makes it through getting activation
> parameters set and released, but doesn't achieve supermajority hashpower
> support is made worse by bip8/lot=true in comparison to speedy trial.
>
> - Flawed proposal making it through activation is a failure of review
> process
>
> - Supermajority hashpower percentage decided by bitcoin core developers
> can choose to not follow old or new consensus rules at any point
>
> - Speedy trial makes it worse by misleading lot of bitcoin users including
> miners to consider signaling as voting and majority votes decide if a soft
> fork gets activated
>
> - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus
> rules as they do right now if they wish to mine blocks for subsidy and fees.
>
>
> Note: Mining pools or individual miners can participate in soft fork
> discussions regardless of activation method and share their concern which
> can be evaluated based on technical merits.
>
>
> pushd
> ---
>
> parallel lines meet at infinity?
> _______________________________________________
> 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/20220330/60a6697e/attachment.html>;

Author Public Key

npub1xqcwcttsyk0a64d63crrwsxp88pa42np37rw87hrfn4uku78g2aqltcnns

Show more details

Published at

2023-06-07 23:06:21

Kind type

1 Short Text Note

Event JSON

{ "id": "6b3f17db9b002b4c98010282b1722d5718aca119736d668d014ecfc045182bd9", "pubkey": "3030ec2d70259fdd55ba8e063740c139c3daaa618f86e3fae34cebcb73c742ba", "created_at": 1686179181, "kind": 1, "tags": [ [ "e", "a5af5e39047c2302ef2c813ca29b2c17152d49444d282becfeb36106acf5ee47", "", "root" ], [ "e", "978306fdd939ed1a249ee98ba6691ef8e8566a8886fdb4386cf9ca278abfaad5", "", "reply" ], [ "p", "7866e39300a17990d3d88285e5fe24e019b0dfdd93c220c6d02f67095af5f70e" ] ], "content": "📅 Original date posted:2022-03-30\n📝 Original message:@Pushd\n\n\u003e Speedy trial makes it worse by misleading lot of bitcoin users including\nminers to consider signaling as voting and majority votes decide if a soft\nfork gets activated\n\nNo it does not. This narrative is the worst. A bad explanation of speedy\ntrial can mislead people into thinking miner signalling is how Bitcoin\nupgrades are voted in. But a bad explanation can explain anything badly.\nThe solution is not to change how we engineer soft forks, it's to explain\nspeedy trial better to this imaginary group of important people that think\nminer signaling is voting.\n\nWe shouldn't change how we engineer Bitcoin because of optics. I completely\nobject to that point continuing to be used.\n\nOn Wed, Mar 30, 2022, 05:36 pushd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e \u003e Any case where a flawed proposal makes it through getting activation\n\u003e parameters set and released, but doesn't achieve supermajority hashpower\n\u003e support is made worse by bip8/lot=true in comparison to speedy trial.\n\u003e\n\u003e - Flawed proposal making it through activation is a failure of review\n\u003e process\n\u003e\n\u003e - Supermajority hashpower percentage decided by bitcoin core developers\n\u003e can choose to not follow old or new consensus rules at any point\n\u003e\n\u003e - Speedy trial makes it worse by misleading lot of bitcoin users including\n\u003e miners to consider signaling as voting and majority votes decide if a soft\n\u003e fork gets activated\n\u003e\n\u003e - BIP 8/LOT=TRUE keeps things simple. Miners need to follow consensus\n\u003e rules as they do right now if they wish to mine blocks for subsidy and fees.\n\u003e\n\u003e\n\u003e Note: Mining pools or individual miners can participate in soft fork\n\u003e discussions regardless of activation method and share their concern which\n\u003e can be evaluated based on technical merits.\n\u003e\n\u003e\n\u003e pushd\n\u003e ---\n\u003e\n\u003e parallel lines meet at infinity?\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220330/60a6697e/attachment.html\u003e", "sig": "34c46c124fc1656721137f5cef35f490f7aa7527d6ded579a9fea7b9b1b47d3003f0202cad8e3d85f64ebb43f5e15324986390b059c7e3cc6d422a049ec946e9" }