 Show Posts
|
|
Pages: [1] 2 3 »
|
|
Si ma io vorrei capire se il wallet sul telefono è un client SPV quindi sul mio telefono ho tutti gli header della blockchain?
|
|
|
|
Quindi la mia applicazione sul telefono la posso definire un nodo spv e quindi sul mio telefono ci sono tutte le intestazioni dei blocchi?? oppure c'è un altra categoria di wallet che a loro volta si collegano ad un nodo spv che a sua volta si collega ad un full node?
No, il tuo telefono per conoscere le transazioni, o gli UTXO relativi ai tuoi indirizzi interroga un nodo “server” e tiene in locale solo le informazioni che gli interessano. Per questo la soluzione SPV è ottimale per dispositivi “leggeri”, ma è subottimale per quanto riguarda la privacy.
Quindi un full node che fa da "server" ad un nodo spv deve stare in ascolto sulla sua mempool e vedere tutte le trx se ce ne sono relative agli indirizzi dei nodi spv ad esso collegato?
No, un nodo server ha la copia intera della blockchain ed ascolta tutte le transazioni nella mempool. E può essere interrogato quindi da qualsiasi wallet SPV, proprio perché contiene “tutte” le informazioni. Voglio dire, è il wallet SPV che “chiede” al nodo server le proprie transazioni, non ilserver che le seleziona per il nodo SPV... Non ho capito quando parli di : No, il tuo telefono per conoscere le transazioni, o gli UTXO relativi ai tuoi indirizzi interroga un nodo “server” e tiene in locale solo le informazioni che gli interessano. Per questo la soluzione SPV è ottimale per dispositivi “leggeri”, ma è subottimale per quanto riguarda la privacy.
quindi il mio telefono è un client spv? ma il client spv per definizione non tiene solo gli headers di tutti i blocchi? |
|
|
|
Buonasera amici,
stavo ristudiando/rivedendo dei concetti in merito al funzionamento della blockchain ma ho i seguenti dubbi:
1. i nodi oltre a tenere una copia della blockchain intera c'è anche una copia delle sole utxo, altrimenti come si calcola il balance di un wallet
2. quando un nodo conferma un blocco veerifica anche se nelle trx ci sono indirizzi relativi ad un wallet ad esso collegato o anche in questo caso guarda la lista delle utxo e se trova un address associato aggiorna iil balance?
3. supponiamo che importo un wallet, mi chiede le parole di recovery... a quel punto che succede riesce a recuperare chiave private pubblica e address? ma come sa a quale address generato si deve fermare per poi controllare? cioè continua a scansionare elenco delle utxo finche trova address associati?
4. come fa un wallet ad aggiornare il suo bilancio senza aspettare effettiva conferma? Cosa va ad interrogare / leggere?
Domande interessanti. Secondo me tutte cose che puoi trovare su mastering bitcoin, che puoi trovare in edizione free qui in un link nel post qui sotto: 5 Risorse per iniziare l'uomo della strada al Bitcoin.Sono al momento impossibilitato a rispondere con calma a tutte queste domande, ma azzardo una risposta a quella più facile: 4. Ogni wallet è collegato ad un nodo. Se hai un wallet su bitcoin core, allora il wallet interroga direttamente il nodo (ci possono essere altri casi, rimaniamo sul semplice). Se invece hai un qualsiasi altro wallet (Electrum, Green o qualsiasi altro) hai un wallet SPV che si collega ad un altro nodo, situato chissà dove. Il succo è che ogni “full node” ha una “mempool” ovvero l’insieme delle transazioni valide, ma non confermate. Ebbene, se all’interno della mempool vede un indirizzo conosciuto, allora può updatare il saldo relativo, anche in attesa della conferma. Ricordiamoci che nella mempool ci sono solo transazioni valide. Ogni nodo difatti può broadcastare solo transazioni che seguono il protocollo. Se provassi a broadcaatare una transazione non valida questa sarebbe rifiutata da tutti gli altri nodi della rete, e quindi non giungerebbe mai ai miner. Ricordiamoci difatti che NON sono i miner a stabilire quali siano le transazioni valide, ma i nodi della rete. Quindi la mia applicazione sul telefono la posso definire un nodo spv e quindi sul mio telefono ci sono tutte le intestazioni dei blocchi?? oppure c'è un altra categoria di wallet che a loro volta si collegano ad un nodo spv che a sua volta si collega ad un full node? Quindi un full node che fa da "server" ad un nodo spv deve stare in ascolto sulla sua mempool e vedere tutte le trx se ce ne sono relative agli indirizzi dei nodi spv ad esso collegato? |
|
|
|
Azzardo una risposta alla 1)
Nel db del nodo non ci sono tutte le transazioni, ma solo quelle del wallet associato. Per capirci non lo puoi interrogare per farci un block explorer. Questo out of the box. Se poi nel file di configurazione bitcoin.conf setti txindex=1, allora vengono messe in db tutte le transazioni della blockchain
Ciao grazie per la risposta... Non capisco che senso ha avere un full node per poi avere solo le trx riguardanti al wallet associato a quel nodo... detto questo nel caso avessi tutte le transazioni e volessi fare io una nuova trx per calcolare le utxo da spendere non credo che ogni volta si vada a leggere tutta la chain alla ricerca di quelle relative al sui indirizzi... |
|
|
|
|
Buonasera amici,
stavo ristudiando/rivedendo dei concetti in merito al funzionamento della blockchain ma ho i seguenti dubbi:
1. i nodi oltre a tenere una copia della blockchain intera c'è anche una copia delle sole utxo, altrimenti come si calcola il balance di un wallet
2. quando un nodo conferma un blocco veerifica anche se nelle trx ci sono indirizzi relativi ad un wallet ad esso collegato o anche in questo caso guarda la lista delle utxo e se trova un address associato aggiorna iil balance?
3. supponiamo che importo un wallet, mi chiede le parole di recovery... a quel punto che succede riesce a recuperare chiave private pubblica e address? ma come sa a quale address generato si deve fermare per poi controllare? cioè continua a scansionare elenco delle utxo finche trova address associati?
4. come fa un wallet ad aggiornare il suo bilancio senza aspettare effettiva conferma? Cosa va ad interrogare / leggere?
|
|
|
|
|
Ciao picchio,
grazie per la risposta, ok se ho capito mi consolo perchè non ne venivo a capo.
Il tuo ma... mi lascia un po confuso... cmq questo tipo di attacco ha senso se il mittente è un exchange perchè il Bob o Alice della situazione potrebbe verificare 'facilmente'.
Ora però mi potresti spiegare o trovare qualche fonte che spiega chiaramente la trx malleability nella lighting network ?
|
|
|
|
Salve a tutti ragazzi, come da oggetto ho una domanda sulla transaction malleability. Leggo e rileggo e vorrei riuscire a capire, ma c'è qualcosa che non mi torna. Da quanto mi sembra di aver capito, questa "malleabilità" viene messa in atto da un ricevente che sfruttando un "bug" della scriptSig altera la firma, rendendola cmq valida, e quindi la trxid. Negli articoli ho trovato spesso come esempio che A paga 1 BTC a B, B cambia la trxid incassa il suo BTC e poi reclama ad A che non ha incassato nulla e quindi A si trova a rimandare un altro pagamento. Ora partendo dal presupposto che con segwit il problema è diventato obsoleto, le mie curiosita sono: - Ovviamente questa malleabilità andava a buon fine se il "malevolo" intercettava la trx prima che quella originale venisse propagata in tutta la rete
- Anche se questo accadeva, tramite blockexplorer A poteva vedere che dal suo indirizzo era partita cmq una trx verso B con trx diversa e quindi ad una seconda richiesta di pagamento di B, A si poteva rifiutare
Probabilmente c'è qualcosa che mi sfugge... Grazie a tutti coloro che mi aiuteranno a capire. |
|
|
|
Salve a tutti ragazzi, avrei una domanda per voi, non ho ben chiaro il concetto di transaction malleability. In particolare: - se ho ben capito la trx malleability consiste in un cambiamento della firma della trx al fine di produrre un nuovo trxid e al mittente vengono sottratti dei bitcoin.
Ma i miner quando verificano il blocco non verificano anche la correttezza della transazione? Perchè si accorgerebbero che la firma non è corretta - Mi è chiaro che la soluzione a questo problema è segwit, ma nello specifico non mi è chiaro dove la parte della firma viene inserita e come questo possa diminuire la grandezza di una trx (visto che la firma viene solo spostata)
- attualmente la grandezza del blocco è passata da 1mb a 2mb?
Grazie per le risposte FP |
|
|
|
|
Ciao arulbero e grazie per la risposta,
si, ho letto quanto mi avevi quotato ma pensavo che quel controllo tramite filtro lo facesse per verificare se una transazione che stava cercando fosse confermata o no.
Forse mi manca un pezzo, mettiamo che invio dei btc, il wallet full verifica il mio bilancio in base alla lista degli UTXO e crea la transazione, mentre nel caso di un wallet SPV come si comporta nel momento di creare una transazione?
|
|
|
|
Ciao grazie mille per la risposta vediamo se ho capito: Caso Full Node/Wallet: il nodo/wallet all'inizio scarica e verifica tutta la blockchain facendosi una lista delle UTXO. Nel momento in cui gli il wallet crea/genera una transazione verifica che l'input faccia parte delle UTXO in quel caso accetta la transazione la propaga a tutti i nodi della rete tra cui anche il nodo ricevente che aggiorna il suo bilancio ( caso in cui wallet ricevente sia un full node), bisogna attendere che la transazione venga minata e inclusa in un blocco al fine di essere considerata valida. Al nodo arriveranno cosi i nuovi blocchi che verificherà, aggiornera la UTXO e cosi via..... Domanda se mi scollego dal mio wallet full e lo riaccendo dopo 2 giorni partirà da capo a scaricarsi la blockchain o solo la parte mancante? Caso SPV: il wallet scarica solo gli header della blockchain e verifica hash. Nel caso in cui deve verificare una transazione chiede ad un full node di inviargli il ramo del merkle tree contenente quella transazione per ricostruire il merkle root. Non capisco pero come possa accettare/scartare transazioni visto che a differenza di un nodo full non ha la lista delle UTXO.  Grazie F |
|
|
|
Grazie ad entrambi per le risposte, sempre molto gentili. Vorrei capire meglio però un passaggio relativo alla transazione e successiva conferma, riporto per semplicità un esempio: Bob possiede nel suo wallet 3 btc derivati da transazione precedenti, per la precisione 1 btc dalla transazione X 1 btc dalla transazione Y e 1 Btc dalla transazione Z. Ora Bob paga un caffe al bar dal costo di 1.4 btc + 0,4 di fee Bot accede al suo wallet e nel caso di full wallet : - il wallet prepara come somma 2 btc dalla transazione X e Y con resto di 0.2 da ritornare a lui
- il wallet verificherà che la somma non è stata effettivamente spesa controllando con una ricerca in tutta la blockchain le transazioni degli indirizzi presenti nella transazioni X e Y o fa altro? e nel caso di light wallet?
- appurato che la somma sia presente e la transazione passi indenna il controllo degli script questa viene accettata e propagata a tutti i nodi della rete, tra cui anche qualche nodo miner che l'inizierà a minare
- il wallet del proprietario del BAR se ha un wallet full vede aggiornarsi il suo bilancio anche se questa non è stata confermata in quanto deve essere ancora minata, se è di tipo light cosa succede? Non vede il suo bilancio aggiornarsi fino a quando anche lui ad intervalli regolari non chiede ad un nodo full se ci sono nuove transazioni per i suoi indirizzi? Poi quando la transazione sarà minata il wallet potrà verificarla scaricando l header del nuovo blocco e verificando che la transazione sia nel merkel tree???
Spero di essere stato chiaro e grazie F |
|
|
|
Salve a tutti ragazzi, grazie per le risposte dei post precedenti, ho ripreso lo studio del sistema bitcoin ed ho un po di dubbi che elenco di seguito: - Non è detto che un nodo della rete bitcoin faccia anche da miner?
- Un wallet è un nodo della rete che può essere di tipo full (scarica tutta la blockchain per intero) o light (scarica solo gli header dei blocchi) ?
- Quando invio una transazione questa si propaga prima a tutti i nodi della rete e poi viene minata?
- Nel momento in cui invio la transazione automaticamente il ricevente vede il suo credito aggiornarsi se ha un nodo full mentre se ha un nodo light deve attendere che la transazione sia validata e inclusa in un blocco?
- Che controlli applica un nodo per bloccare una transazione che utilizzi un importo già speso ma non ancora confermato?
Grazie a tutti |
|
|
|
|
Buongiorno ragazzi,
ho un dubbio sul tempo della creazioni dei blocchi...
Se ho ben capito nella blockchain BTC i ndoi creano un blocco ogni 10 minuti, ma se vado su blockchain.info noto che l'age tra i vari blocchi non è di 10 minuti... a volte di meno a volte di piu
Ad esempio tra il blocco 535760 e 535761 ci sono piu di 10 minuti.
Come è da interpretare?
|
|
|
|
Ciao grazie ancora per le risposte [quote ] Se i nodi facessero il broadcast delle tx non valide, un attaccante potrebbe sfruttare questa cosa per flooddare(ddossare) la rete con miliardi di tx che fanno doublespend dello stesso utxo. [/quote] Ok quindi una volta che la trx ha raggiunto tutti i nodi non è possibile fare doublespend corretto? NI se le fee sono zero, la tx probabilmente non sarà mai inclusa in un blocco. A puo' semplicemente aspettare che i nodi decidano che la tx vada in timeout(tempo a discrezione del singolo nodo, se non ricordo male sono circa 3 giorni) e quindi la cancellino dalla loro mempool.
Una volta che tutti i nodi si sono dimenticati della tx, A puo' fare doublespend dell'UTXO.
E' quello che ti dicevo anche prima quando parlavo dell'introduzione di RBF.
Ok ma supponi che il sistema non concepisca le fee, ogni transazione viene comunque lavorata dal nodo in ordine di arrivo, domanda è sempre la stessa per poter provare a fare double spend ho il tempo solo di propagazione della trx ai nodi e non quel tempo piu il tempo di preparazione del blocco? e A invii a B 5000 satoshi e la transazione viene propagata
Il risultato appena riportato rimarrà valido e quindi c'è una possibilità di double spending finche la transazione non si sarà propagata su tutti i nodi o finche la transazione non è inclusa in un blocco?
dovrebbe essere così.
quale delle due opzioni?  Il dubbio è che finchè la trx non è confermata e quindi inclusa in un blocco, sicuramente B non potrà spendere quanto ricevuto, ma A potrà fare il furbo e provare a usare una somma già "teoricamente" spesa ma ancora non confermata?
questo e' sbagliato, B puo' spendere non appena vede la tx(tx1) ricevuta. Se la tx1 ha zero fee, B puo' spendere l'utxo non confermato facendo una nuova tx(tx2) e mettendo delle fee altissime in modo da convincere i miner ad includere nel blocco anche la tx1. Ovviamente B dovrebbe fare il broadcast sia della tx1 che della tx2, in modo da assicurarsi che la tx1 non vada in timeout e che i miner vedano entrambe le tx. E' quello che dicevo quando parlavo di CPFP.
Corretto perchè ci sono questi meccanismi CPFP, ma supponi che il sistema sia all'inizio dove come ti dicevo prima le fee non ci sono tutte le trx vengono lavorate in ordine di arrivo al nodo, a quel punto B, anche se il suo wallet riporta il nuovo bilancio potrà spenderla solamente quando ci saranno le conferme ovvero inclusa in un blocco - 1 conferma, e per esserne certo max 6. Comincio a deprimermi, forse e' meglio se smetto di risponderti perche' mi sa che son proprio negato a spiegare le cose e ti creo solo piu' confusione.
Noooooo nn deprimerti, sono concetti non banali se uno ci ragiona in fondo e normale che ci siano delle incomprensioni  |
|
|
|
Ciao grazie per la risposta Lo stato pending non esiste, non capisco di cosa parli.
Pending è sinonimo di unconfirmed, cioè transazione che sono state inoltrate alla rete sono verificate a livello di SCRIPT ma non sono state ancora incluse in nessun blocco, cioè nessun miner le ha "considerate". Ogni miner seleziona le transazioni che vuole dalla sua mempool, le ordina, e calcola il merkle root. Ma questo merkle root,e' personale, ogni miner lo calcola indipendentemente, e un miner con molta potenza di hash, spesso, ne calcola pure piu' di uno, in modo da parallelizzare la ricerca del blocco tra i vari asics. Quindi tu non lo sai se il miner sta realmente lavorando alla tua transazione. Non lo sa nessuno su che transazioni stanno lavorando i miner. E' una informazione inutile comunque.
Chiaro Le connessioni fra i nodi della rete bitcoin, formano una rete mesh, quindi una informazione per raggiungere tutti i nodi ha bisogno di tempo, che si chiama tempo di propagazione, o ritardo di propagazione.
Le tecniche di doublespend degli UTXO consistono nello sfruttare i ritardi di propagazione delle tx(spesso pochi secondi o meno), nella rete.
Ok, credevo che finche la transazione non venisse inclusa in un blocco e aggiunta alla blockchain, durante quel periodo, min 10 minuti, si potesse procedere cmq con un double spend, mentre mi stai dicendo, se ho capito bene, che il periodo è solo quello di propagazione della transazione a tutti i nodi della rete, corretto? Ad esempio se faccio una trx di 1 btc da A a B (supponiamo che i costi di fee siano a zero), A per poter spendere nuovamente 1 btc ha il temppo di propagazione della transazione a tutti i nodi della rete e non quel tempo piu il tempo di elaborazione del blocco dove questa transazione sarà inclusa. Cioè sempre nello stesso esempio supponiamo che il wallet di A recuperi questi UTXO: {
"unspent_outputs":[
{
"tx_age":"1322659106",
"tx_hash":"e6452a2cb71aa864aaa959e647e7a4726a22e640560f199f79b56b5502114c37",
"tx_index":"12790219",
"tx_output_n":"0",
"script":"76a914641ad5051edd97029a003fe9efb29359fcee409d88ac", (Hex encoded)
"value":"5000661330"
}
]
}
e A invii a B 5000 satoshi e la transazione viene propagata Il risultato appena riportato rimarrà valido e quindi c'è una possibilità di double spending finche la transazione non si sarà propagata su tutti i nodi o finche la transazione non è inclusa in un blocco? Il dubbio è che finchè la trx non è confermata e quindi inclusa in un blocco, sicuramente B non potrà spendere quanto ricevuto, ma A potrà fare il furbo e provare a usare una somma già "teoricamente" spesa ma ancora non confermata? Spero di essere stato piu chiaro |
|
|
|
|
Ciao grazie per la risposta, ora me la studio attentamente, conosco il funzionamento della trx e del resto pero il dubbio nasceva dal fatto che credevo che durante il periodo in cui la transazione è "lavorata" dal miner ma ancora non inclusa nel blocco o ancora meglio propagata a tutti i nodi, questi non conoscono l'effettivo stato quindi il wallet potrebbe spendere non facendo apposta - facendola apposta laddove ci sia intenzione da parte dello sviluppatore .- lo stesso UTXO.
La mempool è diverso da pending credo perchè il pending è lo stato in cui la trx è stata considerata dal miner il mempool ancora no.
Non ero a conoscenza che se la transazione sta in mempool allora sia il wallet che i nodi rifiutassero ulteriori trx con input presi dalla UTXO giò in uso
Gli altri meccanismi descritti non ne ero a conoscenza adesso me li studio
Quindi in sostanza il wallet quando deve recuperare gli UTXO per creare dei nuovi input in una trx controlla parallelamente se gli stessi sono inclusi in qualche trx che attualmente è in pending o in mempool?
|
|
|
|
il wallet lo previene, e così pure gli altri nodi a cui comunichi la tua transazione, la seconda viene rifiutata. Come fa a prevenirlo, se ho solo un UTXO da 2 BTC e faccio una trx di 1 BTC al bar e prima che questa venga confermata (min 10 minuti) ne faccio una da 1.4 BTC al supermarket il wallet come me la impedisce? Comunque i modi per farlo, volendo smanettare un po', ci sono sempre stati. Si quello immaginavo, ma intendo in via teorica. Per questo hanno aggiunto RBF(replace by fee), così e' possibile fare doublespend in maniera "legit" aumentando le fee. Cambiando il concetto di doublespend, delle transazioni non confermate, dall'essere un problema, all'essere una feature. Questo ovviamente ha creato un sacco di FUD generato dai vari oppositori di btc.
No qua mi sono perso lo ammetto, forse perchè devo cenare non ti segui |
|
|
|
Poi invia al nodo full l'indirizzo di cui vuole recuperare gli UTXO, il nodo full risponde con la trx dove compare quell'indirizzo piu tutti gli hash delle trx contenuti in quel blocco dal quale può risalire alla merkle root.
In questo modo ha la prova che la trx fornita è inclusa effettivamente in quel blocco e recupera anche eventuali UTXO.
a grandissime linee e' così, in pratica no. Devi guardarti la bip37, che ammetto di non conoscere, non e' che il client manda realmente l'indirizzo(altrimenti non potrebbe conoscere le tx p2sh), fa delle richieste usando dei filtri.
Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto?
Grazie
FP
no, Nakamoto prevedeva i nodi SPV, anche nel whitepaper, ma non ha dettagliato precisamente come avrebbero dovuto funzionare. Ne ha dato solo delle linee guida generali, piu' o meno come quelle che ti ho dato io. Ok rido un'occhiata al wp, l'importante pero che il funzionamento a grandi linee del spv |
|
|
|
Salve ragazzi, in precedente post parlavo del double spending https://bitcointalk.org/index.php?topic=4460741.0ma secondo voi il wallet ha qualche meccanismo che blocca questo? Nel senso se pago un caffe in BTC e poi vado dal macellaio e impiego meno di 10 minuti, il wallet riseleziona lo stesso UTXO oppure ha un meccanismo di prevenzione interna per cui permette ciò? Grazie |
|
|
|
Ciao, grazie per la risposta: SPV=simple payment verification
VPS=virtual private server
non centrano niente, occhio a non confonderti
Errore di battitura un client spv non e' un vero client, non si collega alla rete bitcoin, si collega a un server che a sua volta e' collegato ad un full node.
dopo aver verificato l'header dei blocchi il client manda al server gli indirizzi di cui vuole conoscere le transazioni . Il server risponde con le tx rilevanti + gli hash, solo quelli, di tutte le tx contenute nei blocchi interessati, fornendo quindi una proof of inclusion.
Il client puo' quindi ricalcolare l'hash della tx in entrata(o uscita) e, utilizzando gli altri hash, calcolare il merkle root e verificarlo con quello del blocco.
Se ho capito bene, correggimi se scrivo fesserie, il client svp si scarica tutti gli headers dei vari blocchi dell'intera blockchain, da un nodo full e li verifica calcolando che l hash di ogni header sia minore o uguale al target riportato in ogni header. Poi invia al nodo full l'indirizzo di cui vuole recuperare gli UTXO, il nodo full risponde con la trx dove compare quell'indirizzo piu tutti gli hash delle trx contenuti in quel blocco dal quale può risalire alla merkle root. In questo modo ha la prova che la trx fornita è inclusa effettivamente in quel blocco e recupera anche eventuali UTXO. Questa procedura, non e' standard, e nemmeno e' stata descritta da Satoshi nel suo paper. I wallet spv moderni, mi sembra facciano riferimento a bip37Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto? Grazie FP |
|
|
|
|
