Profile: 1525d058...

The softfork proposal as I see it, (not finalized yet in code) is to limit the amount of data per transaction.

There is no “committee” or judge that decides which transactions are ok or not- other than the consensus rules of the network itself.

These consensus rules are why Bitcoin has value, if someone (like Peter Todd did) proposed to increase the 21 million cap- would the network accept it?

If someone proposes segwit? Or taproot? Or limiting the total amount of data per transaction?

We will see.

Keep in mind the UASF during the block size war was implemented with only 15% of the nodes signaling for it.

It is not correct that a soft fork (same as segwit or taproot)

“changes the permissionless nature of Bitcoin”

Bitcoin is a system of rules, that anyone can use for peer to peer digital cash permissionlessly- but you cannot break the rules without ending up on your own hard fork with a worthless token. The rules are based originally on Satoshi’s design in the whitepaper, and they are updated according to network consensus over time.

In general, Bitcoin is based on restricting things- you cannot send the same Bitcoin twice, and the amount of Bitcoin is never more than 21 million coins for example.

This softfork in theory is not flawed, and does not require a “gatekeeper” it is a proposal to change consensus, limiting the amount of abritrary data.

It can be implemented similar to the UASF during the block size war.

Who “made the call” to implement segwit or taproot or other soft forks?

How about the inflation bug?

The rabbit hole beckons to you brother

Because it’s asymmetrical.

You should read about the UASF during the block size war. The network complied with the UASF with 15% of the nodes signaling for it.

You are going to argue for the spam chain if a major chain split happens? Good luck explaining why it’s good for Bitcoin to publish CSAM to the public shareholders of foundry and Mara.

Ironically, the centralization and corporate structure of major mining pools today make the soft fork easier to implement.

Chris, you are either intentionally mid-representing this soft fork, or you aren’t remembering what orphan blocks are.

https://www.lightspark.com/glossary/orphan-block

Reorganizing a block happens often- that’s why we have the little 6-block circle indicator in Sparrow for example. You should be waiting about 6 confirmations to consider a transaction fully settled. That isn’t “F***ing with property” that’s how Bitcoin works.

Btw, guess what Foundry, Blackrock, Coinbase, etc, think about what CoreV30 does- by default making bitcoin an anonymous permanent data storage service -to their property?

Not to mention myself and any other decent Bitcoin node runner.

The decision here isn’t about voting thankfully. You are free to reject the soft fork, pin and persist on the CSAM chain and call it “the real Bitcoin” if you like, just like the B-cashers do with their hard fork.

https://fountain.fm/episode/WOslYaeXHkGPni8BznUK

nostr:nevent1qvzqqqpxquqzpzm0ttuld48qtds5l0jkmz8r07h5jj6d8wpw5c88kfr5fcyd8dxkrsxhwm

Svetski is a coward for that stance on Core 30.

We are all retards? Then I guess I won’t waste my money on your book since I obviously won’t understand anything anyway.

Pure nihilism.

https://fountain.fm/episode/zqajzJxjR7eN156fVH3s

Boomer can’t see the Bitcoin/Bitcoin lifeboat because it’s so much faster it already dropped survivors off on shore and is circling back to pick up more people.

The gold/gold boat is sitting there next to the sinking ship, yes you will survive but you are gonna freeze your ass off getting back to shore.

https://fountain.fm/episode/zcAlc4csTun2cGVRIa54

nostr:nevent1qvzqqqpxquqzqmakvfkkucr60gselk5xe4ky928d4gp73czhllvhtg9r57j48k2t7gnn45

Core/Knots is about Core removing User options.

IMO, Free and open-source software is about empowering Users.

Knots enables more options to the User.

The current B-Core team needs to reflect on the broader intentions of the Users, and of the bitcoin network itself.

https://fountain.fm/episode/vNS3UnEX1NMhmngvCl9m

nostr:nevent1qvzqqqpxquqzp7qj2w8r2x4j7d8qcesrgr52jrulg4afnalp66c8a42ky9lerrwp6add86