Bitcoin Forum
August 18, 2017, 12:57:09 PM *
News: Latest stable version of Bitcoin Core: 0.14.2  [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 ... 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 1209 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1953416 times)
thezerg
Legendary
*
Offline Offline

Activity: 1246


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

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

1503061029
Hero Member
*
Offline Offline

Posts: 1503061029

View Profile Personal Message (Offline)

Ignore
1503061029
Reply with quote  #2

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

Posts: 1503061029

View Profile Personal Message (Offline)

Ignore
1503061029
Reply with quote  #2

1503061029
Report to moderator
1503061029
Hero Member
*
Offline Offline

Posts: 1503061029

View Profile Personal Message (Offline)

Ignore
1503061029
Reply with quote  #2

1503061029
Report to moderator
1503061029
Hero Member
*
Offline Offline

Posts: 1503061029

View Profile Personal Message (Offline)

Ignore
1503061029
Reply with quote  #2

1503061029
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



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

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

Activity: 1764



View Profile
April 27, 2015, 11:24:16 PM
 #23163

Here's an idea for some young entrepreneur that will greatly expand the number of  network nodes.

Instead of using a USB adapter to power these small compute sticks, use an AC adapter to power them. Load in the pruned 1.3GB block chain and connect them to a nearby open wifi in some obscure outlet. I know I have access to lots of open and closed wifi systems.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 11:37:42 PM
 #23164

Imo, the volatility we're starting to get to the upside, OKcoin last week and BTC-e  today,   is a bullish sign. 
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 27, 2015, 11:47:10 PM
 #23165

Here's an idea for some young entrepreneur that will greatly expand the number of  network nodes.

Instead of using a USB adapter to power these small compute sticks, use an AC adapter to power them. Load in the pruned 1.3GB block chain and connect them to a nearby open wifi in some obscure outlet. I know I have access to lots of open and closed wifi systems.



Oh yeah, don't forget to build in a  miner. 
smooth
Legendary
*
Offline Offline

Activity: 1512



View Profile
April 27, 2015, 11:53:56 PM
 #23166

Here's an idea for some young entrepreneur that will greatly expand the number of  network nodes.

Instead of using a USB adapter to power these small compute sticks, use an AC adapter to power them. Load in the pruned 1.3GB block chain and connect them to a nearby open wifi in some obscure outlet. I know I have access to lots of open and closed wifi systems.



Oh yeah, don't forget to build in a  miner. 

Add solar cells and a mesh network.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
April 27, 2015, 11:56:54 PM
 #23167

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. That is a massive savings in bandwidth, and one that will be needed.

The current update simply reduces the amount of storage and node requires to operate, it does not reduce the amount of bandwidth a node needs to join the P2P network. Even with the update, you still have to download the full blockchain.
smooth
Legendary
*
Offline Offline

Activity: 1512



View Profile
April 28, 2015, 12:06:00 AM
 #23168

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.

sidhujag
Legendary
*
Offline Offline

Activity: 1540


View Profile
April 28, 2015, 12:06:39 AM
 #23169

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. That is a massive savings in bandwidth, and one that will be needed.

The current update simply reduces the amount of storage and node requires to operate, it does not reduce the amount of bandwidth a node needs to join the P2P network. Even with the update, you still have to download the full blockchain.
Yup and maybe as Smooth says its not practical to create lite wallets which are entrusted by the foundation or some other globally known trustful entity because it may cause havoc if that node(s) was hacked. However in order to do some kind of SPV to save bandwidth when syncing (something we will need) we have to give up some sort of trust somewhere.. so problems still there.. and that is the major problem I have with the bloat, storage is a non issue imo.

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

Activity: 1512



View Profile
April 28, 2015, 12:08:26 AM
 #23170

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. That is a massive savings in bandwidth, and one that will be needed.

The current update simply reduces the amount of storage and node requires to operate, it does not reduce the amount of bandwidth a node needs to join the P2P network. Even with the update, you still have to download the full blockchain.
Yup and maybe as Smooth says its not practical to create lite wallets which are entrusted by the foundation or some other globally known trustful entity because it may cause havoc if that node(s) was hacked. However in order to do some kind of SPV to save bandwidth when syncing (something we will need) we have to give up some sort of trust somewhere.. so problems still there.. and that is the major problem I have with the bloat, storage is a non issue imo.

I didn't say it's not practical to relax any of these trustlessness assumptions, just different. Peter R explained more or less the same thing a bit more clearly, I think.

You don't need to trust a central party to have light wallets though, just the collective good behavior of the miners and at least one of the nodes you connect to has to be honest (but you don't have to know ahead of time which one).


marcus_of_augustus
Legendary
*
Offline Offline

Activity: 2352



View Profile
April 28, 2015, 12:56:44 AM
 #23171


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

thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
April 28, 2015, 01:35:33 AM
 #23172

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.

LOL I should read the whole thread rather then skimming it.  You guys were already talking about the UTXO hash!   But its easy to miss stuff when multiple conversations are interleaved and you are only interested in one of them :-).  

Note if you make it a UTXO merkle tree whose root is stored in the block (not a flat hash) then a light client could verify that certain UTXOs exist without downloading the entire UTXO set.

EDIT:  And what do you think of the idea of just doing it (as data in a txn), and then if people use it we can incorporate it into every block so that it is trustless?

brg444
Hero Member
*****
Offline Offline

Activity: 644

Bitcoin replaces central, not commercial, banks


View Profile
April 28, 2015, 01:44:25 AM
 #23173

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.

You don't seem to quite get it.

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

I don't care if you stick "validating" nodes on every USB key you can get your hands on. This does not improve the number of COMPLETE copies of the transaction log from which nodes can sync on the network.

Did you bother reading the last link I posted? To quote

Quote
Finally (for the purposes of this piece), there is the immutable transaction log. The log demonstrates incontrovertibly the complete heredity of each and every satoshi, from coinbase to unspent output. This globally-shared, append-only log cannot be disentangled from that which is Bitcoin. Nodes that run with "pruned" blockchains will still always depend on the existence of nodes with unpruned blockchains from which to sync. Perhaps in some idyllic (for the fiat shitgnomes) world, the entire Bitcoin network would switch over to this "headers first" synchronization method, bypassing the all-important verification of each transaction in each block.

So much for inclusion and "nodes" propagation when only people who can afford petabytes of storage can run the only nodes that matters and that are foundation to the Bitcoin network

"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
STT
Legendary
*
Offline Offline

Activity: 1456


¯\_(ツ)_/¯


View Profile WWW
April 28, 2015, 01:53:24 AM
 #23174

Quote
"centralized blockchain", at a very fundamental level does not understand what Bitcoin is.

The dollar is a digital currency pretty much, so what he appears to be suggesting is the status quo and this technology is pointless.    A problem with education is its biased to government, partly from the funding and many other cross overs.    Bitcoin fail or suceeds, it was never pointless and it is very much something new and never seen in this world before.  Whether we need it Im not sure yet
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
April 28, 2015, 02:28:46 AM
 #23175

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.

You don't seem to quite get it.

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


for one, you'll be able to get it from me.

and you don't seem to get that if we increase the # of nodes by orders of magnitude larger than what we have now, even if just pruned nodes, that Bitcoin's exchange value will likely increase along with it making it much easier financially for those of us to continue committing to providing full blockchain server nodes.  it also will help decentralize mining.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
April 28, 2015, 02:31:17 AM
 #23176

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.

You don't seem to quite get it.

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

I don't care if you stick "validating" nodes on every USB key you can get your hands on. This does not improve the number of COMPLETE copies of the transaction log from which nodes can sync on the network.

Did you bother reading the last link I posted? To quote

Quote
Finally (for the purposes of this piece), there is the immutable transaction log. The log demonstrates incontrovertibly the complete heredity of each and every satoshi, from coinbase to unspent output. This globally-shared, append-only log cannot be disentangled from that which is Bitcoin. Nodes that run with "pruned" blockchains will still always depend on the existence of nodes with unpruned blockchains from which to sync. Perhaps in some idyllic (for the fiat shitgnomes) world, the entire Bitcoin network would switch over to this "headers first" synchronization method, bypassing the all-important verification of each transaction in each block.

So much for inclusion and "nodes" propagation when only people who can afford petabytes of storage can run the only nodes that matters and that are foundation to the Bitcoin network

You are taking the situation to its extremes.

The reality is that in a decent sized Bitcoin economy there will be thousands of businesses who will always run full nodes. Individuals who want to use pruning *should* have the option of storing a percentage of the full blockchain. Even if it is 5% or 1%, as mentioned earlier, the whole blockchain can be rebuilt from segments held by many nodes with this variation of pruning.

Also, storage is not really the problem, in 10 years time petabyte storage should be available to consumers, let alone to high-end users. 3D (even 5D) glass storage has huge potential.
Bandwidth is the real limiting factor, and fortunately there are major efficiencies to be had there.

justusranvier
Legendary
*
Offline Offline

Activity: 1400



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

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

Activity: 1153


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

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


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



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

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