Gold collapsing. Bitcoin UP.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

[sidhujag]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

No,  you do download the entire block chain at first to independently verify. Only them do you delete all but the last 200 or so blocks.

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

No,  you do download the entire block chain at first to independently verify. Only them do you delete all but the last 200 or so blocks.

That's exactly what I said cyperdoc.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

No,  you do download the entire block chain at first to independently verify. Only them do you delete all but the last 200 or so blocks.

That's exactly what I said cyperdoc.

Then I didn't understand this part:

"In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model."

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

No,  you do download the entire block chain at first to independently verify. Only them do you delete all but the last 200 or so blocks.

That's exactly what I said cyperdoc.

Then I didn't understand this part:

"In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model."

By "prune syncing" I meant reduce the amount of bandwidth needed for syncing so that it doesn't grow arbitrarily with the length of the chain. That doesn't exist currently.

[justusranvier]

By "prune syncing" I meant reduce the amount of bandwidth needed for syncing so that it doesn't grow arbitrarily with the length of the chain. That doesn't exist currently.

I think that a yet-to-be-invented zero knowledge proof could probably achieve this eventually.

[sidhujag]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

[sidhujag]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

[sidhujag]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

By unspent I assume you mean the ones in mempool. But how would one import their wallet key into an spv thin client backed by a pruned node and get correct balance? It needs tx that have been pruned?

[smooth]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

By unspent I assume you mean the ones in mempool.

No mempool is unconfirmed. Unspent is means unspent. Meaning not already spent and you could therefore spend them. The total of your unspent outputs equals your balance.

But how would one import their wallet key into an spv thin client backed by a pruned node and get correct balance? It needs tx that have been pruned?

Wallet imports the private key and derives a public address. Address is sent to a node, which finds all the unspent transactions for that address and returns them.

You might not get old transactions (if pruned), but you will get any and all coins that are available for spending, which add up to the correct balance.

[sidhujag]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

By unspent I assume you mean the ones in mempool.

No mempool is unconfirmed. Unspent is means unspent. Meaning not already spent and you could therefore spend them. The total of your unspent outputs equals your balance.

But how would one import their wallet key into an spv thin client backed by a pruned node and get correct balance? It needs tx that have been pruned?

Wallet imports the private key and derives a public address. Address is sent to a node, which finds all the unspent transactions for that address and returns them.

You might not get old transactions (if pruned), but you will get any and all coins that are available for spending, which add up to the correct balance.

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

[smooth]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

[sidhujag]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

Makes total sense. Yea I even read that part of the code didn't clue in, duh.

[marcus_of_augustus]

cool thanks, but I thought unspent outputs would be derived from transactions which would no longer exist in the "backend" node. How does it know the unspent balance without tallying up all of the transactions it was involved in?

The way pruning works is the node still receives all transactions as before. The ones that get spent, it throws away. So the ones left are the ones it keeps in its database. Those are the unspent ones. This requires much less storage.

Makes total sense. Yea I even read that part of the code didn't clue in, duh.

The unspent transaction outputs (UTXO) is the actual distributed ledger. They are contained within the journal of all transactions seen on the network (the blockchain) which needs to be sorted through and filtered for unspent outputs.

You can tell all the "blockchain tech." was a bunch of marketing BS spouted by followers, not leaders, because the blockchain is already obsolete. UTXO is the future and where all the bleeding edge development is happening.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

this is why spv clients will sample several different peers.

[cypherdoc]

My understanding is you download the whole blockchain first for verificatio,  then delete all but around the last 200 or so blocks. It works off the UTXO set.

In the case of the compute stick, you could use a separate SSD to initialize the blockchain, then disconnect it. Sticking these things in every nook and cranny could be a real problem for those against Bitcoin.

So for basically to allow for p2p tx and block relaying around the globe thru smaller mediums. The main use case I woulda thought is to reduce time for new nodes to sync up.. Since we know the price of hd is falling faster then the need for that space.

The pruning stuff does not reduce sync time at all, though the recent headers-first and syncing improvements do.

In order to prune syncing you have to relax the idea of independent verification and rely on someone else telling you that the part of the chain you are seeing is valid (as with SPV nodes). That's a major change to the Bitcoin trust model.

With spv you only get headers and maybe coinbase tx correct? So you wont be able to import your pvt key and get your txs in spv mode..

No you tell the server the addresses you are interested in and it gives you those tx. However, since you don't see the other tx you can't be sure that the tx you receive actually represent a valid chain of custody back to a coinbase (unless you trust the miners).

Ahh i see so essentialy those that dont want to sync fully can download a lite wallet which gets blocks via spv mode via a trusted node( ssl rpc).. so pruning doesnt really come into play here? If you prune then you wont be able to get your tx if trusted node pruned that block. So spv solves the blockchain sync time and pruning solves what? Being able to store on small flash disks running to relay transactions?

SPV solves being able to create and receive transactions without the bandwidth requirements of a node. Pruning solves being able to run a node that validates and relays transactions (and can even mine!) without storing the entire blockchain. They can even serve SPV clients, because they have all of the unspent transactions, and that's all SPV clients would ever want. These nodes just can't sync new nodes though (at least not by themselves) since they don't have all the old blocks to share.

actually, pruned nodes can't interact with SPV clients since they won't have the blocks. 

SPV clients use a bloom filter looking for the addresses and transactions they are interested in to the peer. The peer then only includes the relevant transactions in blocks it returns, together with their Merkle paths to prove that these transactions were indeed part of returned block.