Correct me if I'm wrong: when we talk about consensus, we mean consensus among the miners. And if the top mining pools agreed on another blocksize limit fork, the rest would probably follow. Correct?
Yes this is true; however it also requires at least the tacit approval of the individual miners who control the hash power. Then there is control over the nodes, code developers etc. My take is that this will require broad community consensus but in the end it will be the mining pools that have to implement it. |
|
|
|
Jeff makes an argument that the block size should be a limited resource (akin to the 21 million limit) and that this will incentivize people to build layers on top of bitcoin. Perhaps experience will teach what was not obvious in the early days, which is that running into the transaction limit causes damage to bitcoin's utility that outweighs any benefit of encouraging "layers on top of bitcoin." His argument may or may not be correct, but it doesn't sound to me (a non programmer) to be some idiotic idea that is completely without merit. So here's my question: if the arguments put forth by Jeff in the above post do not stand the test of time, will the proponents of this idea will be too stupid to see it? Because if they CAN see it (and why wouldn't they?), then the problem will most likely be solved. Sidenote: He also does not like feedback based methods, saying they can be easily gamed. It seems to me it would be easy to design a feedback based method that is prohibitively expensive to game. Just my initial reaction. Short sighted decisions of this nature happen all the time. The 640KB limit decision by Microsoft led to an an entire generation of computer users to have to deal with the consequences for close to 20 years (until the 3.x and 9.x versions of Microsoft Windows were retired in the mid 2000's). I must say that I got a few grey hairs dealing with "extended" and "expanded" memory in MS-DOS as a result. ...
ArticMine - what do you think about the spin off method described in Peter R's post?
It is an interesting proposal that can work if there is a very clear vote and hence valuation one way or the other. Where it can get real messy and problematic is if there is close to an even split or even significant vote for the minority chain. Then the uncertainty created can cause a significant overall loss of trust. The reality is that a hard fork only works with strong consensus and my thought is that Peter R's proposal will expose that reality. Having said this it may in the end have to come down to a spin off method solution as a last resort. It sounds like one of those drastic measures that would probably never actually have to be implemented. Having said that, one of the biggest if not the number one chief threat to bitcoin as a long term store of value is that it could get replaced by an alt. If that ever looked like it might actually happen, I would imagine it would not be difficult to reach a consensus that the above plan would be preferable to watching the value of bitcoin plummet. So it is comforting, at least, to know something like that MIGHT be implement-able. So, my thought process tells me that perhaps the chief threat to bitcoin is not replacement by an alt, but rather, fragmentation of community consensus. (Which could be the resestult of threat from an alt, or could come from who knows what.) Methods of managing community consensus is a problem that seems very interesting, although I have not seen it much discussed. One of the most effective ways to get a community to pull together is a serious threat. This is just human nature and it is why there was strong consensus for the 2013 fork. So a fast rising alt may well generate the necessary consensus. Edit: Managing and more importantly building community consensus is a very interesting topic on its own right. I must say this is not my best area of expertise as I am more the "geek" left brain type of person rather than the "people oriented" right brain type of person. There are others who are very good at this type of work and I respect them for their skills. |
|
|
|
...
ArticMine - what do you think about the spin off method described in Peter R's post?
It is an interesting proposal that can work if there is a very clear vote and hence valuation one way or the other. Where it can get real messy and problematic is if there is close to an even split or even significant vote for the minority chain. Then the uncertainty created can cause a significant overall loss of trust. The reality is that a hard fork only works with strong consensus and my thought is that Peter R's proposal will expose that reality. Having said this it may in the end have to come down to a spin off method solution as a last resort. Edit: The best solution is a hard fork with strong community consensus. |
|
|
|
... block size limit is simply too small for Bitcoin to maintain reasonable growth, and it will hit a bottleneck just trying to process normal business.
If it's about 260,000 transactions per day, it is indeed too small. If it can be increased, I favor increasing. And also setting in stone the increasing schedule so that no further vote or community decision is needed ever concerning this matter. Yes 260,000 transactions per day, 3 transactions per second, is the practical limit. The maximum theoretical limit assuming all transactions were ideally optimized is closer to 600,000 thousand per day or 7 transactions per second. Is a technical solution that meets the above quoted requirements possible? Yes there are many including getting rid of the limit altogether as Gavin has proposed. Furthermore a solution very close to above that meets the above quoted requirements is part of the implementation of the CryptoNote alt-coins including its leader XMR (Monero); however virtually all other alt-coins suffer from this very same limitation. The problem is social. There is a significant and influential point of view within the Bitcoin community that is opposed to or at best very resistant to making this change. Furthermore this debate is very old. Here is a post from 2010 that addresses this issue and is in many respects highly prophetic. Hello all, Recently I just posted on another thread to express my concern about this subject, but I thought it might deserve a topic of its own. This block size rule is something really "dangerous" to the protocol. Rules like that are almost impossible to change once there are many clients implementing the protocol. Take SMTP as an example. Several improvements could be done to it, but how? It's impractical to synchronize the change. And, well, if we ever want to scale, such limit will have to grow. I really think we should address this problem while there is only one client used by everyone, and changes in the protocol are still feasible, because in the future we may not be able to. As far as I understand, one of the purposes of this block size limit was to avoid flooding. Another purpose as well, as mentioned here, is to keep the transaction fees not "too small" in order to create an incentive for block generation once the coin production isn't that interesting anymore. (if only a limited number of transactions can enter a block, those with the smallest fees won't be quickly processed...) So, if we really need a block size limit, and if we also need it to scale, why not making such limit so that it adjusts itself to the transaction rate, as the difficulty of generation adjust itself to the generation rate? Some of the smart guys in this forum could come up with an adjustment formula, taking in consideration the total size of all transactions in the latest X blocks, and calculating which should be the block size limit for the next X blocks. Just like the difficulty factor.This way we avoid this "dangerous" constant in the protocol. One of the things the smart guys would have to decide is how rigorous will the adjustment be. Should the adjustment be done in order to always leave enough room to all transactions in the next block, or should blocks be "tight" enough to make sure that some transactions will have to wait, thus pushing up the transaction fees? Okay, I do realize that it would allow flooders to slowly increase the limit, but, what for? As long as generators aren't accepting 0-fee transactions, a flooder would have to pay to perform his attack. So, what do you think? I take the point of view that the 1 MB blocksize limit in Bitcoin makes no more sense than limiting the RAM in a personal computer to 640K http://quoteinvestigator.com/2011/09/08/640k-enough/ for the very same reason: Moore's Law. As a baby boomer, I happen to remember that debate well and had to deal with its aftermath. The time for endless arguments and debates on this issue is over, since we are fast approaching this limit. The time for action is now. This brings me to my next point since this is after all a thread in Speculation: How can Bitcoin investors profit from this and / or protect their XBT investment? There are two sides to consider here: First (XBT bull) if one takes the 1 MB blocksize limit out of the equation the fundamentals for Bitcoin are otherwise very bullish. Furthermore the most likely scenario, although not certain is that the Bitcoin community will finally get its act together and deal with the 1MB blocksize limit. This would make moving out of XBT into fiat or precious metals a very risky move for a long time XBT investor. The second case (XBT bear) is that the Bitcoin community does not get its act together, we get close to the limit and fees start to rise as a result. It is here where a coin not encumbered by this limit will become highly desirable, and XMR (Monero) is the leading candidate. Now and this is critically important XMR must stand on its own merits with good reasons to appreciate in terms of XBT for reasons completely unrelated to the to the 1MB blocksize limit issue. It is for these reasons that after reviewing this thread https://bitcointalk.org/index.php?topic=624223.0 and after performing my own independent due diligence on XMR that I have moved approximately 15%, by market value, of my XBT holdings into XMR. This is to both protect my XBT position and potentially profit not only from XMR making bronze or silver on its own merits, but from also the small chance of it actually making gold as a result of the turmoil associated with Bitcoin reaching the 1MB blocksize limit. |
|
|
|
Suppose Monero (or a different alt) were to gain enough traction for it to appear inevitable that it would eventually topple bitcoin. How feasible would it be to fork bitcoin to adopt some or all features of Monero? iow, a merger of the first mover advantage of bitcoin with the technical advantages of Monero. I suppose this question has two parts: 1) What would be the technical feasibility of doing this? and 2) Would the community go along?
The chances of such a merger are zero. From a technical perspective the coins are very different, and the economic interests strongly align against this. More importantly such a merger would violate the most basic economic fundamentals of both coins. This means that such a merger would break all trust in the coins and yes could make them both worthless. Both communities would reject such a merger and for very good reasons. What is more likely to happen here is that Bitcoin would have to fork to deal with the 1 MB Limit. Both coins would live side by side, compete and hopefully learn from each other. First mover is not everything. A very good example is the credit card industry. The first movers were Diner's Club and then American Express. Then came the later entrants including Visa and MasterCard. The first movers are still around but with vastly reduced market share. The challenge for the Bitcoin is to deal with the 1 MB blocksize limit before the above happens and not become the American Express or even Diner's Club of crypto-currency. Edit: Bitcoin might even fork in the middle of a boom, like it did the last time. After all it is way easier to get consensus when everyone is getting wealthier. |
|
|
|
The block size limit in the protocol will not become an issue until transaction fees become a more substantial portion of mining revenue. As it stands at the moment, there is a market-based soft block size limit that results due to the economic incentives that miners face due to block propagation races. Since transaction fees are eclipsed by the block reward, miners are incentivized to publish smaller blocks with fewer transactions.
Yes this is a problem, but it can be solved by the market by increasing fees to cover the propagation risk to the miners. Furthermore it also creates an incentive to run full nodes as users compete to get their transactions confirmed. This has the overall effect of reducing the latency of the network, thereby mitigating the propagation risk to the miners. In short there are built in economic incentives already to address this problem. The problem with the 1 MB limit is that it is arbitrary and not related the costs incurred by the miners or the rest of the network, so no amount of fee increases or reduction of risk by adding full nodes will address the fact that a certain number of transactions will not get any confirmations. |
|
|
|
Pointing to the smartphone, Kurzweil says, devices like the iPhone are 100,000 times smaller than the computer that he used as an MIT student. "It is also several thousand times more powerful," he says. "It is a million times cheaper. That is a several billion-fold increase in price performance." Technology is being reduced at a rate of "100,000 in 3-D volume per decade," says Kurzweil. "That is another predictable exponential trajectory, so computers of this capability will be blood-cell size in 2030.
The iPhone in the above example is not more powerful because it is crippled with DRM, a rooted Android phone would however be several thousand times more powerful. |
|
|
|
is there a significant consequence to 2x, 4x, 10x -ing the block size as a temp fix?
Increasing the hard-coded blocksize limit as a temporary fix is trivial from the software perspective, but it is a hard fork. In pseudo code: if (blocknumber > 350,000) blocksize_limit = 4 MB else blocksize_limit = 1 MB I expect that we will implement a temporary fix like this ^^ when we get closer to the limit. There will also be a strong commitment at this point that the next change will implement a floating blocksize limit. The algorithm used to calculate this limit must be chosen very carefully and shouldn't be rushed. This may well turn out to be the case, although I am not so sure that the next change, after a temporary fix, would implement a floating blocksize limit. This is because of human nature. We must also keep in mind that the 256K to 1 MB blocksize limit change in 2013 in the end became a hard fork, so in reality this coming change is the "next" change. |
|
|
|
... Many people cite 7 transactions per second (tps) as the limit for 1 MB blocks, but 3 tps is probably more accurate. Here's a chart that uses extrapolation to estimate the dates when the bitcoin network would reach the blocksize limit (3 tps or 7 tps) if historical growth rates hold. If we witness another "growth spurt," I expect we will approach 3 tps on several days and the discussions with regards to increasing the blocksize will become more focussed. ... Yes I agree. This combined with the threat of an alt-coin, not encumbered by a static blocksize limit, rising up the charts should focus the debate and could lead to a consensus in the Bitcoin community. I am of the belief that Bitcoin will weather this and make the necessary hard fork but it may well take reaching the limit and a good "kick in the pants" from an alt-coin to achieve the necessary consensus. As for which alt-coin I have to agree with aminorex that XMR (Monero) as the leading CryptoNote coin is a good candidate to deliver the necessary "kick in the pants". |
|
|
|
These people are dangerous because of the influence they wield over Bitcoin that can destroy it as a free and open system. Recently Gavin made a post calling to raise the blocksize limit which is connected to this vision of Bitcoin as a system for payments. There is an agenda behind that kind of talk because raising the blocksize limit morphs Bitcoin as a better payment's system but centralizes more power with miners - which is already at dangerous levels in Bitcoin. We can either have a decentralized, free and uncensored Bitcoin, or a centralized Bitcoin good for payments (same as the banks). He is completely wrong on the raising the blocksize limit issue. The problem with his analysis is that there are enough people "living in squats" around the world to bring the Bitcoin network to its knees should even a very small fraction of them use Bitcoin with the current 1MB blocksize limit. Furthermore that is without any of them using Dark Wallet. As a programmer he should simply know better. The fear of "bloat" leading to centralization and corporate control is in reality FUD because of Moore's law. Ironically keeping the 1 MB blocksize will lead to a situation where only the very wealthy will be able to use Bitcoin cost effectively because of sky-rocketing network fees. Edit: I have lost a lot of respect for Amir because of his position on the 1 MB blocksize limit. |
|
|
|
This may depend on how the question of the 1 MB max blocksize limit is handled. One thing is certain without an increase in this limit, and a hark fork is necessary for this, Bitcoin will be dethroned by a competitor. Once the limit is reached transaction fees will skyrocket as an ever growing number of transactions compete for the 1 MB space every 10 min. Fortunately Gavin Andresen understands the need for this. So do other Bitcoin developers. The real question in my mind is will they muster the necessary community consensus to make this hard fork happen?
In the absence of a hard fork, how soon do we expect to hit this limit? I have heard estimates in the range of one year. What I would recommend, however, is to spend some time at https://blockchain.info/ and take a look at what is actually happening in the Bitcoin network in real time and then form one's own opinion, rather than depend on what I or someone else may say. |
|
|
|
So this could be the end of the bitcoin bubbles, possibly. Will a competitor come and dethrone bitcoin? Or, are we just entering a new and much smaller growth period?
This may depend on how the question of the 1 MB max blocksize limit is handled. One thing is certain without an increase in this limit, and a hark fork is necessary for this, Bitcoin will be dethroned by a competitor. Once the limit is reached transaction fees will skyrocket as an ever growing number of transactions compete for the 1 MB space every 10 min. Fortunately Gavin Andresen understands the need for this. So do other Bitcoin developers. The real question in my mind is will they muster the necessary community consensus to make this hard fork happen? |
|
|
|
There, i said it.  This was a mere 13 days after my first BTC purchase at a price of 5.38 CAD. According to this advice I should have panicked and sold, instead I held.  |
|
|
|
|
I just completed an additional donation of 305.60 XMR for upgrade to 5th dan.
|
|
|
|
The trend is so blindingly obvious that it scarcely warrants mention: unskilled labor gets easier and easier ( hard/dangerous/dirty labor gets paid more), and the wages received buy a dramatically greater standard of living. When we add in technological innovations that further save on the labor that is otherwise necessary for basic living - such as washing dishes, bailing water from a well (to say nothing of digging and maintaining the well) - the argument becomes several times more striking. How does this apply to real estate? In the US a lot of people living in crack addled trailer parks who have iPhones and Netflix, but they still have drug addicts for neighbors. We need to broaden what is included in our "quality of life" stats to capture this; it's presently invisible. I would argue that they are living in in crack addled trailer parks because they have iPhones and Netflix. |
|
|
|
|
They changed their domain DNS servers and this can take up to 48 hours to propagate across the Internet. I run my own DNS and had to clear the DNS cache and then it worked. Just give it some time. This morning one hotspot in town resolved it correctly another did not.
Edit: This should not happen with a domain transfer unless one makes the mistake of using the same company to host the DNS and register the domain.
|
|
|
|
Where are you getting the info on the Whales? Is this reflected somewhere in the blockchain? Then I have missed it somewhere for sure.
Please provide evidence of this whale dump. Thanks.
The blockchain doesn't know anything about bitcoin's 'price'. You can see these things when you see the trades on bitcoin exchanges. If they coincide with some news being released, it's pretty obvious what caused a rise or fall of the price. It's might not be obvious, but we have proof that someone dumped a ton of btc.  1. Around 4k-5k BTC dumped, pushes price to $591.49. 2. Around 2k-3k BTC dumped, pushes price to $575.80. 3. Arond 2k-2.5k BTC dumped, pushed price to $568.05. There were more dumps on various exchanges, but i'm too lazy to look at that. Yeah i've been following that too. BTC is being manipulated downwards at regular weekly intervals, often going for the quiet gap between US going to bed and China waking up when market is least liquid. Probably someone playing contracts for difference or other bitcoin derivative. An unregulated market is bound to be subject to this kind of manipulation, and what a great way to launder stolen bitcoins by dumping them on market to depress price, whilst simultaneously taking profit out of put type derivatives!! There is also an argument that they are trying to trigger collapse by invoking margin calls. Either way, best way to protect yourself against these crooks is don't overleverage, and don't sell no matter how low it drops! My guess is Ethereum. They are dumping the BTC sold for ether. |
|
|
|
|
Show Posts
