3 replaced http://bitcoin.stackexchange.com/ with https://bitcoin.stackexchange.com/
source | link

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. SPV wallets sync very fast because they validate only headers and not the payload.

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answerthis answer for details.

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. SPV wallets sync very fast because they validate only headers and not the payload.

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. SPV wallets sync very fast because they validate only headers and not the payload.

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

2 added 25 characters in body
source | link

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. This is how SPV mode works -- it validateswallets sync very fast because they validate only headers and not the payload.  

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. This is how SPV mode works -- it validates only headers.  

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. SPV wallets sync very fast because they validate only headers and not the payload.

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.

1
source | link

A block has two parts: a short header (metadata) and a (possibly large) payload containing the actual transactions. Header contains all the necessary data to validate the PoW and chain of headers since the genesis block header. Additionally, each header contains an authenticating value of its payload. This is how SPV mode works -- it validates only headers.

If a block contains transactions whose outputs have not been spent, then nodes must store that block to prove to another bootstrapping node that the UTXO set indeed contains a certain element. On the other hand, if all outputs generated in a block (say X) have been spent, than a node can discard block X and say to another bootstrapping node "all UTXO of block X have been spent, just validate header and move on".

This is a conservative approach. While a bootstrapping node cannot be fooled into accepting invalid UTXOs, we also cannot prove to that node that "all UTXO of block X have been spent" without exhibiting the actual payload.

Now the question may be: How do SPV nodes obtain and maintain an untampered UTXO set? See this answer for details.