mordaunt on Nostr: Your argument is fine, but contains absolutely no justification for why the default ...

Your argument is fine, but contains absolutely no justification for why the default needs to be unanimously changed, or why the configuration needs to be deprecated for removal.

If this is the case, then Core should _make the argument_ - in the same way that Mechanic and Mathew are doing. Not simply use their power to all but force their opinion onto the network.

Attempting to step around consensus is fundamentally anti-Bitcoin. The network should decide based on individual nodes making their own choice about how to proceed. It should not be pushed and prodded by a unanimous update to the main client.

Sovereignty respecting Bitcoin software should expose ALL configuration to the end user.

#bitcoin #knots #core

quoting
nevent1q…sx3q

did you know you can get the bitcoin whitepaper from your pruned node? Its stored in the utxoset permanently. Heres a one liner i created to extract it

seq 0 947 | (while read -r n; do bitcoin-cli gettxout 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713 $n | jq -r '.scriptPubKey.asm' | awk '{ print $2 $3 $4 }'; done) | tr -d '\n' | cut -c 17-368600 | xxd -r -p > bitcoin.pdf

This is why we prefer people use large OP_RETURNs instead of 947 outputs that can’t be pruned. OP_RETURNs are probably unspendable so they will never end up in your pruned nodes utxoset.

They also produce smaller blocks than inscriptions. Unfortunately they are 4x more expensive… but lifting the filter restriction is one small thing we can do to encourage it over other options that are much worse for bitcoin spam-wise.

You definitely don’t want illegal, unprunable stuff in your utxoset permanently, which is why i am running core v30 to do what i can to disincentivize this spam.