pull down to refresh

BIP 444: Reduced Data Temporary Softforkgithub.com/bitcoin/bips/pull/2017
1759 sats \ 18 comments \ @Scoresby 17h bitcoin
zaps forwarded to @d01abcb3eb (100%)
@d01abcb3eb posted about this yesterday (#1264865) but it didn't get much attention, and it really should have.
You can read the full BIP here.
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.
write
preview
related posts
1 reply \ @Scoresby OP 5h
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.
reply
0 sats \ 0 replies \ @Scoresby OP 26m
mailing list thread: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/FUbFjHYZAgAJ
reply
140 sats \ 1 reply \ @Scoresby OP 1h
source
source
source
reply
0 sats \ 0 replies \ @Scoresby OP 44m
source
reply
210 sats \ 2 replies \ @Scoresby OP 5h
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.
reply
102 sats \ 1 reply \ @ek 5h
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
reply
102 sats \ 0 replies \ @south_korea_ln 1h
Very much seems like it.
What's also quite telling is how fresh many of the GitHub accounts are from most people interacting on that PR.
reply
202 sats \ 3 replies \ @south_korea_ln 9h
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.
reply
102 sats \ 2 replies \ @d01abcb3eb fwd 54m
Yeah, the potential double-spending issue is interesting. But so is the apparent clumsiness of the proposal - and the path that has lead here. Whatever game theoretic play the spam team is playing it's obviously working.
reply
0 sats \ 1 reply \ @Scoresby OP 50m
would you be willing to hazard a guess as to what the goal of a soft fork like this is?
reply
102 sats \ 0 replies \ @d01abcb3eb fwd 25m
Not really. From my vantage point there seems to be nothing positive in it for the "Knots-side". I think, to hazard a guess one would need to have some understanding of the target audiences here - for which I have none... To me it simply does not make much sense. Perhaps needless to say, I'm impressed by neither the new relaying defaults nor core's ability to make it harder to spam the blockchain.
reply
1124 sats \ 1 reply \ @d01abcb3eb fwd 12h
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.
reply
21 sats \ 0 replies \ @ek 10h
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!
reply
100 sats \ 2 replies \ @DarthCoin 11h
Does this SF affect LN ?
reply
100 sats \ 1 reply \ @ek 8h
Good question, I asked
reply
0 sats \ 0 replies \ @DarthCoin 8h
great, thanks
reply
102 sats \ 0 replies \ @south_korea_ln 8h
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.
As mentioned above, this is a terrible scenario with no ideal solutions.
Wait, is this proposal going to solve Blockchain's oracle problem?
/s
reply
0 sats \ 0 replies \ @anon 7h
.
reply