Bitcoin is strong. But if bitcoin is only strong because of how many dollars it cost to buy a bitcoin then the focus is off.
It is a strong bad sign of the strongest of bitcoin if the price return in that levels. It is already to low as it is. And predictions which "send" bitcoin at this kind of prices (lower than actual) demonstrate and called pessimism. You have not indicators to do factual and right predictions. Why predict the lower and not the higher price? I make predictions because I can. Doesn't make my predictions true. Time will tell. And no let's agree to disagree that my prediction is not based on pessimism. It is based on my own personal OPINION. It's your right to give opinions. But don't call those predictions. Prediction is another thing. Is based in analyse of several facts connected with the phenomenon for which will do that prediction. Giving on opinion is one thing and is called giving thoughts or opinion. Or simple discussing. Giving an prediction is a totally another thing.  He is likely right though. Look at the hash rate following the $32 bubble. It wasn't until the least efficient miners were flushed out that we bottomed at $2. There is also the sentiment of greed that says Bitcoin isn't useful beyond investment/speculation. Smoothie mentioned both of these, but you were too focused on his use of the word prediction to see the analyses he is offering. Now can we discuss these points, or do you just want to argue semantics some more? |
|
|
|
I don't know where to post it, so will stick it here. first-i don't think that btc will correlate, except on high down days. However i found an interesting blurb on the market conditions; CNBC Pisani says that conditions of yesterday/today should exist (theoretically) only one time in 140000 tries or once in 383 years, yet then he says that we had one in 80ies (he probably meant 1987), then in 2011 and now in 2015. http://finance.yahoo.com/video/pisanis-market-open-p-500-134300969.htmlgo to ~1:55min If you still follow theories that assume stock prices are normally distributed than you need to read Mandelbrot. no, i was just quoting him contradicting himself in the same sentence. What Mandelbrot's book would be relevant-the (mis)behavior of markets? I think you know |
|
|
|
I don't know where to post it, so will stick it here. first-i don't think that btc will correlate, except on high down days. However i found an interesting blurb on the market conditions; CNBC Pisani says that conditions of yesterday/today should exist (theoretically) only one time in 140000 tries or once in 383 years, yet then he says that we had one in 80ies (he probably meant 1987), then in 2011 and now in 2015. http://finance.yahoo.com/video/pisanis-market-open-p-500-134300969.htmlgo to ~1:55min If you still follow theories that assume stock prices are normally distributed than you need to read Mandelbrot. |
|
|
|
I thought this debate made it clear that no one w/ half a brain really cares about spending Bitcoin at online stores. If Bitpay decides for some reason to support Bitcoin XT then by all means go ahead. They'll be left with no users in no time. The economic majority (people who actually hold coins) couldn't care less what Bitpay decides to do, they're not trying to spend their coins anyway.
You obviously don't seem to understand the peculiarities of a fork here. For anyone holding Bitcoins before the fork, there'd be a huge incentive to spend their coins on the chain they don't feel like supporting. After all, they would still hold all coins in their respective preferred chain, while at the same time, they could go shopping "for free" with their assumed worthless Altcoins. Basically, the more convinced you are that you're on the "right" side of the chain, the stronger your motivation to push the "wrong" side. You obviously don't seem to understand the reality of what we have to deal with here. The millions of coins held on cold storage and paper wallets will NEVER risk the security of their holdings by starting to shop their coins around in the event of a fork. That's just outrageous to say. What it will do if two chains coexist for any significant length of time is create a premium on post fork coins. Adding post fork coins to the transaction will taint it so that it can be spent on one chain only. After that, you can freely spend on each fork separately. Basically we break fungibility and confuse the shit out of anyone who doesn't understand the technical details. |
|
|
|
There is no way anything big will happen before the XT mess isn't sorted out. Everyone's confidence is just too shaky at the moment. The community seems very divided.
We need consensus and we need it fast. The longer this uncertainty lasts about the fork, the more damage will be done to Bitcoin.
I still believe strongly into this technology though!
It's not the divided community that worries me, it is the rush to resolve it. Lets take our time and let a majority develop naturally. Personally, I'd love to see a few other candidate clients arrive so there is more choice than fork or no fork. Knowing the support for each proposal would make it easier to compromise. how do you come to the conclusion, that it is rushed. the problem is known for years! I just keep seeing statements like the above. You can't speed up consensus because trying to push one option down everyone's throat will only create more division. Also, the problem is old, but the detailed proposals to address it are all only a few months old. If we don't figure out which is the best path we will be fighting about it again soon. |
|
|
|
There is no way anything big will happen before the XT mess isn't sorted out. Everyone's confidence is just too shaky at the moment. The community seems very divided.
We need consensus and we need it fast. The longer this uncertainty lasts about the fork, the more damage will be done to Bitcoin.
I still believe strongly into this technology though!
It's not the divided community that worries me, it is the rush to resolve it. Lets take our time and let a majority develop naturally. Personally, I'd love to see a few other candidate clients arrive so there is more choice than fork or no fork. Knowing the support for each proposal would make it easier to compromise. |
|
|
|
I think XT won't be happening given the market uncertainty it caused. Currently zero percent of the miner vote. http://xtnodes.com/Grab those those coins boys! So if i start mining on XT, will the blocks be easier to find? No. Where can i see XT hash?? Only one of the last thousand blocks has advertised XT compatibility. |
|
|
|
Satoshis recent comments were right and I agree that bitcoin wasnt designed to be at the whim of central authority which is what it is trying to destroy. So with that im with bitcoin original thick or thin.
Central authority like the bitcoin core devs? |
|
|
|
…
At this point I'd say just find a way to put the forks on the market and let's arbitrage it out. I will submit if a fork cannot gain the market cap advantage, and I suspect the small-blockers will likewise if Core loses it. Money talks.
I had a strange idea recently: what if we don't even bother with BIP100, BIP101, etc., or trying to come to "consensus" in some formal way. What if, instead, we just make it very easy for node operators to adjust their block size limit. Imagine a drop down menu where you can select "1 MB, 2 MB, 4 MB, 8 MB, … ." What would happen? Personally, I'd just select some big block size limit, like 32 MB. This way, I'd be guaranteed to follow the longest proof of work chain, regardless of what the effective block size limit becomes. I'd expect many people to do the same thing. Eventually, it becomes obvious that the economic majority is supporting a larger limit, and a brave miner publishes a block that is 1.1 MB is size. We all witness that indeed that block got included into the longest proof of work chain, and then suddenly all miners are confident producing 1.1 MB blocks. Thus, the effective block size limit slowly creeps upwards, as this process is repeated over and over as demand for block space grows. TL/DR: maybe we don't need a strict definition for the max block size limit. You know that you can do this now, right? And always could. The code is open source, you can (of course) just change it and compile. We were discussing writing a BIP for the idea where the block size limit is removed from the consensus layer, and each client manually selects the max block size that they are willing to accept. If this idea truly makes sense and can gain some mindshare, then perhaps to go along with a BIP, we could fork Bitcoin Core to create a "reference implementation" for the new idea? Like Awemany said, it wouldn't require much coding. I'd probably run it too, because by setting my personal block size limit high, I would always get dragged along with the longest proof-of-work chain. Who knows, it could actually catch on more widely too… We'd also need a name for this implementation. You may also need to add a mechanism to alert the user when the network does fork away from their limit. |
|
|
|
What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on. IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.
I don't think it would be a problem. Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size. Worst case, a large block gets orphaned and nobody tries again for a while. But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit). IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.
This doesn't put the power directly in the miners' hands. It keeps the power where it already is: in everybody's hands! It just makes it much easier for people to exercise the power they already possess. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.
I disagree. For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better. I expect many people would do the same thing. Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned. Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems. Okay... I'm going to have to agree with that. But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before. By publishing a block of size X + 1 byte, the attacker effectively splits the network in half. If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network. Even if the attacker only has small hashpower, it will still cause a hash war between the two forks. I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for. awemany might have answered your question here: https://www.reddit.com/r/Bitcoin/comments/3eaxyk/idea_on_bitcoin_mailing_list_blocksize_freely/cu1tzuhIOW, as a full node operator wanting to stay on the longest chain at all times, set your maximum block size high enough so as not to be exceeded. Ensuring you are part of the supermajority by looking at votes should give you a safe least upper bound. Ensuring you have the largest size possible is a bit excessive and will raise your costs too much compared to someone who only upgrades when they are coming close to falling out of the supermajority (however they define that). If miners don't take the supermajority into account, it could be a risk to the network. Including a risk to the nodes with the highest limits as they suddenly become part of a chain with half as much hash power. |
|
|
|
What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on. IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.
I don't think it would be a problem. Like Erdogan said, the miners will use the "tip-toe" method of increasing the block size. Worst case, a large block gets orphaned and nobody tries again for a while. But if the larger block doesn't get orphaned, then the network will assume that that size is now supported (thereby setting a new effective upper limit). IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely.
This doesn't put the power directly in the miners' hands. It keeps the power where it already is: in everybody's hands! It just makes it much easier for people to exercise the power they already possess. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB.
I disagree. For example, I would not set my node's limit to anything greater than 32 MB until I understood the 33.5 MB message size limitation better. I expect many people would do the same thing. Rational miners won't dare to randomly publish a 100 MB block, because they'd be worried that it would be orphaned. Furthermore, since miners would likely use the "tip-toe" method, the effective block size limit will grow only in very small increments, helping to reveal any potential limitations before they become problems. Okay... I'm going to have to agree with that. But what if, when everyone is voting, an attacker sees that 50% is advertising < X MB and 50% is advertising > X MB with X obviously been larger than any block seen before. By publishing a block of size X + 1 byte, the attacker effectively splits the network in half. If he was previously 25+% of the network, he is now 50% of the two new forks and can either cause further bifurcation or anything else you can do with half the network. Even if the attacker only has small hashpower, it will still cause a hash war between the two forks. I suppose this could be mitigated if most nodes refuse to build on a block that is larger than what a supermajority votes for. |
|
|
|
[...]
So…is this a good idea? If there are no obvious "gotchas" then perhaps we should write up a BIP.
I'd be willing to help! But I'd also suggest to just make it about the configurable setting and leave the rest to the user. I think signalling about blocksize has to happen out-of-band for the time being. Because it is potentially a lot of code complexity. And simple IMO beats complex here. Just make it mandatory to start bitcoind with -maxblocksizelimit (or similar) and have an edit box for bitcoin-qt that has to be filled with a value. The amount of code change should be about the same as BIP101. Start requesting this value at some switchover date in the future - maybe at the beginning of Gavin's increase schedule. Reason for this: Time for user education on building a function Bitcoin network. What do you think? I think that all makes perfect sense, and I agree that simple is better! Perhaps the BIP could only advocate for doing what you said to start, and then there could be a follow-up BIP to do the signalling in the block headers and to add the p2p "block size limit request" messages. The nice thing is that the signalling stuff in the follow-up BIP would have nothing to do with the consensus layer, so it would be much easier to build support for it. I'd be willing to contribute to this too. Realistically, I couldn't do any serious work on this until mid-September, however. Timing wise, it would be great to have a polished proposal published for the second Scalability Workshop in Hong Kong probably in November or December: https://scalingbitcoin.org/I'm actually quite excited about this idea. It has a sort of inevitable feel to it. What about lying? If enough miners claim to support larger blocks but actually don't, then part of the network will waste time producing blocks that won't be built on. IMO, if we want to put the power directly in miners hands it would be better to raise the limit entirely. However, to do so we would need to test the crap out of everything to be reasonably sure that there aren't bugs that are only uncovered by larger blocks like what happened when the soft limit was raised to 1MB. |
|
|
|
Those days of fearing a hard fork will kill BTC are long gone. At the beginning it was true, not the software and project is way too widespread. Too big too fail situation.
 Technically, at least one chain will continue. Socially, the fight over which chain is in fact Bitcoin may well destroy confidence in both. Hard forks were easier when there were less people to upset by changing the rules. |
|
|
|
So China decides to float the yuan when the dollar is high, and controls the descent by selling USD. That seems to align well with your thesis on the market favoring UST over USD as safe haven. |
|
|
|
|
You can lose it all if you want to, just leverage to the moon and walk away.
|
|
|
|
There really should be some type of fucking first grade arithmetic test before anyone's allowed to post here.
Got a big fat news flash for everyone - a $10,000 bitcoin is still fuck all in terms of the wider world.
The dollar does not need to collapse. A loaf of bread does not need to be worth $1000. Nothing needs to change other than the desire by a greater number of people to use and hold BTC.
Why are so many on here too dim to harness basic conceptualisation?
$210B would be about 5x paypal's market cap, but only 1/30th of the gold market. |
|
|
|
You guys/girls hold gold/silver as well as BTC?
not me. only a few ounces of silver and a couple grams of gold |
|
|
|
The nature of bitcoin is that if mining becomes too centralized and the miners decide on an unpopular fork, the users can just ignore them (well, we will need some miners, and in the worst case we might have to manually drop the difficulty to keep things running with less hashpower).
As long as the user base disagrees with the change, they don't have to follow along. More users is more decentralized. The miners only have as much power as we grant them, and we can take it away if necessary.
The fact that you and a couple others try to smash this idea inside everyone's head does not make it more true. If you mean more nodes then granted but more users != more nodes. This is the first time I've said it... how is that "smashing this idea inside everyone's head"? When did miners decide on a fork anyway?
The fear of centralization is that miners will decide on a fork that goes against the principles of bitcoin. Isn't that what your afraid of? I don't see how your comments address any of mine and others' concerns. It seems you're basically saying "if Bitcoin becomes too centralized then we'll just switch to something else"... That's not a very productive argument...
A plurarlity of miners can decide on a fork, but if the users (individual and business) don't agree with the change, they can continue with the old rules. This leaves the miners on an unused fork and they will quickly figure out that they are the ones who have switched to something else. I'm saying "if bitcoin becomes too centralized when it comes to mining, the miners still have to answer to the user base." Getting every bitcoin accepting business (or at the very least the exchanges and the payment processors) to accept your fork is a prerequisite of a successful fork. These entities add to the decentralization of consensus. Excluding them is illogical. |
|
|
|
How does scaling bitcoin separate the store of value bitcoin holds from it's function as a payment network? The two are inseparable and go hand in hand.
How can bitcoin retain it's function as a base store of value when it loses its active userbase to other block chains?
Ps. Don't be rude
Disclaimer : raising the block size is not about scaling Bitcoin. The idea is not to separate the two. The logic is you need a strong monetary base on top of which you can build any kind of desired payment network. How can bitcoin retain it's function as a base store of value when it loses its decentralization? Btw, can we stop lieing to people with this "active" userbase non-sense. We all know you and everyone here sit on our Bitcoin stash like dragons on their hoard. The use of Bitcoin as a "payment network" at this point is laughably marginal. And that's certainly not because of the block size limit. The nature of bitcoin is that if mining becomes too centralized and the miners decide on an unpopular fork, the users can just ignore them (well, we will need some miners, and in the worst case we might have to manually drop the difficulty to keep things running with less hashpower). As long as the user base disagrees with the change, they don't have to follow along. More users is more decentralized. The miners only have as much power as we grant them, and we can take it away if necessary. |
|
|
|
Unfortunately, eliminating the limit would open up the existing code bases to several of DOS attacks. If we really want to go that way, we need to make sure that all the software can handle blocks that won't fit in memory + swap. There are also likely other technical issues that would need to be addressed, and the only way to tease them all out is a ton of code reading and testing. When software is written, constants are treated as assumptions, and when that assumption changes there is a risk of the previous logic breaking down.
The tcp buffer limit is 33554432 bytes (33.5MB) which means that Bitcoin messages cannot exceed this or p2p transmission breaks at the receiver with a read error. If the 1MB limit did not exist then this is the maximum block size that can be sent, and it is no good mining a block too large to send anywhere. Blocks not fitting in memory or swap is not the immediate restriction. Jeff Garzik commented that increasing this limit means a major reworking of Bitcoin's p2p protocol. If anyone thinks that the 1MB hardfork is scary (which is a tiny software change) resolving the 33.5MB is a much bigger issue. It may never be done, because one or more of alternative options: LN having enough block space to allow a *lot* of payment channels to function and the VISA-scale volumes do-able long-term. Tier Nolan / Adam Back extension blocks are one solution when the 33.5MB limit is being approached, A combination of IBLT (if it is efficient at this level) and block segmentation logic could allow disk blocks > 33.5MB In the meantime (and I'm guilty in the past too) bitcointalk is full of comments about 100MB, ZOMG 1GB blocks, etc etc and "dangerous" unlimited block sizes, when the reality is that no block can exist > 33.5 MB even if the 1MB limit disappeared. When Satoshi put in the 1MB it was 1000x larger than the average block size. The 33.5 is about 80x the average block size seen in 2015. This is large, but not stupidly large, and continuing improvements in computing tech and bandwidth should make this size manageable by the mid-2020s because 5MB blocks should be manageable today. A road-map which permits 33.5MB blocks by about 2025 still allows Bitcoin to be a major global currency. BIPs 100 and 101 at least leave the opportunity open to make this possible. There is no 33.5MB limit, that is at most a minor programming problem. Just read the rfc for the tcp protocol, there is no limit. Daily, people exchange larger blocks of data between computers. I sense a block minimalist creating a new non-limit to choke bitcoin for the benefit of an altcoin. I don't see any conspiracy, just confusion. The message limit is only a problem for transactions or block headers larger than that size, as these two things can be requested separately. You generally only need to get the header since you should have seen most of the transactions already. |
|
|
|
|
Show Posts
