Due to time shortages and being behind getting started on it, I'm going to have to be more selective about new features in #Bitcoin Knots 25.
With that in mind, please let me know if there's anything specific you'd want me to make an effort to include.
Thank you
This would be great. Currently people have to run my fork to use our signet. If this was in knots we could just point people to that
Datacarrier=3 for removing ordinals and stamps spam
This. But why implement it as datacarrier=3?
tongue in cheek. it should more accurately be another parameter, like Dataspam=1 or 0
I like relayopfalseopif, it's cryptic af but descriptive.
Why another parameter?
Because of backwards compatibility. AFAIK datacarrier is for OP_RETURNs only, this would change its behavior.
For instance I don't want to relay OP_FALSE OP_IF transactions but I'm fine relaying OP_RETURNs smaller than 80 bytes. From my PoV it'd suck to roll both filters under the same config option.
It's called datacarrier, not OP_RETURN...
Why would you be okay with 80 bytes OR, but not 80 bytes OFOI? (Assume there's an option to weight them both at 4 WU/B)
I might have another option just because, mostly debating this as a "devil's advocate"
Because OP_RETURN was specifically designed for that, and I (subjectively) feel that up to 80 bytes here and there that are included in the block and pay the full fee is reasonable.
No, it wasn't designed for it
What for, then? 🤔 I always thought that OP_RETURN was for arbitrary bytes.
Apparently it was to burn bitcoins but you’ll have to be crazy to do that. https://en.bitcoin.it/wiki/OP_RETURN
They exist, though! https://twitter.com/YoshishiSatoshi/status/1668345218821939200
OMG Thank you for your donation guys 🫡😂
Smart contracts. It indicates the transaction spending is invalid.
Having the legacy options/parameter clearly defined and untouched while adding a new one seems wise on the surface to me. clearly demarcates the thing to end users. it's somewhat disclosure too. Otherwise you may be mixing legacy parameter behavior and expanding it's scope without disclosure (other than release notes)?
Arguably it's already within scope. After all, all previous versions disallowed this
If you have little time it seems difficult to me but #ordislow?
#[4] #[2]
There are some hints that #Ordisrespector (Luke’s patch) and mempoolexpiry=24 have an effect degree pursued by #Ordislow.
Though a real #Ordislow could reduce the incentives and increment the opportunity cost for processing inscriptions at mining pools (thus, miners).
What would be your opinion about #Ordislow Luke? 🙂
The worst thing is that it bothers me because by slowing down the blocks or even not relaying them at all, I « censor » perfectly legitimate transactions.
There is not censorship in Bitcoin system as long as Bitcoin regular nodes and mining nodes are decentralized. I personally, do not worry about that aspect or narrative.
And if mining node operators process non-inscription transactions, then the entire Bitcoin system works as before; #Ordislow would not be active at all, thus no effects as #Ordislow would never existed.
You don't, censoring would be rejecting a block because it has inscriptions. Though in reality this would only kick you out of the Bitcoin consensus.
The mere fact that you stay in consensus proves that you aren't censoring anything.
I think I chose the term wrong I would say earlier than in the event of a block reorganization, which the desired effect, the transactions that was confirmed are no longer what is still a little annoying for legitimate transactions without being dramatic obviously.
That situation is always possible even without #Ordislow. Participants of the Bitcoin system should know the concept of “confirmation” and evaluate how many confirmations they consider safer.
For instant payments; the choice to use would be lightning.
Unfortunately, people still accept zero-conf transactions 😬
I need to write a thread about that sometime 😁
That is the reason why transaction fees do NOT “buy” space in ROM memory (SSD); instead is a compensation to the miner for his/her marginal competitiveness loss due to a marginal addition of a transaction.
A #Ordislow would better balance an opportunity cost & SegWit discount. 
As measure against SegWit discount exploit.
