Thread - Nostr Hypermedia

BIP 110 doesn’t fix SegWit and the arbitrary discounting of bits stored on the node. Speaking of the word arbitrary. SegWit broke the original protocol constants of 21M/1MB/1Block and the economical relationship of sats:bits. We devalued and attacked the nodes starting in 2017; op_return was the last domino. You can’t hate arbitrary data when you arbitrarily discount certain data and have severed yourself from Satoshsi’s original protocol. Let’s agree there is a problem; I’m saying BIP110 is not the proper solution. You still are mispricing the bits of your node and still allowing the chain to grow faster than Satoshi defined. If we are to take his words as gospel, we should take his code and defined constants as gospel too. We need to stop double spending to make Bitcoin fit our individual definitions of “money”.

↑ Parent

Replies (2)

BitcoinIsFuture 1 week ago

Tauri

What #BIP110 does is pretty minimal actually. 1. It limits new ScriptPubKeys to 34 bytes; 2. It limits OP_RETURN outputs to 83 bytes; 3. It limits data pushes and witness elements (contiguous data) to 256 bytes; 4. It removes OP_IF inside Tapscript; 5. It disables the Taproot annex and undefined witness versions / OP_SUCCESS; 6. It limits Taproot control block size (~257 bytes); This only applies to newly created UTXOs. And the following are my 80 IQ interpretations of each of those changes: 1. It restricts how complex a new payment address can be so people can’t sneak large chunks of arbitrary data into normal Bitcoin payments. 2. It caps how much extra data can be attached to a transaction so Bitcoin blocks don’t turn into general-purpose message boards / free cloud storage. 3. It prevents hiding large files inside transaction data by limiting how big any single chunk of stored data can be. 4. It removes a scripting trick that lets people hide data like inscriptions inside conditional branches that aren’t meant to be used for payments. 5. It closes lesser-known backdoors in Taproot that can carry arbitrary data while pretending to be normal transaction components. 6. It limits how large Taproot script trees can grow so they can’t be abused to store massive hidden data structures. This soft fork is intended to be TEMPORARY. It means that after a one-year period the new rules automatically expire if they aren’t explicitly extended. The main reasons are: 1. A permanent soft fork consensus change can otherwise only realistically be reversed with a hard fork. 2. It acts as a pressure valve while longer-term policy and consensus rules are debated. 3. The one-year window serves as a trial period to verify no critical bugs exist, no unintended consequences appear, and no new methods for stuffing arbitrary data into scripts are discovered.

View quoted note →

BitcoinIsFuture 1 week ago

Also this was said by Hunter Beast who now supports BIP 110 too: "I'm generally supportive of the changes in this BIP. Aside from minor nitpicks in language, the 34 byte scriptPubKey restriction I think will prove to be quite valuable in addressing the larger concern of DoS blocks / poison blocks that impose such high computational costs on nodes that a single block would take 30 minutes to verify on decent hardware instead of taking about a second. This is an even larger threat to Bitcoin than either CSAM or quantum, because I've read that CSAM has already been present on Bitcoin for a very long time, and quantum computers aren't anywhere near good enough to be a threat, and may never be, whereas DoS blocks could be introduced by miners who take direct submissions without sufficient checks at any time."