Topic: Gold collapsing. Bitcoin UP. - page 297. (Read 2032266 times)
EPIC! We need more of this! http://www.coindesk.com/taringas-content-creation-surges-following-bitcoin-integration/
hey iCE,
did u see ZB's link above; which i can't verify, btw:
/u/nullc is already backpedaling. and you know what happens next?
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?
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.
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
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?
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.
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.
For posterity, here is Gregory Maxwell's blocksize increase proposal:
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.
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://bitcointalksearch.org/topic/m.11507371
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.
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/
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.
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.
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.
For posterity, here is Gregory Maxwell's blocksize increase proposal:
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.
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"?
For posterity, here is Gregory Maxwell's blocksize increase proposal:
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.
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://bitcointalksearch.org/topic/m.11506215
For posterity, here is Gregory Maxwell's blocksize increase proposal:
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.
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 heard something about that. that's extraordinary.
how does one convert their full nodes seamlessly and hopefully easily?
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.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.
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.
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.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.
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.
i don't discount the importance of diversity of opinion that exists theoretically in the current group of devs.
but can you imagine if a new group of core devs were put in place that could cooperate more fully leading to more responsive changes in the marketplace via the code?
but can you imagine if a new group of core devs were put in place that could cooperate more fully leading to more responsive changes in the marketplace via the code?
there's a clue here. and it's not good news.
/u/nullc still thinks he was right in banning Ver & Matonis despite an overwhelming community opinion to the contrary. the community's only course of action at the time, which has proven very successful and stood the test of time, was to "fork" away from PressCenter.org and move to another website. which has now become the de facto go to place.
I believe the Blockstream crew is going to learn the hard way that there's no such thing as tenure in Bitcoin./u/nullc still thinks he was right in banning Ver & Matonis despite an overwhelming community opinion to the contrary. the community's only course of action at the time, which has proven very successful and stood the test of time, was to "fork" away from PressCenter.org and move to another website. which has now become the de facto go to place.
in a way, i also see this as an opportunity which can be very bullish long term.
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.
after all, Bitcoin has evolved to that of a public good.
Jump to: