Bitcoin Forum
November 24, 2017, 04:22:37 AM *
News: Latest stable version of Bitcoin Core: 0.15.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 ... 1107 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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2013486 times)
molecular
Donator
Legendary
*
Offline Offline

Activity: 2408



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

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
1511497357
Hero Member
*
Offline Offline

Posts: 1511497357

View Profile Personal Message (Offline)

Ignore
1511497357
Reply with quote  #2

1511497357
Report to moderator
1511497357
Hero Member
*
Offline Offline

Posts: 1511497357

View Profile Personal Message (Offline)

Ignore
1511497357
Reply with quote  #2

1511497357
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511497357
Hero Member
*
Offline Offline

Posts: 1511497357

View Profile Personal Message (Offline)

Ignore
1511497357
Reply with quote  #2

1511497357
Report to moderator
1511497357
Hero Member
*
Offline Offline

Posts: 1511497357

View Profile Personal Message (Offline)

Ignore
1511497357
Reply with quote  #2

1511497357
Report to moderator
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


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

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


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

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

Activity: 1610



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

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


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

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

starting to roll:

sidhujag
Legendary
*
Offline Offline

Activity: 1652


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

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

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

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

Activity: 1106


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



Oh fuck indeed
sidhujag
Legendary
*
Offline Offline

Activity: 1652


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

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

Activity: 1610



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

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


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

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

Activity: 1610



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

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.


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 07:36:15 PM
 #23135

Not normally a fan of Kashmir Hill but this was well written:

http://fusion.net/story/125475/ai-weiwei-jacob-appelbaum-and-laura-poitras/
sidhujag
Legendary
*
Offline Offline

Activity: 1652


View Profile
April 27, 2015, 07:40:43 PM
 #23136

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.




If you are a new user why would you want to reverify transactions you don't care about?

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

Activity: 1610



View Profile
April 27, 2015, 07:48:49 PM
 #23137

If you are a new user why would you want to reverify transactions you don't care about?

1. You might want to know that transactions aren't violating the rules that would compromise the integrity of the system (and therefore the value of your own coins).

2. How do you know the coins you receive are real? In theory you could trace back only the coins you receive in an SPV-line manner, but as coins get split and combined this seems in practice to grow to much or all of the chain before long.

3. Maybe you in fact don't care and would find a higher trust level acceptable.
sidhujag
Legendary
*
Offline Offline

Activity: 1652


View Profile
April 27, 2015, 07:58:47 PM
 #23138

If you are a new user why would you want to reverify transactions you don't care about?

1. You might want to know that transactions aren't violating the rules that would compromise the integrity of the system (and therefore the value of your own coins).

2. How do you know the coins you receive are real? In theory you could trace back only the coins you receive in an SPV-line manner, but as coins get split and combined this seems in practice to grow to much or all of the chain before long.

3. Maybe you in fact don't care and would find a higher trust level acceptable.

A new user wouldn't have any coins yet.... they would first need an address. So #1 doesn't really apply they are trusting the node they are connected to (blockchain foundation or something)... the people are care about security would fully verify. Those that import their pvt key would reverify too.

You trust the foundation in the same way that you must trust that they won't commit bad code that may compromise the value of their coins aswell.

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

Activity: 1610



View Profile
April 27, 2015, 08:37:10 PM
 #23139

If you are a new user why would you want to reverify transactions you don't care about?

1. You might want to know that transactions aren't violating the rules that would compromise the integrity of the system (and therefore the value of your own coins).

2. How do you know the coins you receive are real? In theory you could trace back only the coins you receive in an SPV-line manner, but as coins get split and combined this seems in practice to grow to much or all of the chain before long.

3. Maybe you in fact don't care and would find a higher trust level acceptable.

A new user wouldn't have any coins yet.... they would first need an address. So #1 doesn't really apply they are trusting the node they are connected to (blockchain foundation or something)... the people are care about security would fully verify. Those that import their pvt key would reverify too.

You trust the foundation in the same way that you must trust that they won't commit bad code that may compromise the value of their coins aswell.

I think you don't understand the concept of trustlessness. The design of bitcoin doesn't trust a foundation. Yes, in practice we have to trust the developers today because the system isn't fully built yet, although maybe that's not true. If there were no more commits ever, it still might continue to work indefinitely in some manner (obviously blocks size limit would be an issue, so if it did continue to function it would be some kind of gold-like backing asset, not transactional).

Bitcoin without pruning is trustless by design (though maybe not 100% in practice). You can verify everything yourself. With pruning it is not trustless even by design.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 08:49:23 PM
 #23140

If you are a new user why would you want to reverify transactions you don't care about?

1. You might want to know that transactions aren't violating the rules that would compromise the integrity of the system (and therefore the value of your own coins).

2. How do you know the coins you receive are real? In theory you could trace back only the coins you receive in an SPV-line manner, but as coins get split and combined this seems in practice to grow to much or all of the chain before long.

3. Maybe you in fact don't care and would find a higher trust level acceptable.

A new user wouldn't have any coins yet.... they would first need an address. So #1 doesn't really apply they are trusting the node they are connected to (blockchain foundation or something)... the people are care about security would fully verify. Those that import their pvt key would reverify too.

You trust the foundation in the same way that you must trust that they won't commit bad code that may compromise the value of their coins aswell.

I think you don't understand the concept of trustlessness. The design of bitcoin doesn't trust a foundation. Yes, in practice we have to trust the developers today because the system isn't fully built yet, although maybe that's not true. If there were no more commits ever, it still might continue to work indefinitely in some manner (obviously blocks size limit would be an issue, so if it did continue to function it would be some kind of gold-like backing asset, not transactional).

Bitcoin without pruning is trustless by design (though maybe not 100% in practice). You can verify everything yourself. With pruning it is not trustless even by design.


You keep saying this. Why?
Pages: « 1 ... 1107 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 ... 1558 »
  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!