Yep. But better website and plans for major improvements beyond that
Why are you spreading lies?
Literally every Bitcoin node has done so since Satoshi's time
The provider should always be your own node, configured the way you like it
If you actually want centralization, then Sv2 won't make you happyπ¬
The UI is already updated for the Hestia rectangle, just a matter of configuration (assuming I pushed the code to GitHub...)
Lmk if any issues, or if I need to push it
I'm not actively working on it these days, but my FreeAbode works fine
You don't know what you're talking about
This wasn't ready at launch, and we publicly announced it when it was
We're not censoring. They're just exceeding a limit that goes back a decade. We didn't do anything here
The OP_RETURN discussion is not new and dates back to 2014 when Bitcoin Core 0.9.0 was released with the OP_RETURN policy included which was intended to discourage more egregious forms of spam. At that time, 40 bytes was the default max datacarriersize limit across all node implementations; this was and still is sufficiently large for tying data to a transaction (32 bytes for a hash and 8 bytes for a unique identifier). Core subsequently increasing the default to 80 bytes was an entirely voluntary decision and in no way contradicts the design objective that OP_RETURN creates a provably-prunable output to minimise damage caused by data storage schemes, which have always been discouraged as abusive. There are also other good technical reasons which I have chosen to retain the lower default in Bitcoin Knots, and no justification for increasing it.
It is not my intention, nor that of my team at
nostr:npub1qtvl2em0llpnnllffhat8zltugwwz97x79gfmxfz4qk52n6zpk3qq87dze, to filter coinjoins. These present an innovative tool for increasing Bitcoinβs privacy and, when constructed properly, coinjoins can easily stay within the OP_RETURN limit (indeed, there is no reason for them to have *any* OP_RETURN data at all). I have some ideas on how to alleviate the recent issue where some coinjoin transactions were flagged as spam from Knots v25, and I am willing, with the full resources of my team, to work collaboratively on a solution in good faith.
Bitcoin does and always has allowed nodes to set filters based on multiple sets of criteria and Knots v25βs defaults are IMO what is best for Bitcoin at this time. Others may disagree and that is ok. They are free to (and should) run their own nodes - it is good for Bitcoin to have more people running nodes, including miners, and there should be a natural diversity in node policies. As was stated before, OCEAN is on a path to decentralization and very soon we are going to be in a position where hashers will be able to fully participate as miners and perform the intelligent parts of mining such as deciding which version of node software to run and what filters or other policies to apply to block template construction.
80 isn't justifiable, and brc20 spam is at 45
And I've been right for a decade.
It was a lie then too. Just because lies are old doesn't make them true
As far as I know, this is a Samourai only issue.
It doesn't make sense for coinjoins to dox themselves like this in the first place.
42 is 40 + 2 opcodes (which are counted in the current versions)
If you think Core gets to just dictate things, get over your centralization mindset.
Knots has used 40/42 since 2013. Samourai are the ones who chose to exceed it.
Also note that having ANY extra data hurts your privacy, which seems to contradict the goals of coinjoins. Not really sure what Samourai is thinking here ...