Bitcoin Forum
December 10, 2016, 01:22:14 AM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   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 ... 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 1217 1218 1219 1220 1221 1222 1223 ... 1560 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1807383 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 04, 2015, 08:09:32 PM
 #23441

new poll
1481332934
Hero Member
*
Offline Offline

Posts: 1481332934

View Profile Personal Message (Offline)

Ignore
1481332934
Reply with quote  #2

1481332934
Report to moderator
1481332934
Hero Member
*
Offline Offline

Posts: 1481332934

View Profile Personal Message (Offline)

Ignore
1481332934
Reply with quote  #2

1481332934
Report to moderator
1481332934
Hero Member
*
Offline Offline

Posts: 1481332934

View Profile Personal Message (Offline)

Ignore
1481332934
Reply with quote  #2

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

Activity: 714



View Profile
May 04, 2015, 08:17:56 PM
 #23442

new poll

Cool, but this time there is no "unlimited" option.

cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 04, 2015, 08:23:19 PM
 #23443

new poll

Cool, but this time there is no "unlimited" option.



well, certainly i'm no expert in polling; i just feed 'em like i see 'em.

if you have any suggestions, lemme know.

edit:  given Gavin's proposal, it looks like the "unlimited" option is off the table for now, so in this sense, this latest poll is heading in the right direction.
Erdogan
Hero Member
*****
Offline Offline

Activity: 714



View Profile
May 04, 2015, 08:51:31 PM
 #23444

new poll

Cool, but this time there is no "unlimited" option.



well, certainly i'm no expert in polling; i just feed 'em like i see 'em.

if you have any suggestions, lemme know.

edit:  given Gavin's proposal, it looks like the "unlimited" option is off the table for now, so in this sense, this latest poll is heading in the right direction.

Yes, let's get 20 MB going, then new poll Smiley
Natalia_AnatolioPAMM
Full Member
***
Offline Offline

Activity: 154


View Profile WWW
May 04, 2015, 09:47:00 PM
 #23445

Multiply that by 100M and pretty soon you're making real money.
Here's an example of a money protocol that allowed for "only" 3%/year worth of double spending:



never realized it's that bad unless saw the graphs like this one

Earn money when BTC crashes - join BTC-E PAMM
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
May 04, 2015, 09:53:22 PM
 #23446

Multiply that by 100M and pretty soon you're making real money.
Here's an example of a money protocol that allowed for "only" 3%/year worth of double spending:



never realized it's that bad unless saw the graphs like this one

Even this chart is misleading, since it is linear it does not show how the dollar continued drop over the past 30 years. Instead it looks relatively flat.

The log chart shows how this process is continuing. Even though the dollar has already lost 98% purchasing power, dropping to 99% is really another 50% lose, not the 1% drop shown on this chart.
sickpig
Legendary
*
Offline Offline

Activity: 1106


View Profile
May 04, 2015, 10:16:33 PM
 #23447

With UTXO merkle tree the whole thing does not need to be in phone RAM.  Or even on the phone.  phone clients could validate and fwd txns iff they are connected to wifi.  The only parts of the UTXO merkle tree that needs to be processed is the logn route from each UTXO involved in a txn to the tree root.  So very doable on today's mid range smart phone esp with a good sized uSD expansion.

On that matter I've just found out an etotheipi's (armory core dev) proposal "Ultimate blockchain compression w/ trust-free lite nodes" that he made in June 2012. This is the summary:

Use a special tree data structure to organize all unspent-TxOuts on the network, and use the root of this tree to communicate its "signature" between nodes.  The leaves of this tree actually correspond to addresses/scripts, and the data at the leaf is actually a root of the unspent-TxOut list for that address/script.  To maintain security of the tree signatures, it will be included in the header of an alternate blockchain, which will be secured by merged mining.  

This provides the same compression as the simpler unspent-TxOut merkle tree, but also gives nodes a way to download just the unspent-TxOut list for each address in their wallet, and verify that list directly against the blockheaders.  Therefore, even lightweight nodes can get full address information, from any untrusted peer, and with only a tiny amount of downloaded data (a few kB).  

More recently TierNolan with his "Locally verifiable unspent transaction output commitments" is "sketching" his idea of a potential implementation. 

A proposal to help SPV nodes verify blocks is to commit the root of an (unbalanced) Merkle tree containing all unspent (and spendable) transaction outputs.

It is possible to create proofs of validity for each modification of the set.  The proof would prove that inserting an entry into a tree with a root of X will give a new tree with a root of Y.  There would also be proofs for removing entries.

it seems that the idea of an "UTXO" light node to add to the the list of the already implemented nodes (full, spv, pruned) is gaining momentum.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
HeliKopterBen
Hero Member
*****
Offline Offline

Activity: 622



View Profile
May 04, 2015, 10:19:11 PM
 #23448

Bitcoin, while its issuance is capped at 21M, the software can be duplicated thousands of times.

The ability to clone/fork the software is a feature, not a bug.  Take the Euro for example, which is under a round of QE right now.  Imagine if Euro savers could easily clone the entire Euro monetary system, take out the QE, and put the QE_less system into production to compete.  Which fork would win?  I imagine sound money would win.

The only thing that cannot be duplicated is processing power.  Processing power is in finite supply, so whichever fork garners the most processing power wins.  The ability to clone the software keeps the system honest.

Counterfeit:  made in imitation of something else with intent to deceive:  merriam-webster
tabnloz
Hero Member
*****
Offline Offline

Activity: 793


View Profile
May 05, 2015, 01:09:55 AM
 #23449

Grabbed this off ZH

Australia to Introduce Bank Deposits tax in upcoming budget.

http://www.zerohedge.com/news/2015-05-04/war-cash-australia-leads-new-age-economic-totalitarianism

From a google search

http://www.theaustralian.com.au/business/financial-services/deposit-tax-banks-oppose-budget-tax-plan/story-fn91wd6x-1227284293520

ZH sees it as a trial balloon with US watching the reaction carefully.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 02:23:55 AM
 #23450

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin

sickpig
Legendary
*
Offline Offline

Activity: 1106


View Profile
May 05, 2015, 06:16:53 AM
 #23451

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin



Nice graph! Thanks for sharing. So with a 100% filled block you have a 0.1 probability of having your tx confirmed after 1000/sec. This is nasty.

As I already said  multiple times I'm a big supporter of Justus proposal to eliminate false block size scarcity and introducing economic incentive in the p2p nodes network.

Nonetheless I think that a part of txs will occur out of bitcoin main chain, through payment hub, lightning network, you name it. In fact the very solution Justus proposed to implement a price discovery mechanism in Bitcoin p2p network is based on micropayment channels.


Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
May 05, 2015, 06:41:34 AM
 #23452

no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:
I just scanned their recent reddit posts about the proposal and to be fair their position leans more to "open mind but cautious" than "outright rejection". This is good as obviously they contribute a lot to core dev, and hopefully that will continue.

Luke mentions increasing the block size in an emergency:
Quote
Those are all scalability issues that will not be fixed by making the blocks larger. We should fix them, not put them off. Maybe we can increase the max block size just in case of emergency, but we most definitely should not increase the actual block sizes simply to ignore real problems.
http://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqye7m6

Well, frankly, passing the point of average blocks being 40% full, where confirmation times start to decay exponentially (as per the hashingit graph) is an emergency, something rightly addressed now because everyone who runs a full node needs to upgrade.

lunarboy
Hero Member
*****
Offline Offline

Activity: 544



View Profile
May 05, 2015, 07:03:16 AM
 #23453

no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:
I just scanned their recent reddit posts about the proposal and to be fair their position leans more to "open mind but cautious" than "outright rejection". This is good as obviously they contribute a lot to core dev, and hopefully that will continue.

Luke mentions increasing the block size in an emergency:
Quote
Those are all scalability issues that will not be fixed by making the blocks larger. We should fix them, not put them off. Maybe we can increase the max block size just in case of emergency, but we most definitely should not increase the actual block sizes simply to ignore real problems.
http://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqye7m6

Well, frankly, passing the point of average blocks being 40% full, where confirmation times start to decay exponentially (as per the hashingit graph) is an emergency, something rightly addressed now because everyone who runs a full node needs to upgrade.

Actually Nullc / Gmax is positive about an increased blocksize WRT sidechains see here:

Are 20mb blocks good or bad for Sidechains?
https://www.reddit.com/r/Bitcoin/comments/34riua/hard_fork_allow_20mb_blocks_after_1_march_2016/cqxhs1o
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 10:26:30 AM
 #23454

Don't forget to vote the poll.
NewLiberty
Legendary
*
Offline Offline

Activity: 1064


Gresham's Lawyer


View Profile WWW
May 05, 2015, 12:02:15 PM
 #23455

interesting logarithmic Monte Carlo simulation of tx confirmation delays related to progressive filling of current 1MB block size.  bottom line is we need an increase in the block size otherwise confirmation delays will exponentially increase as the fill reaches the max.  note in the conclusion who would benefit from NOT increasing the block size; "SC's".  no wonder gmax and LukeJr are spamming Reddit in defiance of Gavin's proposal:

http://hashingit.com/analysis/34-bitcoin-traffic-bulletin



Nice graph! Thanks for sharing. So with a 100% filled block you have a 0.1 probability of having your tx confirmed after 1000/sec. This is nasty.

As I already said  multiple times I'm a big supporter of Justus proposal to eliminate false block size scarcity and introducing economic incentive in the p2p nodes network.

Nonetheless I think that a part of txs will occur out of bitcoin main chain, through payment hub, lightning network, you name it. In fact the very solution Justus proposed to implement a price discovery mechanism in Bitcoin p2p network is based on micropayment channels.

Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

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

Activity: 1106


View Profile
May 05, 2015, 03:11:58 PM
 #23456


Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

I can't have said it better, really.

I'm aware that bitcoin development is quite peculiar and there's little to no margin for errors.
And this is the reason why I think it's important to start spreading Justus's idea in advance,
because as you rightly said we need a lot of time to get there. So the sooner we start the better.

That said I wonder what are the link you see between the price discovering mechanism sketched by Justus
and the Bitcoin consensus code? I see them as quite unrelated pieces of the system, but maybe I am missing
something obvious.

Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
justusranvier
Legendary
*
Offline Offline

Activity: 1400



View Profile WWW
May 05, 2015, 03:53:23 PM
 #23457


Justus laid out a structure.  There are a great number of missing pieces between what exists today in the consensus code and that structure.  There are also undefined and missing elements in the ecosystem.  I like the structure too, but we aren't anywhere close to it yet and it won't be soon.

The current proposal is Gavin's most reasonable one yet.  He dropped the assumptions about the future, took out most of the guesswork, and is implementing the method satoshi offered when the antispam 1mb limit was created in 0.3 or so.

More would be great, and future proof would be even better, no limit best....  but... remember, we are still in beta.  The pieces to do any of that are not written, tested, integrated, accepted and secured.

Bitcoin is still a baby.  So as eager as we all are to get there, we will get there by baby steps or end up not getting at all.  There are a great many looking for us to fail (check the short interest lately?) we help that failure by over-extending what can be done.

20mb gives us some room to build more of the missing pieces.  Its enough for now.

I can't have said it better, really.

I'm aware that bitcoin development is quite peculiar and there's little to no margin for errors.
And this is the reason why I think it's important to start spreading Justus's idea in advance,
because as you rightly said we need a lot of time to get there. So the sooner we start the better.

That said I wonder what are the link you see between the price discovering mechanism sketched by Justus
and the Bitcoin consensus code? I see them as quite unrelated pieces of the system, but maybe I am missing
something obvious.

I'll devote more time to explaining how the price discovery mechanism could be rolled out as an incremental upgrade after I finish with this:

https://github.com/justusranvier/wallet-ratings/tree/2015-1/2015-1
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 05:12:35 PM
 #23458

weaker, weaker, and weaker:

thezerg
Legendary
*
Offline Offline

Activity: 1246


View Profile
May 05, 2015, 07:48:29 PM
 #23459

I'm for Gavin's 20MB increase.  But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works.  The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).

So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit).  In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve).  So supply (space in a block) can actually increase as demand increases.

You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit.  The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high.  In that case, we are no worse than today's proposal.

Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1022


View Profile
May 05, 2015, 07:52:18 PM
 #23460

I don't think we need the same security model for buying loaves of bread that we use for buying homes,.
Of course you do, once you understand what the security problem is.

The entire job of the Bitcoin network is to make sure that the number of currency units is exactly correct at all times.

There's probably a hundred million loaves of bread sold every day, which represents a hundred million opportunities to improperly expand the currency supply.

I don't know if there's much hope of avoiding every possible improper expansion. I'm undecided on whether it really matters to have everything be on blockchain (or otherwise completely un-finagle-able like through OT).
Pages: « 1 ... 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 1217 1218 1219 1220 1221 1222 1223 ... 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!