Bitcoin Forum
November 21, 2017, 04:32:47 PM *
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 ... 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 1212 1213 1214 1215 1216 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2010862 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 09:34:02 AM
 #23301

It's about time people are fighting back. These idiots need to be flat out embarrassed in  public over and over:

http://www.dailydot.com/politics/second-crypto-war-hearing-washington/
Join ICO Now Coinlancer is Disrupting the Freelance marketplace!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511281967
Hero Member
*
Offline Offline

Posts: 1511281967

View Profile Personal Message (Offline)

Ignore
1511281967
Reply with quote  #2

1511281967
Report to moderator
1511281967
Hero Member
*
Offline Offline

Posts: 1511281967

View Profile Personal Message (Offline)

Ignore
1511281967
Reply with quote  #2

1511281967
Report to moderator
1511281967
Hero Member
*
Offline Offline

Posts: 1511281967

View Profile Personal Message (Offline)

Ignore
1511281967
Reply with quote  #2

1511281967
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 09:43:31 AM
 #23302

SPV clients don't  normally carry the UTXO set around in their memory, correct?
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 01, 2015, 12:50:49 PM
 #23303

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...
ssmc2
Legendary
*
Offline Offline

Activity: 1092


View Profile
May 01, 2015, 01:36:10 PM
 #23304

It's about time people are fighting back. These idiots need to be flat out embarrassed in  public over and over:

http://www.dailydot.com/politics/second-crypto-war-hearing-washington/

My fear is that in the end this is just theatrics and the 3 letter agencies will do as they please regardless.
jmw74
Full Member
***
Offline Offline

Activity: 236


View Profile
May 01, 2015, 01:50:50 PM
 #23305

It's about time people are fighting back. These idiots need to be flat out embarrassed in  public over and over:

http://www.dailydot.com/politics/second-crypto-war-hearing-washington/

My fear is that in the end this is just theatrics and the 3 letter agencies will do as they please regardless.

You say this as if they don't already do as they please.
NewLiberty
Legendary
*
Offline Offline

Activity: 1162


Gresham's Lawyer


View Profile WWW
May 01, 2015, 02:53:02 PM
 #23306

It's about time people are fighting back. These idiots need to be flat out embarrassed in  public over and over:

http://www.dailydot.com/politics/second-crypto-war-hearing-washington/


"(Massachusetts District Attorney Daniel) Conley also said Apple and Google are 'protecting those who rape, assault, and kill' with their encryption policies."

Doesn't he realize how bad this argument is?
Traffic rules and copyright law also protects those who rape assault and kill...as well as everyone else.

FREE MONEY1 Bitcoin for Silver and Gold NewLibertyDollar.com and now BITCOIN SPECIE (silver 1 ozt) shows value by QR
Bulk premiums as low as .0012 BTC "BETTER, MORE COLLECTIBLE, AND CHEAPER THAN SILVER EAGLES" 1Free of Government
Grafzep
Member
**
Offline Offline

Activity: 92


View Profile
May 01, 2015, 03:00:57 PM
 #23307

Today's edition of The Economist has a short article  (p68) looking at the decline in the gold price.

"One reason may be that investors have so many options nowadays. Humble citizens who distrust their own currencies can buy assets ranging from shares to bitcoins."



Very encouraging to see bitcoin mentioned in the context of a global asset class in a magazine (sorry, newspaper) with this readership.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 03:11:30 PM
 #23308

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...

Its a good idea.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 03:55:49 PM
 #23309

another example of outrageous volatility in the stock mkt that makes Bitcoin look trivial.  in fact, in the milliseconds in after hour earnings reporting, you have absolutely no chance to react to protect yourself.  and that's even if you have privileges to trade in after hours which most don't have.  how many examples of this have i shown over the years?  ans:  many:

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 03:58:16 PM
 #23310

here's the daily chart.  look at all those frickin gaps.  at least with Bitcoin, there are no gaps:

ssmc2
Legendary
*
Offline Offline

Activity: 1092


View Profile
May 01, 2015, 04:21:11 PM
 #23311

https://www.reddit.com/r/Bitcoin/comments/34g0s1/apple_cofounder_steve_wozniak_joins_next_gen/cquezii

Heavy hitters indeed   Cool
thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 01, 2015, 04:24:02 PM
 #23312

another example of outrageous volatility in the stock mkt that makes Bitcoin look trivial.  in fact, in the milliseconds in after hour earnings reporting, you have absolutely no chance to react to protect yourself.  and that's even if you have privileges to trade in after hours which most don't have.  how many examples of this have i shown over the years?  ans:  many:



linked-in 250?  Holy sh*t.  Our attempts to advertise with them were utterly useless... I couldn't even find my own ad on the site until marketing pointed it out to me (you had to scroll to see it).  Bubble anyone?

There is a reason why ppl use the term "liquid" to refer to dollars.  Someday, its all going to come crashing back out, desperate for a place to go...
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
May 01, 2015, 05:19:53 PM
 #23313

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...

SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity).

Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches.

All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network.

The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history, another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block (i.e. with a hash embedded in the block). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node.

I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 06:05:23 PM
 #23314

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...

SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity).

Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches.

All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network.

The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history, another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block (i.e. with a hash embedded in the block). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node.

I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification.

You're doing a great job articulating this but what's a bit confusing, at least for me, is from which type of node's perspective you're arguing from;  namely 1. Archival nodes, 2. SPV clients, or 3. Pruned nodes.

I think it matters because I don't think that current SPV clients have the capability to download the UTXO set to verify the UTXO hash embedded in their block headers. Do you think it would just be a small additional implementation detail that these wallet providers will insert once this protocol change gets enacted? Do smartphones have that memory capability?
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
May 01, 2015, 06:12:29 PM
 #23315

what is a "graduated limit" in the pole?

is that what we have, or is that like a limit determined by a quantifiable metric?

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 06:24:37 PM
 #23316

what is a "graduated limit" in the pole?

is that what we have, or is that like a limit determined by a quantifiable metric?

A staged unspecified increase over time.
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
May 01, 2015, 06:29:55 PM
 #23317

what is a "graduated limit" in the pole?

is that what we have, or is that like a limit determined by a quantifiable metric?

A staged unspecified increase over time.

would it be automated, not requiring a hard fork to adjust?

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 06:35:09 PM
 #23318

what is a "graduated limit" in the pole?

is that what we have, or is that like a limit determined by a quantifiable metric?

A staged unspecified increase over time.

would it be automated, not requiring a hard fork to adjust?

I guess I made it purposely vague to get a general sense of the sentiment out there.
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
May 01, 2015, 07:04:01 PM
 #23319

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...

2) SPV Clients

SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity).

Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches.

1) "Archival nodes" [Full nodes operating with full history] &
3) "Pruned nodes" or "UTXO hash started nodes" [Full nodes operating without full history]


All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network.

The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history (i.e. 1 - Archival nodes; 3 - Pruned nodes) , another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block with a hash embedded in the block (i.e. 3 - UTXO hash started nodes). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node.

I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification.

You're doing a great job articulating this but what's a bit confusing, at least for me, is from which type of node's perspective you're arguing from;  namely 1. Archival nodes, 2. SPV clients, or 3. Pruned nodes.

I think it matters because I don't think that current SPV clients have the capability to download the UTXO set to verify the UTXO hash embedded in their block headers. Do you think it would just be a small additional implementation detail that these wallet providers will insert once this protocol change gets enacted? Do smartphones have that memory capability?

Ah OK, I think I now see what you were getting at.

In the post above I was contrasting all three types, sorry if that was confusing. I edited the quoted text above to hopefully make the post more clear.

If I understand your question correctly, you're asking if thin clients such as smartphones could utilize some form of a UTXO set to verify transactions and blocks on the P2P network. That is an interesting possibility.

The reason smartphone type devices can't be full nodes today is due to both the storage and the bandwidth requirements. In terms of storage both 3) Pruned nodes and 3) UTXO hash started nodes could run on a smartphone since neither have to store the full blockchain. Bandwidth would still be an issue though. Pruned nodes would still need to download the full blockchain, over a mobile connection that would be expensive. UTXO hash started nodes however would only have to download the UTXO set, probably reasonable today, but it keeps growing. And that is just to get started, once started the node would need to transmit transactions & blocks. At over 1MB every 10 minutes, that will eat through any wireless plan's data allowances pretty fast.

Here is a chart on the current UTXO set size. We are already at 650MB and growing. High end smartphones today only have 2-3GB of memory, and some of that is needed for other apps.
http://statoshi.info/#/dashboard/file/default.json?panelId=5&fullscreen&from=now-24h&to=now

So my guess is pretty soon the size of the UTXO set will be large enough that smartphone like devices couldn't run a full node, even if you ignore the bandwidth and storage limitations. Node memory requirements will become too large.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 01, 2015, 08:25:49 PM
 #23320

SPV clients don't  normally carry the UTXO set around in their memory, correct?

Right the "UTXO client" we've been talking about is a different animal with a stronger security model...

2) SPV Clients

SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity).

Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches.

1) "Archival nodes" [Full nodes operating with full history] &
3) "Pruned nodes" or "UTXO hash started nodes" [Full nodes operating without full history]


All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network.

The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history (i.e. 1 - Archival nodes; 3 - Pruned nodes) , another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block with a hash embedded in the block (i.e. 3 - UTXO hash started nodes). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node.

I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification.

You're doing a great job articulating this but what's a bit confusing, at least for me, is from which type of node's perspective you're arguing from;  namely 1. Archival nodes, 2. SPV clients, or 3. Pruned nodes.

I think it matters because I don't think that current SPV clients have the capability to download the UTXO set to verify the UTXO hash embedded in their block headers. Do you think it would just be a small additional implementation detail that these wallet providers will insert once this protocol change gets enacted? Do smartphones have that memory capability?

Ah OK, I think I now see what you were getting at.

In the post above I was contrasting all three types, sorry if that was confusing. I edited the quoted text above to hopefully make the post more clear.

If I understand your question correctly, you're asking if thin clients such as smartphones could utilize some form of a UTXO set to verify transactions and blocks on the P2P network. That is an interesting possibility.

The reason smartphone type devices can't be full nodes today is due to both the storage and the bandwidth requirements. In terms of storage both 3) Pruned nodes and 3) UTXO hash started nodes could run on a smartphone since neither have to store the full blockchain. Bandwidth would still be an issue though. Pruned nodes would still need to download the full blockchain, over a mobile connection that would be expensive. UTXO hash started nodes however would only have to download the UTXO set, probably reasonable today, but it keeps growing. And that is just to get started, once started the node would need to transmit transactions & blocks. At over 1MB every 10 minutes, that will eat through any wireless plan's data allowances pretty fast.

Here is a chart on the current UTXO set size. We are already at 650MB and growing. High end smartphones today only have 2-3GB of memory, and some of that is needed for other apps.
http://statoshi.info/#/dashboard/file/default.json?panelId=5&fullscreen&from=now-24h&to=now

So my guess is pretty soon the size of the UTXO set will be large enough that smartphone like devices couldn't run a full node, even if you ignore the bandwidth and storage limitations. Node memory requirements will become too large.

Great explanation.

So I see we really  have 4 types of node's:

1. Archival
2. Pruned
3. UTXO hash started
4. SPV

As for smartphones, I just got my Samsung S6 with 64GB. Could've have gotten the 128 GB.  Plenty of space for even an archival node. So storage isn't an issue anymore. Also, as far as download and verification of the blockchain, to save bandwidth, you could download on your home pc and transfer to the phone later. This could be done for a pruned chain as well. As for relaying tx's and blocks, most of my day is at work connected to the office router. With the blockchain loaded, you could act   as a temporary full node. Full nodes work fine with just  1GB of RAM (with some swap) and definitely with 2GB. With all the phones out there owned by Bitcoiners that might be willing to do this we could logarithmically  increase the number of full nodes and thus security of the network significantly, I'd  think.
Pages: « 1 ... 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 1212 1213 1214 1215 1216 ... 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!