Una conversazione alquanto lunga quella di questa settimana nel Meeting avvenuto nella chat IRC #monero-research-lab il giorno 8 Gennaio 2020 alle ore 19:00.
Viene affrontata di nuovo l’idea esplorata nello scorso meeting riguardo la possibilità di criptare tutti tempi di blocco, inoltri commenti vari sulle nuove pubblicazioni Triptych e CSLAG e molto altro ancora.
Non posso mancare di fare le mie congratulazioni per la pubblicazione di Triptych (il link porta al sito della pubblicazione).
Puoi trovare la trascrizione del meeting in lingua originale al seguente link su Github.
Il prossimo Monero Research Meeting avverrà il 15 Gennaio 2020 sempre alle 19:00.
Registro della Chat del Meeting in Italiano
19:01 <sarang> SALVE a tutti
19:01 <almutasim> Ciao.
19:02 <binaryFate> ciao ciao
19:02 *Isthmus saluta
19:02 <sarang> Iniziamo con la ROUNDTABLE
19:03 <sarang> La pre-pubblicazione di Triptych, un nuovo modo per fabbricare firme ad anello collegabili che può essere esteso per utilizzi nelle transazioni, è nell’archivio IACR
19:03 <sarang> Link: eprint.iacr.org/2020/018
19:03 <sarang> CoinTelegraph ha appena rilasciato un articolo a riguardo (c’è da notare che ci sono degli errori nei dati inseriti all’interno, mi è stato detto che verranno sistemati)
19:04 <sarang> Ho in programma di effettuare un aggiornamento nei dati di tempo e grandezza, per tenere correttamente conto delle verifiche di gruppo e garantire un equo confronto
19:04 <sarang> Ho portato avanti il lavoro sulla versione multi-indice di Triptych, sistemando la correttezza in cambio di una separata relazione di dimostrazione, per la quale dobbiamo mostrare sia equivalente ad un’altra relazione di dimostrazione
19:05 <sarang> Questo permetterebbe migliori prestazioni
19:05 <sarang> Ho elaborato un MPC anche per questa versione di Triptych, che sarebbe utile per multisig
19:06 <sarang> E al momento sto lavorando su delle domande riguardo alla matematica di Omniring, che ho esposto agli autori di questo articolo accademico
19:07 <sarang> Altri vogliono condividere dei lavori di ricerca?
19:07 <almutasim> Al momento opportuno, potremmo annunciare un comunicato stampa per Triptych. Monero Outreach potrebbe supportarlo. Magari quando viene stabilito che sarà rilasciato.
19:07 <sarang> Per essere chiari, non ci sono garanzie che Triptych, o altre fabbricazioni conosciute al momento, siano adatte per essere utilizzate
19:07 <almutasim> Vero.
19:07 <Isthmus> Ho delle cose riguardanti il fingerprinting, e n3ptune ha appena completato un’analisi del network davvero interessante
19:07 <sarang> Ooh
19:08 <sarang> Isthmus: che genere di dati hai scoperto?
19:09 <Isthmus> Ah le mie note sul fingerprinting non sono nulla di nuovo o eccitante, solo un’idea che potrebbere rendere più intuitiva la presentazione dei dati. Quindi, cerco di pensare al fingerprinting del portafoglio in un modo abbastanza astratto – ogni transazione rimane in un determinato angolo di un ipercubo in uno spazio con molte dimensioni creato con un’euristica differente bla blaaa bla
19:09 <Isthmus> Quindi anche se lovoro con set di caratteristiche booleane nel backend, volevo un buon modo per mostrare i risultati
19:09 <Isthmus> Questo è il mio primo tentativo: https://mitchellpkt.github.io/fingerprint.html
19:10 <sarang> Cosa, non puoi rappresentare accuratamente visuali di ipercubi con tante dimensioni? =p
19:10 <Isthmus> llol
19:10 <Isthmus> Questo è in parte di @suraeNoether, aggiungendo output interpretabili dall’uomo al matching grafico
19:10 <sarang> Mi piace quest’idea di enumerazione
19:11 <Isthmus> grazie! è anche un modo semplice per condividere le informazioni in una tabella CSV a 2 colonne, e i ricercatori possono accoppiamenti substring nelle sezioni che sono rilevanti per una data analisi.
19:12 <suraeNoether> Ack scusatemi! Ci sono! Il cambiamento dell’orario mi ha scombussolato
19:13 <sarang> Isthmus: hai qualcosa da condividere riguardo all’analisi del network che hai menzionato?
19:13 <n3ptune> Re: le domande che sono state fatto lo scorso mese riguardo al tempo di propagazione dei blocchi, ho collezionato e analizzato i dati dei tempi di ricezione dei blocchi dai nostri nodi globali registrati durante gli scorsi 6 mesi
19:13 <sarang> Bene!
19:14 <sarang> Quali conclusioni hai tratto?
19:14 <n3ptune> Isthmus ha delle note riguardo l’interpretazione e io ne ho altre da scrivere ma puoi già dare una occhiata ai grafici qui https://github.com/noncesense-research-lab/archival_network/wiki/Block-propogation-time
19:14 <Isthmus> Questo è per rispondere ad una domanda che aveva fatto @moneromooo, giusto?
19:14 <Isthmus> Le unità sono grandezze in bytes e i timestamps sono in millisecondi, giusto?
19:15 <suraeNoether> questa era la mia domanda ^
19:15 <n3ptune> abbiamo usato questo formula, dove NRT è Node Received Timestamp: prop_time_lower_bound(h) = MAX[NRT(h,1), NRT(h,2), NRT(h,3)] – MIN[NRT(h,1), NRT(h,2), NRT(h,3)]
19:15 <sarang> Quali sono gli indici che cambiano?
19:15 <sarang> Nodi differenti?
19:15 <sgp_> ciao
19:15 <n3ptune> sì, arriva fino a 3 ma ci sono 4 nodi totali
19:16 <sarang> capito
19:16 <suraeNoether> quindi il block prop time è attendibile ad almeno 0.1s. interessante.
19:16 <Isthmus> Oh lo spargimento nella heatmap è in altezza, da scuro=vecchio fino a chiaro=nuovo
19:17 <Isthmus> ^ la scala dei colori
19:18 <sarang> E quelle sono le differenze tra il timestamp segnalato dal miner e il tempo del nodo quando viene ricevuto?
19:19 <Isthmus> I timestamp segnalati dai miner non sono considerati da nessuna parte in questo studio
19:19 <Isthmus> Lo abbiamo fatto da un’altra parte
19:19 *Isthmus sta cercando su github
19:19 <suraeNoether> hm quindi cosa viene misurato come prop time?
19:19 <sarang> Quindi questi blocchi vengono solamente scambiati tra i tuoi nodi?
19:20 <sarang> Dove guardi i tempi locali di quando viene inviato e ricevuto?
19:20 <Snipa> ^ Stavo per chiederlo, in quanto il tempo di propagazione minimo sembra particolarmente basso, secondo la nostra esperienza 100 millisecondi è abbastanza basso per attraversare il globo.
19:20 <sarang> Oppure domanda migliore: come viene calcolato NRT
19:20 <n3ptune> è la differenza dei tempi tra i differenti nodi che ricevono gli stessi blocchi
19:20 <sarang> Ah, ok
19:20 <Isthmus> Sì, ma non passando tra i nostri nodi, ma passando attraverso.
19:20 <n3ptune> NRT è registrato dal tempo di sistema del nodo quando il blocco arriva
19:20 <sarang> Indipendentemente dal nodo da cui viene ricevuto
19:21 <sarang> (che sarebbe diverso)
19:21 <sarang> Vedere la differenza tra il tempo segnalato dal miner (il quale potrebbe essere inaccurato) e il tempo di ricezione interno sarebbe interessante
19:22 <suraeNoether> hmmmm
19:22 <endogenic> o/
19:22 <Isthmus> https://usercontent.irccloud-cdn.com/file/brPsQyeU/image.png
19:22 <Isthmus> @sarang solo per te
19:22 <sarang> Quindi quello che stiamo veramente guardando qui non è direttamente il tempo di propagazione, ma la variazione in uno strato di tempo di propagazione
19:22 <sarang> qui = il punto iniziale, non questo
19:23 <Snipa> Devo dare un’occhiata ai dati del registro della pool, in quanto potrei avere la possibilità di aggiungere dei dati se sei interessato. Abbiamo cominciato a registrare il tempo di quando il nodo di una pool trova un blocco, mettendo a confronto quando quel determinato blocco viene memorizzato nei nostri database, che vuol dire che è stato processato dal nodo locale, visto che saltiamo tutti i tempi di monerod nella pool stessa.
19:23 <suraeNoether> oooop
19:23 <suraeNoether> che figo
19:23 <sarang> Tempi molto alti
19:23 <Isthmus> @Snipe ottimo!
19:23 <Isthmus> “Quindi quello che stiamo veramente guardando qui non è direttamente il tempo di propagazione, ma la variazione in uno strato di tempo di propagazione” < puoi elaborare?
19:24 <suraeNoether> isthmus è il tempo che serve al blocco per propagarsi da uno dei tuoi nodi ad un altro; non il tempo che serve per propagarsi da un miner ad uno dei tuoi nodi
19:24 <sarang> Intendo che per i punti iniziali che hai mostrato, non puoi interpretare direttamente il tempo che serve al blocco per raggiungere il tuo nodo dopo che è stato minato
19:24 <sarang> suraeNoether: no
19:24 <suraeNoether> no?
19:24 <Isthmus> Sì, abbiamo deliberatamente tutte le ascisse “prop time lower bound” per questa ragione
19:25 <Isthmus> Inoltre, potremmo ipotizzare che c’è un vecchio computer in dial up da qualche parte in Nebraska con un tempo di propagazione di 4 minuti, ma questo non è utile
19:25 <sarang> suraeNoether: sta osservando la differenza in tempo di ricezione, per qualunque strada il blocco abbia preso per la propagazione totale
19:25 <Snipa> Hrm, in realtà, posso fornire un flusso di dati sulla propagazione globale dei nostri blocchi, in quanto ogni nodo ha un reporter locale a cui possiamo agganciarci
19:25 <Isthmus> @Snipa sì, per favore!
19:25 <suraeNoether> sarang anche questo è vero
19:25 <n3ptune> sarebbe fantastico poter lavorare con quei dati
19:25 <Isthmus> Propongo qualcosa che potrebbe essere sbagliato:
19:26 <Isthmus> è uno sciocco modo di pensare alla scienza dei dati –
19:26 <Snipa> Contattami più tardi e possiamo discutere come posso farteli avere, ed esaminare i formati dei dati.
19:26 <Isthmus> Cavolo, devo scendere dal bus
19:26 <suraeNoether> isthmus: hai due sensori disponibili per rilevare il tempo di propagazione. me hai bisogno di 3 per triangolare, in modo simile a come si fa per rilevare l’epicentro dei terremoti
19:26 *Isthmus lascia un appunto, e tornerà tra 3 – 6 minuti
19:26 <sarang> Non lasciarci con questa suspense Isthmus!
19:26 <suraeNoether> sono col fiato sospeso
19:27 <suraeNoether> ho rovesciato il mio tè
19:27 <suraeNoether> sono così arrabbiato con isthmus che potrei darmi fuoco
19:27 <sarang> Rimani sul bus Isthmus… farà il giro e prima o poi tornerà alla tua fermata
19:27 <sarang> Nel frattempo, ci sono altri fatti interessanti su questo lavoro?
19:27 <sarang> Questi dati sono veramente interessanti
19:28 <suraeNoether> mentre aspettiamo Isthmus, vi dò il mio super-breve aggiornamento: dopo aver discusso con endo, il mio codice di abbinamento è decisamente più efficiente, semplice da capire e più facile effettuare debug; Lo aggiornerò più tardi nel pomeriggio. le mie due categorie di lavoro oggi sono fare una nuova revisione di CLSAG e lavorare sull’abbinamento
19:28 <n3ptune> da me è tutto per ora, ci aggiorneremo
19:28 <endogenic> il suo pseudo codice ora sta tutto in un singolo foglio di quaderno…
19:28 <suraeNoether> isthmus ed io tecnicamente abbiamo avuto una conversazione riguardo lo scrivere una proposta per criptare ed imporre tutti i tempo di blocco, ma non abbiamo ancora stabilito i dettagli
19:29 <sarang> Intendi usando i commitments in stile DLSAG?
19:29 <sarang> Ne abbiamo discusso precedentemente in un meeting
19:29 <suraeNoether> se ricordo bene durante l’ultimo meeting. dopodiché io e isthmus abbiamo avuto una conversazione al telefono a riguardo. Ritengo che questo sia un grande miglioramento della privacy nel senso che va a coprire una fonte di non casualità negli enormi set di dati nei quali ad isthmus piace passare al setaccio.
19:30 <sarang> Se vuoi posso ricavare la grandezza e le implicazioni di tempo su questo
19:30 <suraeNoether> non sono convinto che questo valga l’aumento di grandezza delle transazioni, ma staremo a vedere cosa ne salterà fuori
19:30 <sarang> Potrebbe essere unito assieme alle bulletproof esistenti
19:30 <suraeNoether> ^ ah
19:30 <sarang> Già, la grandezza non è un problema qua, grazie alla scala logaritmica
19:30 <suraeNoether> sì, e i tempi per la verifica sono veloci quanto le palle di un ghepardo
19:31 <suraeNoether> perdonatemi, questo è un meeting pubblico, dovrei essere meno volgare. per favore accettate le mie scuse.
19:31 <sarang> Giusto… c’è una crescita lineare nel tempo di verifica, ma è ridotta leggermente con i benefici di multiexp
19:31 <sarang> CoinTelegraph ha aggiornato l’articolo it.cointelegraph.com/news/moneros-triptych-research-could-vastly-improve-its-anonymity
19:31 <sarang> Grazie all’autore per averlo sistema così velocemente
19:33 <almutasim> Un comunicato stampa potrebbe ricevere più copertura, quando e se si vorrà.
19:33 <sarang> suraeNoether: una nota interessante, grazie a come funzionano le bulletproof, per molte transazioni non ci sarebbe nessun aumento di grandezza oltre allo spazio occupato dai dati di commitment
19:33 <suraeNoether> buon per cointelegraph
19:33 <sarang> (al contrario di una più ridotta rappresentazione in testo in chiaro)
19:34 <suraeNoether> sarang: un simile approccio potrebbe includere il testo cifrato di un messaggio?
19:34 <suraeNoether> ad esempio moneroMail
19:34 <Isthmus> Scusatemi, qualcuno si è messo a litigare con l’autista del bus poco prima della mia fermata
19:34 <sarang> Non proprio… c’è dello spazio libero di riserva nelle bulletproofs che potrebbe contenere qualcosa come 1-2 dimostrazioni di elementi dei dati arbitrari, controllando la casualità (Devo controllare i dettagli)
19:34 <Isthmus> Uff San Francisco
19:35 <sarang> Bentornato Isthmus
19:35 <Isthmus> Ok fatemi scarabocchiare delle cose, 1 secondo
19:35 <Isthmus> n3ptune: vuoi condividere il padding?
19:35 <Isthmus> Nei blocchi
19:35 <n3ptune> va bene
19:35 <suraeNoether> sarang quindi abbastanza per uno scambio di chiavi ma probabilmente non sufficiente per un testo cifrato?
19:36 <sarang> Beh, sei limitato dallo spazio
19:36 <n3ptune> C’è una ragione conosciuta per avere il padding tag nullo in tx_extra?
19:36 <sarang> Non ricordo se Poelstra e amici hanno trovato 32 o 64 bytes di spazio
19:36 <sarang> n3ptune: bella domanda per moneromooo e altri.
good question for moneromooo et al.
19:39 <sarang> Mentre aspettiamo l’aggiornamento di Isthmus, altre cose interessanti da condividere?
19:39 <sarang> Oppure COSE DA FARE, secondo il programma?
19:40 <suraeNoether> voglio fornire dei commenti finali su clsag ma è molto improbabile che lo riesca a finire oggi
19:40 <suraeNoether> cerco di farlo per questa settimana
19:40 <Isthmus> Rieccomi
19:41 <sarang> Le mie sono presentare CLSAG (dopo la revisione), sperando di riuscire a capire quel problema che avevo trovato con Omniring ed inviarlo agli autori, lavorare su alcuni aggiornamenti sulla crittografia ellittica per una prima bozza del codice, e sistemare le faccende per la pre-pubblicazione tramite MR sul sito di monero.
19:41 <sarang> Isthmus: per favore continua
19:42 <sarang> (oh, e aggiornare con maggior chiarezza i dati del rendimento nella pre-pubblicazione di Triptych)
19:42 <Isthmus> https://usercontent.irccloud-cdn.com/file/gAM3VbDV/1578508953.JPG
19:43 <sarang> cos’è questo
19:44 <Isthmus> Quindi immaginiamo di avere 100 nodi archivio di n3ptune/NRL in funzione
19:46 <Isthmus> Se abbiamo solamente 2 nodi, la nostra propagazione sarà molto variabile, dipendente dalla topologia (assumiamo che i nodi archivio non si connettono tra di loro), e t_second – t_first
19:46 <Isthmus> Nel momento che aggiungiamo un terzo nodo, c’è la possibilità che si verifichi un aumento del prop time misurato (visto che può “ascoltare” prima o dopo) ma non può diminuire il prop time dato che è max-min
19:48 <Isthmus> Quando arriveremo a 100 nodi, la variabilità si smusserà e arriveremo ad avere il prop time giusto (dal miner ai nodi globali con internet a banda larga)
19:48 <sarang> Il prop time non dipendeva dal max/min tra tutti i nodi? Quindi il terzo nodo potrebbe fuoriuscire dall'”involucro” degli altri due ed influenzare i valori?
19:48 <Isthmus> Sì, è questo il punto
19:49 <sarang> OK, devo aver male interpretato
19:49 <sarang> Oh, non può diminuire
19:49 <Isthmus> In maniera molto ampia, quando aggiungiamo il terzo nodo, la probabilità è di 2/3 che sia fuori N=2 e che aumenti il prop time, e 1/3 di probabilità che sia tra i primi 2 nodi.
19:49 <sarang> lascia stare
19:49 <Isthmus> Scusa, mi sto spiegando male perchè mi sono appena reso conto di questo nel bus
19:50 <almutasim> Max-Min è una metrica molto delicata, sensibile alle anomalie
19:51 <Isthmus> Hmm fammici riflettere
19:51 <Isthmus> Tralasciamolo per ora
19:51 <Snipa> Come ricavi il tempo di quando è stato ricevuto il blocco? monerod modificato/usando i registri oppure facendo polling nell’interfaccia RPC per determinare quando è veramente sostenibile aggiungerlo al box?
19:52 <Isthmus> Questa è una domanda per n3ptune, si dedicano loro a tutti i DevOps e al data engineering. Quando ci ho messo le mani io era già in un database SQL
19:52 <n3ptune> monerod modificato
19:52 <Snipa> Per ricevere in P2P quindi?
19:53 <Isthmus> Quindi per ogni altezza abbiamo una epsilon (linea verde) che è una nostra approssimazione di più nodi del prop time globale
19:53 <n3ptune> puoi anche utilizzare monerod –block-notify, se lo punti ad uno shell script che scrive il timestamp
19:54 <Snipa> –block-notify aspetta che il blocco sia committed, per questo lo chiedo, perchè i nodi che non usano NVMe hanno in genere tempi di propagazione più lenti, per il fatto che devi aspettare che i dischi scrivano.
19:54 <n3ptune> Questo mi piace di più perchè puoi usare il daemon stock. ma non lo usiamo ancora
19:54 <sarang> Ok, quindi usiamo i parametri max-min, assumendo che il posizionamento dei nodi all’interno della topologia del network sia relativamente omogeneo
19:54 <Isthmus> Sì, sebbene dopo @almutasim sto considerando dei parametri meno sensibili
19:54 <Isthmus> inserisci tutte quelle epsilon in un istogramma, ed è quello sulla destra.
19:54 <sarang> Le anomalie sono i nodi vicini al miner e quelli lontani, topologicamente
19:55 <Isthmus> Uhm, le anomalie potrebbero anche essere solamente a 2 salti di distanza ma uno dei salti è lento
19:55 <n3ptune> Ricezione P2P: no succede quando lo aggiunge alla blockchain, dopo che viene determinato se è un blocco alternativo oppure no. funziona così perchè avevamo l’obiettivo di raccogliere i dati sui blocchi alternativi. la patch per il daemon è condivisa qui https://github.com/neptuneresearch/monerod-archive
19:55 <Isthmus> @sarang quindi dipende se la definizione della distanza topografica è solamente il grafico di connessione p2p oppure se prende anche in considerazione il tempo tra i vertici
19:56 <sarang> giusto
19:57 <Isthmus> E il gruppo di epsilon visualizzato nel grafico è praticamente quello che ha condiviso n3ptune prima tranne che al posto di “max-min con 4 nodi” è “approssimazione asintotica del prop time globale”
19:57 <Isthmus> ^stop parlando dell’asse delle x dell’istogramma
19:57 <n3ptune> –block-notify aspetta che il blocco sia committed >> oh quindi credo che il metodo utilizzato nella blockchain::add_new_block() accada prima di block-notify. ma sì non succede immediatamente alla ricezione
19:59 <sarang> Visto che abbiamo quasi finito il tempo, altre informazioni da condividere prima di aggiornarci (la discussione può comunque continuare) così da concludere il registro per questo meeting?
19:59 <Isthmus> Ah sì
20:00 <Isthmus> una veloce nota, tx_padding viene spesso usato, ma non ne capisco il perchè
20:00 <Isthmus> Nel grafico di dispersione di prima, le fasce verticali da sinistra a destra sono blocchi vuoti seguiti da N=1,2,3… transazioni
20:00 <sarang> Questa è una domanda per qualcuno come moneromoo
20:01 <Isthmus> Certamente c’è una variabilità nella larghezza laterale delle fasce verticali a causa della differenza di dimensione delle transazioni, ma i blocchi con sole transazioni coinbase sono strani
20:01 <Isthmus> https://xmrchain.net/tx/acdf8eac41a7a76fd899e09640db34023abff66b3ae2c9ea86e49f19c0720af4
20:01 <Snipa> Non proprio, i blocchi di sole transazioni coinbase sono abbastanza comuni a causa di come sono progettate le pool
20:01 <Isthmus> No no, la variabilità della grandezza nelle transazioni di sole coinbase era strana
20:01 <Isthmus> A quanto pare alcuni (adesso fingerprinted) miner stanno utilizzando molti null padding, controlla il tx_extra per questa coinbase
20:01 <sarang> ah wow
20:02 <Snipa> Non particolarmente sorprendente.
20:02 <Isthmus> A me sembra rigonfio
20:02 <Isthmus> Un mucchio di blocchi sprecano spazio con nulls nel tx_extra
20:02 <Snipa> Forse, può anche essere qualcosa richiesto da una pool.
20:02 <Snipa> Essendo che è il padding dei blocchi che usiamo per avere spazio nonce aggiuntivo
20:03 <Isthmus> “Essendo che è il padding dei blocchi che usiamo per avere spazio nonce aggiuntivo.” il nonce del blocco o il nonce della transazione? Questo è il padding nella transazione coinbase
20:03 <Snipa> Oh scusa, transazione, colpa mia.
20:04 <Isthmus> Sai perchè alcuni minatori usano il padding e altri no?
20:04 *Isthmus è molto ingenuo riguardo gli aspetti pratici del mining
20:04 <Snipa> Fammi dare un’occhiata al mio codice per la decodifica che ho scritto proprio per quello.
20:05 <Isthmus> Io confronterei:
20:05 <Isthmus> https://xmrchain.net/search?value=1988283
20:05 <Isthmus> e
20:05 <Isthmus> https://xmrchain.net/search?value=1985042
20:05 <Isthmus> Visto che sembrano esattamente uguali eccetto per il diverso padding
20:05 *Isthmus chiude il filo del discorso
20:06 <Isthmus> Comunque, grazie per aver ascoltato i miei vaneggiamenti e aver spostato quando viene effettuato il meeting
20:07 <Snipa> Per un rapido riferimento: La CB transazione del blocco contiene una sezione “supplemento”, la quale è richiesta da Monerod come spazio aggiuntivo dove poter scrivere dati arbitrari. Questi dati sono usati dalle implementazioni della pool per implementare le nonces per pool nonchè qualsiasi dato nonce personalizzato usato da tecniche più avanzate.
20:08 <Isthmus> “spazio aggiuntivo dove poter scrivere dei dati arbitrari”
20:08 *Isthmus rabbrividisce
20:08 <Snipa> Puoi usare questi dati in una varietà di modi differenti, soprattutto con conoscenza di come sono progettate le pool, in quanto le due principali implementazioni delle pool usano quando spazio in modo simile, ma hanno grandezze differenti sulla base di diversi addon di supporto.
20:09 <Isthmus> Ooh, come vengono usati al momento?
20:09 <Snipa> Puoi anche indentificare quali istanze di pool stanno inviando i blocchi, in quanto le pool utilizzano degli identificatori in dei determinati bytes.
20:09 <Isthmus> (Non ho alcuna conoscenza di progettazione delle pool)
20:09 <Snipa> https://github.com/Snipa22/nodejs-pool/blob/master/lib/coins/xmr.js#L115
20:09 <suraeNoether> Per chi di voi è interessato ad aiutare per Monero Kon 2020 a Berlino, c’è un meeting che sta avvenendo ora per potenziali volontari. Questo è relativo alla ricerca, ma a parte questo è offtopic, quindi ve lo lascio qui.
20:10 <Snipa> ^ questa è l’implementazione che trovi nelle pool che supporta le estensioni XNP, che ho scritto qualche tempo fa.
20:10 <sarang> Sì, possiamo ufficialmente aggiornare il meeting, ma continuate pure la conversazione
20:10 <sarang> Grazie a tutti per aver partecipato
