Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-04-22 Thread pushd via bitcoin-dev
Hi Luke, > But none of this ST nonsense, please. That alone is a reason to oppose it. Agree. Any soft fork that uses only speedy trial should be opposed. There are few other reasons to oppose it as well: - Premature idea - Use cases are not interesting for all users - We are still in research

Re: [bitcoin-dev] ANYPREVOUT in place of CTV

2022-04-22 Thread pushd via bitcoin-dev
> I would like to know people's sentiment about doing (a very slightly tweaked > version of) BIP118 in place of (or before doing) BIP119. NACK for the below reasons: - Premature idea - I do not find use cases interesting - We are still in research phase of implementing covenants in bitcoin and

Re: [bitcoin-dev] Speedy Trial

2022-03-31 Thread pushd via bitcoin-dev
and a better activation method fixes it. There are other >>>> positives for using BIP 8/LOT=TRUE which I shared in >>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020178.html >>>> >>>> I will continue to discuss this problem with

Re: [bitcoin-dev] Speedy Trial

2022-03-31 Thread pushd via bitcoin-dev
es 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 expla

Re: [bitcoin-dev] Speedy Trial

2022-03-30 Thread pushd via bitcoin-dev
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,

Re: [bitcoin-dev] Speedy Trial

2022-03-30 Thread pushd via bitcoin-dev
> 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

2022-03-26 Thread pushd via bitcoin-dev
> 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

2022-03-17 Thread pushd via bitcoin-dev
> 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

2022-03-12 Thread pushd via bitcoin-dev
> 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

2022-03-11 Thread pushd via bitcoin-dev
> 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