raga, qualcuno mi posta un du aggiornato di una blockchain bitcoin core con -txindex attivo ? voglio attivare -txindex, ma non ho idea di quanto spazio in piu' mi richiede. questo e' il mio di adesso SENZA -txindex: 53M ./blocks/index
56G ./blocks
60K ./database
1,2G ./chainstate
57G .
63G ./blocks 1,2G ./chainstate 16K ./database EDIT: se qualcuno usa anche Armory, in più si ritroverà 51G .armory/databases/blocks |
|
|
|
...
qui non esiste soluzione, in quanto non e' previsto nessun supporto per i full node per progetto,
e quindi il destino e' segnato.
Quindi dopo aver rinunciato a contribuire a costruire la blockchain e a generare moneta (il mining è costosissimo) adesso dovremo rinunciare anche a verificare direttamente le transazioni e a propagarle per la rete. Di fatto un cambio di prospettiva forte rispetto al progetto ideale iniziale di decentralizzazione. O forse era in fondo prevedibile, puntare tutto da una parte sull'efficienza e la competitività dei miner, e dall'altra parte sulla capacità dei full node di verificare percorsi di coerenza in una storia di transazioni che può solo aumentare con il tempo, non poteva non produrre come risultato naturale che solo i più bravi e i più attrezzati sarebbero rimasti in pista, declassando gli altri attori a semplici "utenti". Dal mio punto di vista comunque il problema vero non è tanto la dimensione crescente della rete di utenti (rete che se adesso fosse costituita diciamo da 1 milione di utenti, al massimo potrebbe aumentare di un fattore 10000 in futuro, non certo di più), quanto il fatto che la lunghezza della blockchain possa solo crescere con il tempo senza alcun limite, il che è dal mio punto di vista assurdo. Il progresso tecnologico potrebbe forse sostenere un aumento della rete anche di un fattore 10000 (certo non entro domani) e rendere magari alla portata di tutte le tasche un full node, ma non mi sembra plausibile poter scommettere sul fatto che il miglioramento tecnologico possa continuare a verificarsi all'infinito con la stessa velocità con cui aumenta inesorabile la lunghezza della blockchain. mi sono dimenticato anche un'altra info-chicca importante: Noi siamo autonumus system, ossia gestiamo il routing BGP dei nostri IP. questo fa si che ho anche un'ulteriore informazione, magari poco nota ai piu': riceviamo spesso segnalazioni da altri autorevoli fonti internet (ad esempio il CERTSI) tipo questa: CERTSI has detected some domain names that seem to be using Fast-Flux techniques[1] pointing to machines under your constituency, which may be members of a botnet.
....
questo vuol dire che se hai il nodo un normale provider VPS probabilmente il nodo te lo spengono forzatamente. Noi ce ne sbattiamo e lo teniamo acceso ugualmente, ma e' veramente sempre piu' difficle  Quindi: un VPS o un server dedicato possono spegnermelo; non ho capito se la stessa cosa può farla la Telecom bloccando la mia connessione casalinga. |
|
|
|
guarda, i dati di questo istante:
2714 root 20 0 7232496 5,482g 11780 S 18,3 17,4 2125:50 bitcoin-qt
in questo monento utilizza 5,48 GB di ram, poca cpu (18%) ed ho 155 altri nodi collegati.
ma capita spesso che abbia picchi da 7/8 GB di ram e come scrivevo cpu che arrivi anche al 90%
il problema e' che il memory pool (ossia tutte le transazioni in attesa di conferama) sono sempre di piu',
e lui ovviamente deve tenersele in RAM finche non vengono incluse nel blocco.
Ma il blocco e' un po' piccolo, quindi le transazioni in attesa sono mediamente molte...
e quindi un full node vero deve fare da "cache" per tutte quesste transazioni pendenti.
Inoltre di tutto questo traffico deve fare le validazioni, e questo spiega l'alto utilizzo di CPU.
poi c'e' l'utilizzo del disco che cresce sempre... e non parliamo della banda, che ha degli spike impressionanti...
Io non ci credo neanche se lo vedo che in queste condizioni uno fa girare un full node
con un raspberry, semplicemente perche' non e' in grado di tenere il memory pool
che mediamente serve di questi tempi.
Il destino sara' che lo terra' attivo SOLO chi ci guadagnera' nella cosa, quindi pool, exchange
e pochi altri, e quindi si, alla lunga ci sara' un'accentramento mostruoso di full node
estremamente poco igienico.
Non è possibile far girare un full node con alcuni parametri che ne limitano l'uso delle risorse hardware? Io pensavo ad esempio di limitare: 1) il numero di connessioni (magari più di 8 ma non certo 600) 2) il numero di transazioni da validare e propagare per la rete (se si limita la mempool di conseguenza si limita moltissimo l'uso della cpu e della RAM, giusto?) In pratica è possibile ottenere dei "mininodi", che sono ancora "full" nel senso che controllano la validità di ogni blocco e di ogni transazione che sono in grado di gestire su tutta la blockchain ma che sono "mini" poichè limitano il numero di transazioni da controllare? Sostanzialmente penso a dei nodi che si "esprimono" su meno situazioni rispetto ai fratelli maggiori, ma con lo stesso grado di conoscenza (e quindi di fiducia). Se invece questo non fosse possibile allora veramente tra un paio di anni i full node casalinghi saranno scomparsi. E se si pensa che far girare un full node è sempre stato proposto come il modo migliore per partecipare attivamente alla rete e sostenere/votare le regole del bitcoin, allora siamo messi veramente male. Insomma un full node e' diventato una risorsa costosa, e come ho scritto, credo sia un errore
non piccolo non aver previsto ne protocollo una ricompensa per chi tiene un full node attivo.
A questo proposito il problema mi pare consista nel fatto che non è possibile dimostrare di essere un nodo oltre ogni ragionevole dubbio (anche le statistiche sui full node attualmente in attività non sono per nulla attendibili), questo poichè in ultima istanza il lavoro di un full node non è dimostrabile (o distinguibile) da quello di un semplice software che riceve una transazione e la ritrasmette così com'è alla rete senza aver fatto nessun controllo, o che chiede ad altri informazioni che non possiede e le rivende poi come sue. EDIT: tu hai per caso ricevuto questo regalo natalizio? http://www.virtual-strategy.com/2015/12/25/btcc-deploys-100-full-bitcoin-nodes-across-five-continents#axzz3vLfWL3X7Sarei curioso inoltre di fare un piccolo sondaggio informale tra gli utenti del forum: avete un full node? Lo fate girare h24? A casa vostra o su un server? Con tutte le opzioni e parametri vari impostati al "massimo"? |
|
|
|
Per contribuire seriamente alla rete vorrei fornire almeno un Full node.
Il problema è minimizzare i costi.
le mie ipotesi sono 2:
ipotesi 1 - comprare un tablet windows 8 oppure un netbook da tenere sempre online (tanto fastweb è già pagata!). mentre l'investimento iniziale è sopportabile e ammortizzabile (quando serve qualcuno a casa può comunque usarlo per navigare); il problema è la corrente elettrica: è ragionevole stimare un consumo massimo di 40-50w/ora? quindi un kw/h al giorno? a questo punto staremmo parlando di circa 1,2 euro a settimana (ergo circa 55 euro l'anno). sono giusti i miei conti?
ipotesi 2 - l'alternativa sarebbe noleggiare una Virtual Machine in qualche hosting. in questo però i prezzi mi sembrano più alti. Considerando che c'è bisogno di almeno 50 Gb di Hard disk (o è troppo poco?) andiamo a ritrovarci a pagare almeno 20-30 $ al mese di noleggio. troppo. per quanto mi riguarda è troppo anche quello che chiede il servizio offerto da l'articolo che vi ho linkato sopra (10$ al mese).
A questo punto le mie domande per cui vi chiedo aiuto sono:
- è realistica la stima in fatto di consumi dell'ipotesi 1?
- quanto spazio disco bisogna calcolare per la blockchain, tenendo presente almeno i prossimi 2 anni di crescita?
- considerando che io già ho una VM con windows 2003 a 10$ al mese ma che uso per altri motivi, ma che lo spazio disco disponibile è di un paio di Gb, conoscete qualche programmino che consenta di creare un disco virtuale collegato ad uno spazio disco in cloud? ma sopratutto, bitcoin-qt potrebbe funzionare con una soluzione simile?
Riuppo questo thread poichè stavo valutando anch'io ultimamente di mettere su un full node operativo h24. Ovviamente bisogna scegliere tra: - un nodo casalingo (ma le risorse saranno sufficienti? Inoltre c'è il problema della connessione internet, soprattutto riguardo l'upload) - utilizzare una vps (ce ne sono di adatte allo scopo a costi ragionevoli?) ma soprattutto mi faccio la seguente domanda: quali requisiti hardware deve avere la macchina su cui gira (e di conseguenza con quali limitazioni nelle impostazioni di Bitcoin Core) ? Certo che in rete si legge di tutto, si va dalle soluzioni minimali: -versione fai da te ( http://n-o-d-e.net/post/115030545546/how-to-build-a-bitcoin-node-on-the-raspberry-pi-2) -versione soluzioni chiavi in mano ( https://getaddr.bitnodes.io/hardware/) alle soluzioni decisamente più "strong": ...io ho un full node. Ora uso una macchina con 32 giga di ram, un quad core abbastanza tosto, dischi sas molto performanti,
e la trovo spesso con bitcoin-qt che utilizza piu' di 7 giga di ram, uso dei processori (per validazioni e cazzi vari) al 90% per non parlare della banda internet.
Io fortunatamente ho a disposizione le risorse aziendali, e quindi per ora posso ancora permettermelo, ma presto (max un anno) con questo ritmo di crescita
dovro' dismetterlo
...
col maxconnection 5000
al massimo ho visto sette/ottocento nodi collegati...
in questo istante ad esempio ne ho 675
In aggiunta a tutto ciò e alle incertezze sulle risorse sempre maggiori che vengono richieste, si trovano anche indicazioni poco incoraggianti da membri autorevoli Most ordinary folks should NOT be running a full node. We need full nodes that are always on, have more than 8 connections (if you have only 8 then you are part of the problem, not part of the solution), and have a high-bandwidth connection to the Internet.
So: if you've got an extra virtual machine with enough memory in a data center, then yes, please, run a full node.Gavin Andresen ( https://www.reddit.com/r/Bitcoin/comments/1scd4z/im_running_a_full_node_and_so_should_you/cdw3lrh?context=3) o poco chiare (almeno per me) So I hope you now see the importance of full nodes in this model. If you run a full node somewhere on the network, and nobody looks at the transactions it validates, it is indeed contributing to the network, but it is not helping with the reduction of trust.
Look at it another way: if only a few large players in the Bitcoin ecosystem were running full nodes, it only requires a malicious intent, or an attack/threat against them, to change the system's rules, as nobody else is validating.
Doing transactions in the Bitcoin ecosystem helps the Bitcoin currency. Running a full node helps the network. Using a full node helps you and the ecosystem reduce the need for trust. Pieter Wuille ( https://www.reddit.com/r/BitcoinBeginners/comments/3eq3y7/full_node_question/ctk4lnd) |
|
|
|
Cosa ho firmato non lo so, ma ho recuperato un account del sito ( che tra parentesi è di proprietà di un legendary/donator del forum) e vi posso far vedere cosa chiede di firmare per poi prelevare.
21aea59b0f2450513db584095f184ebe
questa era la stringa da mettere , mi pare che ad ogni account sia diversa
La tua stringa è lunga 32 caratteri, io sapevo che la lunghezza della stringa da firmare in una transazione dovrebbe essere lunga 64 caratteri (vedi il punto 14 della risposta strutturata in 19 passi alla domanda iniziale posta qui http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-tx ) Aspetto che qualcuno più esperto ci illumini. |
|
|
|
... Quindi e' importante che se qualcuno vi sottopone un file, un testo, una stringa esadecimale, insomma una qualsiasi forma di documento e vi chiede di firmarlo digitalmente (col vostro wallet), EVITATE DI FARLO se non sapete ESATTAMENTE cosa state firmando, ne siete consapevoli,
e avete la VOLONTA' di farlo. la firma digitale e' l'equivalente di una firma nella vita reale, e come nella vita reale se qualcuno vi chiede di firmare qualcosa lo fate solo se siete ben consapevoli di cosa state firmando (a parte chi vi prende per sfinimento tipo le banche  ) allo stesso modo, anzi con ancora maggor attenzione dovreste comportarvi nel mondo bitcoin, dove quando una cosa e' fatta NON SI TORNA INDIETRO. Il punto da sottolineare più volte è proprio questo. Se cercate "sign a message" qui nel forum troverete molte situazioni in cui si invita qualcuno a firmare un messaggio come metodo per dimostrare di essere il proprietario di un certo indirizzo (ad esempio, se non si è sicuri dell'identità di un account - sospetto di account rubato - si può chiedere alla persona in questione di firmare un messaggio con un suo indirizzo - un indirizzo riportato nel forum molto tempo fa e quindi ricollegabile a quell'account in tempi non sospetti) Di solito in questi post l'attenzione è sul "sign" (come si fa a firmare?, cosa significa?) e quasi mai sul "message", che però è altrettanto importante! Con la propria firma si dichiara di essere l'autore del messaggio che si sta firmando! Se nel messaggio c'è scritto (ovviamente nel linguaggio del protocollo bitcoin): "io possessore della chiave privata dell'indirizzo x autorizzo il trasferimento di tutti gli input non spesi dal mio indirizzo all'indirizzo y" e io lo firmo, ho appena creato una transazione (è così che funzionano tutti i client)! A quel punto basta che questo messaggio sia trasmesso alla rete e io ho speso in maniera irrecuperabile i miei btc. |
|
|
|
|
Buon Natale a tutti gli utenti del forum anche da parte mia
|
|
|
|
Tecnicamente si chiama "blind signature" https://en.m.wikipedia.org/wiki/Blind_signature(se questo è stato effettivamente il tuo problema):
Blind signature schemes exist for many public key signing protocols. Some examples are provided below. In each example, the message to be signed is contained in the value m. m is considered to be some legitimate input to the signature function. As an analogy, consider that Alice has a letter which should be signed by an authority (say Bob), but Alice does not want to reveal the content of the letter to Bob. She can place the letter in an envelope lined with carbon paper and send it to Bob. Bob will sign the outside of the carbon envelope without opening it and then send it back to Alice. Alice can then open it to find the letter signed by Bob, but without Bob having seen its contents.
More formally a blind signature scheme is a cryptographic protocol that involves two parties, a user Alice that wants to obtain signatures on her messages, and a signer Bob that is in possession of his secret signing key. At the end of the protocol Alice obtains a signature on m without Bob learning anything about the message. This intuition of not learning anything is hard to capture in mathematical terms. The usual approach is to show that for every (adversarial) signer, there exists a simulator that can output the same information as the signer. This is similar to the way zero-knowledge is defined in zero-knowledge proof systems.
|
|
|
|
Se si usa Bitcoin Core con il pruning attivato tecnicamente si può considerare ancora un "full node"?
tecnicamente no, perche' in certi casi serve un full "node" e' una sorta di via di mezzo, molto piu' leggero, ma avendo solo 500 MB (regolabili) circa di blockchain non puo' fare ogni tipo di validazione. supponi che ti arriva una TX che fa riferimento ad altre TX che sono in un pezzo di blockchain di cui tu non hai una storia, non sai come gestirla, se validarla o no in pratica. Rimango ancora un po' OT, ma secondo me è fondamentale capire non solo la tecnica ma anche le implicazioni "politiche" che soggiacciono a certe scelte tecniche (e questo credo è comunque anche il senso di questo thread). L'impiego dei client leggeri sembrerebbe da una parte rendere più "democratico" l'accesso alla rete (anche chi ha scarse risorse computazionali può collegarsi alla rete) ma d'altra parte questo utilizzo "al risparmio" va nella direzione di modificare i rapporti di forza tra minatori e nodi nel meccanismo di gestione delle regole. Se infatti in una rete a forte prevalenza di full node il "potere" è concentrato nei nodi a scapito dei minatori, (vedere a riguardo l'ottimo articolo di HostFat http://www.rischiocalcolato.it/2015/07/bitcoin-oirgini-crisi-transazioni.html da cui ricavo la seguente citazione): Le regole del network sono imposte dai nodi, che hanno costi inferiori a quelli dei minatori. Il costo di installazione e gestione dei nodi è proporzionale all’uso che ha il mercato, se il mercato è piccolo, il costo di gestione di questi singoli nodi sarà ancora più basso, viceversa se il mercato si amplia indefinitivamente, può andare ad alzarsi.
Il minatore, che deve sottostare alle regole dei nodi, è un “umile” (ormai si fa per dire) servitore, che rispetta queste regole e in base ad esse emette il blocco, puntando sul fatto che tale venga accettato dalla totalità del network, o comunque da quella maggioranza del network che “da valore ai bitcoin che è andato a creare”.
E’ l’ultima ruota del carro, il suo potere decisionale è molto limitato, ed è del tutto focalizzato nel accontentare il volere del mercato, del cliente … visto che tale è ciò che va a dare valore al premio che riceve.
nel caso di una presenza importante di client leggeri il "potere" verrebbe spostato sui minatori (fonte: https://en.bitcoin.it/wiki/Full_node): Full nodes enforce the consensus rules no matter what. However, lightweight nodes do not do this. Lightweight nodes do whatever the majority of mining power says. Therefore, if most of the miners got together to increase their block reward, for example, lightweight nodes would blindly go along with it. If this ever happened, the network would split such that lightweight nodes and full nodes would end up on separate networks, using separate currencies. People using lightweight nodes would be unable to transact with people using full nodes
Come si situano allora i client Core con pruning attivato? In che senso sono a metà strada, vanno nella direzione di dare maggior potere ai nodi o ai minatori? Tutto questo discorso mi fa riflettere sulla relazione "tecnica - economia". Certo che già è difficile capire se una proposta come il "Segregated Witness" ad esempio sia più o meno valida dal punto di vista tecnico, ma riuscire anche a cogliere le conseguenze politico-economiche di questa proposta per poter esprimere poi un parere assennato mi sembra quasi impossibile! |
|
|
|
Si certo, non c'è nessun metodo al mondo, a meno che l'investimento non sia reale, a meno che non si abbiano buone intenzioni e a meno che non si dichiara che in massimo 20 giorni (potrebbe scappare qualche giorno in più) si ha il proprio investimento indietro rialzato del 150%. So che è difficile fidarsi di un semplice post o di un sito web, infatti ho messo come minimo investimento 0.001, in modo tale che chiunque non si fidi, può provare con una piccola cifra. Ah dimenticavo, se fosse un sito scam o un sistema non sicuro avrei aperto un topic qui? No, quello che stai dicendo è sbagliato proprio come principio! Nessun metodo al mondo che si basi su qualsiasi cosa può produrre un guadagno certo, non esiste!Questo fatto non dipende dal tipo di investimento nè dalle intenzioni di chi lo propone, fosse pure un investimento reale e assennato gestito dalla persona più competente del mondo e con le intenzioni migliori possibili, nessuno può garantire un guadagno certo, mai! E non vedo come lo specificare il lasso temporale (20 giorni) e il precisare il ritorno (150%) possano cambiare le cose. Anzi, a maggior ragione non è possibile garantire un guadagno delle dimensioni che proponi tu. |
|
|
|
1. Il sistema è semplice ed è spiegato oltre qui anche sul sito: i bitcoin investiti vengono re-investiti fin quando non si ottiente un profitto 1.5 volte maggiore, una volta tanto tornano all'investitore, quindi è chiaro che non è schema Ponzi;
...
4. Il sito NON duplica i soldi, investe i bitcoin e ne torna una quantità 1.5 volte superiore;
...
6. Non è un sistema che può collassare, visto che i bitcoin investiti verranno tornati indietro solo quando raggiungono il profitto prefissato.
Quello che bisogna dire chiaramente è: non c'è nessun modo al mondo per garantire con sicurezza un guadagno del 50% (ma neanche dell'1%) in nessun lasso di tempo, breve o lungo che sia. C'è sempre il rischio di perdere tutto, per quanto buono possa essere sulla carta (ammesso e non concesso che lo sia) questo investimento. Quindi invece del verbo all'indicativo bisogna declinare tutto al condizionale e i "quando" si devono trasformare in "se/qualora": " qualora (caso veramente poco probabile) i btc che mi avete dato riescano a produrre un guadagno del 50%, fidatevi che ve li restituirò, guadagno stellare compreso; qualora invece questo non accada, avrete invece perso in modo irrecuperabile i vostri soldi, per sempre" 3. L'investimento può impiegare anche più o meno di 20 giorni, a seconda del prezzo del bitcoin sul dollaro (anche questo è scritto sul sito);
Anche qui bisogna essere più espliciti, l'investimento può durare anche per sempre, nel senso che i soldi potrebbero non tornare indietro mai (e questo ripeto vale per tutti gli investimenti sul pianeta Terra, senza nessuna eccezione, e senza tirare in ballo le intenzioni buone o cattive che siano dei proponenti l'investimento). |
|
|
|
No probabilmente mi sono espresso di cazzo.
Per correttezza avrei dovuto dire che ci troveremmo 3 tipi di client
- Full Header + Merkel
- Full Solo Blocchi Header (Nuovi Client)
- Chainless
Veramente nel nuovo core, con il parametro -prune, (per ora disabilitato di default) in realta' ci sono gli header + una parte (piccola) della blockchain che e' sufficente per quasi tutte le verifiche , se poi si trova in un caso che non sa gestire, chiede agli amichetti full come fare. Se si usa Bitcoin Core con il pruning attivato tecnicamente si può considerare ancora un "full node"? Avevo inoltre letto che con quella opzione attivata non si può usare il wallet (ma dovrebbero risolvere la cosa nella 0.12) |
|
|
|
Guarda, io credo che Chainless voglia dire SENZA NIENTE, cioè è solo un client, parla con un webservice che gli fornisce i dati.
Sul webservice cè un full node
Non ti riferivi ai client SPV? EDIT: io mi riferivo a questo http://bitcoin.stackexchange.com/questions/32529Forse lì c'è una risposta alla mia domanda, adesso devo capire cos'è questo "Bloom filter". |
|
|
|
Il problema che cercherò di sviscerare è il seguente
"Come fa un client chainless a capire se i blocchi che gli stanno arrivando sono merda?"
Un client che ha solo gli header dei blocchi dovrebbe comunque riuscire a capire da solo se questi sono validi o meno Leggendo la domanda di Sampey mi sono accorto che io non conosco bene nemmeno il funzionamento dei client "chainless" attuali. Ho provato allora a dare un'occhiata al paper originale di Nakamoto --> https://bitcoin.org/bitcoin.pdf nel quale c'è una breve sezione al riguardo: 8.
Simplified Payment Verification
It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification.
e questo wiki https://en.bitcoin.it/wiki/Thin_Client_SecurityA client verifies the depth D of a block by checking that there are D blocks after it (also called "confirmations"), all of which are well-formed. SPV clients don't verify the preceding blocks, they use the number of confirmations (whether they are valid or not) as a measure of the likelihood of a block chain reorganization producing a new longer fork which excludes the transaction.
Riassumo quello che ho capito sul funzionamento attuale di questi client: a) essi scaricano solo gli header dei blocchi (non i blocchi interi); l'header di ciascun blocco è costituito dall'hash dell'header del blocco precedente + nonce + Merkle Root (che è il punto finale del Merkle Tree, ovvero di un albero di hash creato a partire dagli ID delle transazioni presenti nel blocco (le foglie dell'albero), che vengono raggruppati a due a due, e a ciascuna di queste coppie di ID viene applicata la funzione hash e questa procedura si reitera raggruppando i risultati ottenuti nel passo precedente a due a due fino a ottenere il Merkle Root) b) quando un client riveve un pagamento su un proprio indirizzo, per controllare la validità di quel pagamento deve per forza affidarsi a dei full node (i quali invece hanno a disposizione tutta la blockchain). Interroga quindi questi full node, e dopo aver scelto quello che possiede la catena più lunga (con la difficoltà complessiva maggiore), ottiene da questi solo la parte del Merkle Tree necessaria (in combinazione con l'ID della transazione di cui sta controllando la validità) a risalire al Merkle Root. In questo modo quindi il client verifica solo che la catena più lunga contiene un blocco che effettivamente contiene a sua volta quella determinata transazione (ma non controlla la "storia" che ha preceduto quella transazione, si fida del fatto cioè che questo controllo sia stato fatto in maniera corretta dal full node che ha scaricato e vagliato l'intera blockchain pezzo per pezzo) c) a questo punto il client calcola, a partire da quel blocco, il numero di conferme che ha quella determinata transazione. Domande: 1) come fa un client "chainless" ad accorgersi che è stato effettuato un pagamento verso un proprio indirizzo? Dal momento che non possiede le transazioni presenti nella blockchain, come fa a ricavare solo dagli header dei blocchi il messaggio: "attenzione, nel blocco x generato ieri alle yy:zz c'è una transazione che ti riguarda?" 2) il problema di questi client leggeri consiste solo nel controllo della validità dei pagamenti in ricezione? Il controllo sulla validità dei pagamenti effettuati invece dagli indirizzi del proprio client è un problema solo di chi riceve il pagamento e dei full node più in generale? |
|
|
|
Ho acquistato da Stemby una banconota nuova di zecca, spedizione immediata e banconota arrivata in condizioni perfette. Ringrazio Stemby per la cura che ha messo nel confezionare la busta (il che gli è costato anche qualcosa in più di spedizione) in modo che la banconota non si danneggiasse. Fa un certo effetto avere 100 trilioni di dollari, ovvero 100mila miliardi di dollari  (ma solo dello Zimbabwe)! |
|
|
|
boh speriamo che ci siano davvero i vantaggi che dicono... quando facevo il programmatore, questa mi avrebbe puzzato tantissimo da pezza penso che a livello client andra' fatto un altro DB per indicizzare il nuovo merkle tree, altre complicazioni, piu' roba che si puo' spaccare o non essere sincronizzata... sperem EDIT: o meglio che i vantaggi superino gli svantaggi. Io non sono mai stato un programmatore e quindi non mi addentro nelle questioni tecniche. Osservo solo che questo tipo di modifica è una specie di ottimizzazione che consente di procrastinare (o evitare per "sempre"?) il momento in cui le dimensioni del blocco dovrebbero essere aumentate. A me sembra che l'aumento delle dimensioni dei blocchi costituisca un elemento di divisione irrisolvibile nella comunità bitcoin (ma non ne capisco sinceramente il perchè), e per evitare di affrontarlo una volta per tutte si prova una strada alternativa (che magari è anche migliore, forse questa specie di suddivisone in 2 parti della blockchain dal punto di vista logico è addirittura una soluzione più pulita, ma non sono in grado di giudicare). Rimane il fatto però che prima o poi la questione di fondo andrà affrontata. |
|
|
|
giusto per completezza, vitalin ha ideato ethereum un progetto mostruoso che seguo per curiosita' da qualche mese,
ed ethereum ATTUALMENTE sta usando anche lui ECDSA con secp256k1 (la stessa curva di bitcoin) ....
(poi ha progetti futuri, e' vero, ma attualmente ethereum e' uguale a bitcoin come fragilita' a un attacco quantistico)
Infatti nello stesso articolo che ho citato Vitalik spiega anche quali sono le contromisure possibili che si possono adottare per superare il problema di cui stiamo discutendo, non è che lui sia un catastrofista. e sono esattamnete le contromisure che verranno prese da bitcoin se e quando la cosa si rendera' necessaria... Ok, ma il rischio c'è. Se qualcuno arrivasse a costruire un computer quantistico della potenza necessaria prima che il mondo bitcoin riesca a mettersi d'accordo su come cambiare, ci sarebbero dei problemi. Inoltre la stessa fase di transizione dal sistema attuale al sistema "Lamport signatures" (ammesso che sia quella la soluzione che sarà adottata) non sarà banale e del tutto indolore, come riconosce lo stesso Vitalik. Da un punto di vista intellettuale è affascinante questo discorso, anche se prematuro, poichè, che sia tra 10 o 30 anni, se il bitcoin esisterà ancora dovrà necessariamente passare attraverso questo momento molto delicato. |
|
|
|
|
Show Posts
