Quindi, ho trascorso gran parte di ieri a discutere tranquillamente con @adam3us. Il suo stagista non è stato invitato. Faremo una discussione pubblica più lunga (anche con @JeffBooth) a breve, ma ecco il TLDR provvisorio (può correggermi se mi manca o rappresento male qualcosa): 1) Siamo d'accordo che lo spam esiste ed è un problema ben definito, che è un problema particolarmente brutto per Bitcoin come sistema di consenso globale (che le commissioni per lo spazio nei blocchi non possono realmente risolvere o mitigare molto), che dovrebbe essere denunciato/combatuto il più possibile, e che ovviamente include le truffe NFT e simili. È d'accordo che le acrobazie mentali relativiste a questo riguardo sono assurde. 2) Siamo d'accordo che resistere alla censura statale è socialmente necessario e importante, e il fine ultimo di Bitcoin e di altri strumenti cypherpunk, e che l'auto-censura per cercare di compiacere lo Stato è tatticamente inaffidabile a breve termine e strategicamente controproducente a lungo termine, specialmente nel contesto della progettazione di sistemi e strumenti (la mitigazione del rischio legale è razionale a livello individuale/aziendale). 3) Siamo d'accordo che, mentre combattere lo spam (e non "spam") è un buon obiettivo ingegneristico e non è affatto "censura", è anche intrinsecamente difficile farlo in sistemi ottimizzati per la resistenza alla censura, e mentre potrebbe essere fatto in una certa misura con l'applicazione delle regole di consenso, è una battaglia in salita farlo con l'applicazione delle politiche di mempool, specialmente se non c'è un fronte unitario in quest'ultimo e cose come LibreRelay e Slipstream esistono. Siamo anche d'accordo che le persone che vogliono ancora provare a farlo non dovrebbero essere derise o antagonizzate, anche se siamo scettici sul risultato. 4) Siamo un po' d'accordo che la gestione del problema all'interno del processo di governance di Bitcoin Core sia stata scadente e sub-ottimale (discutiamo sull'enfasi: lui pensa che sia stata carente, io penso che sia stata un disastro totale simile a un incendio in un cassonetto). Siamo d'accordo che se questo fosse stato gestito nello stesso modo del dibattito Full-RBF (e in una certa misura del dibattito sull'attivazione di Taproot, su cui lui è più generoso/ottimista di me), saremmo già a nostro agio su qualche tipo di status quo che quasi nessuno ama ma che quasi tutti accettano. 5) Siamo un po' in disaccordo sul fatto che l'ondata di follia woke originata dagli Stati Uniti sia particolarmente rilevante per il dibattito attuale: lui riconosce l'esistenza di questa isteria di massa politicizzata, spesso sfruttata per lotte di potere e takeover ostili, e la forte influenza che ha raggiunto nello sviluppo software (particolarmente in FLOSS: da NixOS a Linux, a FSF a Rust, ecc.), ma non pensa che questo sia attualmente prominente tra gli sviluppatori di Bitcoin, o che venga attualmente utilizzato come arma per tentativi di takeover della governance. Non pensa che il fenomeno sociale abbia impattato significativamente la qualità della produzione e revisione del codice in Core. 5) Siamo in disaccordo sul fatto che eseguire Knots per nodi non minerari sia una buona risposta al (molto reale e molto rilevante) problema dello spam: mentre lui riconosce l'effetto di segnalazione sociale di farlo e la sua rilevanza nel quadro più ampio, è molto preoccupato per le implicazioni di sicurezza delle vaste differenze di codice tra Core e Knots, specialmente se si esegue quest'ultimo come wallet, o a supporto di un L2 che dipende fortemente dalla vivacità e dalle condizioni di gara (come LN). Io non lo sono: non uso né Core/Knots/LibreRelay per cose di wallet, e uso un vecchio Core per CLN. Inoltre, mentre riconosco il rischio di Knots, sono molto più pessimista di lui riguardo ai rischi di Core. 6) Siamo in disaccordo sulla distribuzione della colpa in termini di attacchi velenosi, argomenti da pagliaccio, accuse iperboliche, mosse in mala fede, tribalismo, reazioni cieche ed emotive tra i due "campi": mentre lui riconosce la presenza di queste dinamiche in "entrambi i campi", la sua impressione è che "Core sia migliore" a questo riguardo, mentre la mia è opposta (questo si estende al nostro giudizio su alcuni degli individui coinvolti). 7) Siamo in disaccordo sulla fattibilità politica di diverse proposte anti-spam e corsi d'azione: mentre sono un po' scettico che il "movimento di filtraggio" raggiunga qualcosa di più che rallentare e mitigare il fuoristrada "che accoglie lo spam" su cui Bitcoin sembrava essere, sono anche totalmente scettico che possiamo trovare un accordo per mitigazioni basate su soft-fork, mentre lui pensa che un cambiamento di consenso possa avere un migliore supporto da parte degli utenti rispetto ai giochi di politica di mempool. In generale, siamo d'accordo che, molto probabilmente, lo spam non ucciderà Bitcoin, e i filtri di mempool non uccideranno Bitcoin, e i file illegali non uccideranno Bitcoin, e il panico legato alla legge non ucciderà Bitcoin, e CoreV30 non ucciderà Bitcoin, e Knots non ucciderà Bitcoin, e la wokeness non ucciderà Bitcoin, e "autoritari distribuiti" come me (lol) non uccideranno Bitcoin. Siamo per lo più in disaccordo riguardo al suo stagista: io dico che dovrebbe licenziarlo, lui dice che porta un buon caffè.

Accidenti, ho di nuovo sbagliato la numerazione, vero?

@BitMEXResearch @adam3us @JeffBooth *un processo che coinvolge attori per lo più non correlati

@BitMEXResearch @adam3us @JeffBooth *cugino super-brutto dopo lo sconto SW

@BitMEXResearch @adam3us @JeffBooth Sì, l'ho riletto ed è appena comprensibile a causa di errori di battitura. :( Ma spero che tu possa afferrare qualcosa @BitMEXResearch, poiché penso che stiamo toccando un disallineamento MOLTO rilevante. Cercherò di riscrivere meglio quando sarò al laptop (ora sono in aeroporto).

@WhalesSecret @BitMEXResearch @adam3us @JeffBooth *expect

@EricSirion @adam3us @JeffBooth *stessa identica

Solo per chiarire, la definizione di spam "non monetaria" è anche chiaramente un diversivo: tutti noi abbiamo definito ciò che Bitmain probabilmente ha fatto allora come un "attacco spam", e tutte quelle erano *transazioni* monetarie. La definizione di buon senso non ha nulla a che fare con il fatto che sia monetaria o meno: è solo informazione che almeno un destinatario preferirebbe non ricevere. I nodi Bitcoin sanno di aver bisogno di un UTxOset aggiornato, perché potrebbero ricevere alcuni di quegli output eventualmente... Ma preferirebbero non scaricare e convalidare transazioni di wash create solo per riempire i blocchi.

E per chiarire ulteriormente: quel tipo di spam non può essere rilevato con precisione, tanto meno prevenuto. E va bene così. La prevenzione totale dello spam è impossibile ovunque, tanto meno in sistemi aperti come Bitcoin. Penso che ciò che le persone vogliono sia poter mitigare almeno alcuni dei casi più ovvi, palesi e sfacciati.

@WhalesSecret @BitMEXResearch @adam3us @JeffBooth Approfondirò ulteriormente i vostri esempi non appena atterro.