Huge numbers of Bitcoin companies will be in locations where high-speed fiber is present. For people with poor internet service there should eventually be an alternative: satellite broadcasting of transactions and blocks, as per Jeff Garzik's bitsats proposal. So it's not acceptable for the poor people to rely on 3rd parties... unless it's to trust them with the most important part: full nodes. The satellite thing is a total joke, and does nothing to enhance security. You're describing a world in which any derp with a satoshi gets to spam the network with his coffee purchase, and any government can take over the network if they control the high bandwidth regions. This is backwards and misses the point of bitcoin. "Hash cash" wasn't the revolution; distributed consensus was. Bitcoin is not valuable because "everybody has access." It's valuable because nobody can counterfeit. Satellites, like ordinary nodes, are not individually trusted. It is the whole network which is to be trusted. There is a distinction between "valid/worthwhile" and "junk/spam" transactions: If >50% of the full nodes accept a transaction into their mempools, whether for a coffee or a car, then it is valid/worthwhile. If >50% want to reject a particular transaction then it is junk/spam. Fortunately IBLT will help make this a clearer process by encouraging strong consensus on unconfirmed tx. For the record, my position is that micro-tx should be handled off-chain. Paying for a coffee is not a micro-tx, IMHO. I've asked MP. While nobody can really know the future, turns out what we'll likely do is start an entirely new coin, this time guaranteed to never be hard-forked; not by a bunch of coder nobodies, but by MP himself. In practice that'll most likely work out to simply staying with the old version and replacing some code monkeys. This, mind you, not because we really care all that much if it's 1 Mb or 100 Gb, but because the precedent of hardforking "for change" is intolerable. We'll find ourselves in due time under a lot more pressure to fuck up Bitcoin than some vague "I can't manage to envision the future" sort of bs.
[my bold emphasis] The reality of MP's position is that he does not want Bitcoin changed, which is why he runs an old version of Bitcoin Core, and has drawn a red line at the 1MB fork. He doesn't really care if the block limit is 1MB or 100GB, it's the principle of changing Bitcoin without MP's permission, which is unacceptable.Anyone else who has an opinion on that can fill in the blank: "________________". |
|
|
|
Yes it's a hard fork and we need all the pools, exchanges and blockexplorers on board
Get two things done at once and kill the pre-mined airdrop addresses (as at a recent block height). |
|
|
|
The article itself has a 'conclusion'. The author first sets up a theoretical framework for valuation and then applies it to Bitcoin. My interpretation is that reasonable price expectations until 2014 are between $10k and $300k, assuming the network continuous to grow exponentially.
between $10k and $300k by 2024 maybe? |
|
|
|
Can you tell me where I can order that 100 MBPS your "law" promised to me two years ago ?
I live in a small town and my house has only a 4 km long copper line.
There is no reason to believe optic fiber will be delivered to me within 15 years.
The future is already here — it's just not very evenly distributed — William Gibson True. Some people have fiber available years before others, so the graph is very much an average with wide variation for individuals. Huge numbers of Bitcoin companies will be in locations where high-speed fiber is present. For people with poor internet service there should eventually be an alternative: satellite broadcasting of transactions and blocks, as per Jeff Garzik's bitsats proposal. Start listening from 42 mins (although it is all interesting, Jeff comes in at 24 min): https://decentralize.fm/shows/episode-21-jeff-garzik |
|
|
|
This change would bloat so hard and make Bitcoin inaccessible to a large portion of the world
That 1MB limit must be the world's most amazing piece of software. 3 years ago it kept the blocks at 0.1MB, two years ago at 0.2MB, a year ago at 0.3MB and today at 0.4MB I mean, how can one number be so f...l...e...x...i...b...l...e? Oh wait, its not really doing anything much, and neither will the 20MB. What is keeping the block size under control is the tx fee policy and the coin-dust setting. |
|
|
|
Question about economics: say we have a hard fork coming up and people expect 2 chains with trading as described earlier by Zangelbert. Will that generate buying pressure on BTC (vs. fiat) beforehand because everyone wants to participate in 'the doubling' of coins?
This is a storm in a teacup. The reality is that a properly implemented fork will have 80+% hashing power on the new version blocks before the first >1MB block is produced. (Hopefully there will be a grace period of, say, 10k blocks after the 80% is triggered, for laggard miners and non-mining nodes to upgrade). So the old fork will have less than 20% hashing power, quickly dropping to as little as 5%. Blocks on the old fork will take about 2 hours each to produce, with coinbase rewards spendable after 1 to 2 weeks. No company in the Bitcoin ecosystem will accept fresh reward coins from the old fork. There will be no "market" as the old fork will be unusable as it will take a year for difficulty to fall until old fork blocks take 10 mins each again. In the scenario where there is a monumental cock-up and no preparations are made until the average block size approaches 1MB, under stress conditions, I expect all the major companies in the Bitcoin ecosystem will quickly converge and agree a change, then two forks would persist for a while. Expect the price to plumb the recent lows if that happens. |
|
|
|
 Right now the same thing is happening w/ strict DER encoding of signatures (BIP 66).
If <75% of prior blocks are v3 then DER encoding is not enforced on v3 blocks.
If >75% of prior blocks are v3 then DER encoding is enforced on v3 blocks (but one can still use non-canonical encoding on v2 blocks).
If >95% of prior blocks are v3 then v2 blocks are rejected.
It is a very cool method for consensus upgrades. And, for general info, this is a graphical representation of the version 3 block roll-out in progress. |
|
|
|
POS? really?
Not sure what you mean by "POS", (the 4x and 10x is based upon blocks per 10 mins).
The number opposed is just 20%. The other 20% is like... whatever.
I was one of the people voting "agnostic". It wasn't "whatever", I wanted to consider a bunch of stuff and see them debated, all of which have now been posted here and/or other places linked here already. This thread (a million posts later) and the other sources have since convinced to be "pro fork". Can't change the vote though. Maybe OP could reset the poll to re-sample how opinions have evolved? Fair point. Perhaps hdbuck can amend the poll to let people change their vote... |
|
|
|
Just do this already.
The Bitcoin chain that only allows 2-5 million people really using it will quickly die as people migrate to the 20 mb one simply in order to actually USE Bitcoin.
To begin with those opposed to the change is only 40%, screw them. They'll change their minds in a week.
The number opposed is just 20%. The other 20% is like... whatever. Bitcoin can have the lion's share at the top of the Pareto distribution, but we should expect a long tail of other crypto with varying degrees of suitability for substitution. If people prefer to use coins based on a silly picture of a dog or constellations of prime numbers, they will. You need to accept that and move on.
The problem is that the 1MB limit is just so small that eventually Bitcoin would be way down in the long tail of the Pareto distribution, behind even Litecoin which has 4x the volume capacity, and the silly-dog-picture-coin which has 10x the volume capacity of Bitcoin. Is that what we want and expect of the No.1 cryptocurrency? In fact it can't remain No.1 the way it is. |
|
|
|
embedding the hash of UTXO in the block headers and retaining only the last few hundred blocks is being experimented with as a client option.
Good to know. screw that, i want direct access to a copy of the entire blockchain at all times.
No one will deny you that access on an open network should you wish it ... destruction of tx history has a myriad of benefits, and risks (that can be mitigated). Yes. The power of Bitcoin is enhanced by in-built flexibility. Many nodes will always have and always want the full blockchain, many will be happier with the UTXO set secured by hashes in the main-chain, and many users will be OK with SPV only. Just because alternative models are available, and can work concurrently with earlier implementations, does not mean everyone jumps ship to one model. |
|
|
|
Even with IBLT a receiving node can't request the missing txns because IBLT only helps them identify the txns in the block if they already have them. If they are missing one or more they will know that but they won't know which specific txns they are missing. IBLT can be considered a 'header + metadata' message*. Using the meta data and the same deterministic transaction sorting used by both nodes will allow the receiving node to determine the txns in the block if the receive node has a superset of the block txns in its memory pool*.
* In practice it is probably going to be more complex. Those not interested in the complexity can just abstract it as header + metadata but a node finding a new block can't definitely know which txns other nodes currently have in their memory pool. IBLT will probably be more like 'header + metadata + full low-propagation txns'. The mining node will include in the message the txns that are unlikely to be in the memory pool of the receiving node to avoid IBLT failing. Anything which is non-standard is unlikely to be in the memory pool of any node following standard rules. The mining node can't change that. If they relay the non-standard txn in advance of the block most nodes will simply drop it. Stale txns (very old unconfirmed txns) may also be dropped by nodes to save space in the memory pool. If the mining nodes is aware of unconfirmed double spends then it should expect that some portion of the network is unaware of the txn in its block so that would be another txn to include the full txns. In the future there may be other reasons why a txn isn't well propagated. It may become complicated if the memory pool becomes very large and different nodes retain different subsets of it to conserve resources. Still IBLT has the ability to significantly reduce the propagation delay even if only used for a subset of the block txns. It doesn't however allow a receiving node to know which txns it is missing and thus it can't request missing txns.
The full transactions for the block are all included in the IBLT but they are XOR'd together such that successfully decoding them becomes probabilistic. So, if there are 18 transactions overlaying each other, and 17 are known to the receiver, then 17 can be peeled off leaving the 1 unknown transaction available to use. However, if >1 in the same cell are unknown to the receiver then decode fails. Continuing the example, there could be 18 transactions overlaying each other and 18 different receivers each missing 1 different transaction from their mempools, yet they will all be able to successfully decode the missing transaction and continue building the block from the IBLT. Yes. If an IBLT is accepted by most nodes and being built upon, then a node which fails to read it will need to request the standard block to resync. |
|
|
|
According to your chart we should have reached 1000 by now!  But really, if you're right, we've got a long way to recover... According to the log regression's trend, 1182 is today's estimated value. You can see it here. So the price is 76% undervalued. i am thinking that the 1MB limit is increasingly becoming a dead-weight on the value. This roadblock to scalability is highly publicized now, and it is reasonable that large amounts of money is on the sidelines waiting to see whether Bitcoin can properly scale. The sooner v4 blocks are happening the better the environment will be for the value to return to trend. Are the debates on this done? There were half people that said yes and the other half said no. Is it decided for sure then? Core dev need to come to agreement on the details, so nothing is "decided", although Gavin has made a proposal which has reasonable support: 60% for, 20% against, 20% whateverSo, only 20% are firmly against changing the limit, which is the same percentage as the polls 2 years ago. |
|
|
|
According to your chart we should have reached 1000 by now! But really, if you're right, we've got a long way to recover... According to the log regression's trend, 1182 is today's estimated value. You can see it here. So the price is 76% undervalued. i am thinking that the 1MB limit is increasingly becoming a dead-weight on the value. This roadblock to scalability is highly publicized now, and it is reasonable that large amounts of money is on the sidelines waiting to see whether Bitcoin can properly scale. The sooner v4 blocks are happening the better the environment will be for the value to return to trend. |
|
|
|
Fortunately most people want it to keep it working how it is now. Umm... No?  Dude he is pro fork... Oh wait you don't read peoples posts you just skim through them quickly so you can post a witty reply. I'm sorry, he claimed one thing, I showed him another... what I showed him, is it it NOT true??? He means that Bitcoin should stay the way it is now. No full blocks. That can only be accomplished with a fork if the transactions keep going up. Correct. Increasing the limit lets Bitcoin function how it is now for its users. Leaving the limit unchanged will cause a lot of user problems, massive delays to confirmations, and higher fees. |
|
|
|
Gavin's GigaBloat proposal calls for 95% support, which is far less than what the poll here reports.
The poll reads that opinion is 80% in support or "relatively OK" with the change. Only 20% is firmly against. This is the same proportion as 2 years ago. So it looks like this ratio will never change. Has any project, organization or community ever functioned long term with 95% support for every major decision? No! What is most insidious about the 1MB limit is that this is software which has not yet had a significant effect. If it never existed then maybe the blockchain would be 41GB instead of 40GB in size (because a few dozen extra large blocks might have been mined and built upon). So basicially the situation is this: 1) Increase the 1MB limit = keep Bitcoin working the same as it is now.2) Keep the 1MB limit = perform a radical economic experiment on Bitcoin.Both 1 and 2 have risks for decentralization, perhaps 2 more so, as a lot of full node owners have bought into the ideal of a global currency and payments system, which would be put at grave risk if the radical experiment goes wrong. Fortunately most people want it to keep it working how it is now. |
|
|
|
It's quite likely we passed a complexity point where a small group of people can't perfectly manage this system around the end of the last century.
any systems related to human society have always been to complex to handle efficiently by a small group of people. The delusion that they can do so efficiently is a dangerous one and lies at the root of pretty much every problem human society is facing today. The basic problem has to do with information not being able to flow without distortions in a centralized system and executive power not lying where there is the biggest abundance of relevant information (with the individuals directly involved with a given situation) Indeed. Mises "calculation problem". I think the delay between the onset of serious central planning meddling, and systemic collapse, is simply due to the sheer size of an economic system and the inertia which is latent. So Zimbabwe will collapse faster than Venezuela which collapses faster than Japan, assuming a similar progression of centralized control. |
|
|
|
Starting next month the European central bank will give 60 billion every month upto one trillion to the top 1% making them more wealthy so that they can buy luxury yatch, gift ferrari to their mistress..
Come on, don't forget the trickle-down effect. Mistress wrecks Ferrari tyres on roadside kerbs. Buys new ones for $20k, Indonesian rubber factory gets another order, factory worker gets paid $17, worker pays 99c for a gaming app, Western software designer earns 5c. QE works! |
|
|
|
|
Don't forget that IBLT (set reconciliation) will reduce the size of new block announcements by about two orders of magnitude. So 20MB blocks could take 200KB (although in practice the minimum IBLT might be a bit larger). Only node bootstrapping and resync will need full size blocks sent on the network. A lot of dev work is going on so maybe this will happen soon after Gavin's v4 blocks. The relay service also reduces block size (by about 80-90%, I think I remember reading), and this is already live.
The efficiency of this will improve over time, and it will also hugely reduce one class of spamming, where a miner keeps a lot of spam transactions secret and eventually blasts out a large solved block full of them.
|
|
|
|
|
Show Posts
