pull down to refresh

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

1764 sats \ 54 comments \ @Scoresby 26 Oct 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

5 replies \ @Scoresby OP 26 Oct

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.

5 sats \ 0 replies \ @Scoresby OP 26 Oct

mailing list thread: https://groups.google.com/g/bitcoindev/c/nOZim6FbuF8/m/FUbFjHYZAgAJ

0 sats \ 3 replies \ @Scoresby OP 26 Oct

source

I don't understand this. Why are they optimizing Bitcoin for the state's approval?

0 sats \ 1 reply \ @Scoresby OP 5h

source

If you are proposing an emergency fork that you want to activate petty much immediately and that fork probably confiscates funds...you don't understand Bitcoin.

Even worse: if your justification for such rash action is merely to make people do something in a slightly different manner to create a legal excuse:

source

I don't think you are even talking about Bitcoin anymore. Go use Visa.

102 sats \ 0 replies \ @SimpleStacker 5h

They are really working themselves into a moral panic. The psychology of this is fascinating.

0 sats \ 0 replies \ @ek 26 Oct

mass psychosis

1129 sats \ 2 replies \ @d01abcb3eb fwd 26 Oct

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.

178 sats \ 0 replies \ @optimism 23h

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?

I think you got this the wrong way around. You meant to ask: what happens to those people that activate this. We will call them shitcoiners.

21 sats \ 0 replies \ @ek 26 Oct

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!

202 sats \ 4 replies \ @south_korea_ln 26 Oct

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.

180 sats \ 3 replies \ @d01abcb3eb fwd 26 Oct

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.

0 sats \ 2 replies \ @Scoresby OP 26 Oct

would you be willing to hazard a guess as to what the goal of a soft fork like this is?

102 sats \ 0 replies \ @d01abcb3eb fwd 26 Oct

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.

0 sats \ 0 replies \ @d01abcb3eb fwd 13h

Although I still do not want to hazard a guess, the question did cause more curiosity to arise. I came to think about the implications of having a system for local filtering what one stores and not having one. IANAL and I do not keep up with legal developments around the world - or at all really -, but the Compuserve case came to mind (think it was Compuserve?). Anyway, the point from that thing was that there seems to be different culpability scenarios depending on if there are attempts to filter, where not attempting to filter seems to be the better choice - on the local level. I'm mostly thinking about filtering what is permanently stored. Changing the rules for everyone to make it harder to publish junk is still a good idea.

315 sats \ 2 replies \ @Scoresby OP 26 Oct

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.

207 sats \ 1 reply \ @ek 26 Oct

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

236 sats \ 0 replies \ @south_korea_ln 26 Oct

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.

100 sats \ 4 replies \ @DarthCoin 26 Oct

Does this SF affect LN ?

223 sats \ 0 replies \ @optimism 23h

Depends on what chaintip your counterparty will force close you on.

100 sats \ 2 replies \ @ek 26 Oct

Good question, I asked

0 sats \ 0 replies \ @Butterfinger 6h

Now github asks for login to read inside it?

0 sats \ 0 replies \ @DarthCoin 26 Oct

great, thanks

145 sats \ 1 reply \ @Scoresby OP 26 Oct

source

source

source

5 sats \ 0 replies \ @Scoresby OP 26 Oct

source

202 sats \ 0 replies \ @south_korea_ln 26 Oct

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?

0 sats \ 25 replies \ @ryu 21h

In response to this post and your subsequently posted replies containing screenshotted reactions, anyone still calling Blockstream Coin "Bitcoin" at this point is an absolute fucking retard.

100 sats \ 24 replies \ @Scoresby OP 20h

Yeah, clearly the "follow the law" freedom money fork proposal is what we should do.

0 sats \ 23 replies \ @ryu 20h

The cult has lost its "community" moniker since 2017, doubling down on defending the worst possible decisions and individual "representatives."

I left the Shitereum community just to end up witnessing another form of it being birthed. No fucking thanks.

55 sats \ 22 replies \ @Scoresby OP 19h

how do you feel about soft forks that may confiscate funds?

source

0 sats \ 21 replies \ @ryu 19h

If this goes through, Blockstream Coin basically becomes Shitoshi's Venture with detrimentally small blocks rather than detrimentally "make them whatever size you want" blocks.

It's funny how the Cashers became vindicated in all their claims about their currency being the true Bitcoin, alongside everything else they've said for nearly a decade... all they need was lots of time for the corporate and governmental subversion to eat away at what little remained of its facade.

205 sats \ 20 replies \ @Scoresby OP 18h

I don't think I understand what you are saying. There's nothing wrong with small blocks and Bitcoin is doing just fine. The only problem is people running around acting like we need an emergency soft fork.

0 sats \ 19 replies \ @ryu 18h

My viewpoint comes down to seeing years of seeing ongoing efforts to sidestep the actual solution to lack of scalability (increasing the block size to 2017-19 BCH levels), and instead try to push Lightning (which Blockstream alongside other paid off and/or deluded developers pivoted towards after their forceful pushing of Liquid failed at the time) as the solution, when you'd be lucky to get even 5% of BSC users to adopt at a self-custodial level without getting wrecked at either a management or application level (bugs can fuck over even the most technically versed of users).

That's on top of disingenuous arguments claiming that raising the block size would kill decentralization (lol) of BSC despite Bitcoin having no size limits originally, and the piece of code that introduced such as a temporary fix for then-real issues around double spending and blockchain drift in 2010 (which is something I touch on in an article that'll be published When It's Ready™ to @lain)... and then raising it an entire megabyte via SegWit and Taproot later on.

When I first jumped ship from one shitcoin to what I believed wasn't another shitcoin in 2021, it was under the presumption that what I thought was Bitcoin was intended to be better money solely without any added fluff or technical excess; you can even find early comments on this account and my Lain account where I joke about not being a maxi for whatever reason(s) I'd give on a per-comment basis.

I'd never be one of any currency and/or shitcoin, but especially not BSC, because I can now see how fundamentally compromised it's been by those who have no interest in it truly displacing the banking system or fiat. No one can force anyone else to pick up on that, the cognitive dissonance has to wear off naturally.

0 sats \ 18 replies \ @ek 16h

sidestep the actual solution to lack of scalability (increasing the block size to 2017-19 BCH levels)

A block size increase scales transaction throughput linearly: 10x bigger blocks => 10x more transactions per block

You think we can scale bitcoin by continuing to increase block size, for example until we can match VISA with 65,000 tps?

view all 18 replies

0 sats \ 1 reply \ @Scoresby OP 5h

@BitcoinErrorLog comes out swinging:

source

0 sats \ 0 replies \ @Scoresby OP 4h

Preach, brother!

source

0 sats \ 0 replies \ @anon 26 Oct