Si ma io vorrei capire se il wallet sul telefono è un client SPV quindi sul mio telefono ho tutti gli header della blockchain?

Non ho capito quando parli di :
quindi il mio telefono è un client spv? ma il client spv per definizione non tiene solo gli headers di tutti i blocchi?

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?

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?



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?

quale delle due opzioni? 

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.

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

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".

Chiaro


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:


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?

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?



Si quello immaginavo, ma intendo in via teorica.


No qua mi sono perso lo ammetto, forse perchè devo cenare non ti segui

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.0

ma 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:



Errore di battitura


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. 


Quindi secondo Nakamto il sistema doveva essere costituito solamente da full node giusto?


Grazie
FP