That's why I support the idea of getting rid of the Proof-of-Work mining altogether and replacing it with Proof-of-Stake. Right now miners are parasites to the network. The only owners of the network are actual bitcoin holders.
Satoshi's invention of mining (which probably should have been called "confirming") not only secures the blockchain but has one very important side-effect: the disbursement of the 21 million coins into as many hands as possible, i.e. distributing BTC wealth. This job is 2/3rds complete. Would we prefer it if 73 people who happened to be around in the first months of 2009 got all the BTC to begin with? |
|
|
|
i would like to propose a compromise.
let the Blockstream folks insert their SPV proof into source while simultaneously eliminating the block size limit. then we can see which Ferrari will go faster.
the network effect of sound money vs that of SC's (speculation). it would be a fantastic test of the market.
[ static] One interesting quote there: "The blocksize debate if anything substantially slowed the release, absorbing mindbogglingly enormous amounts of time, and also having avoid including some scaling tools to avoid people getting confused that sidechains themselves were a scaling answer." In the process of trying to show how they are not a conflict of interest, he uses a conflict of interest (time devoted). The thing is, he is right sidechains are only a factor in scaling, but they aren't the answer. They do provide for some scaling, but not at all a full solution. They waste a lot of time trying to claim that there isn't a conflict of interest. The better method is to simply acknowledge it and move on. People are fairly accepting of the risk for now, but their efforts to fight it and claim it doesn't exist both make them look foolish and waste their time. No one asked that mindbogglingly enormous amounts of time be wasted. That was their free decision. The simple approach was to let Gavin proceed with handling the block-size issue while they focused on side-chains, instead of being a ball-and-anchor chain hampering dealing with the single most serious threat to Bitcoin's network effect and ecosystem growth. |
|
|
|
How does velocity of money in gold and between central banks compare to the velocity of money with PayPal and Visa, either in volume or transactional bandwidth?
I don't think that there is much day-to-day traffic in gold between central banks because that role was fully devolved to the US$ in 1971. So, in the modern era there is a split between SoV and payments, which didn't exist before the 20th Century. Bitcoin is a difficult comparison because it straddles and rejoins the two domains: currency and payments, so while gold is primarily a SoV currency, Visa is 100% a payment system and contributes to the velocity in fiat. The potential for Bitcoin is phenomenal because it can usurp both domains if computing technology permits. This is probably only a question of time because computing tech is getting more powerful at a much faster rate than the world economy is growing. Bitcoin is also interesting because for the first time there is a currency for which velocity can be exactly measured, as most of the time it is statistical guesswork. They are not incorrect about it won't run decentralized.
The most important single feature of Bitcoin is its 21 million cap. Decentralization is the horse for this cart. The goal is to maintain the 21 million (preventing extra issuance and double-spending). Decentralization is the only way to be sure of this, compared to say, XRP, which could be upped at any time. The solution to centralization concerns is to implement payment channels for node services, as Justus Ranvier has detailed, not to restrict volumes by pretending that Bitcoin is competing with gold only. |
|
|
|
Game over, Frap.doc. Thus Saith The LORD. Amen! of course not. as long as you continue to constrain it to 1MB. Cypherdoc is correct. Nick Szabo and Oleg Andreev are both wrong. I don't care what their credentials are, in this matter they are not thinking clearly. If Bitcoin does not compete with Paypal and Visa then it will NEVER compete with gold and central banks.The reason is that physical presence matters. Gold is physical and has only two serious rival metals: platinum and silver. CB fiat is made physical by government power: legal tender for printed cash and debt-money backed by taxation and guns (although through incompetence, fiat is proving a failed experiment). Bitcoin also has a physical presence: its ecosystem of users, companies, on-line services and large mining network. Take those away and it becomes just another Worldcoin, Yacoin, Litecoin or Auroracoin. Bitcoin, the software can be copied many times, and its principles can be adapted in new ways e.g. NXT and Monero. There is no scarcity for a digital currency unless that scarcity is backed by a physical presence, an ecosystem. Capping the Bitcoin network at 1MB blocks is an assumption that enough of an ecosystem has been established that this particular instance of digital currency cannot be overtaken by a larger ecosystem, a larger physical presence, by one of the alternatives. This is a huge assumption which is not viable because the Bitcoin ecosystem footprint in the world economy is miniscule. Only when volumes approach Visa-scale can people sit back and consider that Bitcoin is seriously competing with gold and central banks. Even then, it can't remain standing still. |
|
|
|
If you try to argue TPTB don't exist or don't intend to do this, then I have no rebuttal other than  They don't exist as the monolithic self conscious entity that you picture.  Thanks for calling this out. I, for one, really struggle dissecting the good points (and there are many) from posts which are framed within a TPTB, NWO or a (Blacklist-style) Cabal world-view. |
|
|
|
Since the blocksize issue is controversial and may take some time to settle, we are better off implementing this elastic cap right now with a softfork (your phase II) and skip the hardfork part (phase I).
We could do that by choosing T=0.5MB (2T = 1MB = current maxblocksize).
True, if the circumstances were different. Presently the average (7-day, moving) block size (ABS) is about 400KB, 80% of T, and T will certainly be less than the ABS by the time an elastic cap can be implemented. ABS will never approach 2T because some miners will always churn out small or empty blocks (certainly while the reward > block fees), so the present ABS is for practical purposes equivalent to T now. The point which would normally be an alert for attention to be given to the prevailing limit. The elastic cap with fee pool does need working out in detail, as the discussion between molecular and NewLiberty shows. Its mechanics, incentives, attack vectors and long-term implications need to be known and understood. This won't happen quickly. Phase I buys time for Phase II. Increasing the 1MB is technically very simple, accepting just the usual risk inherent in larger blocks. If this type of consensus can be hand-waved away, then we are going to have to go home and learn to love our respective fiats, because they will all be around for a lot longer. |
|
|
|
I really like Meni's elastic block cap proposal. Obviously increasing the block size requires a hard fork, but the fee pool part could be accomplished purely with a soft fork.
Absolutely. It's worth clarifying that the actual mechanics of how the pool fee works, (particularly how it is calculated), does not have to be on the critical path to resolving the 1MB problem. All that is necessary today for Meni's proposal is to agree that a pool fee, of some make-up, can usefully exist.Then it is possible to look at a simple implementation plan which overcomes the urgency of dealing with the 1MB, does not raise the limit too much, and allows time for an elastic cap with rollover penalties to be fully worked out, modeled, developed, and tested. As mentioned before, the pool fee could incorporate a function of block delta utxo and sigops. Phase I: Hard Fork to increase the max block size to 2T, e.g. via block version 4. 2T might be in the region of 6 or 8MB which also scales at a fixed percentage each year, say 20%, or a fixed multiple (e.g. 4x) of the recent average 144 or 2016 blocks. However, the difference this time is that no miner will be able to mine a block larger than T without paying a pool fee, but this won't be possible because it requires a supermajority on version 5 blocks to vary the pool fee from zero. Phase II:Soft fork to implement the full elastic cap, effective by supermajority, e.g. via block version 5, when blocks between T and 2T can then be mined. Advantages: Decoupling dealing with the hard-limit, from the making of a graceful decay in network performance as the limit is approached. No urgency on how to best to set the pool fee, lots of time for debate and modelling. A yearly scaling percentage can be more approximate because it should be easier to schedule hard-fork revisions to this as and when changes in global computing technology dictate. |
|
|
|
Bitcoin for everybody not just for the elite, super rich or startup services ....
Voted for XT
uhh I think, that you missed the point. please take your time and read about XT and recent news again.. So what are the recent news? I am voting for XT under the assumption that THE ONLY THING they would do is to increase the max block size from 1 MiB to 8 MiB. If there anything else they want to implement as a part of the hard fork then I might not vote for XT. This poll sucks in a sense that it is unclear what XT would specifically introduce. Gavin has said that he would not link the hard-fork with any other changes (even though it would be a real benefit to Bitcoin to get a few technical improvements done at the same time which also need hard-forks, and will probably never happen because of that). |
|
|
|
All good points. And yes, Greg's posts are full of clever sub-texts. He did reply in the dev & tech on Mike's article, but only to hand-wave it away: https://bitcointalk.org/index.php?topic=1054181.msg11318788#msg11318788It remains curious to me that such a strongly written article was largely ignored by the dev & tech contributors, who sometimes debate the minutiae of an obscure software topic. There was no attempt to determine whether Mike is broadly right or not, and maybe Greg's reply "put-off" other people echoing the concerns. Those quotes are nice to see in one place. Some evidence of flexibility overall. Yes, Luke was tagged "poisonous". He runs Eligius which I mentioned earlier, never played ball when the soft-limits were being tested, though Greg omits this fact, and any criticism of Luke for it. |
|
|
|
...
There are issues among such a group of people that we probably can't hope to understand. The politics, the interpersonal clashes, the miscommunications, the lingering grudges tinting things. Again, I think your implication may be right, this may be more a social issue than a technical one.
Interesting. I decided to read all Greg's recent posts and found one which makes his position much clearer. There is a soft blocksize limit in addition to the hard one. Originally it wasn't easy to adjust. We ran into the soft limit, and were pushing into it for months at a time back at the end of 2012 and beginning of 2013. Transactions slowed down and there was some complaining, but the wheels did not fall off and Bitcoin's adoption grew substantially during that time. A lot of technical innovation happened then-- in particular replace-by-fee was invented and child-pays-for-parent was deployed. After the soft limits were increased, development on these improvements went fallow, sadly (e.g. CFPF was never merged, or matured to a merge ready state, in Bitcoin Core).
The experience we have says there will not likely be a dire emergency. We also have reason to believe, from the prior accidental quasi-hardfork, that the mining portion of the network can be updated within a day or two during an actual emergency. A straight-forward blocksize bump also has the benefit of being completely compatible with existing SPV clients (they can't see the blocksize). If there really were a dire situation where it was larger blocks or doom-- I'm confident that larger blocks could be deployed quickly without much trouble; and in that kind of situation: consensus would be easy. No matter how concerned people are about larger sizes, if the choice is really larger or a useless network, the former is preferable to everyone. There is also plenty of room for other creativity, as we saw before in 2013, should the need arise, but it can be hard to predict in advance.
He doesn't really want to engage in the mechanics of a block size increase right now, because his opinion is that the limit can be safely maxed out. I wish he had said this a couple of years ago in BCT because then the pros-and-cons of letting the limit be hit could have been hammered out before the question of how to change the limit needed addressing (which is the case now). Maybe he didn't say this two years ago because it wasn't his position then? Compromise is very difficult when one side does not recognize that an urgent problem, or even just that a problem, exists. He is looking at it from a very technical level. Advantages of hitting the limit is speeding the development of some software components, work in adversity etc, the downside is non-technical: a PR disaster, collapsing price, loss of VC enthusiasm, academics noting that a decentralized community cannot be trusted to manage a global currency. IMHO, these downsides far outweigh the technical, software benefits. It is simply playing with fire. He also forgets that not all mining pools obeyed the soft-limits in 2013. A few didn't. e.g. when the soft-limit was 250KB Eligius was mining 500, when the soft-limit was 500 Eligius mined 750. There was always some level of extra capacity which does not exist at 1MB. He repeatedly says that he is worried about centralization, loss of nodes. Well, the fact is the fastest way to kill *off the most nodes at once is to quickly deploy a hard-fork. A hard-fork needs as much time as possible to be as smooth as possible, maintaining the network intact. *Nodes left on an old fork are not guaranteed to upgrade, some will just switch off. |
|
|
|
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/crqqmzsNote, 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:
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:
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/crqy4viYour thoughts? |
|
|
|
And Rusty Russell offers a stepped increase: Countries which had best bandwidth grew about 17% a year, so I think that’s the best model for future growth patterns (China is now where the US was 7 years ago, for example).
If bandwidth is the main centralization concern, you’ll want block growth below 15%. That implies we could jump the cap to 3MB next year, and 15% thereafter. Or if you’re less conservative, 3.5MB next year, and 17% there after.
http://rusty.ozlabs.org/?p=493This would be tight, but a hell of a lot better than doing nothing. All he needs to do is convince his Blockstream colleagues and the basis for a compromise exists. |
|
|
|
Another misleading title.  Which part ? It is quoted from his comment as it is... You took two things which Maxwell told and made it one-like. This will make people think in a different way. Moreover, he didn't tell "I will sell my coins and will move on with other things", instead he told, "if Bitcoin goes a centralizing route, I will find other things to work on". Both are different. If you read the full statement that he has made, it'd be clear to you that he considers the adoption of Bitcoin-XT as the centralized route. When the 1MB maxes out and confirmation times blow out, and the press articles appear savaging the "community" that failed, the ensuing PR disaster, and price collapse, a lot of full nodes will go dark - and then Gregory Maxwell will see the route to centralization. He might say "oops I didn't expect that", but it will be too late. So if Maxwell doesn't want to fork and create a 20MB+ blocksize and stay with 1, what are his proposed solutions? Gregory recently came up with a solution, which Gavin found very interesting, and tried to work from it, but somehow he got no further useful feedback and the proposal has languished. http://sourceforge.net/p/bitcoin/mailman/message/34100485/It is the kind of thing that all the core dev could have worked from to get a solution - if they wanted to, but the discussion went elsewhere, |
|
|
|
It is not that GMaxwell and other core devs did not agree with the problem of 1 MB cap. But, they are proposing a different solution to handle this, i.e. use of www.lightning.network and sidechains, which blockstream is working on. Though, I am not sure, how far that work is done. But, increase of cap to 20MB only delays the issue for a few more years. This is not a permanent solution as Gavin agreed too. What GMaxwell is saying is, if we do not implement the permanent solution sooner using sidechains & lightning.network and delay it for a few years, then bitcoin might grow too big to implement a fork. They have said that sidechains are much more for experimental development (replacing the need for alt-coins), not for scaling. Lightning Network is big and complex and will not be deployed any time soon, maybe in 3 years, or 2 if lucky. However, the 1MB will be causing serious delays in tx confirmations within 1 year. So, an increase, even to 5MB or 10MB will buy the time needed for LN to be fully developed and deployed. Personally, I like what LN offers, I want to see it succeed as it will enhance Bitcoin. But I would rather have it enhance a healthy Bitcoin than one that is crippled and under a PR disaster cloud. Why won't Core Dev buy the few years needed to bring LN and other off-chain solutions to the point where they are taking volume? |
|
|
|
Time to revive this thread again. Gavin is now taking action on the 1MB limit. https://bitcointalk.org/index.php?topic=1074701.0;allEdit: I doubt Bitcoin will remain viable in two years time if the 1 MB limit is not addressed, so I will not be able to revive this thread a third time.  Yep, and I would really like to see Jeff Garzik explain what his solution is now since he has had 4.5 YEARS to consider it further. A solution other than do nothing, lets crash into the limit (which he never liked in the first place), and see what happens. More like this maybe: We should be able to at least match Paypal's average transaction rate... -static const unsigned int MAX_BLOCK_SIZE = 1000000;
+static const unsigned int TX_PER_MINUTE = 1400;
+static const unsigned int TX_AVG_SIZE_GUESS = 256;
+static const unsigned int MAX_BLOCK_SIZE =
+ TX_PER_MINUTE * TX_AVG_SIZE_GUESS * 10 * 2;
|
|
|
|
Another misleading title. Which part ? It is quoted from his comment as it is... You took two things which Maxwell told and made it one-like. This will make people think in a different way. Moreover, he didn't tell "I will sell my coins and will move on with other things", instead he told, "if Bitcoin goes a centralizing route, I will find other things to work on". Both are different. If you read the full statement that he has made, it'd be clear to you that he considers the adoption of Bitcoin-XT as the centralized route. When the 1MB maxes out and confirmation times blow out, and the press articles appear savaging the "community" that failed, the ensuing PR disaster, and price collapse, a lot of full nodes will go dark - and then Gregory Maxwell will see the route to centralization. He might say "oops I didn't expect that", but it will be too late. |
|
|
|
|
My Q&A on why going with XT is the correct and conservative approach if Core fails to upgrade with Gavin's fix to the 1MB problem:
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Q; What is a conservative course of action?
A: Conservative action (for a successful enterprise) is always to maintain the status quo as much as possible in the face of necessary change. Because Bitcoin has prospered for 6 years the status quo is to maintain the network as it is now.
Unfortunately, neither keeping the 1MB or increasing it can maintain the network how it is now!
This is a dilemma, but all enterprises face dilemmas at some time: necessity for change from competition, customers, technology or regulation. So, a conservative position is to adapt to an external change while maintaining the status quo as much as possible.
Q; Why isn’t “doing nothing” the best approach?
A: Because “doing nothing” has no real fall-back plan.
The fall-back plan for an increase to, say 20MB, is a later soft-fork down to 2 or 3MB. This may or may not become necessary, but at least it can be achieved smoothly. Think: duck paddling hard in a millpond.
If the 1MB limit is kept and causes mayhem to confirmation times, bad publicity etc, then the fall-back “plan” is a painful and panicked hard-fork. Think: duck going through the water-wheel.
Q: When is a hard-fork not a hard-fork?
A: When it is planned so long ahead that 100% of all software instances are upgraded before it takes effect.
In practice, this can’t be achieved but targeting 90+% is desirable and sufficient for a smooth transition.
Q: When is a hard-fork most painful?
A: When it is a rapid decision, forced by circumstances, and everyone has to upgrade in a very short time.
The more delay before acting causes a bigger downside when a fork becomes forced.
Q: What about keeping the 1MB to put upward pressure on fees?
A: That is “Blockchain Economics”. Applying to the blockchain a false economic model of reality, i.e. an economic model which has a hard limit such as the zero-bound in Central Bank interest rate targeting which attempts to set the price of money in a fiat system, but fails in a deflationary economy.
When the rubber hits the road of this reality the result will be a rapid plateau in total fees and then an inexorable decline as users abandon the use of Bitcoin in favour of alternatives, and new cryptocurrency users keen on the future of money are forced to use alternatives from the get-go.
Q: OK, but I’m a determined fan of Blockchain Economics. When is it safe to try it?
A: It’s never safe because of the Trade-Off, but the best time is trying a soft-limit while the hard-limit is higher (safety valve), and when the network is small but viable, and no one is paying attention, such as the situation in 2012, Unfortunately, the time for this has gone because the Bitcoin market capitalisation is in the billions of dollars and the world’s press is closely watching.
Q: What is the Trade-Off?
A: A fundamental of Bitcoin is its confirmation cycle which averages 10 minutes.
When blocks have extra space the transaction counts per block are highly variable, but any given unconfirmed transaction may expect confirmation in 10 minutes.
When blocks are full transaction counts per block are stable, but the expected confirmation time for a unconfirmed transaction becomes highly variable.
Q: Is the benefit of very stable block sizes worth the cost of highly variable confirmation times?
A: No!
Q; When is a flooding or spamming attack on Bitcoin most effective and cheapest to execute?
A: When blocks are nearly always full. It is least effective and most expensive when blocks normally have lots of unused space.
Q: Can Bitcoin be a reserve / settlement currency with high-value users, primarily a store of value like an electronic gold?
A: Yes, but not when it can only handle 0.01% (a ten-thousandth) of the world’s transactions. Not when another cryptocurrency is handling even 1%, let alone 10%, 50% or 99.99% of the world’s transactions. Bitcoin can only become a true reserve currency and electronic gold when it scales. Otherwise this remains a dream, a mirage.
Q: What about bandwidth considerations?
A: Satoshi put the 1MB in place when there were no lightweight nodes and all users had to run a full node. That time is nearly five years ago. Global improvements in bandwidth mean that the overhead he allowed for, by selecting 1MB in 2010, is more like 4MB in 2015.
Q: What about technical concerns such as growth of the UTXO set?
A: The smartest way to meet a challenge is to leverage it as an opportunity.
Example : Aligning the demand for blocks larger than 1MB with an incentive to maintain a cleaner UTXO set.
The complexity of this change needs to be weighed against the simplicity of a fixed limit (e.g. 20MB). Sometimes simplicity outweighs a leveraged gain.
Also, the UTXO set could be kept cleaner, as a stand-alone change: allowing free transaction space based upon reducing utxo (negative delta) instead of being based upon the number of days destroyed, which was to encourage old coins being spent, something less important.
Q. What are the implications for decentralisation, particularly: full node counts?
A. Full node counts have been in decline for several years, mostly because of the growth in SPV wallets and lightweight nodes, and mining pools (for minimizing variance), also the increase in blockchain size for users who won’t spend a few $100 on TB disks.
Many node owners are long-term investors and believers in Bitcoin as a major currency and payment system of the future. That is why they hang in there. They are waiting to see it scale and will run non-mining, non-commercial nodes to do it. If the status quo is destabilized (e.g. unstable confirmation times) then full node owners will switch off faster.
Full node counts would be improved by greater adoption and the future use of node payment services where non-mining nodes get micro-payments via off-chain channels for servicing the network.
Keeping the 1MB, because it is the least conservative action, will accelerate the decline in full node counts.
Q: What if someone makes a load of gigablocks?
A: They can’t. If the 1MB disappeared, the message size limit of about 32MB means that this is the maximum block size. Gigablocks are not possible until all nodes support set reconciliation ("bandwidth reduction scheme") such as in IBLT, and block segmentation software.
Q: Why not wait for off-chain solutions which can handle 100x the on-chain volume, like Lightning Networks?
A: There is no time for that, LN is still in the documentation and technical specification stages, also the LN opinion is that 1MB is too small for them in the event that a lot of payment channels need to be closed quickly. 32MB or even 20MB would be sufficient for a long time.
|
|
|
|
You can never win with the masses. They will always be wrong, for as long as they demand to organize themselves in collectives. The Internet is essentially the mass of masses. Extrapolate the audience averaging effect in the popular game show Who Wants to Be a Millionaire: "But there’s a third option: You can use your “Ask-the-Audience" life line. You can poll the entire studio audience on the four possible answers, and their responses are instantaneously assembled into a bar graph. Invariably, this graph shows one overwhelming choice, and with rare exceptions the audience is right. “I’ll trust the audience,” you tell Regis. “Final answer.” Good move. But why? No person in the audience is any more likely than you to know where grapes come from, yet the collective intelligence of the group is almost always a better bet than your best guess. Psychologists are very interested in this perplexing statistical phenomenon. If the crowd is always wiser than any individual, what does that say about the way knowledge is stored and arranged in our minds? And can it help us make better choices, even beyond game shows? ... That’s actually what Vul and Pashler found when they ran the experiment. As reported in the July issue of the journal Psychological Science, the average of two guesses for any individual participant was better than either guess alone, regardless of the time between guesses. So polling the “crowd within” does indeed yield a statistically more accurate answer. What’s more, this internal crowd gets more independent-minded with time: Contestants who were asked to second-guess themselves three weeks later benefited even more by averaging their two guesses than did those who second-guessed themselves immediately. The psychologists speculate that the cognitive pull of the original answer loses its power and allows more mental flexibility over time." http://www.psychologicalscience.org/onlyhuman/2008/06/polling-crowd-within.cfm@vokain You have probably seen this already, but in case not: enjoy! BBC - The Code - The Wisdom of the Crowd https://www.youtube.com/watch?v=iOucwX7Z1HUPS. Interesting how every single block size limit poll, since the first one in Feb 2013, has had majority support for the increase. |
|
|
|
Gavin is 100% right and showing leadership to break the analysis paralysis.sourceforgeWhat do other people think?
If we can't come to an agreement soon, then I'll ask for help
reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
big increase now that grows over time so we may never have to go through
all this rancor and debate again.
I'll then ask for help lobbying the merchant services and exchanges and
hosted wallet companies and other bitcoind-using-infrastructure companies
(and anybody who agrees with me that we need bigger blocks sooner rather
than later) to run Bitcoin-Xt instead of Bitcoin Core, and state that they
are running it. We'll be able to see uptake on the network by monitoring
client versions.
Perhaps by the time that happens there will be consensus bigger blocks are
needed sooner rather than later; if so, great! The early deployment will
just serve as early testing, and all of the software already deployed will
ready for bigger blocks.
But if there is still no consensus among developers but the "bigger blocks
now" movement is successful, I'll ask for help getting big miners to do the
same, and use the soft-fork block version voting mechanism to (hopefully)
get a majority and then a super-majority willing to produce bigger blocks.
The purpose of that process is to prove to any doubters that they'd better
start supporting bigger blocks or they'll be left behind, and to give them
a chance to upgrade before that happens.
Because if we can't come to consensus here, the ultimate authority for
determining consensus is what code the majority of merchants and exchanges
and miners are running.
--
--
Gavin Andresen
If BitcoinXT needs to blaze the trail then two further considerations are: 1) Make the 20MB expire after 5 years so that the limit becomes the default of 32MB. 2) After the desired mining majority for the fork is achieved, allow a short grace period, e.g. 10 days, before >1MB blocks are allowed, which gives time for laggard full nodes to upgrade.
|
|
|
|
But now (or Soon) is not the right time. We need studies, simulations, and (most importantly) actual empirical feedback from persistent full blocks to best determine how and when to proceed with altering the 1mb parameter.
Wrong. We already know it will be a clusterfuck.I venture my opinion from 30 years experience in IT, when it appears that you have zilch and should just speak to what you know about (Monero? Hashfast?) good re-read. and i'm pretty sure he changed that write-up. initially, he claimed the entire UTXO was held in RAM but down in the Reddit comments for the thread several ppl pointed out that it was held on disk with a 100MB high speed cache. so, bottom line, it doesn't necessarily appear that this is a problem except for maybe miners. given that tx growth won't immediately go to 20MB/block, i think it's safe to say this space problem should be worked out in time. I really think there is a fast and simple constraint on UTXO bloat which can be done: Allowing the existing free transaction space to be used for tx which reduce UTXOs (i.e. negative delta) instead of being based upon the number of days destroyed, which was to encourage old coins being spent, something less important. |
|
|
|
|
Show Posts
