Nel paragrafo sotto puoi trovare la traduzione in italiano del Meeting avvenuto sul canale IRC #Monero-research-lab in data 30 Dicembre 2019 alle 18:00 (Ora Italiana) con partecipanti i vari membri del team di ricerca di Monero.
Il prossimo meeting verrà tenuto Mercoledì 8 Gennaio alle 19:00 ora italiana.
ATTENZIONE: Ho fatto la traduzione cercando di mantenere, al meglio delle mie capacità, il significato della frase senza sconvolgerla troppo, essendo la prima volta che provo ad effettuare una traduzione di questo tipo il contenuto potrebbe non essere perfetto. (Premendo qui puoi trovare il registro del meeting in lingua originale)
Per qualunque consiglio o commento non esitate a contattarmi!
Registro della Chat del Meeting in Italiano
18:01 <suraeNoether> Benvenuti a tutti all’ultimo MRL Research Meeting dell’anno
18:02 <suraeNoether> Se ci avessi pensato prima, avrei preparato qualcosa di più profondo, purtroppo mi è venuto in mente solamente ora ;P
18:02 <suraeNoether> iniziamo con 1) SALUTI
18:02 <endogenic> o/
18:02 <sarang> ciao
18:02 <suraeNoether> bene e tu, oh non male
18:03 <suraeNoether> isthmus era qui qualche momento fa
18:03 <Isthmus> più o meno. Brutto mal di testa. Guardo lo schermo ad intermittenza.
18:03 <sarang> yikes
18:03 <endogenic> 🙁
18:04 <Isthmus> C’est la vie.
18:04 <suraeNoether> okay, bene; vai via isthmus e torna quando sei in salute
18:04 <suraeNoether> ci farai ammalare tutti col mal di testa
18:04 <endogenic> ora ho mal di testa
18:04 <Isthmus> Visto, dovremmo bandire i mal di testa a livello di protocollo
18:04 <Isthmus> Non solo nel portafoglio.
18:04 <suraeNoether> no il tuo mal di testa ora
18:05 <suraeNoether> prima di passare a 2) ROUNDTABLE vorrei sollevare un problema amministrativo
18:05 <suraeNoether> vorrei proporre di considerare un cambio di quando effettuare i meeting; abbiamo selezionato i lunedì alle 17 UTC praticamente a caso circa 2 anni fa
18:05 <sarang> ?
18:05 <sarang> quale potrebbe essere un buon momento
18:05 <suraeNoether> al giorno d’oggi non tutti i nostri partecipanti possono facilmente riunirsi a quell’ora, spesso ci siamo solamente Sarang ed io
18:06 <suraeNoether> quindi visto che io non ho vincoli di tempo, volevo sentire cosa ne pensavate, ad esempio isthmus che spesso ha altri meeting attorno alla stessa ora
18:06 <suraeNoether> e avere una discussione generale per trovare il momento adatto per gli incontri
18:06 <Isthmus> grazie
18:06 <suraeNoether> lo so che è noioso, ma è da più di un mese che mi gira per la mente
18:06 <sarang> suggerimenti per un momento migliore?
18:07 <endogenic> an hr fro // (incomprensibile)
18:07 <Isthmus> Di solito sono nel fuso orario del Pacifico, quindi il lunedì alle 17:00 UTC è presto ed esattamente quando sono sommerso di lavoro in ufficio
18:07 <endogenic> e adesso?
18:07 <Isthmus> Sono qui solo perchè ci sono le feste ed è EST (Eastern Standard Time)
18:07 <sarang> Che ne dite delle 18:00 o 19:00 UTC?
18:07 <endogenic> Mercoledì?
18:07 <Isthmus> Mercoledì alle 18 o 19 sarebbe meglio
18:07 <Isthmus> In questo caso penso che potrei segnarlo nel mio calendario riservato al lavoro come un evento ricorrente
18:07 <sarang> Possiamo sempre provare una nuova data/ora e vedere come va
18:08 <suraeNoether> sono d’accordo con mercoledì alle 18-19 UTC provvisoriamente per il primo mese dell’anno, giusto per vedere se può funzionare
18:08 <sarang> Farò in modo che la barra degli argomenti mostri la data/ora dell’incontro
18:08 <Isthmus> +1
18:08 <sarang> OK, Mercoledì alle 18:00 UTC
18:08 <Isthmus> Grazie! Mi aiuterà molto.
18:08 <suraeNoether> okay, bene
18:09 <suraeNoether> passiamo a 2) ROUNDTABLE
18:09 <suraeNoether> visto che la scorsa settimana era festa, magari potremmo discutere non solo di “questo è quello che ho fatto la settimana scorsa” ma anche “questo è quello che ho fatto quest’anno, anche se potrebbe diventare una particolarmente lunga lista.
18:09 <suraeNoether> magari senza andare troppo nello specifico
18:09 <suraeNoether> sarang o isthmus, volete iniziare voi? no aspetta, isthmus: vai via e cura il tuo mal di testa
18:10 <sarang> La scorsa settimana ho finito di scrivere una bozza MPC per la versione aggregata di RCT3
18:10 <sarang> Al momento sono bloccato con del materiale di Omniring che mi sta lasciando perplesso
18:10 <sarang> Inoltre, la mia richiesta per fondi è aperta: https://ccs.getmonero.org/proposals/sarang-2020-q1.html
18:10 <suraeNoether> raccomando fortemente che tutti facciano una donazione alla richiesta di fondi di sarang
18:11 <suraeNoether> beh, intendo, con un importo a seconda delle proprie possibilità
18:11 <sarang> e sto aspettando con impazienza commenti da suraeNoether sulla pre-pubblicazione aggiornata di CLSAG o di Triptych
18:11 <suraeNoether> quello che volevo dire è: questa richiesta è di grande valore, se stavate considerando di donare ad un CCS ma non sapete quale, quello di sarang è di alta priorità, secondo la mia opinione
18:11 <sarang> Ringrazio moltissimo per tutto il supporto
18:12 <sarang> Non vedo l’ora di vedere cosa riserverà il prossimo anno la ricerca, particolarmente riguardante i protocolli per le transazioni
18:13 <Isthmus> Sì, qual è il nostro tema di ricerca per il 2020
18:14 <Isthmus> Io ovviamente continuerò a rompere le scatole riguardo la fuga di informazioni
18:14 <sarang> sì per favore
18:14 <sarang> “2020: nessuna conoscenza, cuore infinito”?
18:15 <Isthmus> Ring size 2020?
18:15 <Isthmus> Oh aspetta, non è un numero primo
18:15 <sarang> Le persone penseranno che c’è una ragione tecnica per avere un numero primo come Ring Size :/
18:16 <sarang> Una cosa interessante è che per certi protocolli non puoi avere un numero primo come grandezza!
18:18 <suraeNoether> per qualunque approccio basato su albero merkle, devi utilizzare potenze di 2
18:19 <suraeNoether> per il 2020, un paio di cose che mi piacerebbero sono una specificazione formale del protocollo per i protocolli basati su triptych, utilizzando ristretto, seguendo la via in dettaglio dell’aritmetica ottimizzata, integrazione di tor, etc
18:22 <suraeNoether> il fatto è, penso che eventualmente dovremo abbandonare le impostazioni DL per ragioni di efficienza e sicurezza; per un fattore di efficienza potrebbe essere necessario utilizzare accoppiamenti multilineari, ma dipende comunque dalla sicurezza computazionale. D’altra parte, cambiare in altre ipotesi di durezza computazionali come RLWE, che si pensa rimangano sicure anche con l’avvento dei computer quantistici, è un’area di ricerca attuale. Quell’ipotesi ha anche
18:22 <suraeNoether> un profilo molto differente utilizzandola nelle Criptovalute perchè la grandezza delle chiavi e la velocità di verifica delle firme sono molto diverse in questo nuovo contesto.
18:23 <suraeNoether> Il mio contributo all’argomento di discussione per la scorsa settimana: ho avuto dei sintomi di influenza dopo Natale, quindi tutto quello che ho potuto fare è stato star seduto senza far nulla ed essere scontroso, quindi ho … controllato e corretto triptych e clsag
18:23 <suraeNoether> (la cosa migliore quando si è scontrosi è correggere gli articoli accademici???)
18:23 <sarang> Non vedo l’ora di leggere le tue note
18:23 <suraeNoether> dovrebbero essere pronte prima delle 3 di oggi pomeriggio
18:23 <sarang> Urrà!
18:24 <sarang> è un miracolo di Festivus!
18:24 <suraeNoether> Mi tornerò a dedicare alle simulazioni letteralmente il prossimo anno
18:24 <suraeNoether> Un miracolo di Festivus richiede il saper usare il palo di alluminio nelle tue rimostranze
18:25 <endogenic> non capisco questo riferimento ma lo cercherò su Google
18:25 <sarang> Continuerò a buttarmi a capofitto nelle cose riguardanti Omniring questa settimana, per determinare se il problema in cui sono incappato può presentare un problema con una qualunque delle dimostrazioni
18:26 <Isthmus> Il mio contributo per il roundtable è ancora in fare di preparazione, ma dovrebbe essere pronto a breve
18:26 <suraeNoether> dopo essermi ripreso dall’influenza, o qualunque cosa avevo, devo ammettere: mi sento come un milione di dollari e sono super eccitato all’idea di finire triptych oggi
18:26 <suraeNoether> endo, isthmus e sarang possono attestare tutti il numero di volte che ogni anno mi sento come un milione di dollari
18:26 <Isthmus> :- )
18:27 <endogenic> 1/4 volte all’anno fino adesso
18:27 <suraeNoether> quando la luna ti colpisce l’occhio come una grande fetta di pizza, questo è N=1
18:28 <Isthmus> Ah, eccoci qua
18:28 <endogenic> sono dispiaciuto per i traduttori che si occupano di trascrivere questi registri
18:29 *Isthmus ridacchia
18:29 <Isthmus> https://usercontent.irccloud-cdn.com/file/ntGPLKhz/image.png
18:29 <Isthmus> ^ non-coinbase TXNs dell’ultimo periodo
18:29 <suraeNoether> oh mio dio
18:30 <Isthmus> Ho zoommato sui valori bassi, ci sono degli assurdi valori anomali
18:30 <Isthmus> https://usercontent.irccloud-cdn.com/file/Uz5uJDlS/image.png
18:30 <suraeNoether> Mi piace l’idea di avere un tempo di sblocco regolabile per gli smart contracts. …
18:30 <endogenic> per i miei ragazzi
18:30 <suraeNoether> hey, sarang: pensi che la tecnica di range proof che scatta ad un determinato blocco in DLSAG potrebbe essere cambiata per nascondere tutti i tempi di sblocco?
18:30 <Isthmus> https://usercontent.irccloud-cdn.com/file/xS32XCWP/image.png
18:30 <Isthmus> ^ Tutti questi sono degli ultimi mesi
18:31 <Isthmus> Ad esclusione di quelli enormi
18:31 <sarang> Penso che potrebbe
18:31 <Isthmus> Apparentemente unlock_time supporta sia i marchi temporali unix che il numero del blocco… Ci sono 13 transazioni che hanno utilizzato il tempo UNIX e gli altri sono basati sul numero del blocco
18:32 <sarang> i marchi temporali unix? non lo sapevo
18:32 <Isthmus> C’è una transazione con output che verranno sbloccati nell’anno 46.000, lol
18:32 <suraeNoether> hmmmm
18:32 <suraeNoether> Non riesco a pensare a nessuno ragione valida per permettere l’utilizzo di marchi temporali unix
18:33 <endogenic> chi utilizza i tempi di sblocco al momento
18:33 <suraeNoether> i costi per nascondere tutti i tempi di sblocco sono una nuova range proof, ma può essere unito assieme ai bulletproofs… e un tempo di sblocco variabile è preferibile per gli smart contract…
18:33 <Isthmus> @endogenic apparentemente 8 diversi tipi di persone, e tutti lo usano in modo differente
18:33 <Isthmus> xD
18:33 <endogenic> lol
18:33 <suraeNoether> la connessione DLSAG è forte con questo
18:33 <endogenic> surae è uno di loro
18:34 <Isthmus> https://xmrchain.net/search?value=2c2762d8817ea4d1cb667752698f2ff7597a051d433043776945669043d908b5
18:34 <Isthmus> “unlock_time”: 1420722551128,
18:34 <suraeNoether> sono veramente terribile con monero
18:34 <sarang> Non solo unito, ma aggregato per beneficiare della larghezza logaritmica
18:34 <suraeNoether> qualcuno riesce a trovare una buona ragione per continuare a tenere il tempo di sblocco con testo non codificato?
18:34 <endogenic> verificabilità
18:34 <sarang> Inoltre è anche più piccolo
18:35 <endogenic> perdonatemi Dei di monero
18:35 <sarang> Altrimenti devi inserirlo all’interno di un commitment
18:35 <Isthmus> Qual è il motivo di usare il tempo di sblocco
18:35 <Isthmus> Domanda seria.
18:35 <Isthmus> Devo capire in quali modi viene utilizzato per trovare il modo in cui dobbiamo gestirlo
18:35 <moneromooo> Una ragione per utilizzare i marchi temporali UNIX è per non dipendere da un potenziale cambio del tempo per trovare i blocchi successivi.
18:35 <endogenic> un periodo di maturazione (non recuperabile); bloccare i fondi in modo forzato
18:35 <sarang> fai una giusta osservazione
18:35 <Isthmus> Se il tempo di sblocco è in testo non codificato, come è possibile fare in modo che i fondi siano effettivamente bloccati
18:36 <Isthmus> Erm
18:36 <Isthmus> *se è criptato, come viene applicato
18:36 <sarang> C’è una range proof inclusa, fa vedere che il numero del blocco corrente supera il periodo di fermo a cui era vincolato
18:36 <moneromooo> Non si può facilmente usare un attacco a forza bruta?
18:36 <sarang> L’obiettivo è ridurre l’euristica attorno alla spesa prevista
18:37 <suraeNoether> endogenic: la verificabilità in questo caso sarebbe lo stesso modello di sicurezza/rischio utilizzato nelle nostre transazioni confidenziali, quindi questo non ridurrebbe la nostra verificabilità… dicendo, per la gente tra il pubblico, il saldo di monero è garantito dalla proprietà di non forgiabilità delle nostre firme; se qualcuno è in grado di imbrogliare il sistema di monero con le nostre transazioni confidenziali, possono anche forgiare firme con
18:37 <suraeNoether> curve ellittiche, che rompe molte più cose oltre che monero.
18:37 <Isthmus> Mi aggrego alla domanda fatta da mooo
18:37 <sarang> moneromooo: il tempo di sblocco è in un Pedersen commitment
18:37 <endogenic> suraeNoether: era una battuta 🙂
18:37 <sarang> che si nasconde perfettamente
18:38 <suraeNoether> isthmus: i modelli iniziali di scambi tra diverse blockchain esigono che i tempi di sblocco decorrano per usare SPV
18:38 <endogenic> ma come fa un destinatario a verificare che il tempo prima dello sblocco non sia ridicolo solamente attraverso l’uso del range proof?
18:38 <suraeNoether> endogenic: è una battuta, ma come succede a fare una battuta matematica in una classe di matematica, è sempre seguita da una discussione seria sul perchè è divertente. #vitadaprofessoredimatematica
18:38 <sarang> Dev’essere comunicato al destinatario endogenic
18:38 <endogenic> suraeNoether: mi hai superato
18:38 <sarang> La range proof è inclusa al momento della spesa
18:38 <sarang> non nel momento che viene generato l’output
18:38 <Isthmus> Ohhhh
18:38 <moneromooo> Quindi un verificatore riceve un sì/no, e ad un certo punto il no diventa un sì.
18:39 <suraeNoether> moneromooo: non può essere forzato, proprio per le osservazioni fatte da sarang riguardo il modo perfetto in cui viene mascherato
18:39 <moneromooo> Giusto ?
18:39 <sarang> non esattamente
18:39 <endogenic> sarang: fuori dalla banda?
18:39 <sarang> Quando generi l’output, viene specificato un commitment con tempo di sblocco, e una versione con testo non codificato viene trasferita al destinatario, criptata o fuori banda.
18:39 <moneromooo> Intendo, dalla prospettiva di un verificatore, dovranno rifiutare una spesa oppure dare l’ok.
18:39 <Isthmus> -_-
18:39 <sarang> Quando l’output è speso, una range proof viene generata utilizzando un particolare tempo ritardato rispetto al commitment, per far vedere che il tempo di sblocco è stato superato relativamente al numero di blocco corrente.
18:39 <moneromooo> Quando smettono di ricevere una verifica fallita, non ci sono altre ragioni (al momento) oltre che quello, no?
18:40 <sarang> Ad essere sincero, il metodo non è molto intuitivo fino a che non lo scrivi
18:40 <moneromooo> Oh. Capisco. Grazie.
18:40 <sarang> ma è incluso nella pre-pubblicazione di DLSAG
18:40 <moneromooo> er.
18:40 <suraeNoether> moneromooo: non saresti in grado di fabbricare una range proof su [0, …, N] con tempo di ritardo -3
18:40 <suraeNoether> non sarebbe una dimostrazione valida
18:40 <suraeNoether> la parte complicata è capire come la fabbricazione DLSAG cattura il ritardo
18:40 <moneromooo> Quindi includi il l’hash del blocco al blocco corrente?
18:40 <suraeNoether> aspetta che lo cerco
18:40 <sarang> Ma moneromooo, è importante notare che non puoi semplicemente forzare la verifica ogni blocco fino a che non riesce
18:41 <suraeNoether> per i membri del pubblico: https://eprint.iacr.org/2019/595
18:41 <sarang> Il firmatario genera la dimostrazione una volta, al tempo di spesa
18:41 <moneromooo> OK, questo mi basta. Grazie.
18:41 <sarang> C’è della sottigliezza nello scegliere il ritardo e simili, per ridurre l’euristica, ma il metodo ha senso
18:41 <suraeNoether> nella parte bassa di pagina 10, colonna a sinistra
18:42 <sarang> Il costo per fare questo sarebbe sostituire i tempi di sblocco in testo non codificato con dei commitments, ed estendere le bulletproofs per includere la dimostrazione di blocco
18:42 <suraeNoether> questo sarebbe il promo passo verso smart contracts “privati” che dipendono dai tempi di sblocco scelti dai programmatori
18:42 <suraeNoether> in un certo senso è più basilare di DLSAG, quasi un componente indipendente usato in DLSAG. mi sarebbe dovuto venire in mente che prima di questo era praticamente una propria fabbricazione
18:42 <sarang> è un componente indipendente… puoi fare DLSAG con lo scatto ad un determinato blocco in testo non codificato
18:43 <suraeNoether> annuisce
18:43 <sarang> ma è probabilmente una brutta idea farlo
18:46 <endogenic> ragazzi devo lasciarvi
18:46 <suraeNoether> ciò significa che ha definizioni di sicurezza indipendenti. in questo caso, le definizioni dipendono da blockchain generate in modo antagonistico, bla bla bla
18:46 <Isthmus> Penso che sarebbe utile fare il cambio in commitments con tempi di sblocco… Ora un antagonista può partizionare (/impronta) la blockchain in ~20 diverse pozze di anonimato basate solo sul tempo di sblocco.
18:46 <Isthmus> Quando l’avevo pianificato mi aspettavo qualche Easter egg, non informazioni euristiche che sanguinano ovunque
18:46 *Isthmus saluta endo
18:46 <endogenic> continua così che vai alla grande Isthmus 🤜🤛
18:48 <suraeNoether> okay, qualcun’altro vuole mostrare qualche ricerca o pensieri?
18:49 <moneromooo> Se state pensando di far diventare il tempo di sblocco un commitment, questo potrebbe essere un buon momento per vedere i possibili cambiamenti semantici per il tempo di sblocco per semplificare cose future come gli atomic swaps etc.
18:49 <Isthmus> ^ ooooh
18:49 <sarang> In che modo?
18:49 <suraeNoether> sì, per favore continua
18:49 <Isthmus> Ok, la mia testa si sta figurativamente dividendo a metà, quindi me ne vado. Grazie a tutti.
18:49 <Isthmus> gg
18:50 <moneromooo> Pensando ai requisiti che conosci per gli atomic swaps ecc, quale sarebbe la migliore semantica da abbinare.
18:50 <sarang> Ci vediamo Isthmus; cerca di stare meglio
18:50 <sarang> anche per te endogenic, ci vediamo
18:50 <moneromooo> In particolare sto pensando al fatto che la semantica unlock_time per monero non corrisponde a quella di bitcoin, e bitcoin viene usato per cose più stravaganti come gli atomic swaps.
18:50 <sarang> Ah ok
18:51 <Isthmus> Ah prima che vado, un grande ringraziamento a @n3ptune che ha curato il set di dati
18:51 <Isthmus> Ok ciao!
18:52 <suraeNoether> moneromooo: sì, dobbiamo identificare degli esempi specifici di comuni atomic swaps con bitcoin e come i tempi di sblocco nascosti su monero si comporteranno con i tempi di sblocco non nascosti di bitcoin…
18:52 <suraeNoether> sicuramente
18:53 <suraeNoether> isthm ed io faremo una videochiamata a riguardo appena si sente meglio. Prenderò degli appunti e rilasceremo una pubblicazione.
18:53 <suraeNoether> va bene, stiamo per arrivare alla fine dell’ora
18:53 <sarang> Quindi, la lista di cose da fare?
18:53 <suraeNoether> giusto
18:54 <suraeNoether> La mia: mandare i miei commenti a sarang per triptych e clsag, consultarmi con isthm riguardo il mascheramento dei tempi di sblocco… che magari dovremmo farlo tramite IRC piuttosto che in videochiamata… fare una donazione alla richiesta di fondi di sarang…
18:55 <sarang> Io continuerò quel problema con Omniring, sistemerò CLSAG/Triptych basandomi sulla revisione di suraeNoether, e alcune cose riguardanti le librerie di codice e MPC
18:56 <suraeNoether> okay, il mio cane sta incrociando le gambe, devo portarla fuori. >.< qualcuno ha delle ultime domande
18:56 <sarang> No
18:56 <sarang> Credo che ci possiamo aggiornare allora
