Bitcoin Forum
November 20, 2017, 11:41:24 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 ... 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 1217 1218 1219 1220 1221 1222 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 2010427 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



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

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

1511221284
Hero Member
*
Offline Offline

Posts: 1511221284

View Profile Personal Message (Offline)

Ignore
1511221284
Reply with quote  #2

1511221284
Report to moderator
1511221284
Hero Member
*
Offline Offline

Posts: 1511221284

View Profile Personal Message (Offline)

Ignore
1511221284
Reply with quote  #2

1511221284
Report to moderator
1511221284
Hero Member
*
Offline Offline

Posts: 1511221284

View Profile Personal Message (Offline)

Ignore
1511221284
Reply with quote  #2

1511221284
Report to moderator
Join ICO Now A blockchain platform for effective freelancing
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1511221284
Hero Member
*
Offline Offline

Posts: 1511221284

View Profile Personal Message (Offline)

Ignore
1511221284
Reply with quote  #2

1511221284
Report to moderator
sickpig
Legendary
*
Offline Offline

Activity: 1218


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

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

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

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

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

Activity: 1162


Gresham's Lawyer


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

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


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


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


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

weaker, weaker, and weaker:

thezerg
Legendary
*
Offline Offline

Activity: 1246


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

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


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

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).
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
May 05, 2015, 08:03:13 PM
 #23432

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.

I assume a fee market will be ready by then, or by whenever block scarcity becomes an issue.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 08:08:23 PM
 #23433

great article by Mike Hearn:

https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
May 05, 2015, 08:11:32 PM
 #23434

Blocksize debate blowing up all over /r/Bitcoin right now, though it's mostly pro-increase.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 08:48:32 PM
 #23435

Blocksize debate blowing up all over /r/Bitcoin right now, though it's mostly pro-increase.

what strikes me most about /nullc and LukeJr objections are that they revolve around incorrect perceptions of what the Bitcoin market looks like today.  for instance, /nullc believes that mining is centralizing.  i don't; look at the pie charts from mempool:



the distribution of miners has improved (decentralized) markedly since the ghash event.  i've regularly documented that improvement over the years and believe we may have in fact witnessed the very last time any pool gets anywhere near 50%.  i've argued using game theory and it appears to have been prescient.

also, he believes that the decrease in full nodes "creates huge systemic risk and undermines Bitcoin's value proposition".  give me a break; the decrease in nodes yes might be due partly to node dropout but i think it is mainly due to the proliferation of SPV clients.  furthermore, i was initially a part of the Bitnodes Incentive Program and was one of it's first payment recipients, however, due to the fact they require re-registration every month, i've dropped out.  it's too much of a hassle and involves relatively complex code to re-register while the payout is trivial.  but i still run my nodes and as i've said before, i'm actually looking forward to learning how to prune so i can run a dozen more nodes or so.

and what does he mean by this? "This is especially concerning as we've seen the deployment of full nodes fade out and even large commercial operations become dependant on third party hosted node services."  what's he talking about and where's the evidence?

and then he points to Kaminsky as some kind of prophet?:  "it should be noted that this outcome was already predicted years ago (e.g. by Dan Kaminsky's comments that I was writing about above), but we've still slid into it."  what sticks in my mind is the lost bet btwn Garzik and Kaminsky when DK predicted Bitcoin's underlying Proof-of-Work hash function (Sha-2) would be replaced within 12 months:  https://storify.com/socrates1024/bitcoin-pow-bet-10btc-jgarzik-vs-dakami-may-2014.   There haven't been any more famous tech experts who have been more wrong about Bitcoin.  even DK admits it now.

and then he points to Todd and MPOE as worthy colleagues against increased block sizes:  "Rather, the only push you see against larger blocks come from strong advocates of personal autonomy and decenteralization, like Peter Todd; or the MPOE crowd".   aligning one's self with these 2 is even more dangerous than Kaminsky.

he's always been almost bearish on Bitcoin; for years.  he's always said mining is centralizing despite the facts.  he's been a fan of Ripple in the past here:  https://en.bitcoin.it/w/index.php?title=Scalability&action=historysubmit&diff=14273&oldid=14112

you'll notice in the link below he admits to going back and deleting his posts of support for Ripple in the past.  who does that?  own up to it, don't try to cover it up.

here's all his concerns highlighted in gory detail  Roll Eyes:

https://www.reddit.com/r/Bitcoin/comments/34uu02/why_increasing_the_max_block_size_is_urgent_gavin/cqycy4h
rocks
Legendary
*
Offline Offline

Activity: 1149


View Profile
May 05, 2015, 09:36:15 PM
 #23436

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.

I like this proposal a lot.

High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all.

Reserving a front space in each block for high-priority non-fee transactions does two things:
1) It would ensure that high-priority transactions are processed in a timely fashion
2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly

This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing.

Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...)
Adrian-x
Legendary
*
Offline Offline

Activity: 1372



View Profile
May 05, 2015, 09:39:35 PM
 #23437


Quote from: nullc on redit
You've repeatedly made this accusation regarding me specifically-

LOL, bribing up that history is his response to this comment, for pointing out sidechains stand to benefit from a small transaction size.  I was not picking on him or even challenging his position merely pointing out why there was a debate at all.  

I originally stopped reading after the word specifically. but if it's any consolation ripple has always been a centralized system, and I have taken a lot of flack for pointing out that's its Achilles' heel and not supporting it, why not take some heat on the other side for not recognizing that fact at the start.  

I think nullc relates to sidechains on a very personal level and is feeling very threatened at the moment, my comment was an observation not an accusation for the record.

Thank me in Bits 12MwnzxtprG2mHm3rKdgi7NmJKCypsMMQw
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
May 05, 2015, 09:47:21 PM
 #23438


Quote from: nullc on redit
You've repeatedly made this accusation regarding me specifically-

LOL, that is his response to this comment, for pointing out sidechains stand to benefit from a small transaction size.  I think nullc feels very defensive at the moment, I was not picking on him or even challenging his position merely pointing out why there was a debate at all. 

ppl get defensive when they know there's some truth to the allegation.  in fact, they start seeing things that aren't there, like in your comment.  problem is, though, Blockstream for profit does indeed represent a conflict of interest to expanding tx throughput on the MC.  it's clear they stand to profit the more this tx volume gets pushed off to SC's.  plus, given all his Bitcoin skepticism and behavior over the years, it all fits.
pa
Hero Member
*****
Offline Offline

Activity: 516


View Profile
May 05, 2015, 09:48:43 PM
 #23439

https://www.reddit.com/r/Bitcoin/comments/34zj70/fincen_fines_ripple_labs_inc_in_first_civil/
Chainsaw
Hero Member
*****
Offline Offline

Activity: 624


x


View Profile
May 05, 2015, 09:51:40 PM
 #23440


So much joy from this news.

Pages: « 1 ... 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 1217 1218 1219 1220 1221 1222 ... 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!