Bitcoin Forum
May 22, 2017, 11:34:15 PM *
News: If the forum does not load normally for you, please send me a traceroute.
 
   Home   Help Search Donate Login Register  
Poll
Question: Will you support Gavin's new block size limit hard fork of 8MB by January 1, 2016 then doubling every 2 years?
1.  yes
2.  no

Pages: « 1 ... 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 [1158] 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 ... 1559 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1901077 times)
sidhujag
Legendary
*
Offline Offline

Activity: 1456


View Profile
April 27, 2015, 01:53:24 AM
 #23141

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.

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
1495496055
Hero Member
*
Offline Offline

Posts: 1495496055

View Profile Personal Message (Offline)

Ignore
1495496055
Reply with quote  #2

1495496055
Report to moderator
There are several different types of Bitcoin clients. EWallets are like banks -- a central organization has complete control over your money. You shouldn't put much money in EWallets.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2254



View Profile
April 27, 2015, 02:33:13 AM
 #23142

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 Wink and where all the bleeding edge development is happening.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 03:48:03 AM
 #23143

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
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 03:58:35 AM
 #23144

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.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 04:07:26 AM
 #23145

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?

i think you are mixing up these concepts.

think of 3 types of nodes:

1.  SPV clients:  only store headers, no blockchain.  has to trust other mining peers by measuring their POW.  subject to Sybil attacks.
2.  full nodes:  full blockchain with all historical tx history.  heavy data storage demands which is what primarily drives up the cost of running a full node.
3.  Pruned full node:  in between #1 & #2.  highly cost effective as it trims the blockchain down to 1.3GB.  initially downloads entire blockchain to verify tx history and build UTXO set and then deletes older blocks up to 2016 blocks back (i hear it can vary depending on a flag with the minimum being 288).  pruned nodes won't be able to serve up the blockchain to new nodes but it can validate, verify, relay and mine.  they will actually improve mining decentralization.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 04:10:44 AM
 #23146

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.

UTXO's have always worked this way; throwing away the spent ones.  The UTXO set is very small compared to blocks because it only contains info on unspent data and doesn't contain any signatures or data, thus, this is not what results in less storage.  it is the discarding of old blocks.  in the case of saving the last 2016 blocks (minimum 288), 351874 of them as of now.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2282



View Profile
April 27, 2015, 05:23:54 AM
 #23147

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0  3F39 FC49 2362 F9B7 0769
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
April 27, 2015, 06:02:36 AM
 #23148

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Yes, keeping whole block ranges (randomly determined before pruning) is an important feature of pruning which will hopefully be included in due course.

sidhujag
Legendary
*
Offline Offline

Activity: 1456


View Profile
April 27, 2015, 07:09:04 AM
 #23149

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
smooth
Legendary
*
Online Online

Activity: 1414



View Profile
April 27, 2015, 07:13:09 AM
 #23150

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.
sickpig
Legendary
*
Offline Offline

Activity: 1162


View Profile
April 27, 2015, 09:37:54 AM
 #23151

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

I think that more than Bittorrent you should look at something along the line of DHT. There's a very informative thread in the Development & Technical Discussion
section of the forum... found:  

"Using a DHT to reduce the resource requirements of full nodes" by DeathAndTaxes
https://bitcointalk.org/index.php?topic=662734.msg7470866#msg7470866

Especially look at gmaxwell reply.

Another really helpful source of info about the approach adopted in the prune implementation is
this this 2014 thread on bitcoin core dev mailing list:

"[Bitcoin-development] Service bits for pruned nodes"
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CAPg%2BsBjSe23eADMxu-1mx0Kg2LGkN%2BBSNByq0PtZcMxAMh0uTg%40mail.gmail.com/#msg30779911


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 03:50:29 PM
 #23152

starting to roll:

sidhujag
Legendary
*
Offline Offline

Activity: 1456


View Profile
April 27, 2015, 05:33:53 PM
 #23153

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ? This would just optimize the p2p layer of the protocol but need to
ensure its safe from attacks maybe thats why we didnt
do it to be on safe side.

I think that more than Bittorrent you should look at something along the line of DHT. There's a very informative thread in the Development & Technical Discussion
section of the forum... found:  

"Using a DHT to reduce the resource requirements of full nodes" by DeathAndTaxes
https://bitcointalk.org/index.php?topic=662734.msg7470866#msg7470866

Especially look at gmaxwell reply.

Another really helpful source of info about the approach adopted in the prune implementation is
this this 2014 thread on bitcoin core dev mailing list:

"[Bitcoin-development] Service bits for pruned nodes"
http://sourceforge.net/p/bitcoin/mailman/bitcoin-development/thread/CAPg%2BsBjSe23eADMxu-1mx0Kg2LGkN%2BBSNByq0PtZcMxAMh0uTg%40mail.gmail.com/#msg30779911



Yea gmaxwell pretty much said its not worth it for the risks you inherit. And DeathAndTaxes pretty much admitted himself that a more efficient p2p layer without DHT complexity would solve the problem in an effective manor.

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 05:45:49 PM
 #23154

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.

Yes, keeping whole block ranges (randomly determined before pruning) is an important feature of pruning which will hopefully be included in due course.

So what  do all these pruned nodes do with the blocks they mine going forward? Immediately delete them after they get accepted into the longest chain?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 05:52:58 PM
 #23155

http://a16z.com/2015/04/27/a16z-podcast-the-five-stages-of-bitcoin-disdain-dismissal-curiosity-oh-fk-and-acceptance/
ssmc2
Hero Member
*****
Offline Offline

Activity: 938


View Profile
April 27, 2015, 06:45:52 PM
 #23156



Oh fuck indeed
sidhujag
Legendary
*
Offline Offline

Activity: 1456


View Profile
April 27, 2015, 06:54:20 PM
 #23157

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

In the current commit the blocks are pruned themselves.. which deletes the merkle tree. Satoshi's approach was more of a compacting of the block by pruning transactions instead of pruning blocks altogether.

hmm, I guess if all nodes ended up pruning the spent tx's there could be a point where a new node syncing would not be able to replay the chain and verify it properly? Even though the hash of the block is preserved , the spent transactions wouldn't be foudn anywhere to download them, so all you would have left is the UTXO, no more historical ledger for accounting purposes.

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
smooth
Legendary
*
Online Online

Activity: 1414



View Profile
April 27, 2015, 06:58:30 PM
 #23158

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.
sidhujag
Legendary
*
Offline Offline

Activity: 1456


View Profile
April 27, 2015, 07:20:13 PM
 #23159

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.

In the back of my mind im still intertwining the concepts of bandwidth/time required for sync versus storage requirements of the blockchain. The bandwidth/time was solved by SPV and perhaps ultimately for desktop users be useful to have a lite wallet download which would be in SPV node and have a default trust of a bitcoin foundation node or something configurable OOTB.. so avg joe can simply click on it and run, but with the fine line that its only for new users who don't already have a wallet.

The storage which isn't really that big of a problem but solves being able to store on smaller flash disks is now solved by the pruning of old blocks of spent outputs.

Correct?

★☆★Syscoin - Decentralized Marketplace and Multisig Platform
Pay with Bitcoin, ZCash and many more
For more visit Syscoin.org  ★☆★
smooth
Legendary
*
Online Online

Activity: 1414



View Profile
April 27, 2015, 07:33:13 PM
 #23160

Did you see the latest commit on pruning? Allows you to specify max disk usage and it prunes old blocks.. validates by reindexing which downloads all chain then prunes. You check it out? I wonder what the point is if youhave todownload the full chain anyway why prune? The main bottleneck is the lenghty sync time not storage space.
I also noticed that it has logic to stop sending blocks requested that have been pruned. So there is assumption that there are full nodes out there to give you the block that others have pruned.

There's also a plan to let you keep certain block ranges and network protocol addition to advertise which parts a node has. That way, full block data can be kept in a distributed fashion while nodes can still run (and contribute more meaningfully than just as a relay and utxo set provider) even with disk space limits.

In fact with that it would be theoretically possible to run the network (fully trustable) without any node having storage space for the whole blockchain.
Kinda like bittorrent ?

Not exactly. BitTorrent distributes the entire file to all peers and in fact it actively tries to distribute pieces with a low count more quickly. In this case, not every node would have every block by design. It's a bit more dangerous what is being proposed. An attacker can prevent new nodes from syncing by finding all of the nodes that have a particular piece of the blockchain (whichever piece is rarest) and attacking them.

Still, as long as there is one good copy of the blockchain in the world, it can always be sent out again. So I don't think we need to worry too much. Some people will still run nodes without pruning.

Isn't the pruning approach Satoshi alluded to in his whitepaper #7 (https://bitcoin.org/bitcoin.pdf) the better approach? The hash of the block remains so full verification is still possible after pruning.. blocks are still around just the spent tx's are gone... so you can reindex to get them again if you wish.

No, unless you can verify the flow of transactions yourself you are ultimately trusting the miners. They put the transaction in the block; the hash proves that. But how do you know they were not cheating when they did? Also, you don't know that they didn't prune something they shouldn't. Maybe you got a payment, and the miner doesn't want you to see it (or the government told him to remove it), so they prune it (retaining only the hash, but the block is still valid).

Satoshi's pruning is basically the same in terms of trust as SPV.

In the back of my mind im still intertwining the concepts of bandwidth/time required for sync versus storage requirements of the blockchain. The bandwidth/time was solved by SPV and perhaps ultimately for desktop users be useful to have a lite wallet download which would be in SPV node and have a default trust of a bitcoin foundation node or something configurable OOTB.. so avg joe can simply click on it and run, but with the fine line that its only for new users who don't already have a wallet.

The storage which isn't really that big of a problem but solves being able to store on smaller flash disks is now solved by the pruning of old blocks of spent outputs.

Correct?

The current pruning scheme that is implemented compromises nothing in terms of trust. You receive the entire blockchain and verify it completely, but you only keep some N recent blocks (or maybe specified amount of storage? i'm not sure). It uses the same bandwidth as before, but less storage.

This doesn't really address where those old blocks will be stored, so that is being worked on as discussed in the last several posts.

If you want to reduce bandwidth you are going to end up with various weaker models in terms of trust because since you aren't receiving the entire chain, you obviously can't verify everything yourself. You end up needing to trust somebody somehow.

SPV is fine for end users, and it has pretty much the minimum possible bandwidth usage. It does have some privacy compromises because you have to tell the nodes which addresses you are interested in (or at least a superset of that).

Satoshi's pruning is ultimately similar to SPV in terms of trust (you are trusting the miners) but has intermediate bandwidth usage (less than full trustless verification and more than SPV) and unlike SPV does allow mining.


Pages: « 1 ... 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 [1158] 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 ... 1559 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!