My bad, I should have stated my assumptions, especially given that my assumption appears to have been incorrect.

BIP 9 does not have the lockinontimeout mechanism as it was introduced later by BIP 8. I assumed that RDTS was going to reuse the semantics of BIP 8 which enforce activation by mandatory signaling, but it appears that this assumption was incorrect, instead RDTS appears to simply switch to LOCKED_IN one difficulty period and a block before the max activation height, so a flag day activation was actually a fitting description.

[as they’d have to find two blocks before the rest of the network finds one] … each and every time the majority of the hashrate adds a block that does not adhere to the soft fork rules.

I don’t think 95% activation threshold would be attempted again after it drew out the Segwit activation like that. The activation threshold for Taproot was 90%.

Actually, thinking more about it, and having had a look at BIP 9 again, the “flag day activation” description is not correct. lockinontimeout is implemented as a period of mandatory signaling in the last eligible difficulty period. If a minority of the hashrate were trying to enforce mandatory signaling then, there could be some reorgs in that difficulty period if any non-signaling blocks were reorged out by the soft forking hashrate. If the soft forking nodes were supported by a minority of the hashrate, they would already fork themselves off on a minority chain during the mandatory signaling rather than at activation, likely with very few or no reorgs, as they’d have to find two blocks before the rest of the network finds one.

I was pointing out one reason why a well-reasoned soft fork proposal would avoid such a low activation threshold. I neither said nor implied that I’m worried about RDTS causing disruption. In fact, I explicitly stated my expectation that it will have negligible adoption. Your repeated refusal to engage with reasonable concerns is rather reassuring in that regard.

I have an Ergodox Ez and use the Neo2 Layout. It's an ergonomically optimized keyboard layout for German, English and programming. I linked its project website in my above comment where you can see a graphic for the six layers of the tenkeyless section of the keyboard.

Yes, I frequently use em dashes ("—"). My keyboard layout provides easy access to a lot of useful symbols, e.g., I also frequently use the actual quotation marks (“”), apostrophes (’), non-breaking thin space (" "), ellipsis ("…"), the multiplication symbol (×), some arrows (⇐⇔⇒↦), superscript (¹²³) and subscript (₁₂₃), have access to the lowercase Greek alphabet (αβγδεφ…), and a number of other useful math symbols (e.g., ∞∃∫∀√¬∨∧∥Σℕℝℤℚ).

I’m not sure why you expect me to do your work for you, while you are in pursuit of a project that I clearly oppose. Good luck.

FWIU¹, it’s a BIP 9 (Versionbits) + LOT²=true activation attempt.

I.e., it would be a miner activated soft fork if in any one difficulty period before September 1st 55% of block headers signal readiness to enforce the soft fork, at which point the soft fork locks in, and then starts being enforced by all soft forking nodes after one more difficulty period without enforcement.

In the case that this doesn’t happen, it turns into an unconditional flag day activation on September 1st. Since it wouldn’t have locked-in in beforehand in that case, the soft fork would only be supported by a minority of the hashrate, but in theory at that point (steelmanning here) an overwhelming majority of the nodes and especially the economic majority would enforce the soft fork by rejecting any blocks that don’t adhere to the rules of the soft fork. As the majority of the economic activity would then supposedly be happening on the soft fork chain, there would be less to no demand for the block rewards on the non-soft forking chain and thus the economic majority would impose their will on the miners, forcing them to mine the soft fork chain in order to get paid.

Alternatively, if neither hashrate nor economic majority back their soft fork proposal, it would not lock in before the timeout, and on September 1st, any nodes still running the activation client would start rejecting blocks that don’t adhere to their soft fork rules. Given that pretty much every block today would be invalid according to their soft fork rules, the enforcing nodes would immediately fork themselves off onto a minority chain as the rest of the Bitcoin network pulls away with the most-work chaintip. Supposedly, the economic majority and majority of the hashrate would then be going to sacrifice their transaction history and block rewards, and impose upon themselves the rules of the soft fork in order to mend the network. I have yet to see a plausible explanation why the network’s majority would choose to let themselves be subjugated by the minority against their financial and ideological interests. It seems obvious to me that the soft forking nodes would be abandoned to their minority chaintip with drastically diminished value which they then would either give up on by switching back to a Bitcoin node, or double down upon per another consensus change that spins off a forkcoin.

As to the actual expected outcome, I would be surprised if this proposal gets more than a low single-digit percentage of signaling, and I’m therefore anticipating no more than a few dozen nodes forking themselves off on September 1st.

¹ I have put in no effort to validate this. The proposal was changing on a daily basis for several weeks, so they might have decided to do something else meanwhile.
² LockinOnTimeout (see BIP 8)

You do know that just repeating this claim like a mantra doesn’t actually make it so, right?

Considering the amount of false signaling we saw before segwit and taproot activation, 55% signaling could easily be reached with less than a majority of the hashrate enforcing the new rules. (Assuming there were an expectation for this proposal to come anywhere close to that level of signaling.)

Curious decision to only make outbound connections to BIP 110 clients, when there are merely ~50 of those (per glancing at coin.dance).

How the hell does anyone type that bitcoin ascii symbol, anyway?

Using BIP 353 does not require you to type the Bitcoin symbol.

However, on my phone, I have set up an autocorrect rule, when I type “BTCSYM”, it replaces it with the Bitcoin character. On my computers, I input the unicode: U+20bf.

On Linux, you enter unicode symbols by hitting Ctrl+Shift+U and typing the code, there are probably similar ways to do so on other operating systems.

deleted by author

Note that BIP 54 does not talk about transactions of 64 bytes, but rather proposes to forbid “Transactions whose witness-stripped serialized size is exactly 64 bytes”.

Still, perhaps I can alleviate you of some of your sadness: it seems very unlikely that anyone will come up with useful stripped transactions of 64-byte size.

Bitcoin transactions have to have at least one input, at least one output, and the header bytes. Without the witness data that leaves us with:

HeaderHeader

• version: 4 byte
• locktime: 4 byte
• input count: 1+ bytes
• output count: 1+ bytes

Usually 10 bytes, unless you have a lot of inputs or outputs.

InputInput

• outpoint:
  • txid: 32 bytes
  • vout: 4 bytes
• input script length: 1+ bytes
• input script: 0+ bytes
• sequence: 4 bytes

In sum that’s at least 41 bytes, and that is for a transaction with an empty input script.

OutputOutput

• amount: 8 bytes
• output script length: 1+ bytes
• output script: 0+ bytes

At least 9 bytes, even with an empty output script.

In SumIn Sum

So, a transaction with an empty input script and an empty output script already puts you at 60 bytes, and that means that you’d have to distribute a total of four bytes into input script and/or output script to land at exactly 64 bytes.

The only standard types of transactions that I can think of that would be affected have a single native segwit input (who have empty input scripts), and either a single P2A output (which has a 4 byte output script) or an OP_RETURN output with a 2-byte payload. The former transaction would pay all its money to fees or make it up for grabs per an anyone-can-spend anchor. The latter would pay all its money to fees, or burn it per the OP_RETURN output. Neither seems seem useful to me, but either could evade the block by simply increasing the payload by one byte (e.g., introducing another standard pattern for P2A with three bytes, if it is used frequently). So, we would fix a consensus bug at potentially introducing a 1-byte penalty to a couple tx patterns that don’t seem useful at this time.

You mean, Satoshi would propose a hard fork to reenable spending? Making them unspendable is a soft fork.

It’s not clear to me why making Satoshi’s coins unspendable would be a hard fork. That seems like an obvious soft fork to me.

Have you seen Hornetnode?

Thanks, I hadn’t seen that before.

I think they’re two different people, but from the same circle.

Yes, but this is a separate issue. The UTXO set is a way of presenting current state of the Bitcoin network with the minimal necessary data. libbitcoin simply chooses to store more data than that, whereas utreexo introduces a framework where other nodes can prove that some UTXO exists and is spendable. Everyone still needs to agree that these UTXOs exist and are spendable.

This proposal seems to delegate the authority to declare some UTXOs unspendable to some underdefined process/council. Basically, it proposes a framework to regularly softfork out some UTXOs at the whim of whoever gets to author that blacklist.

Edit: Oh, I see. You mean that the motivation for the fork is poor. — I agree with that.