Bitcoin Magazine
Ocean Mining VP Jason Hughes: BIP-110 sulla buona strada per fallire poiché il segnale dei miner rimane sotto l'1%
Questo è un post ospite diJason Hughes, VP dello Sviluppo e Ingegneria presso Ocean Mining. Le opinioni espresse sono esclusivamente le sue e non riflettono necessariamente quelle di BTC Inc. o Bitcoin Magazine. L'articolo è apparso originariamente su X.com ed è stato pubblicato con il permesso dell'autore.
Iniziamo col dire che non sono pro BIP110 e non sono nemmeno contro BIP110. Se dovesse effettivamente avere successo come qualcosa che ottiene un vero consenso all'interno della rete e finisce per essere applicato dalla maggioranza della rete... bene. Se così fosse, allora procederemo con esso perché la rete ha parlato e l'ha accettato, e tutti i nodi, compresi i nodi non BIP110, saranno trascinati lungo il percorso. Sfortunatamente per i sostenitori della proposta, attualmente non è affatto così secondo alcun parametro misurabile, né sembra avere una traiettoria che suggerisca che ciò cambierà.
Ci sono state molte informazioni fuorvianti su tutta questa faccenda, specialmente nel contesto del mining. Alcuni punti chiave rapidi per controbattere brevemente alcune esagerazioni da parte dei sostenitori: BIP110 NON è inevitabile. Può FALLIRE. BIP110 può e causerà una divisione 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 estraendo blocchi "non validi" solo perché esiste una proposta che non è ancora stata adottata. Non sei una brutta persona o malvagia semplicemente perché non ti piace o non supporti BIP110. (Il fatto che senta il bisogno di sottolineare quest'ultima parte è in realtà un po' triste...)
Stavo per scrivere un lungo post per aiutare a tenere informati i miner su cose di cui devono rimanere a conoscenza mentre tutto questo si svolge... prima di rendermi conto che l'avevo già fatto mesi fa, come un documento che ho redatto e che speravo potesse essere pubblicato come un pezzo di educazione per i miner su OCEAN. Purtroppo, non è mai stato pubblicato. Così ho proceduto ad aggiornarlo, ed ecco qui.
Ancora una volta, tieni presente che questo è stato scritto mesi fa, con l'intento di essere il più agnostico possibile nel tentativo di renderlo accettabile come post aziendale. Quel tentativo è fallito, quindi lo pubblico oggi come documento personale. Come miner che prende decisioni importanti sulle tue operazioni, devi essere a conoscenza di tutto questo senza il buonismo e, francamente, le informazioni fuorvianti provenienti da alcuni sostenitori di BIP110. Devi essere vigile e decidere cosa è giusto per te.
Sebbene ci siano certamente alcune informazioni fuorvianti anche dall'opposizione, nulla di ciò che ho visto è quasi così eclatante come le affermazioni di vittoria estremamente premature e l'iperbole accompagnatoria spinta dal lato BIP110. Riassumendo un po' il mio documento, il mio suggerimento personale ai miner è questo: Segnala se supporti BIP110. Non segnalare se non supporti BIP110 o non ti interessa. In ogni caso, monitora la rete su/attorno/prima del blocco 961632.
Se continui a vedere blocchi non segnalanti da grandi pool, puoi essere ragionevolmente certo che non decideranno improvvisamente di buttare via milioni di dollari di entrate per tornare indietro e segnalare per BIP110. Se lo fanno, per qualche caso, iniziano a segnalare per BIP110, dovresti monitorare la situazione e considerare di cambiare come necessario per rimanere sulla catena più pesante. Il punto chiave è che, realisticamente, solo una parte può vincere. O BIP110 ha successo e i miner che non sono dalla parte di BIP110 falliscono, oppure BIP110 fallisce e i miner dalla parte non BIP110 hanno successo.
Passando oltre, immergiamoci in una piccola frazione della mia logica.
FATTO VELOCE: Tra il 7 e il 15% dei nodi Bitcoin stanno segnalando supporto per BIP110.
A seconda di quale crawler centralizzato guardi... non c'è modo di sapere con certezza [quanti nodi BIP110 stanno segnalando supporto]. Il mio crawler privato personale stima questo numero molto più basso, ma questa è una discussione per un altro giorno. Basta dire che penso sia logico e corretto affermare che anche il 15% non è una maggioranza.
“Ma Jason! UASF ha attivato Segwit con meno nodi!”
Sì, perché molti miner, commercianti, utenti, ecc., volevano davvero Segwit. C'era un enorme peso economico e comunitario dietro di esso. Senza ripetere tutta quella questione, poiché ci sono molte risorse sull'argomento da prima di BIP110 che meritano di essere lette, basta dire che le attivazioni di BIP110 e Segwit non sono del tutto comparabili, come molti hanno già sottolineato. Segwit, ad esempio, è entrato nel suo territorio UASF con circa 1/3 della potenza di hash della rete già a segnalare 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.
FATTO VELOCE: lo 0,6% dei blocchi negli ultimi 60 giorni ha segnalato supporto per BIP110.
[Lo 0,6% è un] contrasto piuttosto netto rispetto anche al basso supporto di base di Segwit. Sì, so che è aumentato leggermente nelle ultime settimane, ma nessun nuovo partecipante. Solo più chiaramente potenza di hash affittata da uno dei soliti piccoli sostenitori.
Qualcosa da tenere a mente è che il mining di blocchi che segnalano BIP110 tramite DATUM su OCEAN comporta praticamente nessun rischio per il miner fino al punto di fork al blocco 961632. Il costo è trascurabile, poiché sei praticamente garantito di recuperare i costi di affitto, ecc.
È fantastico che esista la possibilità di farlo, e non lo vorrei in nessun altro modo... ma è solo qualcosa da tenere a mente quando si valuta il segnale di tali blocchi nel grande schema delle cose da una prospettiva rischio-rendimento, soldi sul tavolo.
“Ma Jason! I minatori non hanno alcun incentivo a segnalare fino all'ultimo minuto!”
Non vedo nemmeno prove che suggeriscano che questo possa essere il caso. Soggettivamente, non sono d'accordo con la premessa, poiché non è nel migliore interesse di un pool minerario destabilizzare la rete in questo modo. Parte del motivo per cui ci sono segnalazioni anticipate e periodi di lock-in è per aiutare a coordinare gli aggiornamenti in modo fluido. Aspettare fino all'ultimo minuto annulla completamente quel beneficio. Non vedo alcuna giustificazione convincente o vantaggio nel farlo.
Continuando su questo, come parte della mia configurazione di monitoraggio dei nodi personali, monitoro specificamente nodi noti per appartenere a varie entità, come altri pool minerari, exchange, grandi nodi lightning, commercianti, ecc. Una supermaggioranza di questi è monitorata con esplicita autorizzazione e conferma/coordinamento.
FATTO VELOCE: Tutti i principali pool minerari che monitoro stanno attualmente eseguendo qualche variante di Bitcoin Core v30 o v31 (eccetto OCEAN).
Espandendo su questo, la maggior parte [dei pool minerari] ha aggiornato i propri nodi dalla proliferazione del rilascio di BIP110, anche dal rilascio di Knots 29.3. Inoltre, è noto che molti pool minerari eseguono versioni modificate del proprio software per nodi per facilitare vari requisiti della loro infrastruttura specifica. Tali modifiche dovrebbero essere portate a un client compatibile con BIP110, testate, valutate e implementate in anticipo. Attualmente non vedo prove che questo sia il caso.
Per quanto posso dire, i pool sono a conoscenza ma ignorano.
“Ma Jason! I miner non determinano il consenso! I nodi lo fanno! Altrimenti, annulleranno semplicemente i dimezzamenti!”
Questo è uno degli argomenti più divertenti e ridicoli 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, per usare un eufemismo.
Inasprire le regole (come BIP110): Soft fork, può essere imposto dai miner se decidono di farlo. Allentare le regole (come annullare un dimezzamento): Hard fork, non può essere imposto dai miner senza un consenso effettivo del 100% 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! Farai [inserisci ulteriore iperbole qui]!”
Questo sarebbe vero per un cambiamento di consenso che ha, beh, consenso. Mentre BIP110 ha fatto un valente sforzo per ottenere quel consenso, non ha ancora una maggioranza misurabile in quello che ora è indubbiamente l'undicesima ora. Non nei nodi, non nella potenza di hash, non nei livelli sociali (consensus.health ha una visualizzazione interessante dove mi troverai in mezzo).
Se in qualche modo BIP110 ottiene il 51%+ della potenza di hash della rete su/entro il blocco 961632... allora, va bene. È applicato, poiché come soft fork una maggioranza dei miner può applicarlo unilateralmente in assenza di un URSF completamente adottato (effettivamente un termine improprio, poiché questo sarebbe in un certo senso un hard fork).
“Ma Jason! Non può ottenere consenso avendo già consenso! Devi dargli una possibilità!”
Innanzitutto... no, non devo, anche se l'ho fatto. Secondo, è una proposta affrettata che non ha mai avuto il tempo di provare a ottenere un vero consenso. Sono passati 7 mesi dal rilascio del primo client BIP110. Mancano circa 3 settimane prima che inizi il segnale “obbligatorio” a partire da ora (meno dal momento in cui leggi questo). Il 90% del tempo disponibile è passato senza alcun cambiamento nel sentimento generale da parte di attori rilevanti. Se non ha ottenuto un'adozione sufficiente negli ultimi 7 mesi, è improbabile che lo faccia nelle prossime 3 settimane.
“Ma Jason! CSAM! CSAM! Pedofili! CSAM!”
Sarò il primo a dire che, anche io personalmente, ho esagerato il rischio qui all'inizio quando Core ha proposto la sua modifica OP_RETURN. Mi aspettavo personalmente che qualcosa di particolarmente eclatante colpisse la catena quasi immediatamente, e per quanto ne so, ciò non è ancora accaduto. Potrebbe ancora succedere? Sì, suppongo.
Ma considerando da una prospettiva tecnica, byte per byte, gli stessi dati arbitrari contigui possono provabilmente finire memorizzati nella catena attuale o nella catena BIP-110 senza troppi problemi... questo particolare argomento per il BIP-110 mi sembra piuttosto debole a questo punto.
Voglio il CSAM nella catena? Certo che no. Sono un pedofilo se non supporto il BIP110? Anche no.
Considerazioni Conclusive
Potrei continuare a parlare e parlare e parlare, ma mi fermerò qui. Ho sprecato abbastanza tempo su questo. Sono sicuro di aver fatto abbastanza per infastidire entrambe le parti del dibattito sul BIP110 a questo punto, poiché non adotto nessuna delle due posizioni. Sono sicuro che riceverò critiche da ogni angolo semplicemente per aver osato esprimere la mia opinione su di esso.
In generale, penso che sia stato sciocco affrontare un problema reale (il cambiamento predefinito di OP_RETURN in Bitcoin Core) con la proposta di soft fork basata sul manifesto anti-spam massimo... che provabilmente non può fermare lo spam, dati arbitrari, ecc. (Sì, lo so, i sostenitori diranno che non si tratta di spam... e faranno anche argomentazioni semantiche che affermano che ferma anche i dati... nessuna delle quali sembra essere corretta.)
Chiuderò con la concessione che potrei avere torto. Non sono Nostradamus e non posso prevedere con certezza al 100% l'esito. Posso solo basarmi su ciò che i dati mi dicono, e quindi do al successo di BIP110 meno del 5% di possibilità di avere successo... e considero questo generoso. Puoi prendere le mie opinioni su questo come meglio credi, ma ti consiglio vivamente di non sminuire i dati reali, rimanere vigile e fare ciò che è meglio per te e per il tuo reddito da mining. Non farti manipolare da nessuna delle due parti del dibattito e prendi le tue decisioni.
Ecco un link allo stesso documento collegato sopra per facilitare l'accesso.
Questo post Ocean Mining VP Jason Hughes: BIP-110 on Track to Fail as Miner Signaling Stays Below 1% è apparso per la prima volta su Bitcoin Magazine ed è scritto da Jason Hughes.
Fonte: BitcoinMagazine
