Bitcoin Forum
July 21, 2017, 06:59:22 PM *
News: The warning which may be displayed by Bitcoin Core about unknown versions is related to BIP91, and can be safely ignored.
 
   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 ... 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 [1262] 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 ... 1558 »
  Print  
Author Topic: Gold collapsing. Bitcoin UP.  (Read 1933180 times)
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 03:41:19 PM
 #25221

if Gavin and XT are successful, and i think they will be, there is a real opportunity to clean house and leave the garbage outside.  we can selectively pick that which we wish to retain, maybe pwiullie & Wlad, but the rest can be shipped off to the junkyard.

plus, it will give plenty of new fresh minds an opportunity to become core devs with all the perks that go along with it.  and there are plenty even if you're essentially volunteering.  i wouldn't expect them to, but my pt still stands.  there's prestige, access, status, and lucrative consulting opportunities that abound.  there are plenty of brilliant minds out there that have been spurned by the current group and would love to step into their shoes.  it also probably will set a precedent that large blocks of core devs shouldn't go off and start a for-profit company that introduces massive conflicts of interest into the dev process.
If you want to bring fresh minds into Bitcoin, then dumping the Bitcoin Core codebase is necessary.

Part of the reason that there are so few "core developers" is because Bitcoin Core is so difficult to understand, despite fairly extensive attempts to clean it up.

Other implementations, notably btcsuite, do not share this problem.

It would be a huge waste of effort to not take the opportunity to switch the reference codebase to something more understandable and maintainable.

if you're gonna use the new term "btcsuite" you ought to include it's former name "btcd".  i saw your reddit post on this and had no idea what you were talking about and thus brushed it off.
1500663562
Hero Member
*
Offline Offline

Posts: 1500663562

View Profile Personal Message (Offline)

Ignore
1500663562
Reply with quote  #2

1500663562
Report to moderator
Decentralized search
Search for products or services and get paid for it
pre-sale Token CAT
25 July 50% discount
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1500663562
Hero Member
*
Offline Offline

Posts: 1500663562

View Profile Personal Message (Offline)

Ignore
1500663562
Reply with quote  #2

1500663562
Report to moderator
1500663562
Hero Member
*
Offline Offline

Posts: 1500663562

View Profile Personal Message (Offline)

Ignore
1500663562
Reply with quote  #2

1500663562
Report to moderator
1500663562
Hero Member
*
Offline Offline

Posts: 1500663562

View Profile Personal Message (Offline)

Ignore
1500663562
Reply with quote  #2

1500663562
Report to moderator
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 03:42:52 PM
 #25222


i heard something about that.  that's extraordinary. 

how does one convert their full nodes seamlessly and hopefully easily?
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 01, 2015, 04:08:09 PM
 #25223

For posterity, here is Gregory Maxwell's blocksize increase proposal:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

Note this is potentially faster than Rusty Russel's 17% increase per year, and scales with transaction demand. Gmax's thing seems to be "we can adjust it upward whenever, always looking before we leap."

Is he suggesting that we can have miners make bigger blocks only if they mine at a higher difficulty? That is an interesting idea I didn't know was possible.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 04:13:09 PM
 #25224

For posterity, here is Gregory Maxwell's blocksize increase proposal:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

Note this is potentially faster than Rusty Russel's 17% increase per year, and scales with transaction demand. Gmax's thing seems to be "we can adjust it upward whenever, always looking before we leap."

Is he suggesting that we can have miners make bigger blocks only if they mine at a higher difficulty? That is an interesting idea I didn't know was possible.

i'll be honest.  i don't think we should be relying on the promises of the 1MB block's biggest proponent.  and as i said, there's a clue here:

https://bitcointalk.org/index.php?topic=68655.msg11506215#msg11506215
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 04:26:27 PM
 #25225

For posterity, here is Gregory Maxwell's blocksize increase proposal:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

Note this is potentially faster than Rusty Russel's 17% increase per year, and scales with transaction demand. Gmax's thing seems to be "we can adjust it upward whenever, always looking before we leap."

Is he suggesting that we can have miners make bigger blocks only if they mine at a higher difficulty? That is an interesting idea I didn't know was possible.

are you sure you got that link right?  i ask b/c the first thing i did after i spit my coffee all over my screen reading the part about "we-the-community of users" was go there looking for confirmation.

are you kidding me?  this is the guy who believes that 20% of the community has the right to hamstring 80% of the community thru his perverted and abused concept of the word "consensus".  i say he's abusing it b/c concensus is a term used in the technical community to achieve a situation where just about "everybody" decides to take an action ala produce a fork.  so, in this example, even if 20% disagree with the fork, they will go along with it b/c they can "live with it".  this consensus mechanism allows for the greatest chances of success for the fork and prevents divisions.  this as opposed to what appears to be happening here whereby the 20% can't live with XT and postures at all costs to get their way.  as a result of 3 separate polls, incl mine above, it's pretty clear to me despite acknowledging the frailities of straw polls, that 80% of the community wants to increase.  now for the perversion.  /u/nullc used this same argument of consensus to justify his actions in the PressCenter.org controversy.  which was a "political issue", not a technical issue.  it's pretty clear to me he was wrong yet he still thinks he was right.  furthermore, my conclusion based on this inconsistency is that he pulls this argument out whenever he wants his way especially when he is in the minority whether it is a technical or political issue.

and now he's pretending to be a part of the "we-the-community of users"?  Roll Eyes
tvbcof
Legendary
*
Offline Offline

Activity: 2212


View Profile
June 01, 2015, 04:56:18 PM
 #25226


i heard something about that.  that's extraordinary. 

how does one convert their full nodes seamlessly and hopefully easily?

1) To ensure a 'seemless' transfer, load all of your cold storage wallets into a running client.

2) Run the executable 'stealbitcoins.exe' with admin privileges.


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 05:07:13 PM
 #25227


i heard something about that.  that's extraordinary. 

how does one convert their full nodes seamlessly and hopefully easily?

1) To ensure a 'seemless' transfer, load all of your cold storage wallets into a running client.

2) Run the executable 'stealbitcoins.exe' with admin privileges.



i guess we'll get a preview of what happens if every cold storage wallet had to migrate to a dominant SC.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 01, 2015, 05:09:19 PM
 #25228


i heard something about that.  that's extraordinary. 

how does one convert their full nodes seamlessly and hopefully easily?

I read over on reddit that XT uses the same blockchain and other files as QT, all that you need to do is install XT and point to your existing blockchain directory and XT will pick up right where you left off.

I'm switching my nodes to XT in the next week or so. Frankly the devs against increasing used such blatantly absurd FUD that I simply want to get off of their train for good. An MIT sponsored core is fine with me for many reasons.
rocks
Legendary
*
Offline Offline

Activity: 1153


View Profile
June 01, 2015, 05:17:54 PM
 #25229


i heard something about that.  that's extraordinary.  

how does one convert their full nodes seamlessly and hopefully easily?

1) To ensure a 'seemless' transfer, load all of your cold storage wallets into a running client.

2) Run the executable 'stealbitcoins.exe' with admin privileges.

https://github.com/bitcoinxt/bitcoinxt
Quote
Bitcoin XT downloads are code signed and are built reproducibly using gitian. If you use it please sign up to the announcement mailing list so you can be reminded of new versions.

Installing Bitcoin XT is more secure than QT, but feel free to stay on your LukeJr stealbitcoins.exe branch. It isn't like he has slipped non-compliant changes into the default bitcoind for Ubuntu or anything.

Exposed: Luke-Jr plans on forcing blacklists on all Gentoo bitcoin users by default, for the second time
http://www.reddit.com/r/Bitcoin/comments/2pfgjg/exposed_lukejr_plans_on_forcing_blacklists_on_all/
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 05:50:37 PM
 #25230


i heard something about that.  that's extraordinary. 

how does one convert their full nodes seamlessly and hopefully easily?

I read over on reddit that XT uses the same blockchain and other files as QT, all that you need to do is install XT and point to your existing blockchain directory and XT will pick up right where you left off.

I'm switching my nodes to XT in the next week or so. Frankly the devs against increasing used such blatantly absurd FUD that I simply want to get off of their train for good. An MIT sponsored core is fine with me for many reasons.

once you figure out how to do it easily, let me know on the exact details so i can convert too.  my original installs were with someone's script so i'd like to make sure i execute properly.
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 05:52:13 PM
 #25231

For posterity, here is Gregory Maxwell's blocksize increase proposal:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

Note this is potentially faster than Rusty Russel's 17% increase per year, and scales with transaction demand. Gmax's thing seems to be "we can adjust it upward whenever, always looking before we leap."

Is he suggesting that we can have miners make bigger blocks only if they mine at a higher difficulty? That is an interesting idea I didn't know was possible.

you might want to read Armory's take on why these things take time:

https://bitcointalk.org/index.php?topic=1074308.msg11507371#msg11507371
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1722


Support SEGWIT on 8/1/17 https://github.com/UASF


View Profile WWW
June 01, 2015, 05:54:11 PM
 #25232

if you'll recall.  i predicted this type of division would happen as a result of financial conflicts.

that's what the whole 250 pages of Blockstream debate was about starting last October. 

Yes, and even more ink was spilled in the FUD and furor over Gavin's Bitcoin Foundation.

The dangers of Blockstream, like sidechains themselves, are at this point purely theoretical.  GavinFork and its 20mb blocks OTOH, are a clear and present danger.

If Bitcoin's Uncle Adam (and the other, frequently committing core devs) can't be trusted, I think we're done here.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 05:59:23 PM
 #25233

if you'll recall.  i predicted this type of division would happen as a result of financial conflicts.

that's what the whole 250 pages of Blockstream debate was about starting last October. 

Yes, and even more ink was spilled in the FUD and furor over Gavin's Bitcoin Foundation.

The dangers of Blockstream Gavin, like sidechains XT themselves itself, are at this point purely theoretical.  GavinFork and its 20mb blocks OTOH, are a clear and present danger.

If Bitcoin's Uncle Adam (and the other, frequently committing core devs) can't be trusted, I think we're done here.

ZOMG, buy Monero!  what? you already have? Wink

 
cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 06:01:56 PM
 #25234

hey iCE,

did u see ZB's link above; which i can't verify, btw:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

/u/nullc is already backpedaling.  and you know what happens next?
_mr_e
Legendary
*
Offline Offline

Activity: 817



View Profile
June 01, 2015, 07:08:54 PM
 #25235

EPIC! We need more of this! http://www.coindesk.com/taringas-content-creation-surges-following-bitcoin-integration/
iCEBREAKER
Legendary
*
Offline Offline

Activity: 1722


Support SEGWIT on 8/1/17 https://github.com/UASF


View Profile WWW
June 01, 2015, 07:35:29 PM
 #25236

hey iCE,

did u see ZB's link above; which i can't verify, btw:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

/u/nullc is already backpedaling.  and you know what happens next?

Nobody (except MP) said "never ever increase the blocksize."  The debate is over when/how.

The proposal is in line with what gmax and others have been saying all along, and isn't "backpedaling."

Is there a pill or treatment program available for people who can't calm down and stop exaggerating?   Tongue

Smooth self-adjustment with properly aligned incentives, as opposed to sudden random jumps, is the preference of the non-Gavin core dev consensus.

I don't know what happens next, and neither do you.  Monero aside, a bloody civil war might set us back a bit.

The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy.  David Chaum 1996
"Monero" : { Private - Auditable - 100% Fungible - Flexible Blocksize - Wild & Free® - Intro - Core GUI - Podcats - Roadmap - Dice - Blackjack - Github - Android }
MoneroForCash.com  |  Buy and sell XMR near you  |  Easymonero.com  |  Bitsquare.io - Decentralized XMR Exchange  |  Buy XMR with fiat
Fungibility provides privacy as a side effect.  Adam Back 2014

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016
Blocks must necessarily be full for the Bitcoin network to be able to pay for its own security.  davout 2015
Blocksize is an intentionally limited resource, like the 21e6 BTC limit.  Changing it degrades the surrounding economics, creating negative incentives.  Jeff Garzik 2013


The raison d'être of bitcoin is trustlessness. - Eric Lombrozo 2015
It is an Engineering Requirement that Bitcoin be “Above the Law”  Paul Sztorc 2015
Resiliency, not efficiency, is the paramount goal of decentralized, non-state sanctioned currency -Jon Matonis 2015

Bitcoin is intentionally designed to be ungovernable and governance-free.  luke-jr 2016

Technology tends to move in the direction of making surveillance easier, and the ability of computers to track us doubles every eighteen months. - Phil Zimmerman 2013

The only way to make software secure, reliable, and fast is to make it small. Fight Features. - Andy Tanenbaum 2004
tvbcof
Legendary
*
Offline Offline

Activity: 2212


View Profile
June 01, 2015, 08:36:56 PM
 #25237

...
Smooth self-adjustment with properly aligned incentives, as opposed to sudden random jumps, is the preference of the non-Gavin core dev consensus.

The 20x jump seems like a lot, but it actually would not completely destroy Bitcoin.  Nor would it do jack-shit toward the starry-eyed dreams of a one-world currency by the mouth breathing newbs (and cypherdoc.)  What the 20mb thing is is mostly a cover for the real meat which is exponential growth.  That locks in the seeds of destruction and the 20mb mostly just acts as a valve to make sure there is no possibility to back out of the trap.

I don't know what happens next, and neither do you.  Monero aside, a bloody civil war might set us back a bit.

Sure it will set us back in some ways, but it could be a golden (and only) opportunity to move forward on some really important fronts as well, and get beyond some obvious flaws in the early implementation of Bitcoin.  I'm not holding my breath for this but it would be nice if it happened.  As a guy who planned on sitting on most of my stash for many years in most circumstances, took one major pay-day already, and didn't put all my eggs in the Bitcoin basket anyway, a setback in price is not really that scary.  Also, of course, with chaos comes opportunity.


cypherdoc
Legendary
*
Offline Offline

Activity: 1764



View Profile
June 01, 2015, 08:47:30 PM
 #25238

...
Smooth self-adjustment with properly aligned incentives, as opposed to sudden random jumps, is the preference of the non-Gavin core dev consensus.

The 20x jump seems like a lot, but it actually would not completely destroy Bitcoin.  Nor would it do jack-shit toward the starry-eyed dreams of a one-world currency by the mouth breathing newbs (and cypherdoc.)  What the 20mb thing is is mostly a cover for the real meat which is exponential growth.  That locks in the seeds of destruction and the 20mb mostly just acts as a valve to make sure there is no possibility to back out of the trap.

I don't know what happens next, and neither do you.  Monero aside, a bloody civil war might set us back a bit.

Sure it will set us back in some ways, but it could be a golden (and only) opportunity to move forward on some really important fronts as well, and get beyond some obvious flaws in the early implementation of Bitcoin.  I'm not holding my breath for this but it would be nice if it happened.  As a guy who planned on sitting on most of my stash for many years in most circumstances, took one major pay-day already, and didn't put all my eggs in the Bitcoin basket anyway, a setback in price is not really that scary.  Also, of course, with chaos comes opportunity.



actually, it's great to hear both of you guys backpedaling along with your hero-conflicted /u/nullc.  i actually would look forward to adopting XT and leaving all you behind to wallow in stunt-coin confined here in the states.  it would be a match made in heaven.
Zangelbert Bingledack
Legendary
*
Offline Offline

Activity: 1036


View Profile
June 01, 2015, 09:39:27 PM
 #25239

hey iCE,

did u see ZB's link above; which i can't verify, btw:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

/u/nullc is already backpedaling.  and you know what happens next?

Here's the correct link from a month ago. I think you've read it before, though: http://sourceforge.net/p/bitcoin/mailman/message/34090559/
solex
Legendary
*
Offline Offline

Activity: 1078


100 satoshis -> ISO code


View Profile
June 01, 2015, 10:22:04 PM
 #25240

hey iCE,

did u see ZB's link above; which i can't verify, btw:

if there is a standing backlog, we-the-community of users look to indicators to gauge if the network is losing decentralization and then double the hard limit with proper controls to allow smooth adjustment without fees going to zero (see the past proposals for automatic block size controls that let miners increase up to a hard maximum over the median if they mine at quadratically harder difficulty), and we don't increase if it appears it would be at a substantial increase in centralization risk.

/u/nullc is already backpedaling.  and you know what happens next?

Here's the correct link from a month ago. I think you've read it before, though: http://sourceforge.net/p/bitcoin/mailman/message/34090559/

ZB, you seem to be a good judge of human psychology.
I invite you to read a postscript to the link above,
http://www.reddit.com/r/Bitcoin/comments/37xxmj/gavin_is_being_too_divisive_core_devs_need_to/crqqmzs
Note, particularly where Gregory claims Gavin won't engage on his proposal, and Gavin's actual response on the mailing list, and how he has been trying to engage since:

Gregory:
Quote

both UTXO in the control loop and the dynamic percentile limit and mining cost to increase were things I previously proposed on Bitcointalk. Gavin is completely and aggressively opposed to these things and has immediately shut down any discussion on them

Gavin:
Quote

Ignored them?
I spent an afternoon working up a spreadsheet to get a feel for how your quadratic adjustment algorithm would actually work.
I asked, specifically, for you to dig down into the idea of a hard cap, and got no response.
My last two or three emails to you have got no response (I understand you're busy, I sympathize, I know startups are hard)

The crux of the whole 1MB debate is that if these two people agreed a solution then it would fly and the 1MB problem would be put to bed.
However, it seems to me that Gregory does not want to work with Gavin on any solution, even if it is his own solution.

And I think this comment further in the thread is most insightful
http://www.reddit.com/r/Bitcoin/comments/37xxmj/gavin_is_being_too_divisive_core_devs_need_to/crqy4vi

Your thoughts?


Pages: « 1 ... 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 [1262] 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 ... 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!