Bitcoin Forum
December 11, 2016, 12:37:38 AM *
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 ... 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 1209 1210 1211 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1808255 times)
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
April 28, 2015, 02:40:43 AM
 #23201

You don't seem to quite get it.

From who do you suppose you will "download" the entire block chain initially.?

So we have people who want a service and they aren't sure how they are going to get it. What a tough problem.

If only there was this technology that could help people cooperate to get what they want more effectively than direct barter. Something that people could exchange but not consume directly, in order to help them keep track of whose turn it is to consume the products and services being produced. Wouldn't that be a great invention?

You know what would be even better? What if anyone who wanted to provide a service was free to do so, and the people who wanted to consume the service were free to choose any provider which which they could come to a mutual agreement, or no provider at all?

I wonder how good of a job such a mechanism might do at making sure that the number of suppliers was sufficient to meet the demand for the service? Could that improved barter trading thing maybe play role? Perhaps there's some kind of signal that might be passed through it that could be useful.

It feels like we're so close to having all the technology we need to solve problems of how people are going to be able to get what they want via mutual trade. Perhaps in some far off future utopia a more advanced civilization just might finally crack this Enigma.
1481416658
Hero Member
*
Offline Offline

Posts: 1481416658

View Profile Personal Message (Offline)

Ignore
1481416658
Reply with quote  #2

1481416658
Report to moderator
1481416658
Hero Member
*
Offline Offline

Posts: 1481416658

View Profile Personal Message (Offline)

Ignore
1481416658
Reply with quote  #2

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

Activity: 1153


View Profile
April 28, 2015, 03:55:03 AM
 #23202

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.

You still have to download the full chain and verify the full chain in order to be able to trust that your state is correct. When the blockchain reaches many petabytes that will be an issue.

Hashing, verifying and committing the UTXO set to blocks enables a node to only download headers and the current UTXO set, and still operate in a trustless manner.

People throw this word trustless around a lot. It doesn't mean what you think it means. If you are relying on a committed UTXO then you are trusting whoever created and verified that UTXO (meaning the miners for the most part) to have done so faithfully. That may be a reasonable or even entirely necessary trade off to avoid needing to process petabytes of data, but you can't wish away that it is indeed a trade off.

Justus is correct that there could conceivably be a zero knowledge proof that the UTXO is the result of only valid bitcoin transactions which could be trustless. (Maybe, but only if there isn't a trusted setup, not even a distributed one.) Just committing any old UTXO doesn't do that.

As stated in my original post, you'd have to trust the P2P network to reject blocks with invalid UTXO hashes. So yes you are relying on that processes work correctly, which requires more trust than we have today (i.e. from fully trustless to trusting the P2P network) and does introduce a potential attack vector.

However given how visible the blockchain is, I find it difficult to imagine a scenario where someone effectively pulls off the attack. It would be flagged immediately and all honest miners would reject it and go to a valid chain.

I think attacking a UTXO hash will prove to be as plausible as a 51% attack, which is not likely.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
April 28, 2015, 04:04:00 AM
 #23203


Open questions;
i) UTXO hash in blockchain is vulnerable to re-orgs, so it needs to be >120 or 288 blocks deep or w/e your 'trust' level is ...

ii) Also some UTXO could discard/prune long unspent dust/spam or other 'bad' TX so not all UTXO sets will be created equal ...

The way I've envisioned it is the UTXO hash becomes a part every block's structure (just as the coinbase transaction) and it serves as a marker for the UTXO set as of the current block. This enables nodes to optionally ask for: a) all prior blocks, or b) the UTXO set only.

If there is a re-org, then the new chain's blocks simply have their own UTXO hash in each block and provide a valid reference for the UTXO set on that branch. Each separate chain would have their own UTXO hash that is valid at every block. The cost is adding 256 bits to each block, but this doesn't even have to be a part of the header structure and instead is part of the block itself.

During a re-org a node could ask for either: a) all new blocks since the branch or b) the UTXO set of the latest block on the new chain. Both would be valid options to function on the new branch.

What I like about this is it allows each node to make optimal decisions that alleviate bandwidth pressure on the network. Every time a node restarts after x number of days, it could quickly determine which is the fastest method to catch-up, a) download the newest block or b) download the UTXO set, whichever is smaller. This would allow nodes to minimize their download requests.
molecular
Donator
Legendary
*
Offline Offline

Activity: 2142



View Profile
April 28, 2015, 05:22:07 AM
 #23204

The way I've envisioned it is the UTXO hash becomes a part every block's structure (just as the coinbase transaction) and it serves as a marker for the UTXO set as of the current block. This enables nodes to optionally ask for: a) all prior blocks, or b) the UTXO set only.

If there is a re-org, then the new chain's blocks simply have their own UTXO hash in each block and provide a valid reference for the UTXO set on that branch. Each separate chain would have their own UTXO hash that is valid at every block. The cost is adding 256 bits to each block, but this doesn't even have to be a part of the header structure and instead is part of the block itself.

Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons:

  • It gives additional capabilities to a 51% attacker
  • Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering

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

Activity: 1764



View Profile
April 28, 2015, 02:22:04 PM
 #23205


Open questions;
i) UTXO hash in blockchain is vulnerable to re-orgs, so it needs to be >120 or 288 blocks deep or w/e your 'trust' level is ...

ii) Also some UTXO could discard/prune long unspent dust/spam or other 'bad' TX so not all UTXO sets will be created equal ...

The way I've envisioned it is the UTXO hash becomes a part every block's structure (just as the coinbase transaction) and it serves as a marker for the UTXO set as of the current block. This enables nodes to optionally ask for: a) all prior blocks, or b) the UTXO set only.

If there is a re-org, then the new chain's blocks simply have their own UTXO hash in each block and provide a valid reference for the UTXO set on that branch. Each separate chain would have their own UTXO hash that is valid at every block. The cost is adding 256 bits to each block, but this doesn't even have to be a part of the header structure and instead is part of the block itself.

During a re-org a node could ask for either: a) all new blocks since the branch or b) the UTXO set of the latest block on the new chain. Both would be valid options to function on the new branch.

What I like about this is it allows each node to make optimal decisions that alleviate bandwidth pressure on the network. Every time a node restarts after x number of days, it could quickly determine which is the fastest method to catch-up, a) download the newest block or b) download the UTXO set, whichever is smaller. This would allow nodes to minimize their download requests.

Wouldn't the UTXO hash have to be in the header since otherwise it could get pruned?
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 02:46:38 PM
 #23206

looks to me like the $DJI is starting to get dragged down by the $DJT:



also, RUT has broken down below the support line of the ascending wedge, depending on how you draw it:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 02:53:25 PM
 #23207

The way I've envisioned it is the UTXO hash becomes a part every block's structure (just as the coinbase transaction) and it serves as a marker for the UTXO set as of the current block. This enables nodes to optionally ask for: a) all prior blocks, or b) the UTXO set only.

If there is a re-org, then the new chain's blocks simply have their own UTXO hash in each block and provide a valid reference for the UTXO set on that branch. Each separate chain would have their own UTXO hash that is valid at every block. The cost is adding 256 bits to each block, but this doesn't even have to be a part of the header structure and instead is part of the block itself.
i have a few questions:
Quote
Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons:

when you say "commitment", you mean by requiring a UTXO hash to be embedded into a block?
Quote
  • It gives additional capabilities to a 51% attacker

you mean that because the UTXO hash is embedded (committed) into blocks, it leaves room to be manipulated?  how so?
Quote
  • Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering


by implementation detail, do you mean that the UTXO set is maintained at the client level and is never actually used in the protocol?
molecular
Donator
Legendary
*
Offline Offline

Activity: 2142



View Profile
April 28, 2015, 04:01:41 PM
 #23208

i have a few questions:
Quote
Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons:

when you say "commitment", you mean by requiring a UTXO hash to be embedded into a block?

yes. I hope I'm using the term correctly.

Quote
  • It gives additional capabilities to a 51% attacker

you mean that because the UTXO hash is embedded (committed) into blocks, it leaves room to be manipulated?  how so?

thezerg explained an approach and I think the implications are valid here (bolding mine):

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

I'm really no sure about this point after re-reading what thezerg said. If it only applies to SPV clients, then it doesn't make much difference because these have to trust the miners anyways. I might be slightly confused.

Quote
  • Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering


by implementation detail, do you mean that the UTXO set is maintained at the client level and is never actually used in the protocol?


yes, that. That's not a very strong reason, though.

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

Activity: 1400



View Profile WWW
April 28, 2015, 04:26:17 PM
 #23209

I think the security of committed UTXO sets might depend on how they are actually implemented.

Maybe it's better to think of a set of transactions which create unspent outputs.

Each transaction in that set can be accompanied by the hashes needed to prove that it was included in the merkle tree of a particular block.

Each bitcoin block that contains a committed set becomes independently verifiable - almost.

If one accepts that they know the hash of the previous block represents a valid block, then any observer can verify that the next block is a valid transformation of the set of transactions which create unspent outputs without knowing any more history than what is contained in the block itself (and its committed set).

In this model, an attacker can not add false transaction to the set without being detected by any client (light or otherwise) which has managed to obtain a correct set of block headers, otherwise the hashes won't match (unless the attacker can also trivially break SHA256).

Now now we're right back to "if an SPV client can manage to connect to a single peer that will tell it the truth, it can't be fooled".

Because each block + committed set is a self-contained proof, even if an attacker with a majority hashpower produces a chain with longer proof of work any honest node can broadcast the proof that one of the links in the attacker's chain is invalid and therefore the entire branch is invalid.
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
April 28, 2015, 05:26:20 PM
 #23210

i have a few questions:
Quote
Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons:

when you say "commitment", you mean by requiring a UTXO hash to be embedded into a block?

yes. I hope I'm using the term correctly.

Quote
  • It gives additional capabilities to a 51% attacker

you mean that because the UTXO hash is embedded (committed) into blocks, it leaves room to be manipulated?  how so?

thezerg explained an approach and I think the implications are valid here (bolding mine):

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

I'm really no sure about this point after re-reading what thezerg said. If it only applies to SPV clients, then it doesn't make much difference because these have to trust the miners anyways. I might be slightly confused.

Yes, it only applies to thin clients.  A full client calculates the UTXO set and Merkle hash from the complete history, compares it to a new block's UTXO hash and rejects the block if they don't match.

A 51% attack could create a longer chain of malicious UTXO sets than the longest valid chain.  But the full nodes reject the chain because it is not correct (incorrect UTXO hash).  However "light" clients (I'm not calling them SPV because SPV refers to a specific algorithm), can't validate the UTXO hash so they assume that it is correct and therefore use the longest (and incorrect) chain. 

Honestly in practice you would simply code up "light" client that refuses to do any TXNs if there are 2 competing chains that forked > 64 (for example) blocks ago.  Bitcoin's natural forks resolve quickly...

Note that it doesn't have to be all or none either... a client could keep X years of back revision history and just assume if the coin is older than that then it is valid.  This might be very important when Bitcoin is 20+ years old.

Quote
  • Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering


by implementation detail, do you mean that the UTXO set is maintained at the client level and is never actually used in the protocol?

yes, that. That's not a very strong reason, though.

Once upon a time revision control systems stored each revision as the difference between the prior rev and the next one.  This is bitcoin today.  As files changed hundreds of times it took a long time to "check out" the file because all the revs had to be read and applied.  Then people realized that there is a better way: store the current file and the reverse difference -- that is the changes needed to get BACK to the prior rev.  This made a lot more sense because the current file is what is used 99% of the time.

This idea to store the UTXO Merkle tree hash is the evolution of the network to the back-revision method -- we only need the "current state" because blocks are symmetric.  So technically you are correct; this is redundant data.  But what it actually is a smooth transformation from one structure/protocol to another.



cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 05:37:13 PM
 #23211

huh.  we got the $DXY and the TLT turning down on top of the Dow Theory non-confirmation we still have in place.  this, plus the break of the RUT below it's support of it's ascending wedge all equals "heads up".  or, i could just be needlessly concerned:



cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 06:10:27 PM
 #23212

Security researchers are reporting a trend for cybercriminals to go directly after financial institutions instead of their customers. In February, researchers from Kaspersky Lab reported that a gang called Carbanak stole up to $1 billion from banks and other financial institutions in 25 countries after infecting their systems with malware and carefully learning their internal procedures. The primary attack vector used was spear phishing, targeted emails containing malicious attachments.

http://www.pcworld.com/article/2915112/police-breaks-up-cybergang-that-stole-over-15-million-from-banks.html
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 06:12:52 PM
 #23213


Yes, it only applies to thin clients.  A full client calculates the UTXO set and Merkle hash from the complete history, compares it to a new block's UTXO hash and rejects the block if they don't match.

how is this practical?  don't UTXO sets differ slightly just like the mempools unconfirmed tx's?
Kupsi
Legendary
*
Offline Offline

Activity: 1190


9.9.2012: I predict that single digits... <- FAIL


View Profile
April 28, 2015, 06:17:08 PM
 #23214


Yes, it only applies to thin clients.  A full client calculates the UTXO set and Merkle hash from the complete history, compares it to a new block's UTXO hash and rejects the block if they don't match.

how is this practical?  don't UTXO sets differ slightly just like the mempools unconfirmed tx's?

The UTXO set merkle hash is created out of confirmed transactions.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
April 28, 2015, 06:17:21 PM
 #23215

don't UTXO sets differ slightly just like the mempools unconfirmed tx's?
No. The state of the Bitcoin ledger as of each Bitcoin block corresponds to exactly one correct UTXO set.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 06:38:02 PM
 #23216

don't UTXO sets differ slightly just like the mempools unconfirmed tx's?
No. The state of the Bitcoin ledger as of each Bitcoin block corresponds to exactly one correct UTXO set.

then it seems that there is no need to hash the UTXO set into the current block.  we aren't doing that now and it works.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
April 28, 2015, 06:40:46 PM
 #23217

then it seems that there is no need to hash the UTXO set into the current block.  we aren't doing that now and it works.
If you put the hash of the UTXO set in the block header, then light clients can obtain a copy of the set from an untrusted source and use the block header to verify that it is correct.
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
April 28, 2015, 06:47:16 PM
 #23218

don't UTXO sets differ slightly just like the mempools unconfirmed tx's?
No. The state of the Bitcoin ledger as of each Bitcoin block corresponds to exactly one correct UTXO set.

then it seems that there is no need to hash the UTXO set into the current block.  we aren't doing that now and it works.

Yes, like I was saying above, it is an optimization.  It transforms the block chain from one that must be processed in one direction (beginning to end) into one that can be read in either direction.  So full clients can still read from beginning to end, but "light" clients can read from end to beginning and essentially make its own tradeoff between confidence level and data storage overhead.   A light client could even read the entire blockchain end to beginning and by doing so gradually become a full client...

What I like most about it is that we could do it today in independent transactions as a proof of concept (but you'd have to trust "us" to not lie about the hash).  However "us" could be multiple independent validators... it could later be turned into a required element in every block to make the trust model similar to what we have with miners today (i.e. not very much trust)...

rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
April 28, 2015, 09:49:25 PM
 #23219

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.

To expand on this, adding a UTXO hash set simply provides nodes a new additional method to engage with the P2P network. The full history still exists and is independently verifiable to anyone who wishes to do so.

With UTXO hashes, a node can optionally decide what level of trust it requires, and can optionally trust that the P2P network has correctly verified the UTXO set up to a given point to save bandwidth, or not if it wants the full history.

We'd end up with 3 types of nodes (vs. 2 types of nodes today):

1) SPV clients - Thin & lightweight nodes that do not contribute to the network. These need to trust their P2P peers to some degree.

2) Full nodes without full history (i.e. UTXO nodes) - Fully functional nodes that are able to fully participate in the P2P network and validate transactions and new blocks. These need to trust that miners and the P2P network correctly verified their starting UTXO point.

3) Archival nodes with full history (i.e. today's nodes) - Fully functional nodes that are able to fully participate in the P2P network and validate transactions and new blocks. They also valid the fully history of a given chain.

Type 3 nodes (I'm calling archival nodes here) would still exist and verify for everyone that a given chain is valid. Given how public this is, I can't imagine and attack were either the P2P network or the full archival nodes wouldn't be able to flag the attack and kick off the invalid chain. What UTXO hashes provide is the option for nodes to save bandwidth by trusting the longest chain, I'd imagine this trade off is OK for some subset of nodes.
marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2100



View Profile
April 28, 2015, 09:55:36 PM
 #23220

The negative interest rate hall of mirrors is screwing with people's minds enough to wake them up from the Central Bank manipulated price-perception fantasy dream. The monetary CONfidence game may be coming to an end ... feels to me like the Rubicon has been crossed.
http://www.telegraph.co.uk/finance/comment/jeremy-warner/11569329/Jeremy-Warner-Negative-interest-rates-put-world-on-course-for-biggest-mass-default-in-history.html

Pages: « 1 ... 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 1209 1210 1211 ... 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!