public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* Re: [bitcoin-dev] Speedy Trial
@ 2022-03-11 11:14 pushd
  0 siblings, 0 replies; 53+ messages in thread
From: pushd @ 2022-03-11 11:14 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

> Do you think BIP8 still has broad consensus? If that's the case, maybe all
that's needed is to gather some evidence<https://www.youtube.com/watch?v=U7rXOgL4oFQ>; and present it.

This pull request had some support and a few disagreements: https://archive.fo/uw1cO

pushd
---parallel lines meet at infinity?

[-- Attachment #2: Type: text/html, Size: 1041 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [bitcoin-dev] Speedy Trial
@ 2022-03-30 10:34 pushd
  2022-03-30 20:10 ` Billy Tetrud
  0 siblings, 1 reply; 53+ messages in thread
From: pushd @ 2022-03-30 10:34 UTC (permalink / raw)
  To: aj; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 980 bytes --]

> Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpowersupport 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?

[-- Attachment #2: Type: text/html, Size: 2234 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [bitcoin-dev] Speedy Trial
@ 2022-03-26 12:59 pushd
  0 siblings, 0 replies; 53+ messages in thread
From: pushd @ 2022-03-26 12:59 UTC (permalink / raw)
  To: aj; +Cc: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

> 0') someone has come up with a good idea (yay!)
> 1') most of bitcoin is enthusiastically behind the idea
> 2') an enemy of bitcoin is essentially alone in trying to stop it
> 3') almost everyone remains enthusiastic, despite that guy's incoherent raving
> 4') nevertheless, the enemies of bitcoin should have the power to stop
the good idea

How do we know if someone is enemy or not in step 2 and step 4?

why bip 8:

- gives more power to users
- miners signaling is not considered voting
- less politics and controversies

During the taproot activation parameters meeting on 2021-02-16,
participants expressed their preferences with regards to BIP 8's lockinontimeout (LOT) parameter:
https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c

pushd
---
parallel lines meet at infinity?

[-- Attachment #2: Type: text/html, Size: 1808 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [bitcoin-dev] Speedy Trial
@ 2022-03-17 14:34 pushd
  0 siblings, 0 replies; 53+ messages in thread
From: pushd @ 2022-03-17 14:34 UTC (permalink / raw)
  To: bitcoin-dev; +Cc: j

[-- Attachment #1: Type: text/plain, Size: 330 bytes --]

> I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd

This python script using `invalidateblock` RPC is an attack on Bitcoin. Just kidding although I won't be surprised if someone writes about it on reddit.

Thanks for writing the script, it will be helpful.

pushd
---
parallel lines meet at infinity?

[-- Attachment #2: Type: text/html, Size: 1217 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [bitcoin-dev] Speedy Trial
@ 2022-03-12 17:11 pushd
  0 siblings, 0 replies; 53+ messages in thread
From: pushd @ 2022-03-12 17:11 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1754 bytes --]

> A mechanism of soft-forking against activation exists. What more do you
want? Are we supposed to write the code on behalf of this hypothetical
group of users who may or may not exist for them just so that they can have
a node that remains stalled on Speedy Trial lockin? That simply isn't
reasonable, but if you think it is, I invite you to create such a fork.
I want BIP 8. And less invitations to fork or provoke people.

> If I believe I'm in the economic majority then I'll just refuse to upgrade
my node, which was option 2. I don't know why you dismissed it.

> Not much can prevent a miner cartel from enforcing rules that users don't
want other than hard forking a replacement POW. There is no effective
difference between some developers releasing a malicious soft-fork of
Bitcoin and the miners releasing a malicious version themselves. And when
the miner cartel forms, they aren't necessarily going to be polite enough
to give a transparent signal of their new rules.

Miners get paid irrespective of rules as long as subsidy doesn't change. You can affect their fees, bitcoin and that should be termed as an attack on bitcoin.

> However, without the
economic majority enforcing their set of rules, the cartel continuously
risks falling apart from the temptation of transaction fees of the censored
transactions.

Transaction fee isn't as expected even if we leave censored transactions in a censorship resistant network. If cartel of developers affect it in long term, there will be a time when nobody wants to mine for loss or less profit.

> Look, you cannot have the perfect system of money all by your
lonesome self.

I agree with this and I can't do the same thing with my local government.

pushd
---
parallel lines meet at infinity?

[-- Attachment #2: Type: text/html, Size: 3025 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread
* [bitcoin-dev] Speedy Trial
@ 2022-03-11  0:12 Russell O'Connor
  2022-03-11  0:28 ` Luke Dashjr
  2022-03-11 12:19 ` Jorge Timón
  0 siblings, 2 replies; 53+ messages in thread
From: Russell O'Connor @ 2022-03-11  0:12 UTC (permalink / raw)
  To: Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 2374 bytes --]

On Thu., Mar. 10, 2022, 08:04 Jorge Timón via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> You're right, we shouldn't get personal. We shouldn't ignore feedback from
> me, mark friedenbach or luke just because of who it comes from.
>

For goodness sake Jorge, enough with the persecution complex.

As the person who initially proposed the Speedy Trial deployment design, I
can say it was designed to take in account those concerns raised by luke-jr
and the "no-miner-veto" faction.  I also listened to the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules" faction
and their concerns.

The "no-miner-veto" concerns are, to an extent, addressed by the short
timeline of Speedy Trial.  No more waiting 2 years on the miners dragging
their feet.  If ST fails to active then we are back where we started with
at most a few weeks lost.  And those weeks aren't really lost if they would
have been wasted away anyways trying to find broad consensus on another
deployment mechanism.

I get that you don't like the design of Speedy Trial.  You may even object
that it fails to really address your concerns by leaving open how to follow
up a failed Speedy Trial deployment.  But regardless of how you feel, I
believe I did meaningfully address the those miner-veto concerns and other
people agree with me.

If you are so concerned about listening to legitimate criticism, maybe you
can design a new deployment mechanism that addresses the concerns of the
"devs-do-not-decide" faction and the "no-divegent-consensus-rules"
faction.  Or do you feel that their concerns are illegitimate?  Maybe, by
sheer coincidence, all people you disagree with have illegitimate concerns
while only your concerns are legitimate.

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.

[-- Attachment #2: Type: text/html, Size: 3274 bytes --]

^ permalink raw reply	[flat|nested] 53+ messages in thread

end of thread, other threads:[~2022-04-27  2:36 UTC | newest]

Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-03-11 11:14 [bitcoin-dev] Speedy Trial pushd
  -- strict thread matches above, loose matches on Subject: below --
2022-03-30 10:34 pushd
2022-03-30 20:10 ` Billy Tetrud
2022-03-30 21:14   ` pushd
2022-03-31  4:31     ` Billy Tetrud
2022-03-31 14:19       ` pushd
2022-03-31 15:34         ` Billy Tetrud
2022-03-31 15:55           ` pushd
2022-03-26 12:59 pushd
2022-03-17 14:34 pushd
2022-03-12 17:11 pushd
2022-03-11  0:12 Russell O'Connor
2022-03-11  0:28 ` Luke Dashjr
2022-03-11  5:41   ` Billy Tetrud
2022-03-11 12:19 ` Jorge Timón
2022-03-11 13:47   ` Russell O'Connor
2022-03-11 14:04     ` Jorge Timón
2022-03-12 13:34       ` Russell O'Connor
2022-03-12 17:52         ` Billy Tetrud
2022-03-17 12:18           ` Jorge Timón
2022-03-23 22:34           ` Kate Salazar
2022-03-15 17:21         ` Jeremy Rubin
2022-03-17  4:17           ` Billy Tetrud
2022-03-18 18:36           ` Jorge Timón
2022-03-17 12:08         ` Jorge Timón
2022-03-17 15:38           ` Billy Tetrud
2022-03-18 23:01             ` ZmnSCPxj
2022-03-21  3:41               ` Billy Tetrud
2022-03-21 15:56                 ` vjudeu
2022-03-22 15:19                   ` Billy Tetrud
2022-03-22 15:45                     ` Eric Voskuil
2022-03-22 16:37                     ` vjudeu
2022-03-19 16:43             ` vjudeu
2022-03-15 15:45       ` Anthony Towns
2022-03-17 14:04         ` Jorge Timón
2022-03-22 23:49           ` Anthony Towns
2022-03-24 18:30             ` Jorge Timón
2022-03-26  1:45               ` Anthony Towns
2022-03-28  8:31                 ` Jorge Timón
2022-03-30  4:21                   ` Anthony Towns
2022-04-08  9:58                     ` Jorge Timón
2022-04-11 13:05                       ` Anthony Towns
2022-04-24 11:13                         ` Jorge Timón
2022-04-24 12:14                           ` Anthony Towns
2022-04-24 12:44                             ` Jorge Timón
2022-04-25 16:11                               ` Keagan McClelland
2022-04-25 17:00                                 ` Anthony Towns
2022-04-25 17:26                                   ` Keagan McClelland
2022-04-26  5:42                                     ` Anthony Towns
2022-04-26 13:05                                       ` Erik Aronesty
2022-04-27  2:35                                         ` Billy Tetrud
2022-03-11 16:26     ` Billy Tetrud
2022-03-17 11:32       ` Jorge Timón

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox