Arulbero non ho capito se hai scritto tu quel msg oppure se lo hai tradotto dal sito indicato sotto , ma comunque sia ti ringrazio se lo hai trdotto, ma se lo hai scritto tu dovresti metterti a scrivere libri sul bitcoin per principianti, perchè finalmente ho capito tutto
Ho preso alcune cose dai link indicati e poi ho rielaborato, se hai capito lo scopo è stato raggiunto. D'altronde per deformazione professionale tendo a rielaborare i concetti, semplificarli e spiegarli a qualcuno per capire meglio anch'io (così fanno di solito quelli che fanno il mio mestiere
)
Dove vengono memorizzate le informazioni che non compaiono in blockchain legate al segwit?
Bisogna scendere proprio nei dettagli dell'implementazione del BIP 141/142 e nel come è fatta una transazione.
Ogni transazione contiene due componenti principali.
La prima sblocca i bitcoin che erano vincolati in transazioni precedenti (UTXO : Unspent Transaction Output), e per fare questo si usano dei dati detti "input". Gli input includono uno o più script, cioè delle istruzioni su come sbloccare gli UTXO, questi script si chiamano "scriptSig".
L'altra parte della transazione consiste in uno o più nuovi "lucchetti" detti output, i quali ribloccano la stessa quantità (o meno) di bitcoin; gli output includono script detti "scriptPubKeys".
Le istruzioni per sbloccare i bitcoin lavorano su una firma e sulla chiave pubblica relativi all'indirizzo mittente,
le istruzioni sul blocco dei bitcoin (i lucchetti) vincolano i bitcoin all'indirizzo del destinatario.
In questo modo i bitcoin effettivamente si muovono dagli input agli output all'interno di una singola transazione (vengono svincolati e rivincolati allo stesso tempo), e così "passano" istantaneamente da una transazione all'altra (e da un address all'altro, cioè da un vincolo a un altro).
Che differenza c'è tra una transazione normale e una transazione segwit?
In sostanza si operano due cambiamenti nella transazione.
1)
la firma (con la chiave pubblica del mittente) viene spostata dal campo "scriptSig" a un nuovo campo "witness" (che è sempre un campo della transazione!);
questo vuol dire "segregated witness", firma separata (segregata in un campo della transazione che non verrà incluso nell'hash della transazione, cioè non impatterà sulla txid)
2)
il testo del campo "scriptPubKey" viene modificato in modo che abbia due significati diversi per un vecchio nodo e per un nuovo nodo (ecco il soft fork!); NB: in quel campo rimane sempre la condizione che blocca i bitcoin (i bitcoin vengono bloccati con l'indirizzo del ricevente, ovvero i fondi vengono vincolati alla chiave pubblica che genera l'indirizzo del ricevente);
in questo caso la condizione di blocco diventa per il vecchio nodo un "non vincolo", cioè un generico "ANYONE CAN SPEND" (un output solo apparentemente non vincolato a nessun indirizzo e quindi spendibile da chiunque) poichè il vecchio nodo non legge
i nuovi indirizzi/script "pay-to-witness-public-key-hash" P2WPKH (
per ulteriori dettagli vedi in fondo al post ***), mentre per i nuovi nodi che conoscono i nuovi indirizzi e il nuovo modo di interpretare quei dati si tratta sempre di una transazione che manda dei bitcoin a un indirizzo preciso
Standard Transaction to Bitcoin address (pay-to-pubkey-hash) P2PKH
scriptSig: scriptPubKey: OP_DUP OP_HASH160
OP_EQUALVERIFY OP_CHECKSIG
Witness Transaction (pay-to-witness-public-key-hash) P2WPKH
The following example is a version 0 pay-to-witness-public-key-hash (P2WPKH):
witness: <-- in questo campo vengono trasferiti la firma e la chiave pubblica del mittente
scriptSig: (empty) <-- questo campo viene svuotato della firma e della chiave pubblica del mittente
scriptPubKey: 0 <20-byte-key-hash> <-- il significato di questo campo viene spiegato in fondo al post
(0x0014{20-byte-key-hash})
The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items. The HASH160 of the pubkey in witness must match the witness program.
The signature is verified as
CHECKSIG
Comparing with a traditional P2PKH output, the P2WPKH equivalent occupies 3 less bytes in the scriptPubKey, and moves the signature and public key from scriptSig to witness.
I vecchi client non vedono proprio il nuovo campo "witness" (essi scaricano i blocchi depurati dal campo "witness"), i nuovi sì. Quando si fa l'hash della transazione però per creare il suo ID (txid), il campo "witness" non viene incluso (questo fatto sistema la questione della malleabilità).
Quindi nella blockchain quel campo (la firma) in realtà c'è (anche se un nodo a cui non interessa fare una validazione completa può fare il pruning di quel campo), sicuramente non c'è però (non viene considerata) nell'hash della transazione (txid).
Quest'ultimo fatto di per sè renderebbe la parte "witness" l'unica parte della blockchain potenzialmente modificabile, in quanto svincolata dalla txid e di conseguenza dall'hash del blocco che a sua volta dipende dall'hash delle transazioni che contiene; per ovviare a questo fatto viene costruito un altro Merkle Tree e di conseguenza ricavato un Merkle Root relativo solo ai campi "witness" di tutte le transazioni del blocco, e quest'ultimo dato viene infine inserito nel campo di input della coinbase del blocco (in questo modo cambia l'ID solo di quella transazione ma questo è sufficiente per modificare l'hash del blocco, di conseguenza la presenza di ogni campo witness del blocco viene fissata per sempre anche nell'hash del blocco stesso, ma ripeto non nell'hash della transazione.)
In sostanza le firme vengono collegate (dal punto di vista della verifica della consistenza della blockchain) per sempre al blocco tramite il suo hash, mentre rimangono scollegate dalla txid della transazione a cui appartengono, e questo porta diversi vantaggi dal punto di vista tecnico (ad esempio finora per ricostruire il database degli UTXO bisogna identificare gli input delle transazioni facendo riferimento a una txid che dipende a sua volta dalla firma, ma la firma dovrebbe servire solo ad autorizzare una transazione, non a identificarla! Con le transazioni witness la firma manterrà solo la sua funzione specifica e non creerà ulteriore lavoro inutile per identificare gli input).
Signatures for historical transactions may be less interesting than signatures for future transactions – for example, Bitcoin Core does not check signatures for transactions prior to the most recent checkpoint by default, and some SPV clients simply don’t check signatures themselves at all, trusting that has already been done by miners or other nodes. At present, however, signature data is an integral part of the transaction and must be present in order to calculate the transaction hash.
Segregating the signature data allows nodes that aren’t interested in signature data to prune it from the disk, or to avoid downloading it in the first place, saving resources.
Quale sarà allora la dimensione di ogni blocco?
Esso potrà contenere delle transazioni purchè sia rispettata questa disequazione:
lo spazio occupato dalla parte "standard" delle transazioni (senza contare il campo witness) + 1/4 dello spazio occupato dal campo witness delle stesse transazioni <= 1 Mega
Since old nodes will only download the witness-stripped block, they only enforce the 1 MB block size limit rule on that data. New nodes, which understand the full block with witness data, are therefore free to replace this limit with a new one, allowing for larger block sizes. Segregated witness therefore takes advantage of this opportunity to raise the block size limit to nearly 4 MB, and adds a new cost limit to ensure blocks remain balanced in their resource use (this effectively results in an effective limit closer to 1.6 to 2 MB).
In questo modo quindi
la dimensione del blocco può (e lo farà) superare tranquillamente 1 Mega per i nuovi client (si stima possa arrivare a 1,5/2 Mega effettivi?)
mentre i vecchi nodi scaricheranno sempre meno di 1 Mega (poichè essi non vedono il "witness").
Il fatto di considerare solo 1/4 del peso del witness (cioè delle firme) mira a favorire l'uso del sigwit, pochè esso porta molti vantaggi (ad esempio il fatto che la ID di una transazione non dipenda più da "scriptSig" rende più facile ricostruire l'insieme degli UTXO mentre finora bisognava scaricare anche le firme solo per ricostruire le txid; l'elenco completo dei vari vantaggi si trova qui
https://bitcoincore.org/en/2016/01/26/segwit-benefits/)
The Unspent Transaction Output (UTXO) database is maintained by each validating Bitcoin node in order to determine whether new transactions are valid or fraudulent. For efficient operation of the network, this database needs to be very quick to query and modify, and should ideally be able to fit in main memory (RAM), so keeping the database’s size in bytes as small as possible is valuable.
Segwit improves the situation here by making signature data, which does not impact the UTXO set size, cost 75% less than data that does impact the UTXO set size. This is expected to encourage users to favour the use of transactions that minimise impact on the UTXO set in order to minimise fees, and to encourage developers to design smart contracts and new features in a way that will also minimise the impact on the UTXO set.
Because segwit is a soft-forking change and does not increase the base blocksize, the worst case growth rate of the UTXO set stays the same.
In futuro quindi potremo finalmente liberarci di giga di firme non più necessarie (solo quelle nel campo witness però! non quelle tradizionali che sono legate alle txid e quindi sono necessarie per ricostruire il database degli UTXO), come afferma lo stesso Pieter Wuille, il promotore di questo soft fork:
We all know how bitcoin transactions work. Every bitcoin transaction gets inputs, which refer to previous outputs being spent. Every input has the txid and the signature to prove that it is allowed, plus an amount and script in every output. What this presentation will mostly be about is the question of whether all of this data is equally important.
In particular, we are going to be talking about signatures. It's important to realize here that signatures are really only needed for fully-validating nodes. As a light-weight client, you are not validating signatures, even though they are part of the transactions you still have to download them. If you are using a full-node that is syncing historical data, you don't actually validate all of the signatures in there. Currently there is a mechanism in there using checkpoints, which we want to deprecate soon, but the result will still be that we're not validating all signatures from years ago in deep history.
These signatures are only needed at time of validation. They don't go into the UTXO set, the database of all unspent coins. These unspent transaction outputs don't enter into the UTXO set. This is a significant cost on the resources of both keeping a node running but also the speed of propagation and access to the UTXO set needs to be fast. Of all the data in a transaction, signatures don't go into the UTXO set, even though they account for 60% of the blockchain data. Segregated witness is about ignoring this whenever possible.
Where does the name witness come from? For now, it's motsly a word to refer to the scriptSig in inputs or signatures inside transactions. Later I will extend this meaning. The reason for this name is because signatures are not part of the transaction. They don't describe what the transaction is doing. The only thing they are doing is proving that the transaction is authorized by the previous owners of the coins. There are usually multiple possible valid signature for the same transaction. We don't really care what the signature is, all we care about is that at least one signature for that existed. Such an example of where something exists is known as a witness.
Wouldn't it be nice to just drop the signatures? The reason why we can't do this is because the signature is part of the transaction hash. If we would just drop the sig from the transaction, the block wouldn't validate, you wouldn't be able to prove an output spend came from that transaction, so that's not something we could do. But let's simplify the problem. What if we could redesign Bitcoin from scratch? What if you're designing an altcoin, there's really no reason why you would want to do this in Bitcoin. This is actually something we did in sidechain alpha.
You would mark the signature data as special. You are indicated by green color on this slide. Everything but the green part goes into the hash of a transaction. The signature doesn't. It's just a piece of data that's still there, but we don't consider it part of the transaction.
What are the advantages of this? It allows you to drop the signatures from relay whenever you are relaying to a node that is not actually doing full-validation at the time. It also allows us to effectively prune this data from history, maybe we're fine with not all nodes in the network actually maintaining these gigabytes of signatures that are buried under years of proof-of-work now.
fonti:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/https://bitcoinmagazine.com/articles/segregated-witness-part-how-a-clever-hack-could-significantly-increase-bitcoin-s-potential-1450553618https://bitcoinmagazine.com/articles/segregated-witness-part-why-you-should-care-about-a-nitty-gritty-technical-trick-1450827675https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Exampleshttps://github.com/bitcoin/bips/blob/master/bip-0142.mediawiki***
Example
The following public key,
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A 299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
when encoded as a P2PKH template, would become: <-- normale transazione
scriptPubKey: DUP HASH160 <010966776006953D5567439E5E39F86A0D273BEE> EQUALVERIFY CHECKSIG
With the corresponding version 1 Bitcoin address being:
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM
When the same public key is encoded as P2WPKH, the scriptPubKey becomes: <-- transazione con firma separata (segwit)
scriptPubKey: OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
Using 0x06 as address version, followed by 0x00 as witness program version, and a 0x00 padding, the equivalent P2WPKH address is:
p2xtZoXeX5X8BP8JfFhQK2nD3emtjch7UeFm
scriptPubKey: OP_0 <010966776006953D5567439E5E39F86A0D273BEE>
scriptPubKey: 0 <20-byte-key-hash>
(0x0014{20-byte-key-hash})
It's a data push that contains the witness program hash, prepended by OP_0.
Old nodes will evaluate this as a script that just pushes two data items onto the stack (a 0 and a hash). That's obviously spendable by all, as the requirement is having a non-zero item as last element on the stack.
The '0' in scriptPubKey indicates the following push is a version 0 witness program. The length of the witness program indicates that it is a P2WPKH type. The witness must consist of exactly 2 items
