https://coinb.in/#verifyVedi le TX di input, gli indirizzi di output e la quantità esatta, oltre al fatto che verifichi se è già firmata o no come transazione. Grazie. Non vedo però 2 cose: 1) un controllo per vedere se l'input è già stato speso o no 2) se inserisco questa transazione che ho creato su Oraclize 01000000018e30d350f09f9c80d0b4c9b058fd58fb015cc6095e7ab1efed10b96e7a80e97a01000 000b500483045022100cf0a7582bd0995cef277d16633d757c4fccb3e9fbcf68e995f851788f896 98f5022021aa2bca14665d6d2745ca473262d96fa535fe582f70a3fed4e7f6a4c9c84d14014c695 221031ad3887e76f50116fec30ab6fc9b871d9e605db639cf3b0b23aa5b67863312b8210342f233 44876c627901d9d79674b1e127e224e9aace83239cfdc4d97fc17f5ff82103f8d58684c90844469 9d85f62bc2884f6104c6bc001ed19fa8902c6f171760b9953aeffffffff01803801000000000019 76a914a88324a4ac0d1f3c0d41f77bbee915fe68ba336488ac00000000 non vedo la condizione sotto la quale deve essere spedita --> "[WolframAlpha] 'time in Rom' > 12:00". |
|
|
|
Esiste un servizio che permetta di visualizzare in maniera chiara tutti gli elementi fondamentali di una transazione prima che questa venga inviata alla rete? Finora ho trovato questo, ma è una decodifica secondo me ancora non alla portata di tutti. La situazione a cui sto pensando: se io ad esempio creo una transazione un po' complessa, con nlocktime modificato, oppure con una condizione tipo contratto su Oraclize, e volessi farla vedere alla controparte perchè controlli che sia tutto in ordine, come faccio? Almeno nelle transazioni già inviate in rete su blockchain.info si vedono chiaramente indirizzi di input, di output, e quantità inviate. |
|
|
|
I contratti creati su Oraclize sono visibili solo da chi li ha creati? Osservo che in "check status" si vede solo se le condizioni sono verificate o no, ma non si vedono le altre caratteristiche della transazione: indirizzi di input, indirizzi di output, quantità inviate. Stavo pensando a un caso di questo tipo: voglio acquistare una quantità importante di btc da un mio venditore di fiducia del forum. Data l'entità della transazione (mettiamo 4000 euro) pago tramite bonifico. Il venditore ovviamente aspetterà gli 1-2 giorni canonici necessari per l'accredito prima di inviarmi i btc. Io mi fido del fatto che sia una persona onesta (e che quindi non mi voglia imbrogliare) ma non posso/voglio fidarmi di qualcosa che nessun essere umano può garantire: del fatto che tra 2 giorni sarà ancora vivo/in grado (fisicamente/mentalmente) di adempiere alla sua promessa. So che può sembrare un caso molto improbabile, ma quando si tratta con un singolo individuo piuttosto che con un gruppo di persone, se succede qualcosa a questo chi può rispondere per lui? Soprattutto quando si parla di cifre così elevate, le precauzioni non sono mai troppe. Allora le soluzioni sarebbero: 1) il venditore immediatamente mi invia una transazione firmata con nlocktime e sequence number modificati, in modo che qualunque cosa succeda tra 5 giorni io entrerò sicuramente in possesso dei miei btc; fino ad allora lui potrà spendere gli input della transazione che mi ha inviato (di fatto annullandola) se non riceve in tempo i soldi del mio bonifico 2) creare un contratto su Oraclize che faccia la stessa cosa Nel caso 1) vedo due problemi: intervenire manualmente su una transazione non è semplicissimo per il venditore (è facile commettere errori) e soprattutto non è facile neanche per me cliente che ricevo la transazione verificare subito che sia tutto in ordine (non è banale leggere una raw transaction); inoltre a tempo debito devo trasmettere io la transazione alla rete (anche se questa è la parte più facile) Nel caso 2) per il venditore c'è il vantaggio della costruzione guidata e quindi meno soggetta a errori della transazione, per me cliente c'è il vantaggio che è più facile leggere questo tipo di contratto e che non devo trasmettere io la transazione alla rete. Mi manca però da capire in che modo il venditore può mostrarmi questa transazione dal momento che "fisicamente" non possiede lui il file. In sostanza ripeto la domanda: è possibile per il venditore creare un contratto e renderlo visibile a un proprio cliente nella forma chiara con cui compare nel sito? EDIT: Ho provato a creare un contratto su Oraclize mettendomi nella parte del venditore. Contract ID dfaf064d71c994d6a8b556baab9754f6 Se inserisco questo ID visualizzo correttamente la condizione "[WolframAlpha] 'time in Rom' > 12:00" che al momento è falsa. Se cambio idea posso rimuovere i fondi dall'indirizzo multisig fornitomi da Oraclize andando in "Tools -> Funds Recovery". Durante la procedura di creazione del contratto è possibile visualizzare e copiare la transazione in formato hex, quindi è possibile eventualmente farla vedere a un'altra persona. L'unico modo che ho trovato però per visualizzarne i dettagli è inserire la transazione qui. In pratica non mi sembra che sia possibile visualizzare in formato "più chiaro" possibile l'intero contratto su Oraclize, ma solo la sua condizione. EDIT2: alle 12:06 è stato fatto un controllo e la domanda [WolframAlpha] 'time in Rom' dà correttamente come risposta "12:06:11 pm CEST | Wednesday, April 1, 2015" ma risulta ancora falsa la condizione espressa dalla disuguaglianza 'time in Rom > 12:00' (no match). Ho fatto qualche errore?  EDIT3: ogni volta che accedo al sito o cambio pagina mi esce questo fastidioso messaggio Ci si sta autenticando sul sito “www.oraclize.it” con nome utente “oraclized” ma il sito non richiede autenticazione.
Potrebbe trattarsi di un tentativo di truffa.
“www.oraclize.it” è il sito che si desidera visitare?Mi pare che succeda solo quando ci arrivo tramite il link del primo post. EDIT4: al momento (ore 18:00) il sito è down, vediamo se il nuovo contratto che ho fatto (bitcoin block height > 350250) funziona in ogni caso. Ha funzionato!!  |
|
|
|
Servizio veloce ed efficiente, acquistato 1 btc senza nessun problema. |
|
|
|
Vendo alcuni dvd rari di Miyazaki e alcuni dvd Disney. Ai prezzi bisogna aggiungere le spese di spedizione. Sconto del 25% per chi paga in btc. Escrow ben accetto. dvd Miyazakidvd Disney |
|
|
|
Mi sfugge il vantaggio di una transazione con LockTime > 0. Se comunque, una volta preparata la transazione, non é possibile trasmetterla alla rete con troppo anticipo perchè verrebbe presto "dimenticata", non sarebbe allora la stessa cosa preparare una transazione standard con LockTime = 0, firmarla, tenerla sul proprio pc e inviarla poi alla rete quando si ritiene più opportuno?
beh, se però si elimina la chiave privata dell'indirizzo del mittente, si ottiene una quantità di bitcoin "bloccati" che è possibile spendere solo dopo una certa data. Ciò può essere utile a vari scopi. É proprio questo il punto che ancora non mi è chiaro, cioè i diversi meccanismi che si possono utilizzare per firmare le transazioni o subordinare una transazione a un'altra, i meccanismi che stanno insomma alla base dei contratti. Ho trovato questo esempio (che penso sia più o meno la spiegazione di come funziona GreenAddress) Example 1: Providing a deposit
Imagine that you open an account on a website (eg, a forum or wiki) and wish to establish your trustworthiness with the operators, but you don't have any pre-existing reputation to leverage. One solution is to buy trust by paying the website some money. But if at some point you close your account, you'd probably like that money back. You may not trust the site enough to give them a deposit that they are tempted to spend. Another risk is that the site might just disappear one day.
The goal is to prove that you made a sacrifice of some kind so the site knows you're not a spambot, but you don't want them to be able to spend the money. And if the operators disappear, you'd eventually like the coins back without needing anything from them.
We can solve this problem with a contract:
The user and website send each other a newly-generated public key.
The user creates transaction Tx1 (the payment) putting 10 BTC into an output that requires both user and website to sign, but does not broadcast it. They use the key from the previous step for the site.
User sends the hash of Tx1 to the website.
The website creates a transaction Tx2 (the contract). Tx2 spends Tx1 and pays it back to the user via the address he provided in the first step. Note that Tx1 requires two signatures, so this transaction can't be complete. nLockTime is set to some date in the future (eg, six months). The sequence number on the input is set to zero.
Finally, the incomplete (half-signed) transaction is sent back to the user. The user checks that the contract is as expected - that the coins will eventually come back to him - but, unless things are changed, only after six months. Because the sequence number is zero, the contract can be amended in future if both parties agree. The script in the input isn't finished though; there are only zeros where the user's signature should be. He fixes that by signing the contract and putting the new signature in the appropriate spot.
The user broadcasts Tx1, then broadcasts Tx2.
At this stage, the 10 BTC are in a state where neither the user nor the website can spend them independently. After six months, the contract will complete and the user will get the coins back, even if the website disappears.
In questo caso il contratto ( che é la Tx2 che spende l'output della Tx1) è la transazione con nlocktime modificato e questa deve essere conservata dall'utente che può trasmetterla alla rete solo dopo sei mesi, se ho ben capito? L'output della Tx1 é bloccato per 6 mesi (a meno che le due parti non cambino entrambe idea prima e modifichino il contratto, cioé la Tx2). L'idea del nlocktime e del sequence number dovrebbe essere all'incirca: stabiliamo da quale momento in poi questi fondi saranno sbloccati, se cambiamo idea facciamo un altro contratto con il sequence number modificato; é comunque l'utente che deve ricordarsi di trasmettere al momento opportuno la transazione con il sequence number più alto dal momento che la rete non é in grado di stabilire se dato un contratto ne esiste una versione più aggiornata (a meno che tutte le versioni esistenti non siano inviate alla rete nello stesso momento, in tal caso la rete stessa sceglie quella con il sequence number più alto e scarta le altre versioni). |
|
|
|
Pensierino: sapete se e' già venuta in mente a qualcuno l'idea di inserire ad ogni nuova relase del client ufficiale una sorta di "chiodo" che analogamente a come funziona il genesis block impone il passaggio della catena in quel blocco ad una determinata altezza?
In questo modo si eviterebbe l'inconveniente di trovarsi la chain errata dopo tantissimo tempo.
Inoltre sarebbe interessante che la chain contenesse anche il codice c++ (mi pare ci sia) e tutte le sue patch (magari ci sono ...).
C'è stato un mandatory tra la versione 0.6 e la 0.7 se non ricordo male, ovvero intorno al blocco 180.000 e ce ne sarà un'altro pilotato quando si decideranno in maniera definitiva sull' aumento della grandezza delle TX. Riguardo la chain, a che pro ? FaSan Penso ti riferissi alle release notes della versione 0.6.3 Added a block checkpoint at block 185,333 to speed up initial blockchain download. Avrei una domanda: ho visto che nelle release notes della versione 0.9.0 si parla del concetto di "coins mature" Wallet:
Consider generated coins mature at 101 instead of 120 blocks
In che senso si considerano "mature" queste monete? |
|
|
|
(...)
Il tutto per minare dei blocchi in parallelo, far "crollare" la catena principale che porterebbe ad un crollo del prezzo e quindi renderebbe la "truffa" inutile comunque.
(...)
A qualcuno potrebbe interessare come giochetto, solo che sono ancora molto ignoranti e dalla parte dei BTC ci sono fior di CERVELLI pronti a prendere le contromisure. Sono d'accordo con picchio, se io ad esempio facessi parte del sistema bancario e mi accorgessi che le criptovalute rischiano di mettere seriamente in discussione i miei guadagni, un 60 - 100 milioni di euro per dimostrare a tutto il mondo la vulnerabiltà del bitcoin ce le li metterei senza troppi problemi. In tal caso non sarebbe affatto una "truffa" inutile, ma assolutamente conveniente dal punto di vista di chi la attua. Poi ci sarebbe anche da discutere sul termine "truffa": se io rubo 100 euro sono perseguibile legalmente, se rubo 1 bitcoin ( che non ha alcun valore "legale" se non sbaglio ) di cosa potrei essere accusato? Altro incentivo per tentare l'attacco del 51%. |
|
|
|
Grazie a tutti per le risposte! |
|
|
|
Provo a fare un esperimento. La transazione è questa:
0100000002e8bfdc8d6a7c318926dcf312be9f270a94765931d9562afc6c2d494b8386f0a325000 0008c4930460221008e481b288a958629715f9f4ce24ac95ca64a04885f757f44681bccd271ae0d 28022100dbe7494844f8fd2b85960a8bff7955c82b9f5a6dcabd83cecf5f13070d171d04014104e 4da05e963255705ed524278005893cb7b95cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b 0bb4fdf7aae9de1b46bbe301abdabd5d2412ebae3fe7cf04ffffffffa0193a457ca7b5aca27ba3a 5b8f3f57eab95ac530b0368d824922123740357ae330000008b483045022035e6c418fb045a5610 6ff4044c9db28027b624d302e09f186c53af08c63bac6c022100d073c28d2c0292460832fd71288 5f6e3e9d5208b5d70ded20e08e182763b918a014104e4da05e963255705ed524278005893cb7b95 cd32ce009d8f7c8e88f28bdc35a12985086f434cc01b0bb4fdf7aae9de1b46bbe301abdabd5d241 2ebae3fe7cf04ffff0fff01d41d0000000000001976a91492e7bae1123b7c58c954f4dfc32035a53fa6d8e788ac023f0500
anzichè ffffffff (che corrisponde al "fondoscala", cioè a infinito) ho messo ffff0fff, cioè un numero a caso. Ovviamente ciò va fatto prima di firmare la transazione.
Ora mi dice "The transaction is not final", dovrebbe poter essere possibile inviare la transazione solo dopo il blocco 343810, vediamo se funziona...
Ho provato anch'io a effettuare una transazione simile con nlocktime modificato, mi esce sempre il messaggio "The transaction is not final" e poi non succede nulla. Guardando in rete ho trovato: The release notes for Bitcoin Core (Satoshi client) version 0.9.0 states
"Accept nLockTime transactions that finalize in the next block"quindi comunque bisogna aspettare per inviare la transazione che questa diventi "finale", in pratica non é possibile inviarla in anticipo. |
|
|
|
le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce
Succede perchè il client ha la TX precedente nella mempool. Basta riavviarlo  FaSan Quindi il controllo viene fatto dal client solo in locale, la mempool è una memoria locale relativa a un singolo nodo? In tal caso la funzione di questa patch é solo evitare il riavvio del client. |
|
|
|
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce Non basta copiare qui le transazioni firmate e poi premere il tasto "Fornisci transazione"? solo se anche il client di blockchaininfo fosse patchato Quindi se ho ben capito il client bitcoin-core, che sia installato sul mio pc o su blockchainfo o da qualsiasi altra parte, ha tra le altre cose il compito di controllare, prima di immettere in rete una transazione, di non averne immessa già un'altra prima che utilizzi gli stessi input. La mia domanda é: il controllo é "locale" o su tutta la rete? Mi spiego: il mio client controlla tutte le transazioni che ha giá immesso in rete prima di inviare una nuova, ma come può sapere se più o meno contemporaneamente tu dal tuo client stai cercando di spendere gli stessi input? E una volta che due transazioni relative agli stessi input sono state immesse in qualche modo nella rete tutti i client e soprattutto tutti i client dei miner le devono inserire nella lista delle transazioni non confermate? Oppure é necessario avere almeno due client patchati: quello da cui immettere la transazione in rete e quello di un miner che deve provare a convalidare un blocco? |
|
|
|
Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch le transazioni le puoi creare e firmare con core originale sì ma poi come le immetti nel network? se provi a fare il push della seconda tx con gli stessi input della prima core non patchato te lo impedisce Non basta copiare qui le transazioni firmate e poi premere il tasto "Fornisci transazione"? |
|
|
|
Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Quando dici che i tentativi di double spend sono stati "confermati", intendi che per ogni doppia spesa 1 transazione é finita in un blocco e l'altra é stata rifiutata? sì intendo che la transazione di doppia spesa (la seconda transazione immessa nel network con gli stessi input della prima) ha ricevuto una conferma, e quando questo succede la prima non potrà più essere immessa nella blockchain (a meno che non ci sia un fork). Per farti un esempio pratico: io ti mando 1 btc a zero fee e tu lo vedi in ricezione nel tuo wallet, mezzora dopo mando una seconda transazione con lo stesso btc verso un mio address, se quest'ultima riceve una conferma a te quel btc non arriverà mai ma "tornerà" nel mio wallet (e la transazione in ingresso nel tuo scomparirà). Ok capito. Altre due domande: 1) una transazione a "zero fee" non dovrebbe neanche essere inserita tra le "transazioni non confermate" o sbaglio? --> In realtà dalla versione 0.9 la fee minima è di 1000 satoshi (al di sotto la tx non viene registrata in mempool, quindi rischia di non essere propagata correttamente nel network)
2) hai usato il core patchato, quindi hai applicato la patch al sorgente di bitcoin-core e poi lo hai compilato? È un'operazione lunga/complicata sotto Linux ? Non si potrebbe fare una doppia spesa semplicemente creando due raw transaction come ha suggerito FaSan? Forse mi sfugge il senso di questa patch Oppure bisogna utilizzare bitcoin-core via riga di comando? Si fà con le RAWTX via riga di comando. Nella blockchain la TX è valida solo dopo aver ricevuto la prima conferma dai nodi, prima di allora tutto può succedere  FaSan |
|
|
|
Ho giocato un po' anche io con core patchato replace by fee negli scorsi giorni, in particolare ho tentato 9 double spend con somme da 0,01 a 1,11 btc mettendo zero fee nella prima tx.
Ebbene: 9 double spend riusciti su 9 tentativi.
Ho notato che quasi tutti sono stati confermati da btc china, il che penso indichi che ha adottato RBF
Quando dici che i tentativi di double spend sono stati "confermati", intendi che per ogni doppia spesa 1 transazione é finita in un blocco e l'altra é stata rifiutata? |
|
|
|
A pelle direi che investire in un anno di chain parallela è troppo rischioso (devi essere sicuro di essere in vantaggio sempre), secondo me puo' avvenire nell'arco di 120 transazioni ma anche molte meno, mi pare che ci debbano essere 6 blocchi in piu' sulla catena vincitrice.
120 Blocchi intendi? Secondo me se fai un vero 51% Attack, non butti giù meno di 24 ore di blockchain (1 giorno sarebbero 144 blocchi in linea teorica), se organizzi un 51% Attack con fini di dolo, la tiri per le lunghe, per mesi, solo così distruggerai veramente ogni possibile speranza di riparazione e di riacquisto di fiducia negli utenti. Io ho una tendenza al catastrofismo, ma da bravo informatico sono convinto che laddove ci sia una falla nota, prima o poi il naso qualcuno ce lo mette. Ora io non voglio sminuire i tecnici della BFL, KNC, Terrahash etc ma non credo che siano dei luminari dell'elettronica, mi permetto di pensare che siano tecnici capaci come possono esserlo tanti altri nel loro campo. Quindi se qualcuno col cash (molto cash) decidesse di mettere in piedi un team per costruire asic di generazioni avanti (noi con i suddetti tecnici siamo passati da 333Mh/S a 10Th/S in meno di anno) e preparare questo disastro, non ne risulterei sorpreso. Risulto invece sorpreso del fatto che la soluzione a questo problema non sia ancora stata codificata nel core e sembra presa molto sotto-gamba. Questo davvero mi sorprende e non capisco cosa stiano aspettando, dato che, ripeto, potrebbe già essere stata messo in atto la preparazione di un 51% attack da molto tempo. io penso che se succedesse un attacco del genere (settimane o mesi di fork) il dev team interverrebbe con un hard fork che escluda la chain "cattiva" a forza dal network "buono" e quindi i danni sarebbero grandi ma verrebbe ripristinata la situazione precedente all'attacco e il bitcoin non verrebbe distrutto In tal caso i danni non sarebbero solo gravi ma gravissimi, annullare tutte le transazioni di settimane e settimane danneggerebbe in modo veramente grave se non irrimediabile il bitcoin. E chi risarcirebbe in tal caso coloro che ad esempio hanno venduto un prodotto/servizio/forza lavoro in cambio di btc ? Quando effettuiamo una transazione con btc, tutti penso diamo per scontato che, al massimo dopo 6 conferme, quella transazione diventa "definitiva"(anche se sappiamo che la logica alla base della blockchain di fatto consente sempre una probabilitá, seppur piccolissima, che la validità di tali transazioni possa venire revocata). Bisognerebbe allora secondo me riflettere un attimo sulla differenza tra "altamente improbabile" e "impossibile", differenza sulla quale si basa tutto l'ecosistema delle criptovalute. Non abbiamo a che fare con un sistema "sicuro" al 100%, ma facciamo finta che lo sia. Per esempio quando genero un indirizzo bitcoin, dò per scontato che nessun altro possa generare casualmente la mia chiave privata. In quel caso però si riesce almeno a quantificare con precisione il grado di probabilità che questo fatto possa verificarsi (e tra l'altro se avvenisse in un solo caso isolato il malcapitato non se ne accorgerebbe neanche, riterrebbe più plausibile essere stato colpito da qualche hacker). Nel caso del 51% attack invece è difficile calcolare la probabilità di questo evento ( che ripeto avrebbe una conseguenza sistemica invece gravissima ) e soprattutto la sensazione è che questa probabilità non sia poi così trascurabile. |
|
|
|
Un giorno, se sapro' leggere la chain con qualche software, provo a stimare pi con gli hash casuali della chain con griglia k*k, magari sarebbe bello trovare una funziona f(k, blocco) e vedere come si comporta ...
E un algoritmo pow/pos o prova di esistenza che coinvolga pi greco non sarebbe male.
Ho trovato in rete questo software per leggere i blocchi https://code.google.com/p/blockchain/, qui un articolo dell'autore http://codesuppository.blogspot.it/2014/01/how-to-parse-bitcoin-blockchain.html. Non l'ho provato, ma potresti usarlo per la stima di pi greco con il tuo metodo.
Un'idea potrebbe essere :
Difficoltà = numero di cifre del pigreco da "indovinare" (tipo 15 o 20)
Parametro n = numero massimo di punti che si possono generare (tipo 10000) per ottenere una stima entro tale margine di errore
A questo punto si genera l'hash di un blocco, che è il seed, e utilizzando una funzione random (uguale per tutti) si generano fino a 10000 punti. Se non si trova un'approssimazione di pi greco alla 15^ cifra, si modifica il blocco (come succede adesso), si ottiene un nuovo hash, a questo punto si prova la nuova serie (al massimo 10000 lanci) e così via.
In questo modo sarebbe molto dispendioso trovare la soluzione, ma molto facile verificarla.
A pelle i pow non mi convincono molto, non ho le idee ben chiare e ritengo interessante un dialogo, il sistema che hai descritto mi convince (simile a come l'avevo pensato anche io) ma non so quanto sia dispendioso generare la sequenza. Tenderei ad aggiungere l'indirizzo BTC del minatore in modo che ciascuno abbia probabilità legate al proprio address e forse si distribuirebbe la probabilità di minare anche a chi non ha macchine performanti, temo che una procedura del genere avrebbe come controindicazione una proliferazione di indirizzi al fine di minare ... Ad esempio (idee alla rinfusa ...): mina il blocco chi ha hash(address) piu' "vicino" ad hash("qualcosa legato al blocco precedente+seed/nonce") e forse si potrebbe inserire il pi greco ... eventualmente si potrebbe far aumentare la distanza consentita qualora dopo 10 minuti non venga generato il blocco (ma credo sia un casino ...) Anch'io non sono del tutto convinto dal sistema pow, che rischia di favorire alla lunga solo pochi minatori ( i più bravi e meglio organizzati ) rispetto a tutti gli altri. Inoltre tutto questo crescente "work" a garanzia del valore della moneta prima o poi lo pagheremo tutti, infatti quando le ricompense per blocco scompariranno o si ridurranno considerevolmente, temo che le commissioni che dovremo pagare per le transazioni aumenteranno di molto. L'idea di distribuire la probabilità di minare un blocco sugli indirizzi alla fine non penso funzionerebbe, proprio perché come hai giá notato tu un singolo minatore potrebbe mettersi a generare miliardi e miliardi di indirizzi. Secondo me la questione che sta alla base é che tutto quello che ruota intorno al mondo bitcoin ( i bitcoin, gli indirizzi, la capacitá computazionale / work, e quindi il concetto stesso di fiducia che sta alla base di ogni tipo di moneta, matematica o no) non "vede" i singoli individui, nel senso che uno stesso individuo può avere 1, 10, 10000 indirizzi / bitcoin / terahash di potenza, il suo "voto" quindi nel processo di verifica della correttezza delle transazioni (quale che sia il metodo scelto per farlo "esprimersi" sulla correttezza delle transazioni, proof of work, proof of stake, ... ) vale quanto quello di altri 1000 individui messi insieme, in altre parole il bitcoin ( e non solo lui ) non si basa su un processo democratico. |
|
|
|
|
Show Posts
