Buonasera a tutti, volevo linkare il nuovo gruppo di telegram italiano per coloro che sono interessati o conoscono già il progetto BitNautic. Penso che unirsi sia utile per capire come sta lavorando il team e quali sono i loro progetti, perchè credo che in futuro sentiremo parlare di questi ragazzi che seguo ormai da 6 mesi e penso che davvero possano fare la differenza.  Questo è il link al gruppo: https://t.me/joinchat/FH8F4g1FneSHXnXhhcbRvwEsiste qualcosa sul forum, tanto per capire indicativamente di cosa si tratta ... |
|
|
|
direi che la misura di un airdrop di xlm... è in xlm
Sicuro, ma quando scrivono quelle frasi li riguardo “il più grande airdrop di sempre”, è abbastanza evidente che stanno parlando di dollari, anche solo per comparare le varie crypto tra loro. Sbaglio o state parlando dello stesso airdrop avvenuto in tempi differenti? Ossia, stellar è stato airdroppato (secondo me per recuperare associazioni address BTC/email e infatti non l'avrei mai fatto ...) e ora stiamo parlando sempre della stessa moneta? Secondo me l'airdrop e' lo stesso ... |
|
|
|
...
Torniamo al fatto che comunque ti devi fidare di quello che QUALCUNO dice (garantisce) quando scrive i dati in BC. E’ questo il punto che non mi convince…..
Secondo me ti devi fidare dei produttori. Il secondo livello potrebbe fare da oracolo distribuito e a cascata tutti gli altri. Il consumatore avrà il diritto di visitare l'azienda produttrice e verificare che sia in linea con le dichiarazioni. Potranno "evadere" una percentuale ma non fare +100% di quanto il terreno produce con le condizioni meteo dell'anno di riferimento. Un mix tra AI (intelligenza artificiale - che io chiamerei "analisi dei dati storici") e BC possono migliorare e risolvere il problema. Sempre meglio un dato immodificabile in bc che un'etichetta che se la fotocopiano non hai modo di verificare di essere l'unico a possederla. |
|
|
|
...
- il produttore avrebbe creato 200 e sarebbe contento essendo riuscito a venderne 100 in nero
...
Le 100 in nero non avrebbero input. Chi le compra sa che sono in nero. Se ne assume la responsabilità. Il produttore con x kg di mele acquistati fa y bottiglie, un certo margine può esserci ma non potrà produrre 2y (o, se lo farà, avrà diluito facendo scendere il valore potenziale del prodotto. Tutto tracciato). La BC serve per dare fiducia ad ogni passaggio dove nessuno dei due (fornitore e cliente (anche non finale)) ha tutto l'interesse a dichiarare ora, quantità e prodotto in modo corretto. Quello che capita dall'ingresso all'uscita di una organizzazione potrebbe essere affare interno e lo gestiscono come vogliono ... Io continuo a vedere la BC utilizzabile e utile. |
|
|
|
Non è solo un problema di double spending, se la maggior parte dei nodi si mette d'accordo può modificare il contenuto di tutta la bc come farebbero con database relazionale.
...
Possono modificare il contenuto della catena vincente ma non il contenuto del fork che sarebbe una prova della manipolazione. Troppo rischioso e inutile ai fini della tracciabilità. Non ho approfondito. Generano un tempo casuale per ogni miner ma non ho capito come fanno ad evitare che un utente non si crei migliaia (o milioni) di indirizzi per partecipare alla lotteria (ripeto: non ho approfondito!). Magari hanno trovato l'algoritmo perfetto ma il problema POW/POS rimane un bel problema e non ho ancora trovato una soluzione che non genera altre problematiche. |
|
|
|
Initiative Q è un nuovo sistema di pagamento creato da un team di ex impiegati di Paypal. Il sistema utilizza la propria valuta, la Q. È possibile ottenere, al momento gratuitamente, le Qs solo su invito (l'importo diminuisce man mano che le persone si iscrivono, quindi è meglio farlo in anticipo). Ecco il link del mio invito: https://initiativeq.comLa registrazione è totalmente gratuita e richiede solo il tuo nome e un indirizzo email. Non c'è niente da perdere! Ma se questo sistema di pagamento dovesse diventare un metodo di pagamento leader mondiale, le tue Q potrebbero valere una fortuna. MI sono registrato e vedo: Hi ******, welcome to the future of payments!
For the next 14 days you can invite and verify up to 5 friends and secure 3,425 for each. Your invite will allow them to also reserve Qs early, and help expand the Q network.
Alessandro needs to log into their account and verify your registration. However, you can start inviting others right now!
Please remind Alessandro to verify your registration so you could verify others.
?
Current task
Invite people you know personally and secure an additional 17,127 Quindi Alessandro sei tu? Se io do il mio invito gli iscritti vedono il mio nome inserito nella registrazione? Tu vedi il mio nome? |
|
|
|
Mi sa che è per addetti ai lavori. Chiede autenticazione. |
|
|
|
Forse valeva 1,309 USD? Ma tra "." e "," fanno sempre casino ... mi sembrano comunque tanti ma non ricordo e non trovo info in merito. Articolo da mettere in spazzatura. dal precedente link dal Sole: La prima quotazione di bitcoin risale all’ottobre 2009: allora con un dollaro si potevano comprare 1.309,03 bitcoin, il che significa che la criptovaluta valeva neanche un decimo di pence Si vede che a repubblica non possono usare gli inversi ... sarà una linea editoriale? |
|
|
|
Forse valeva 1,309 USD? Ma tra "." e "," fanno sempre casino ... mi sembrano comunque tanti ma non ricordo e non trovo info in merito. Articolo da mettere in spazzatura. |
|
|
|
Ho visto l'articolo. Molto critico, alla fine riconosce solo la "notarizzazione" dei dati ai fini di non manomissione. Pur mantenendo una certa privacy sui processi si potrebbero estrarre le informazioni utili ai consumatori e inserirle in una chain pubblica insieme all'hash dei dettagli, le forze dell'ordine dovrebbero poter avere accesso ai file che generano gli hash per svolgere i controlli. Per quanto riguarda il problema del punto 1 Supponiamo adesso che dalla lavorazione del 21/05 rimanga una percentuale di prodotto invenduto. Tale prodotto verrà conservato ed etichettato il giorno successivo con il lotto AB220518 cioè lo stesso lotto della lavorazione odierna. In questo caso il consumatore deve sapere che l'azienda ha comprato ogni giorno 100 litri e ne ha prodotti 80 un giorno e 120 l'altro. Non mi sembra un segreto industriale e indicherebbe una probabile frode ... Rimane il fatto che ad un eventuale controllo le forze dell'ordine troverebbero la sera precedente 20 kg di formaggio invenduto non inserito in BC. Per barare si espone a controlli anche a posteriori. Conviene? E, comunque, senza BC cosa gli impedirebbe di barare? Potrebbe nascondere le tracce ancora meglio fingendo di aver comprato il giorno prima 80 litri e 120 il giorno successivo ... magari alterando anche i dati precedenti se non ci sono stati controlli. Ripeto: non ho le idee chiare ma ritengo verosimile che si possa trovare un algoritmo funzionante. Credo ci vogliano degli oracoli che potrebbero essere le forze dell'ordine o qualcosa che ancora mi sfugge. A naso mi sembra comunque meno peggio una BC di un db classico centralizzato. |
|
|
|
...
1. Chi mi garantisce che non vi sia doublespend? Ovvero che non vi siano due entry uguali a quella che sto analizzando? Come faccia a sapere che il we sulla mia ananas non sia riciclato da qualche altro ananas?
...
Vediamo se riesco a spiegare come potrebbe funzionare una chain per certificare la filiera. Immaginiamo un contadino che ha 10 alberi di mele che forniscono 10.000 Kg di mele/anno. 10 produttori di succo di mele acquistano 1000 kg a testa, tutto in BC e ovviamente non dovranno esserci piu' di 10.000 kg venduti altrimenti il contadino mente (tutte le transazioni in uscita saranno pubbliche). Ci saranno delle variabili dipendenti dall'anno ma se inserisce 100.000 kg sicuramente bara. I 500 litri di succo (ipotizzo 2kg per 1lt) prodotti dai 1000 kg acquistati dal produttore di succo saranno "figli" di quei 1000 kg, se ne smerciano 1000 litri significa che hanno acquistato altrove le mele. Se vendono al consumatore difficilmente due clienti scopriranno che la loro bottiglia è un clone ma se acquistano dei costruttori di cestini natalizi potranno verificare che solo loro hanno "speso" quei litri per creare i loro 500 cesti. Se un altro cestinaio (come si chiamano?) spende (utilizza per i suoi cesti) le stesse bottiglie di un altro ci sarà un output utilizzato due volte. Rimodulando: Se il cliente finale scarica (*) il cesto (o la bottiglia o la cassetta di mele) utilizza l'output del passaggio precedente e il clone (eventuale) si accorgerà della truffa quando cercherà di scaricare l'output. Non e' detto sia il secondo il truffato ma sicuramente il venditore ha fatto double spending e si vedrà rifiutato l'acquisto salvo ricevere anche una denuncia (segnalazione in BC?) dell'accaduto. Riassumendo: Potrebbe anche funzionare, l'unico che potrebbe truffare (tanto) sarebbe il primo livello ma dichiarando una produzione eccessiva e la truffa sarebbe facilmente identificabile (e poi, comunque, dovrebbe pagarci le tasse in quanto sono dati di dominio pubblico). EDIT: (*) scarica significa che inserisce in BC l'acquisto del prodotto singolo identificato da un codice unico e dichiara che lo consuma quindi non potrà comparire come input di un altro prodotto più elaborato. EDIT2: fiscalmente sarebbe l'unico che dovrebbe pagarci l'IVA . EDIT3: i prodotti utilizzati per produrre le mele (pesticidi, carburante per trattori, lavoro, affitti vari ...) potrebbero essere anche loro frutto di una BC che certifica quali trattamenti hanno subito le mele e, magari, anche come sono stati trattati i braccianti che le hanno colte.
Qui ciascuno si certifica da solo quello che fa. Allora se nessuno controlla, tanto vale fare un database condiviso.
Tutti si fidano, tutti inseriscono il proprio dato ed il cliente finale controlla.
Che c’entra la blockchain? RR Credo siamo ampiamente OT, il thread è su BAKKT. comunque sono d'accordo con RR: neanche io capisco cosa serve una blochain a certificare dati, se poi bisogna fidarsi di chi i dati li inserisce. HO letto un articolo ben scritto in proposito: https://medium.com/@thebluster01/problematiche-pratiche-legate-allintroduzione-della-blockchain-in-un-progetto-di-rintracciabilità-4e77eb350d4f?fbclid=IwAR1alsXb8GO9zneImQOiv0xsItwDY0DaQCMHdbAwO8Gq3NkeW1Qboz2sIFg Comunque ripeto, l'argomento è interessante, ma è fuori tema: se lo ritentete chiedete ad un admin di spostare i messaggi in un nuovo thread, anche per coinvolgere eventualmente chi sia interessato, ma non legga il thread su BAKKT. Non devo essermi spiegato ... Nessuno si fida di nessuno, nessuno inventa dati se non nella fase di creazione della materia prima che deve comunque arrivare da risorse dichiarate. Da dove capisci che tutti si devono fidare? La BC serve per evitare il double spending (vendere due volte la stessa bottiglia di succo o analogo). |
|
|
|
...
Credo siamo ampiamente OT, il thread è su BAKKT.
...
Comunque ripeto, l'argomento è interessante, ma è fuori tema: se lo ritentete chiedete ad un admin di spostare i messaggi in un nuovo thread, anche per coinvolgere eventualmente chi sia interessato, ma non legga il thread su BAKKT.
https://bitcointalk.org/index.php?topic=5060977 |
|
|
|
in una bc privata dove i nodi
1)sono a numero chiuso
2)sono ad accesso chiuso
3)si conoscono fra loro
4)si fidano tra loro
Per ingannare gli utenti è sufficiente che siano disonesti il 50%+1 dei nodi presenti
In un bc pubblica basata su mining il fatto che il 50%+1 dei nodi siano disonesti è condizione necessaria ma non sufficiente per portare a compimento una truffa.
Perchè l'inganno funzioni occorre anche che abbiano più del 50% della potenza di calcolo di tutta la rete.
La differenza sta tutta qui.
L'altra grossa differenza è che la criptovaluta sottostante alla bc pubblica crea un incentivo diretto che stimola i nodi ad essere onesti. Se io truffo gli utenti, faccio perdere valore e credibilità alla "moneta" che muove il sistema e quindi creo un danno anche a me stesso che vengo ricompensato in quella moneta.
Le bc private avranno quindi sempre un tasso di immutabilità dei dati infinitamente inferiore a quello delle bc pubbliche.
Il futuro della tracciabilità della filiera secondo me sarà con sidechain private che si appoggiano alla sicurezza e inviolabilità della rete bitcoin.
Il doble spending nella certificazione di filiera non lo vedo come un problema. Potrebbe rimanere fregato l'utente finale che si accorge di aver bevuto un succo fantasma a causa di un fork che ne faceva sparire gli input che l'hanno generato (mele, lavoro spremitura, bottiglia di vetro, tappo, trasporto ecc. ecc.) Inoltre, nelle private, se uso POW devo avere solo 51% della POW anche se sono da solo ad essere contrario. ... NB: avere uno snap in BC bitcoin credo sia utile. Ogni mese/settimana/giorno (DeltaT) inserisci in BC bitcoin una tx con hash del blocco n_ersimo della tua chain, se fanno double spending lo devono fare entro DeltaT altrimenti ciccia a meno di reverce su funziona di hash utilizzata. |
|
|
|
Alla fine, quando pensi all'utilizzo della BC, puoi trovarti in un punto nel quale decidi che i partecipanti devono essere noti e riconosciuti.
In una scuola/azienda per dare accesso a servizi e informazioni hai bisogno che gli utenti siano stabiliti, che i voti siano riservati, che le annotazioni siano private, che non possano "scambiarsi" voti o azioni, farlo con un contratto ethereum puo' essere costoso (ogni info hai gas da spendere), rischioso (se craccano l'algoritmo di codifica il file crittato è pubblico), potresti fare una chain privata ethereum risolvendo in parte.
Corda mi sembra orientato alla soluzione di problemi interessanti che non possono essere come BTC (fungibili e pseudoanonimi).
Inoltre x.509 mi ha sempre attirato insieme a LDAP e gestione domini, risorse aziendali e informazioni di qualunque tipo (gerarchiche).
Mi chiedo solo cosa c'azzecchi il java ... ma vediamo il protocollo che è quello che conta.
lo ripropongo in modo ancor piu' chiaro: ... 3.2 Identity and the permissioning service
Unlike Bitcoin and Ethereum, Corda is designed for semi-private networks in
which admission requires obtaining an identity signed by a root authority. This
assumption is pervasive – the flow API provides messaging in terms of identities,
with routing and delivery to underlying nodes being handled automatically.
There is no global broadcast at any point.
La root authority sarà in possesso dell'amministratore che inserisce utenti a seguito di verifica. Mi sa che nella catena dei certificati la root authority sia la normalità. Se ti fidi della root accetti quello che firma. Se si tratta di un indirizzo mail del domino dell'azienda ti fidi solo di chi detiene il potere per decidere chi riceverà l'email. Idem per DNS e, presumo, anche per token di una azienda. EDIT: in una rete corda libera mi immagino che chiunque possa farsi la sua root authority e chi vuole acceta le info firmate. Ad esempio per invio mail. |
|
|
|
... non so se ha senso ma è come dire che il sistema bancario ha i costi di transazione ma non le ricompense dei blocchi
...
Mi viene in mente che il sistema bancario, attraverso la riserva frazionaria e il conio, non solo ha l'equivalente delle ricompense ma al posto di decrescere quelle lievitano nel tempo facendo esplodere la quantità di fiat in circolazione. Bisogna dire che le banche possono solo imprestare la valuta generata con la riserva frazionaria e non metterla in sacoccia ma con gli interessi ci marciano (rischiano l'insolvenza del credito). |
|
|
|
...
1. Chi mi garantisce che non vi sia doublespend? Ovvero che non vi siano due entry uguali a quella che sto analizzando? Come faccia a sapere che il we sulla mia ananas non sia riciclato da qualche altro ananas?
...
Vediamo se riesco a spiegare come potrebbe funzionare una chain per certificare la filiera. Immaginiamo un contadino che ha 10 alberi di mele che forniscono 10.000 Kg di mele/anno. 10 produttori di succo di mele acquistano 1000 kg a testa, tutto in BC e ovviamente non dovranno esserci piu' di 10.000 kg venduti altrimenti il contadino mente (tutte le transazioni in uscita saranno pubbliche). Ci saranno delle variabili dipendenti dall'anno ma se inserisce 100.000 kg sicuramente bara. I 500 litri di succo (ipotizzo 2kg per 1lt) prodotti dai 1000 kg acquistati dal produttore di succo saranno "figli" di quei 1000 kg, se ne smerciano 1000 litri significa che hanno acquistato altrove le mele. Se vendono al consumatore difficilmente due clienti scopriranno che la loro bottiglia è un clone ma se acquistano dei costruttori di cestini natalizi potranno verificare che solo loro hanno "speso" quei litri per creare i loro 500 cesti. Se un altro cestinaio (come si chiamano?) spende (utilizza per i suoi cesti) le stesse bottiglie di un altro ci sarà un output utilizzato due volte. Rimodulando: Se il cliente finale scarica (*) il cesto (o la bottiglia o la cassetta di mele) utilizza l'output del passaggio precedente e il clone (eventuale) si accorgerà della truffa quando cercherà di scaricare l'output. Non e' detto sia il secondo il truffato ma sicuramente il venditore ha fatto double spending e si vedrà rifiutato l'acquisto salvo ricevere anche una denuncia (segnalazione in BC?) dell'accaduto. Riassumendo: Potrebbe anche funzionare, l'unico che potrebbe truffare (tanto) sarebbe il primo livello ma dichiarando una produzione eccessiva e la truffa sarebbe facilmente identificabile (e poi, comunque, dovrebbe pagarci le tasse in quanto sono dati di dominio pubblico). EDIT: (*) scarica significa che inserisce in BC l'acquisto del prodotto singolo identificato da un codice unico e dichiara che lo consuma quindi non potrà comparire come input di un altro prodotto più elaborato. EDIT2: fiscalmente sarebbe l'unico che dovrebbe pagarci l'IVA . EDIT3: i prodotti utilizzati per produrre le mele (pesticidi, carburante per trattori, lavoro, affitti vari ...) potrebbero essere anche loro frutto di una BC che certifica quali trattamenti hanno subito le mele e, magari, anche come sono stati trattati i braccianti che le hanno colte. |
|
|
|
... 3.2 Identity and the permissioning service
Unlike Bitcoin and Ethereum, Corda is designed for semi-private networks in
which admission requires obtaining an identity signed by a root authority. This
assumption is pervasive – the flow API provides messaging in terms of identities,
with routing and delivery to underlying nodes being handled automatically.
There is no global broadcast at any point.
solo questo mi demotiva fortemente alla lettura del resto... Alla fine, quando pensi all'utilizzo della BC, puoi trovarti in un punto nel quale decidi che i partecipanti devono essere noti e riconosciuti. In una scuola/azienda per dare accesso a servizi e informazioni hai bisogno che gli utenti siano stabiliti, che i voti siano riservati, che le annotazioni siano private, che non possano "scambiarsi" voti o azioni, farlo con un contratto ethereum puo' essere costoso (ogni info hai gas da spendere), rischioso (se craccano l'algoritmo di codifica il file crittato è pubblico), potresti fare una chain privata ethereum risolvendo in parte. Corda mi sembra orientato alla soluzione di problemi interessanti che non possono essere come BTC (fungibili e pseudoanonimi). Inoltre x.509 mi ha sempre attirato insieme a LDAP e gestione domini, risorse aziendali e informazioni di qualunque tipo (gerarchiche). Mi chiedo solo cosa c'azzecchi il java ... ma vediamo il protocollo che è quello che conta. |
|
|
|
Ammetto di essere in difficoltà. Non ho chiaro il funzionamento ma ho visto che ci sono 2 whitepaper, uno tecnico e uno informativo. Mai notata una cosa simile. Ammetto di essere stato piacevolmente coinvolto dal fatto che usano LaTex, x.509 ma capire come funziona esattamente .... Con i certificati, che siano soggetti al 51% in una parte delle transazioni potrebbe anche non essere un grosso problema se intendi dare fiducia ai partecipanti (non è il massimo ma non e' detto sia un problema). NB: devo ancora riflettere parecchio sulla questione e quindi ben vengano le considerazioni. |
|
|
|
|
Show Posts
