Bitcoin Forum
September 23, 2017, 07:46:44 AM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   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 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1979924 times)
sidhujag
Legendary
*
Offline Offline

Activity: 1582


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

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  ★☆★
1506152804
Hero Member
*
Offline Offline

Posts: 1506152804

View Profile Personal Message (Offline)

Ignore
1506152804
Reply with quote  #2

1506152804
Report to moderator
1506152804
Hero Member
*
Offline Offline

Posts: 1506152804

View Profile Personal Message (Offline)

Ignore
1506152804
Reply with quote  #2

1506152804
Report to moderator
The network tries to produce one block per 10 minutes. It does this by automatically adjusting how difficult it is to produce blocks.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1506152804
Hero Member
*
Offline Offline

Posts: 1506152804

View Profile Personal Message (Offline)

Ignore
1506152804
Reply with quote  #2

1506152804
Report to moderator
1506152804
Hero Member
*
Offline Offline

Posts: 1506152804

View Profile Personal Message (Offline)

Ignore
1506152804
Reply with quote  #2

1506152804
Report to moderator
1506152804
Hero Member
*
Offline Offline

Posts: 1506152804

View Profile Personal Message (Offline)

Ignore
1506152804
Reply with quote  #2

1506152804
Report to moderator
smooth
Legendary
*
Offline Offline

Activity: 1540



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

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

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?
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
April 27, 2015, 09:07:25 PM
 #23144


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?

Because trustlessness is the foundation upon which Bitcoin is built.

My node could leave the network for a few months, and, upon rejoining, determine the state of the ledger without requiring any new information beyond what is encoded in the candidate blockchains.  To do this, my node considers all valid chains and selects as the "best chain" the one with the highest cumulative work.

If it was not possible to verify every transaction (including the pruned ones) then how would my node know that nothing "funny" occurred while it was not connected?  Maybe some coins got moved without valid signatures?  [That being said, I'm still supportive of pruning--it's just that it must always remain possible for nodes to verify all transactions right back to the genesis block].  

Remember, this trustlessness is one property that separates a PoW system from a PoS system.  For example, a Nxt node needs new information upon rejoining the network (what they call economic clustering) in addition to what's encoded in the candidate blockchains.  I think this "not-quite-trustless-by-design" property of PoS is what Vitalik et al. refer to as "weak subjectivity."

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
April 27, 2015, 09:17:45 PM
 #23145

That being said, I'm still supportive of pruning--it's just that it must always remain possible for nodes to verify all transactions right back to the genesis block

Agree, in case that was not clear from my earlier comments.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 09:41:07 PM
 #23146


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?

Because trustlessness is the foundation upon which Bitcoin is built.

My node could leave the network for a few months, and, upon rejoining, determine the state of the ledger without requiring any new information beyond what is encoded in the candidate blockchains.  To do this, my node considers all valid chains and selects as the "best chain" the one with the highest cumulative work.

If it was not possible to verify every transaction (including the pruned ones) then how would my node know that nothing "funny" occurred while it was not connected?  Maybe some coins got moved without valid signatures?  [That being said, I'm still supportive of pruning--it's just that it must always remain possible for nodes to verify all transactions right back to the genesis block].  

Remember, this trustlessness is one property that separates a PoW system from a PoS system.  For example, a Nxt node needs new information upon rejoining the network (what they call economic clustering) in addition to what's encoded in the candidate blockchains.  I think this "not-quite-trustless-by-design" property of PoS is what Vitalik et al. refer to as "weak subjectivity."

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?
Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
April 27, 2015, 09:50:46 PM
 #23147

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security). 



Run Bitcoin Unlimited (www.bitcoinunlimited.info)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 09:56:57 PM
 #23148

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security). 




I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
April 27, 2015, 09:58:29 PM
 #23149

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security).
I'd like to think it's within the realm of possibility to create a ZKP that a given set of headers is only composed of the hashes of valid Bitcoin transactions.

If such a proof existed, it would be safe for the entire network to discard the old history.
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
April 27, 2015, 10:08:16 PM
 #23150

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security). 




I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Yes I agree. I would feel a bit better if there were an incentive to do it, but that isn't hard to imagine. Something like a small payment per block served should be enough to incentivize people to hold it (and also to share it when needed).

rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
April 27, 2015, 10:14:35 PM
 #23151

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security). 

I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

It does reduce the trustless aspect, but only slightly. With this you'd have to trust that the P2P network rejected any attempts to insert an invalid UTXO hash (which has the effect of being able to arbitrarily change unspent outputs). But to attack this, you essentially would have to take over the P2P network. Plus given how visible the blockchain is, I'd say any attempts to do this would be noticed and rejected in real time.

As the total blockchain gets very very large, I think we are going to need something like this. A UTXO hash would enable full nodes to operate without ever downloading past blocks, you'd only need headers (which is small) and the UTXO set. Otherwise we are forced to have new nodes download petabytes of data they'll never keep. Network BW is still a limited resource, so this aspect of bitcoin will become more and more of an issue.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 10:16:44 PM
 #23152

A couple things. Iirc, the UTXO set was not part of the original Satoshi design; which is why he proposed a slightly different means of trimming down the blockchain. It was added only later by the current core dev team.

Also, the block chain of a full node is never accessed except to serve blocks  to new nodes coming online or for reorgs; which is why the new proposal makes you save at least the last 288 blocks. So once you've verified your download, you can prune away yet still function completely as a full node would otherwise do.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 10:20:39 PM
 #23153

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security). 

I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

Yes, thanks for bringing this up; I was gonna say. I think that makes great sense as well.
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
April 27, 2015, 10:22:59 PM
 #23154

Also, the block chain of a full node is never accessed except to serve blocks  to new nodes coming online or for reorgs; which is why the new proposal makes you save at least the last 288 blocks. So once you've verified your download, you can prune away yet still function completely as a full node would otherwise do.

Again we are going to disagree a bit about what a "full node" means. To be full full node, you have to be able to serve blocks to peers who need them. When people talk about running full nodes to support the network, that is one form of support they are providing. Relaying is another. A pruned node only does the latter, not the former.

Peter R
Legendary
*
Offline Offline

Activity: 1050



View Profile
April 27, 2015, 10:27:13 PM
 #23155

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security).  

I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

Yes, thanks for bringing this up; I was gonna say. I think that makes great sense as well.

Right, and now we're back to one of Smooth's points that a network full of nodes that don't personally verify every transaction in each block back to the genesis block (e.g., by relying on UTXO commitments instead) doesn't offer the same level of trustlessness than one that does.

Run Bitcoin Unlimited (www.bitcoinunlimited.info)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 10:30:46 PM
 #23156

Also, the block chain of a full node is never accessed except to serve blocks  to new nodes coming online or for reorgs; which is why the new proposal makes you save at least the last 288 blocks. So once you've verified your download, you can prune away yet still function completely as a full node would otherwise do.

Again we are going to disagree a bit about what a "full node" means. To be full full node, you have to be able to serve blocks to peers who need them. When people talk about running full nodes to support the network, that is one form of support they are providing. Relaying is another. A pruned node only does the latter, not the former.



Agreed. But let me give you a practical consequence of what has happened.

I look at this situation and think instead of converting my current full nodes to pruned  nodes, I am thinking of how i will add at least a dozen or more new pruned nodes on those little compute sticks from Intel to every open, free wifi connection I can get my hands on.
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
April 27, 2015, 10:31:14 PM
 #23157

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security).  

I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

Yes, thanks for bringing this up; I was gonna say. I think that makes great sense as well.

Right, and now we're back to one of Smooth's points that a network full of nodes that don't personally verify every transaction in each block back to the genesis block (e.g., by relying on UTXO commitments instead) doesn't offer the same level of trustlessness than one that does.

Yes there are some interesting divergences between what it is reasonable to do as an individual (especially when the rest of the network does not take shortcuts) and what you want the network to do as a whole. I smell a bit of a free rider problem here.
smooth
Legendary
*
Offline Offline

Activity: 1540



View Profile
April 27, 2015, 10:32:15 PM
 #23158

Also, the block chain of a full node is never accessed except to serve blocks  to new nodes coming online or for reorgs; which is why the new proposal makes you save at least the last 288 blocks. So once you've verified your download, you can prune away yet still function completely as a full node would otherwise do.

Again we are going to disagree a bit about what a "full node" means. To be full full node, you have to be able to serve blocks to peers who need them. When people talk about running full nodes to support the network, that is one form of support they are providing. Relaying is another. A pruned node only does the latter, not the former.



Agreed. But let me give you a practical consequence of what has happened.

I look at this situation and think instead of converting my current full nodes to pruned  nodes, I am thinking of how i will add at least a dozen or more new pruned nodes on those little compute sticks from Intel to every open, free wifi connection I can get my hands on.

Yes I'm just making a point about terminology more than anything else. Previously we just had full nodes and clients. Now we have another category of nodes to consider. I don't think its bad that people can run nodes on smaller hardware.
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
April 27, 2015, 10:45:57 PM
 #23159

So it seems like there are two approaches:
  
The "strong" validation model allows anyone at any time (T) to validation the entire history.
The "weak" validation model allows anyone to validate T to T-N back in history.  We assume that at any time T1 that is currently unavailable there were people validating it.  

I like the strong model but in practice I think the weak one works fine and could be very useful for a micropayment sidechain.  To explain, consider this thought experiment:  Tomorrow somebody reveals that they've been mining all along and releases a competing blockchain starting from the genesis block that is longer than the current one and gives them all the coins.  Do you REALLY think all the people involved in Bitcoin would just be like "OK" we'll use your chain?  No way.  We'd issue a patch to the client that prefers "our" chain and probably create some hopefully temporary and unfortunately-centralized solution where Gavin or someone periodically stamps what he thinks is the valid chain.  The point is that the fact that the chain is globally accepted today, yesterday and last year actually makes it stronger than the math.


Here's an alternate idea:

create a hash of the UTXO sorted set (ok a Merkle tree of hashes would be better) and periodically issue it in a dummy txn.  Today, that can be done via the extra bytes.  Now anyone can use your published, hashed UTXO set (presumably its shared P2P), if they trust you.  

If the above is useful, next we create a soft-fork new op code that identifies this as a hash of the UTXO and miners don't accept block with an invalid UTXO.  Miners must put this UTXO hash in every (block number%31 ==0).  Clients don't use the most recent UTXO hash but the prior one.

So now we can have a very small client that is also trustless (well, a single miner would have to find 32 blocks in a row or 51% the network to fool a client).  Small clients could use even older UTXO sets if they are less trusting of the diversity of the miner network.  

The only problem with the above is that today 51%ing the network only lets you get all the newly minted coins and deny the ability of others to spend.  This is a pretty cool feature

But with the above a 51% miner could "mint" new coins (at least from the perspective of the small clients) and remove existing ones by creating a fake UTXO set.  You'd have to remove existing UTXOs or the # of coins would not match the coinbase issue rate.  But if a 51%er ever did this, the non-small clients would see it instantly and so there would presumably be a huge PSA.  So this idea is acceptable within the "weak" validation model...

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 10:56:43 PM
 #23160

I guess I don't understand. You've verified everything up to the time you exit the network. You have an  up to date UTXO set and the last 2016 blocks or so. When you return, you can  download all the blocks from the longest candidate chain and verify them working forward from the UTXO set , can you not?

Yes, that's fine provided there are nodes in the network that can serve you the blocks you haven't verified yourself. A brand new node of course needs to verify every transaction in every block all the way back to the genesis block (to keep the current level of security).  

I'm very comfortable with that fact. There will always be enough of us that will hold copies of the full blockchain out of purity or shear paranoia.

Personally I like the concept of adding a hash of the current UTXO set to each block. This would enable a new node to only download headers and the UTXO set as of the last block, and that would be enough to start operating as a full node.

Yes, thanks for bringing this up; I was gonna say. I think that makes great sense as well.

Right, and now we're back to one of Smooth's points that a network full of nodes that don't personally verify every transaction in each block back to the genesis block (e.g., by relying on UTXO commitments instead) doesn't offer the same level of trustlessness than one that does.

Actually, I wasn't agreeing with his whole concept of just depending on headers and a hash of the UTXO set for a full node. I still think it's important for every new full node to download the entire block chain initially to build a valid UTXO set before discarding  any blocks. But I do like the idea of adding a  hash of the UTXO set into each block to ensure it's integrity.
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 ... 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!