Bitcoin Forum
December 08, 2016, 10:22:14 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   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 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1806501 times)
smooth
Legendary
*
Offline Offline

Activity: 1246



View Profile
April 27, 2015, 01:36:55 AM
 #23141

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.

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

1481235734
Hero Member
*
Offline Offline

Posts: 1481235734

View Profile Personal Message (Offline)

Ignore
1481235734
Reply with quote  #2

1481235734
Report to moderator
1481235734
Hero Member
*
Offline Offline

Posts: 1481235734

View Profile Personal Message (Offline)

Ignore
1481235734
Reply with quote  #2

1481235734
Report to moderator
1481235734
Hero Member
*
Offline Offline

Posts: 1481235734

View Profile Personal Message (Offline)

Ignore
1481235734
Reply with quote  #2

1481235734
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481235734
Hero Member
*
Offline Offline

Posts: 1481235734

View Profile Personal Message (Offline)

Ignore
1481235734
Reply with quote  #2

1481235734
Report to moderator
1481235734
Hero Member
*
Offline Offline

Posts: 1481235734

View Profile Personal Message (Offline)

Ignore
1481235734
Reply with quote  #2

1481235734
Report to moderator
sidhujag
Legendary
*
Offline Offline

Activity: 1302


View Profile
April 27, 2015, 01:47:49 AM
 #23142

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.

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

Activity: 1246



View Profile
April 27, 2015, 01:51:09 AM
 #23143

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

Activity: 1302


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

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

Activity: 2100



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

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
 #23146

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
 #23147

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
 #23148

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
 #23149

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



View Profile
April 27, 2015, 05:23:54 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.

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

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


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

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

Activity: 1246



View Profile
April 27, 2015, 07:13:09 AM
 #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 ?

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


View Profile
April 27, 2015, 09:37:54 AM
 #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.
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
 #23155

starting to roll:

sidhujag
Legendary
*
Offline Offline

Activity: 1302


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

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

Activity: 1764



View Profile
April 27, 2015, 05:45:49 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.

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
 #23158

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


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



Oh fuck indeed
sidhujag
Legendary
*
Offline Offline

Activity: 1302


View Profile
April 27, 2015, 06:54:20 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.

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.
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 ... 1560 »
  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!