pull down to refresh
33 sats \ 3 replies \ @theariard OP 3 May \ parent \ on: Proposal to move Bitcoin Core development over Nostr or decentralized equivalent bitcoin
ask every post to be counter-signed with a pubkey committed in a scarce utxo.
if too much spam posts originating from the pubkey, your client down scores the utxo.
now minimal fee cost on the spammer to get a new fresh utxo.
https://www.freehaven.net/doc/oreilly/accountability-ch16.html
you have 4MB weight unit block and 10 min in average block time.
enough foundations to build internet-large anti-spams.
can ask the scarce utxo to be older than X blocks.
no need for everyone to have the same anti-spam policy, it’s a client-side config.
reply
Cool, doxxing developer financials as an incredibly inefficient method to control spam, that's what Bitcoin is all about /s
reply
well ECC public keys are cheap to generate.
but (a) yes coinjoin multiple-times the utxo you might have to use or other coins clustering obfuscations techniques and (b) if you’re a devs who can’t afford the ~300 sats (or 0.20 GBP) for a single on-chain UTXO you’re free (b.1) go to work until you can afford a 0.20 GBP utxo or (b.2) go to ask nicely to someone to lend you 0.20 GBP to buy an on-chain utxo.
otherwise, go to read the oreilly “accountability” chapter pointed out above, and you will realize that mitigating well spams is an incredibly hard task.
we do not have magical “trusted” third parties who can magically say what is “spam” or not “spam” in bitcoin, as the only source of truth we have is the blockchain itself.
i’m saying all of this without ironical tone, and it’s not like it’s publicly known i've worked for years now on distributed systems.
reply