It’s heavy work for sure on the charge of all current contributors (we would have to change our dev habits quite substantially), though on the long-term it’s worthy and it would avoid a lot of frustrations we’re seeing recently with discussions like consensus changes or OP_RETURN policy changes.
pull down to refresh
zaps forwarded to @standardcrypto (5%) @BITC0IN (5%)
25 sats \ 0 replies \ @kristapsk 3 May
https://github.com/JoinMarket-Org/joinmarket-clientserver/issues/1302
reply
5 sats \ 5 replies \ @OT 2 May
How would you stop unwanted posts from spamming up discussion?
I like how no one can get banned from nostr.
reply
33 sats \ 3 replies \ @theariard OP 3 May
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
reply
23 sats \ 0 replies \ @theariard OP 3 May
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
0 sats \ 1 reply \ @02c42fc294 4 May
Cool, doxxing developer financials as an incredibly inefficient method to control spam, that's what Bitcoin is all about /s
reply
0 sats \ 0 replies \ @theariard OP 4 May
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
0 sats \ 0 replies \ @jb55 3 May
deleted by author
0 sats \ 0 replies \ @theariard OP 4 May
so i won’t champion further this proposal, after an instance of meditation:
https://github.com/bitcoin-core/meta/issues/17#issuecomment-2849415676
i think it’s a reasonable way to move to for bitcoin core, but i do not wish to allocate my time lobbying for that among the community of contributors on bitcoin core.
i prefer to focus on dev’ing my own full-node implem.
cypherpunks write code.
reply
0 sats \ 0 replies \ @88b0c423eb 2 May freebie
great idea