Re: [bitcoin-dev] Speedy Trial

@Erik > can we all agree that this verbal and social wrangling and chest pounding seems, right now, to remain the best system of achieving consensus? or can we do better? I would love to see more people interested in discussing this. Social wrangling is certainly the best we have, but is it the

Re: [bitcoin-dev] Speedy Trial

- it occurs to me that the real problem we have isn't whether miners lead or users lead. we know that users lead, we just need miners to be "ready" and have time to upgrade their software - in the case of "evil" forks, i also don't need or want miners to "defend" bitcoin... (if bitcoin is so

Re: [bitcoin-dev] Speedy Trial

On Mon, Apr 25, 2022 at 11:26:09AM -0600, Keagan McClelland via bitcoin-dev wrote: > > Semi-mandatory in that only "threshold" blocks must signal, so if > only 4% or 9% of miners aren't signalling and the threshold is set > at 95% or 90%, no blocks will be orphaned. > How do nodes decide

Re: [bitcoin-dev] Speedy Trial

> BIP8 doesn't have mandatory signaling during the lockin period, it has semi-mandatory [0] signalling during the must_signal period. Thanks for the clarification. > Semi-mandatory in that only "threshold" blocks must signal, so if only 4% or 9% of miners aren't signalling and the threshold

Re: [bitcoin-dev] Speedy Trial

On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via bitcoin-dev wrote: > > Under *any* other circumstance, when they're used to activate a bad soft > > fork, speedy trial and bip8 are the same. If a resistance method works > > against bip8, it works against speedy trial; if it fails

Re: [bitcoin-dev] Speedy Trial

Hi AJ, > Under *any* other circumstance, when they're used to activate a bad soft fork, speedy trial and bip8 are the same. If a resistance method works against bip8, it works against speedy trial; if it fails against speedy trial, it fails against bip8. IIRC one essential difference between ST

Re: [bitcoin-dev] Speedy Trial

You're not even considering user resistance in your cases. You're purely relying on miners and calling speedy trial superior. I don't know if you're being obtuse on purpose, I'm explaining myself very badly... I DON'T WANT TO RELY ON MINERS TO RESIST CHANGES I DON'T WANT TO. Sorry for the tone,

Re: [bitcoin-dev] Speedy Trial

On Sun, Apr 24, 2022 at 2:14 PM Anthony Towns wrote: > On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote: > > You're not even considering user resistance in your cases. > > Of course I am. Again: > No, you're relying on miners to stop bad proposals. > > > My claim is that for *any*

Re: [bitcoin-dev] Speedy Trial

On Sun, Apr 24, 2022 at 12:13:08PM +0100, Jorge Timón wrote: > You're not even considering user resistance in your cases. Of course I am. Again: > > My claim is that for *any* bad (evil, flawed, whatever) softfork, then > > attempting activation via bip8 is *never* superior to speedy trial, > >

Re: [bitcoin-dev] Speedy Trial

On Fri, Apr 08, 2022 at 11:58:48AM +0200, Jorge Timón via bitcoin-dev wrote: > On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote: > > > Let's discuss those too. Feel free to point out how bip8 fails at some > > > hypothetical cases speedy trial doesn't. > > Any case where a flawed proposal

Re: [bitcoin-dev] Speedy Trial

On Wed, Mar 30, 2022 at 6:21 AM Anthony Towns wrote: > On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev > wrote: > > > In particular, any approach that allows you to block an evil fork, > > > even when everyone else doesn't agree that it's evil, would also allow > > > an

Re: [bitcoin-dev] Speedy Trial

> If that's really true then you're wasting my and everyone's time here. It isn't waste of time but important for everyone to understand different opinions about soft fork activations before moving to next soft fork. The reason I am not trying to convince you or others but sharing my opinion:

Re: [bitcoin-dev] Speedy Trial

> I am not trying to convince you If that's really true then you're wasting my and everyone's time here. > Signaling period is a waste of time if mining pools that agreed on a soft fork earlier do politics They can and will do politics regardless of why misunderstandings about signaling. This

Re: [bitcoin-dev] Speedy Trial

> Why do you care what they think? Why does it matter if they misunderstand? I care about improving soft fork activation mechanism and shared one of the advantages that helps avoid misleading things. It matters because they are participants in this process. > If the people aren't imaginary,

Re: [bitcoin-dev] Speedy Trial

> Many users, miners and exchanges still think its voting Why do you care what they think? Why does it matter if they misunderstand? > it is not an imaginary group of people If the people aren't imaginary, then its their importance that's imaginary. > One example of a mining pool This isn't

Re: [bitcoin-dev] Speedy Trial

> 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. I agree it is worst but why do you think this narrative exists? People

Re: [bitcoin-dev] Speedy Trial

@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

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

On Mon, Mar 28, 2022 at 09:31:18AM +0100, Jorge Timón via bitcoin-dev wrote: > > In particular, any approach that allows you to block an evil fork, > > even when everyone else doesn't agree that it's evil, would also allow > > an enemy of bitcoin to block a good fork, that everyone else correctly

Re: [bitcoin-dev] Speedy Trial

On Sat, Mar 26, 2022, 01:45 Anthony Towns wrote: > On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev > wrote: > > Sorry, I won't answer to everything, because it's clear you're not > listening. > > I'm not agreeing with you; that's different to not listening to you. > You're

Re: [bitcoin-dev] Speedy Trial

> 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

Re: [bitcoin-dev] Speedy Trial

On Thu, Mar 24, 2022 at 07:30:09PM +0100, Jorge Timón via bitcoin-dev wrote: > Sorry, I won't answer to everything, because it's clear you're not listening. I'm not agreeing with you; that's different to not listening to you. > In the HYPOTHETICAL CASE that there's an evil for, the fork being

Re: [bitcoin-dev] Speedy Trial

Sorry, I won't answer to everything, because it's clear you're not listening. In the HYPOTHETICAL CASE that there's an evil for, the fork being evil is a PREMISE of that hypothetical case, a GIVEN. Your claim that "if it's evil, good people would oppose it" is a NON SEQUITUR, "good people" aren't

Re: [bitcoin-dev] Speedy Trial

Hey On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev wrote: > > > If I find out I'm in the economic minority then I have little choice but > > to either accept the existence of the new rules or sell my Bitcoin > > I do worry about what I have called a "dumb majority soft fork".

Re: [bitcoin-dev] Speedy Trial

On Thu, Mar 17, 2022 at 03:04:32PM +0100, Jorge Timón via bitcoin-dev wrote: > On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote: > > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote: > > People opposed to having taproot transactions in their chain had over > > three

Re: [bitcoin-dev] Speedy Trial

> What do you mean "capture that" and "your network"? I was imagining a > scenario where these poll messages are always broadcast globally. Are you > implying more of a private poll? If you vote by making a Bitcoin transaction, then someone could move real bitcoins, just by including your

Re: [bitcoin-dev] Speedy Trial

> > Even if it is not needed, it is kind of "free" if you take transaction size > > into account > > But it would require an on-chain transaction. We don't want 6 billion people > to have to send an on-chain transaction all in the same week in order to > register their preference on

Re: [bitcoin-dev] Speedy Trial

> If you vote by making transactions, then someone could capture that and broadcast to nodes > you can only send that to your network What do you mean "capture that" and "your network"? I was imagining a scenario where these poll messages are always broadcast globally. Are you implying more of

Re: [bitcoin-dev] Speedy Trial

> I don't quite understand this part. I don't understand how this would make > your signature useless in a different context. Could you elaborate? It is simple. If you vote by making transactions, then someone could capture that and broadcast to nodes. If your signature is "useless in a

Re: [bitcoin-dev] Speedy Trial

Good Evening ZmnSCPxj, > I need to be able to invalidate the previous signal, one that is tied to the fulfillment of the forwarding request. You're right that there's some nuance there. You could add a block hash into the poll message and define things so any subsequent poll message sent with a

Re: [bitcoin-dev] Speedy Trial

> A. Every pollee signs messages like support:10%}> for each UTXO they want to respond to the poll with. It should not be expressed in percents, but in amounts. It would be easier and more compatible with votes where there is 100% oppose or 100% support (and also easier to handle if some LN

Re: [bitcoin-dev] Speedy Trial

Good morning Billy, > @Jorge > > Any user polling system is going to be vulnerable to sybil attacks. > > Not the one I'll propose right here. What I propose specifically is a  > coin-weighted signature-based poll with the following components: > A. Every pollee signs messages like support:10%}>

Re: [bitcoin-dev] Speedy Trial

On Tue, Mar 15, 2022 at 6:25 PM Jeremy Rubin via bitcoin-dev wrote: > > Boker tov bitcoin devs, I don't undesrtand what that means, sorry >> A mechanism of soft-forking against activation exists. What more do you >> want? > > > Agreed -- that should be enough. No, resistance should ideally

Re: [bitcoin-dev] Speedy Trial

@Jorge > Any user polling system is going to be vulnerable to sybil attacks. Not the one I'll propose right here. What I propose specifically is a coin-weighted signature-based poll with the following components: A. Every pollee signs messages like for each UTXO they want to respond to the poll

Re: [bitcoin-dev] Speedy Trial

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

Re: [bitcoin-dev] Speedy Trial

On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote: > > On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote: > People opposed to having taproot transactions in their chain had over > three years to do that coordination before an activation method was merged > [0], and

Re: [bitcoin-dev] Speedy Trial

On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev wrote: > > > If I find out I'm in the economic minority then I have little choice but > > to either accept the existence of the new rules or sell my Bitcoin > > I do worry about what I have called a "dumb majority soft fork". This is

Re: [bitcoin-dev] Speedy Trial

On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev wrote: > > On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote: > 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

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev wrote: > > I think involving users more in activation is a good avenue of thought for > improving how bitcoin does soft forks. I also think the idea you brought up > of some way for people to signal opposition is a good idea. I've

Re: [bitcoin-dev] Speedy Trial

@Aj Your steps seem reasonable. I definitely agree step one (talking to each other) is obviously the ideal solution, when it works. Step 2 (futures market) is the option I would say I understand the least. In any case, a futures market seems like it only incorporates the opinions/predictions of

Re: [bitcoin-dev] Speedy Trial

Boker tov bitcoin devs, A mechanism of soft-forking against activation exists. What more do you > want? > Agreed -- that should be enough. > 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 >

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote: > > 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,

Re: [bitcoin-dev] Speedy Trial

> If I find out I'm in the economic minority then I have little choice but to either accept the existence of the new rules or sell my Bitcoin I do worry about what I have called a "dumb majority soft fork". This is where, say, mainstream adoption has happened, some crisis of some magnitude

Re: [bitcoin-dev] Speedy Trial

> 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

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote: > > 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

Re: [bitcoin-dev] Speedy Trial

Thanks for pointing out that PR @pushd. Looks like pretty good evidence for what the status of consensus was around BIP8 in the last 2 years. @Jorge, I tried to engage with you on the topic of activation rules last year. This is where we left it

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022, 13:47 Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón wrote: > >> I talked about this. But the "no-divergent-rules" faction doesn't like >> it, so we can pretend we have listened to this

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022 at 7:18 AM Jorge Timón 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

Re: [bitcoin-dev] Speedy Trial

On Fri, Mar 11, 2022, 00:12 Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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

Re: [bitcoin-dev] Speedy Trial

> Do you think BIP8 still has broad consensus? If that's the case, maybe all that's needed is to gather some evidence; and present it. This pull request had some support and a few disagreements: https://archive.fo/uw1cO pushd ---parallel lines meet

Re: [bitcoin-dev] Speedy Trial

> BIP 8 did in fact have broad consensus I hear you claim this often Luke, but claiming its so does not make it so. Do you think BIP8 still has broad consensus? If that's the case, maybe all that's needed is to gather some evidence and present it.

Re: [bitcoin-dev] Speedy Trial

On Friday 11 March 2022 00:12:19 Russell O'Connor via bitcoin-dev wrote: > 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. It's still a miner veto. The only way this works is if the