Got the parts for mine from nostr:nprofile1qqs06qnxfpth00tna978cdl4yryreqhrvtlycfdxh6flxwqqs02xg6cpz4mhxue69uhhyetvv9ujuerpd46hxtnfduhsz8rhwden5te0dehhxarj9eehw6tnwvkk2mnfvakkztnrdqhszxnhwden5te0dehhxarj9e3k2unrv968ymmkvyhx6ef0p9amlg
That doesn't really sound like a zap anymore.
I don't think I'd interact with any mint to retrieve any tiny IOUs that random people give me. But LN sats I'd still take.
Back in 2017 a few of the spam filters from Core that apply to legacy TXs were not adapted for SegWit.
Fixing this inconsistency in Core would go a long way in mitigating the problem, but the current maintainers don't seem willing to make this fix (they recently closed a Pull Request that did just that).
Running Bitcoin Core with the ordisrespector filter, running Bitcoin Knots (@lukedashjr's version of Core with extra features and adequate filters), or pointing your hashrate to Ocean if you are a miner are the things that are in the hands of individual Bitcoiners.
Back in the day I followed this excellent guide from @Gigi to create a simple Nostr bot (@`ordisbot`).
Anyone knows if there's anything written about programming interactive Nostr bots? Meaning bots that accept commands by DM and reply back and forth.
I don't get why the Nostr community (clients & relays) has given up on supporting NIP-42. It'd prevent random users from doing this (but not the operators of the relays you use). Nevertheless feels like low hanging fruit.
@semisol@fiatjaf you authored the NIP, any insights on this?
https://github.com/nostr-protocol/nips/blob/master/42.md
Node runners should not cater to miner incentives but their own ones. While the situation doesn't resolve, if I want another estimation I can get it with a few keystrokes.
There is no such thing as an "accurate fee estimation" as each node runner has full control over mempool policy, so each mempool can be different (and actually is in practice).
My incentive as a bitcoin user is to pay less fees when I transact, not more. And as a node runner my incentive is to prevent my node from relaying spam* so that the blockchain doesn't bloat, and operating the node doesn't become more expensive than necessary, leading to more pruned nodes and centralization.
*Each node runner decides what he considers spam, it follows from the fact that he controls mempool policy.
Calling that censorship is disingenuous and not constructive to debate. You also "censor" unless you've explicitly set minrelaytxfee=0, or you've never run with blocksonly=1.
And I'm not criticising it, my node also does that. What I'm doing is pointing out the contradiction of calling inscription filtering "censorship", but not 0-fee tx filtering. Both are done in exactly the same way, and neither are an act of censorship.
Both inscribers and 0-fee transactors can tweak their node configs and mine themselves, or strike their deals with miners. An Ordisrespector node doesn't get in the way of any of that.
The thing is I believe we're in a catch-22 situation where an actual supermajority of node runners want to filter inscriptions from their mempools but they don't know how to do it (because BC devs and most node distros aren't making it easy), or they don't even realize they can do it. If I'm right and the situation ends resolving this way the patch will be no more and no less effective than minrelaytxfee. There are 0-fee txs from time to time but they aren't half of the mempool space.
Regarding other Bitcoin Script opcode sequences to embed arbitrary bytes in tx: I don't think they even need to be patched. If the network coordinates to reject this first kind of txs it should discourage spammers from trying much further. Detecting these patterns and patching them out is orders of magnitude easier than finding them, then it's just a matter of how fast most nodes patch them out.
I won't tell you what to do with Raspiblitz. But your users are sovereign to filter inscriptions, and some of them want to do it. They placed their trust in you, and you can either respect that sovereignty or you can try to get in the way of it. That's just the way it is.
> But some “fixes” could even backfire and create less fees, or introduce bugs, or damage the incentive structure
> Some soft forks like covenants can be thoughtfully considered for scaling and fee density
Couldn't this be one of these cases? If covenants allow moving a lot of the transactional volume offchain wouldn't this compromise the incentive of a fee market to form in the first place?
Oddbean new post about login | logout
Notes by Unhosted Marcellus | export