(Non avevo mai provato questa cosa degli articoli X prima d'ora)
Iniziamo col dire che non sono pro-BIP110, né anti-BIP110. Se effettivamente riesce a ottenere un vero consenso nella rete e viene imposto dalla maggioranza… bene. In tal caso, lo seguiremo perché la rete ha parlato e lo ha accettato, e tutti i nodi, compresi quelli non-BIP110, verranno trascinati lungo il percorso.
Sfortunatamente per i sostenitori della proposta, non è attualmente il caso secondo nessuna metrica misurabile, né sembra avere una traiettoria che suggerisca un cambiamento.
C'è stata molta disinformazione su tutta questa faccenda, specialmente nel contesto del mining. Ecco alcuni rapidi punti chiave per contrastare brevemente l'iperbole dei sostenitori:
- BIP110 NON è inevitabile. PUÒ fallire.
- BIP110 può e causerà una scissione della catena (fork) in una situazione di hashrate minoritario.
- BIP110 NON è privo di rischi per i miner che scelgono di adottarlo.
- I miner che non supportano BIP110 non stanno improvvisamente minando blocchi "non validi" solo perché esiste una proposta non ancora adottata.
- Non sei una persona cattiva o malvagia solo perché non ti piace o non supporti BIP110.
(Il fatto che senta il bisogno di sottolineare l'ultima parte è in realtà un po' triste…)
Stavo per scrivere un lungo post per aiutare i miner a rimanere informati sulle cose che devono tenere d'occhio mentre tutto questo si svolge… prima di rendermi conto di averlo già fatto mesi fa come documento che avevo scritto e che speravo potesse essere pubblicato come pezzo educativo per i miner su OCEAN. Purtroppo non è mai stato pubblicato. Quindi l'ho aggiornato, ed eccolo qui:
https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
Di nuovo, tieni presente che è stato scritto mesi fa, con l'intenzione di essere il più neutrale possibile per renderlo accettabile come post aziendale. Quel tentativo è fallito, quindi oggi lo pubblico come documento personale.
Come miner che prendi decisioni importanti sulle tue operazioni, devi essere consapevole di tutto questo senza edulcorazioni e, francamente, informazioni fuorvianti provenienti da alcuni sostenitori di BIP110. Devi essere vigile e decidere cosa è giusto per te. Sebbene ci siano anche informazioni fuorvianti da parte dell'opposizione, nulla di ciò che ho visto è così grave come le dichiarazioni di vittoria estremamente premature e l'iperbole associate spingendo dal lato BIP110.
Riassumendo un po' il mio documento, il mio consiglio personale ai miner è questo:
- Segnala se supporti BIP110
- Non segnalare se non supporti BIP110 o non ti interessa
- In ogni caso, monitora la rete intorno/al/prima del blocco 961632.
- Se continui a vedere blocchi senza segnalazione da parte dei grandi pool, puoi essere ragionevolmente certo che non decideranno improvvisamente più tardi di buttare via milioni di dollari di entrate per tornare indietro e segnalare per BIP110.
- Se per qualche caso iniziano a segnalare per BIP110, dovresti monitorarlo e considerare di cambiare se necessario per rimanere sulla catena più pesante.
Il punto chiave è che, realisticamente, solo un lato può vincere. O BIP110 ha successo e i miner che non sono dalla parte di BIP110 falliscono, o BIP110 fallisce e i miner dalla parte non-BIP110 hanno successo.
Andando avanti, approfondiamo una piccola parte della mia logica.
🟠DATI RAPIDI: Tra il 7 e il 15% dei nodi Bitcoin stanno segnalando supporto per BIP110.
A seconda di quale crawler centralizzato guardi… nessun modo per saperlo con certezza. Il mio crawler privato personale mette questo numero molto più basso, ma questa è una discussione per un altro giorno. Basti dire che penso sia logico e corretto affermare che anche il 15% non è una maggioranza.
"Ma Jason! L'UASF ha attivato Segwit con meno nodi!"
Sì, perché molti miner, commercianti, utenti, ecc. volevano davvero Segwit. C'era un peso economico e comunitario notevole dietro. Senza ripercorrere tutta quella storia (ci sono molte risorse sull'argomento precedenti a BIP110 che vale la pena leggere), basti dire che BIP110 e le attivazioni di Segwit non sono proprio confrontabili, come molti hanno già sottolineato. Segwit, ad esempio, è entrato nel suo territorio UASF con circa 1/3 dell'hashrate di rete già segnalante supporto. Con quel tipo di sostegno, l'UASF per aiutare a spingere il MASF oltre il punto di svolta aveva molto senso.
Non ha senso qui per BIP110.
🟠DATI RAPIDI: Lo 0.6% dei blocchi negli ultimi 60 giorni ha segnalato supporto per BIP110.
Un contrasto piuttosto netto anche con il basso supporto di base di Segwit. Sì, so che è aumentato leggermente nelle ultime due settimane, ma nessun nuovo entrante. Solo più hashrate noleggiato chiaramente da uno degli stessi piccoli sostenitori.
Qualcosa da tenere a mente è che minare blocchi di segnalazione BIP110 tramite DATUM su OCEAN non comporta praticamente alcun rischio per il miner fino al punto di fork al blocco 961632. Il costo è trascurabile, poiché sei effettivamente garantito di recuperare i costi di noleggio, ecc.
È fantastico che esista la possibilità di farlo, e non vorrei diversamente… ma è solo qualcosa da tenere a mente quando si valuta la segnalazione da tali blocchi nel quadro generale dal punto di vista rischio/ricompensa/soldi sul tavolo.
"Ma Jason! I miner non hanno alcun incentivo a segnalare fino all'ultimo minuto!"
Non vedo nemmeno prove che suggeriscano che possa essere così. Soggettivamente, non sono d'accordo con la premessa, poiché non è nell'interesse di un pool di mining destabilizzare la rete in questo modo. Parte del motivo dei periodi di segnalazione anticipata e blocco è per coordinare gli aggiornamenti in modo fluido. Aspettare fino all'ultimo minuto annulla completamente quel beneficio. Non vedo alcuna logica convincente o vantaggio nel farlo.
Continuando su questo, come parte della mia configurazione di monitoraggio dei nodi personali, monitoro specificamente i nodi noti appartenenti a varie entità, come altri pool di mining, exchange, grandi nodi Lightning, commercianti, ecc. Una supermaggioranza dei quali sono monitorati con esplicito permesso e conferma/coordinamento.
🟠DATI RAPIDI: Tutti i principali pool di mining che monitoro stanno attualmente eseguendo qualche variante di Bitcoin Core v30 o v31 (eccetto OCEAN).
Approfondendo, la maggior parte ha aggiornato i propri nodi dalla proliferazione del rilascio di BIP110, anche dal rilascio di Knots 29.3. Inoltre, è noto che molti pool di mining eseguono versioni modificate del loro software nodo per facilitare vari requisiti della loro infrastruttura specifica. Tali modifiche dovrebbero essere portate su un client compatibile con BIP110, testate, valutate e distribuite in anticipo. Attualmente non vedo prove che ciò sia il caso.
Per quanto posso dire, i pool sono consapevoli ma ignorano.
"Ma Jason! I miner non determinano il consenso! Lo fanno i nodi! Altrimenti annulleranno gli halving!"
Questa è una delle argomentazioni più divertenti e ridicole che abbia sentito dalla folla pro-BIP110. Confrontare un cambiamento di consenso che può essere imposto unilateralmente sulla rete dai miner e accettato dal 100% dei nodi esistenti (un soft fork), con un hard fork che nessun nodo esistente accetterà… è disonesto nel migliore dei casi.
Stringere le regole (come BIP110): Soft fork, può essere imposto dai miner se lo scelgono. Allentare le regole (come annullare un halving): Hard fork, non può essere imposto dai miner senza un'accettazione effettivamente del 100% da parte dell'intera rete… Il che non è probabile che accada.
Confrontare i due è, francamente, semplicemente stupido.
"Ma Jason! Se non aggiorni alle ultime regole di consenso, sei insicuro! Perderai fondi! Minerai blocchi non validi! [Inserisci qui ulteriore iperbole]!"
Questo sarebbe vero per un cambiamento di consenso che ha, beh, consenso. Mentre BIP110 ha fatto un lodevole sforzo per ottenere quel consenso, non ha ancora alcuna maggioranza misurabile a quella che è ormai l'undicesima ora. Non nei nodi, non nell'hashrate, non negli strati sociali (consensus.health ha un grafico interessante lì dove mi troverai nel mezzo).
Se in qualche modo BIP110 ottiene il 51%+ dell'hashrate di rete al/blocco 961632… allora, va bene. Viene imposto, poiché come soft fork una maggioranza di miner può imporlo unilateralmente in assenza di un URSF completamente adottato (effettivamente un termine improprio, poiché questo sarebbe una specie di hard fork).
"Ma Jason! Non può ottenere consenso avendo già consenso! Devi dargli una possibilità!"
Innanzitutto… no, non lo devo, anche se l'ho fatto. Secondo, è una proposta frettolosa che non ha mai avuto il tempo di provare nemmeno a ottenere un vero consenso. Sono passati 7 mesi dal rilascio del primo client BIP110. Mancano circa 3 settimane all'inizio della segnalazione "obbligatoria" (meno quando leggerai questo). Il 90% del tempo disponibile è passato senza alcun cambiamento nel sentimento generale da parte di alcun attore rilevante. Se non ha ottenuto sufficiente adozione negli ultimi 7 mesi, è improbabile che lo faccia nelle prossime 3 settimane.
"Ma Jason! CSAM! CSAM! Pedofili! CSAM!"
Sarò il primo a dire, anche io personalmente ho sopravvalutato il rischio all'inizio quando Core ha proposto la sua modifica OP_RETURN. Mi aspettavo personalmente che qualcosa di particolarmente grave colpisse la catena quasi immediatamente, e per quanto ne so, non è ancora successo. Potrebbe ancora succedere? Sì, suppongo.
Ma considerando da una prospettiva tecnica, byte per byte gli stessi dati arbitrari contigui possono probabilmente finire memorizzati nella catena attuale o in quella BIP-110 senza troppi problemi… questo particolare argomento per BIP-110 mi sembra piuttosto debole a questo punto.
Voglio CSAM nella catena? Certo che no. Sono un pedofilo se non supporto BIP110? Nemmeno.
…
Potrei continuare all'infinito, ma mi fermo qui. Ho perso abbastanza tempo su questo. Sono sicuro di aver fatto abbastanza per infastidire entrambi i lati del dibattito su BIP110 a questo punto, dato che non adotto nessuna delle due posizioni. Sono sicuro che riceverò critiche da tutti i lati solo per aver osato dire la mia.
Nel complesso, penso per lo più che sia stato sciocco affrontare un problema reale (la modifica predefinita di OP_RETURN in Bitcoin Core) con la proposta di soft fork basata sul manifesto anti-spam massimo… che non può provatamente fermare spam, dati arbitrari, ecc. 🤦♂️ (Sì, lo so, i sostenitori sosterranno che non si tratta di spam… e faranno anche argomentazioni semantiche che ferma anche i dati… nessuna delle quali sembra essere corretta.)
Chiuderò con la concessione che potrei sbagliarmi. Non sono Nostradamus, e non posso prevedere con precisione l'esito con certezza al 100%. Posso solo basarmi su ciò che i dati mi dicono, e quindi do a BIP110 meno del 5% di possibilità di successo effettivo… e lo considero generoso.
Puoi prendere le mie opinioni su questo come preferisci, ma ti raccomando vivamente di non sottovalutare i dati effettivi, di rimanere vigile e di fare ciò che è meglio per te e per le tue entrate di mining. Non farti manipolare da nessuno dei due lati del dibattito e prendi le tue decisioni.
Ecco un link allo stesso documento collegato sopra per facilità di accesso: https://docs.google.com/document/d/14DfMSVYBHTHIOmW32JTOR6BAP7AITbinvrhl8rJuvvc/edit?usp=sharing
