[bitcoin-dev] Proposal: Scheduled Activation with Potential Miner-Signaled Delay

Hello Bitcoin Protocol Discussion Mailing List, The binary presented by "Lock on Timeout" or LOT; is inherently divisive. Hence, after taking some time to meditate; please consider the following as an overview, and a possible solution: --- The lingering bad-taste from the drama surrounding

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

I think it has been shown that an understanding of reasonableness is not universal, making any assertion about it as a collective goal kind of self-defeating. The question is what is achievable, not what is reasonable. I’m not making any value judgements here. Simply pointing out that anything

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

In the attempt to change consensus rules there is a simple set of choices: 1) hard fork: creates a chain split 2) soft fork: creates a chain split 3) 51% attack: does not create a chain split The presumption being that one can never assume 100% explicit adoption of any rule change. A 51%

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

Glad you asked! Yes, your goal here is #4 on the list of goals I laid out at [1], which I referenced and specifically addressed each of in the OP of this thread. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-January/017547.html On 2/28/21 15:19, Eric Voskuil wrote: In the

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

SPV mining has been curtailed somewhat to only apply for a brief period of time (based on public statements) since the last time SPV mining caused a fork. Indeed, if you can make other miners mine on top of an invalid block, you can make money by reducing the difficulty, but that is true as much

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

Miners still can generate invalid blocks as a result of SPV mining, and it could be profitable to do "bad block enhanced selfish mining" to take advantage of it. Hard to analyze exactly what that looks like, but... E.g., suppose 20% is un-upgraded and 80% is upgraded. Taking 25% hashrate to

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

Note further that mandatory signaling isn't "just" a flag day - unlike a Taproot flag day (where miners running Bitcoin Core unmodified today will not generate invalid blocks), a mandatory signaling flag day blatantly ignores goal (3) from my original post - it results in any miner who has not

Re: [bitcoin-dev] Taproot activation meeting 2 - Tuesday 16th February 19:00 UTC

Answering the F1-F7 arguments for LOT=False... > F1) The probability of Taproot not being activated by miners is small. This > is not 2017, this is not SegWit, there is no need to worry. While we believe miners have no reason to sabotage Taproot activation, this was also the belief leading up

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

I agree with much of the logic presented by Matt here. BIP8 was intended to be simpler to agree on to maintain consensus, yet we find ourselves in a situation where a "tiny" parameter has the potential to cause great network disruption and confusion (rationality is not too useful a concept here

[bitcoin-dev] LOT=False is dangerous and shouldn't be used

(Note: I am writing this as a general case against LOT=False, but using Taproot simply as an example softfork. Note that this is addressing activation under the assumption that the softfork is ethical and has sufficient community support. If those criteria have not been met, no activation

Re: [bitcoin-dev] Straight Flag Day (Height) Taproot Activation

On Sunday 28 February 2021 16:45:22 Matt Corallo via bitcoin-dev wrote: > many individuals are committing themselves to running > incompatible consensus rules. Yet that is exactly what you propose herein... > Given this, it seems one way to keep the network in consensus would be to > simply

[bitcoin-dev] Straight Flag Day (Height) Taproot Activation

As anyone reading this list is aware, there is significant debate around the activation method for the proposed Taproot soft fork. So much so, and with so much conviction, that many individuals are committing themselves to running incompatible consensus rules. Obviously, such commitments, were

Re: [bitcoin-dev] Taproot NACK

Hello LORD HIS EXCELLENCY JAMES HRMH I find a striking dichotomy between your concern of increased privacy in bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com At first your concerns seemed genuine but after seeing your promotion of a bitcoin mixer I'm thinking your

Re: [bitcoin-dev] Exploring alternative activation mechanisms: decreasing threshold

On Sat, Feb 27, 2021 at 5:55 PM Luke Dashjr via bitcoin-dev wrote: > This has the same problems BIP149 did: since there is no signalling, it is > ambiguous whether the softfork has activated at all. You only need to see one block in the heaviest valid chain to dissolve that ambiguity. There are

Re: [bitcoin-dev] Taproot NACK

Good Evening, Thank-you for your advice @JeremyRubin on the basis you advise, "Taproot does not enable monero-like privacy features", I am prepred to withdraw my NACK notably that the existing feeatures of Bitcoin MUST be maintained, and whereby the UTXO of a

Re: [bitcoin-dev] A design for Probabilistic Partial Pruning

Only headers need to be downloaded sequentially so downloading relevant blocks from one node is totally possible with gaps in between. On 2/27/21 4:10 AM, Igor Cota via bitcoin-dev wrote: > Hi Keagan, > > I had a very similar idea. The only difference being for the node to decide on > a range of