BIP 444: Reduced Data Temporary Softfork \ stacker news ~bitcoin

pull down to refresh

BIP 444: Reduced Data Temporary Softfork github.com/bitcoin/bips/pull/2017

1729 sats \ 11 comments \ @Scoresby 13h bitcoin

zaps forwarded to @d01abcb3eb (100%)

@d01abcb3eb posted about this yesterday (#1264865) but it didn't get much attention, and it really should have.

From the mailing list here's a brief outline:

Limit (new) scriptPubKeys to 83 bytes or less. 34 doesn't seem terrible. UTXOs are a huge cost to nodes, we should always keep them as small as possible. Anything else can be hashed (if SHA256 is broken, we need a hardfork anyway).

Limit script data pushes to 256 bytes, with an exception for BIP16 redeem scripts.

Make undefined witness/taproot versions invalid, including the annex and OP_SUCCESS*. To make any legitimate usage of them, we need a softfork anyway (see below about expiring this).

Limit taproot control block to 257 bytes (128 scripts max), or at least way less than it currently is. 340e36 scripts is completely unrealistic.

Make OP_IF invalid inside Tapscript. It should be unnecessary with taproot, and has only(?) seen abuse.

view all related items

0 replies \ @Scoresby OP 1h

From the Activation section, which I should have included in the OP, but hadn't read it yet.

Reactive Deployment

Doesn't this proposal activate too soon?

In short, yes, it does. Unfortunately, due to the release of Bitcoin Core 30 endorsing large data storage and actual illegal content being mined in proposed block , the network as it stands is already contaminated. This is not a preemptive measure, but an emergency response to an immediate crisis. Therefore, there is no time for lengthy signaling periods or careful deployment; the only remaining option is immediate and retroactive activation to mitigate the harm.

However, because this is a softfork, old nodes will continue to follow the blockchain so long as it attains significant enough hashrate. Even if non-upgraded miners continue to mine (now) invalid blocks, old nodes will continually replace them with valid blocks every time the valid chain overtakes the invalid one. Since this results in an incoherent consensus system, unusable for actual currency, and loss of rewards for the lagging miners, they should quickly adapt and bring the softfork to near 100% compatibility quickly.

The true risk is that for an initial period of time, nearly all nodes will cease to function as fully validating nodes. This can only be mitigated by encouraging nodes to upgrade quickly, possibly by backporting the softfork to old and/or niche node software as necessary. Toward this end, the actual changes in this softfork have been kept very simple.

100 sats \ 1 reply \ @Scoresby OP 1h

This is not a preemptive measure, but an emergency response to an immediate crisis.

If this is such an emergency, why weren't they concerned about such transactions being mined before? It was possible, and yet no one was running around screaming about it.

Unless I'm mistaken, a user could have configured datacarriersize to be 100kb in many prior versions of Core. Also there was Libre relay, which I think would have relayed such transactions. Why wasn't this an emergency last year or the year before?

I don't like being pressured into doing things because people falsely claim it's an emergency.

0 sats \ 0 replies \ @ek 1h

Yeah I’m also confused of framing it as an emergency

Or maybe I’m not, because it’s straight out of the playbook of how to manipulate people

202 sats \ 0 replies \ @south_korea_ln 5h

I wonder how this will affect potential double spends. One could publish some child porn at the same time of paying for a service and then activate this invalidation mechanism to recover the funds. How many descendants before a block is considered irreversible? Who decides what is considered not to Luke's liking? There will be edge cases that one does not think about now. There are always edge cases.

Putting aside my own position on this debate, this all seems poorly thought out.

1102 sats \ 1 reply \ @d01abcb3eb fwd 8h

Thanks, @Scoresby! :)

I think a couple of things raises questions, in addition to the BIP giving the impression of being hastily written and not thought through. Like:

Does this cause a chain split?

Generally, softforks do not cause chain splits. However, since we are rejecting an already-mined block proposal, this softfork does indeed cause a chain split. In fact, that is an important part of its purpose: to keep the illegal content storage in block out of Bitcoin.

To achieve this, the softfork must activate retroactively, invalidating that block and all its descendants. The prior segment of the blockchain including this block will eventually (hopefully quickly) be discarded entirely, as the network adopts the softfork proposed herein.

I also wonder about the implications of future developments. Like, say a node runs this BIP, and we get a new versions of tapleaf or segwit. What will happen to these nodes assuming they do not upgrade the node software they are running?

Disclosure: I am unfortunately not funded by any side of the spam "war", and so am just trying to understand what to do to avoid shooting myself in the foot.

0 sats \ 0 replies \ @ek 6h

Very good questions I unfortunately cannot answer.

Also thank you for originally sharing the link! Very sorry that it went under, not sure why. For me, this is easily the most important link in a long time about Knots vs Core.

Oh and welcome!

102 sats \ 0 replies \ @south_korea_ln 4h

From the discussion under the BIP proposal:

Who decides which op_return is bad enough to require an invalidation of the said block?

That is not a decision that can be unilaterally made by anyone. It would presumably be something sufficiently terrible enough to cause enough people to come to the same conclusion.