SLP569 Why Bitcoin Should Not Ossify – Steve Lee \ stacker news ~bitcoin

pull down to refresh

SLP569 Why Bitcoin Should Not Ossify – Steve Lee stephanlivera.com/episode/569/

713 sats \ 7 comments \ @stephanlivera 29 Apr bitcoin

How are other protocols fairing?

Has TCP/IP seen any recent changes? What about SMTP?

(I'm not being snarky, I honestly don't know). But my deeper point is I think at some point widely used protocols tend to ossify naturally as the risk of disruption becomes too great.

30 sats \ 1 reply \ @anon 30 Apr

Protocols can ossify, but software cannot. The issue with Bitcoin is that the Bitcoin protocol can't be disentangled from the Bitcoin Core software.

0 sats \ 0 replies \ @Bell_curve 2 May

By design

31 sats \ 0 replies \ @nerd2ninja 29 Apr

Using the quickest web search in the west:

(AUGUST 2022) Here's the newest TCP update: https://www.rfc-editor.org/info/rfc9293 Quick overview: https://www.youtube.com/watch?v=gp0BGvluhB0

TCP still has this vulnerability called a SYN flood attack which to this day is handled server side using anomalous detection and things. There is also the question of if you even can patch that by updating the protocol.

However, what changes are made to TCP, you will notice are soft changes or soft forks if you will. They aren't disruptive, they just add on things.

Unlike Bitcoin, with TCP, they did actually sunset some things that people just don't do anymore which is why it wasn't disruptive, no one does them anymore.

How about SMTP?

Well, the Simple Mail Transfer Protocol became a permissioned protocol. Often if you try to set up SMTP on your home PC, your ISP will just say "no" and most people use big services like gmail, yahoo, tutanota, etc. If you're not on the list, you never show up in that user's inbox.

Jamason Lopp The Perils of Premature Protocol Ossification

10 sats \ 1 reply \ @nerd2ninja 29 Apr

I believe cries for ossification are not genuine and are rather just a defense mechanism for people who don't understand (or care) about the benefits and downsides (aka tradeoffs) of a BIP.

It seems to me that people who scream for ossification are just defending against a social narrative attack (aka judging BIPs against the BIP author's personality), which is fair enough actually. As much its been said that we should judge code by its merits rather than its author's personality, I do think people have good reason to be afraid of narratives that don't reflect the reason a BIP is merged, popping up as a result of the soft fork.

Jeremy Rubin decided to prove (rather than dismiss) this fear when he decided to throw a fit at core and opened a PR to remove BIP 119. I swear if that PR went through, I'd have half a mind to submit it again (not that I would be able to maintain it). I'm not sure what the license on that code is, but hopefully its the kind that lets you fork it like that just so I could show Jeremy that he can't go around pulling stunts like that.

(this is the PR I'm talking about): https://github.com/bitcoin/bips/pull/1561#issuecomment-2073870968

0 sats \ 0 replies \ @Bell_curve 2 May

Good analysis

10 sats \ 0 replies \ @TNStacker 29 Apr

Protocol ossification is the loss of flexibility, extensibility and evolvability of network protocols. This is largely due to middleboxes that are sensitive to the wire image of the protocol, and which can interrupt or interfere with messages that are valid but which the middlebox does not correctly recognise. This is a violation of the end-to-end principle. Secondary causes include inflexibility in endpoint implementations of protocols.

-Wikipedia https://en.m.wikipedia.org/wiki/Protocol_ossification