it it possible or even practical to identify a bitcoin as having been a "direct descendant" of a coin involved in a given transaction and/or as a coin that has been "co-mingled" with such a coin?
Definitely. That is easy to do. However since each transaction can have multiple inputs and outputs, the set of descendants is likely to grow over time, until eventually most bitcoins are descendants of that transaction.
it may make it practical to for major players and for that matter anyone who uses BC to "locally blacklist" seized bitcoins.
If there isn't any consensus in the "community", then such a blacklist is unlikely to have any effect.
If some miners decide to blacklist transactions involving certain coins, then other miners are just going to pick them up. If only a minority of miners are in on the blacklisting, then this is going to cause a fork in the blockchain. Other miners have to decide, which fork they are going to bet their resources on. If there isn't consensus on what to blacklist, there could be so many forks blacklisting different subsets, that each fork is going to become irrelevant leaving only the chain with no blacklisting as viable.
Even if you could manage to get a majority of miners to agree on exactly what should be blacklisted, it is of questionable value to the miners to attempt blacklisting. It could be seen as introducing a dangerous precedence for introducing blacklists. This would introduce a new and even more unpredictable danger to anybody owning bitcoins.
Traders could decide to blacklist certain bitcoins. This would mean you would refuse to accept blacklisted coins. But if you are selling goods for bitcoins, then you'd have to announce in advance, which coins you consider blacklisted, otherwise you'd have disputes where the buyer of goods says they have paid, but seller of goods says the received bitcoins are no-good. And as receiver of bitcoins you'd also have to decide how diluted the blacklisted bitcoins would have to be, before you'd accept them. And in all, there'd have to be consensus about both the set of blacklisted bitcoins and the dilution threshold. Otherwise nobody will know, if the bitcoins they are accepting are good or not, and without such knowledge blacklisting wouldn't have the intended effect, instead you'd just be rejecting arbitrary payments, you might as well flip a coin and say no-thanks to a certain payment.
I think the only consensus that has a real chance of being reached is that bitcoins are not blacklisted.
Keep in mind; if the miners did have to communicate with the pools constantly and synchronously with their mining, it could slow down their mining, and therefore give them a competitive disadvantage.
True. I was assuming it was obvious, that the communication had to be asynchronous. And I can't see any reason to communicate with other pools more often than once per block.
Once a node has started computing, it should be able to go on for quite a while without any communication. If the node doesn't hear anything else, it should just keep doing whatever it was doing. The only thing that can render the continued computation completely pointless for the node is if a node somewhere (in the same pool or any other pool) successfully mines a block. If communication has been totally dead for an hour, it is probably a waste of energy to keep trying to mine a block, since somebody else likely mined it already. But if you haven't heard anything for five minutes, just keep trying to mine the same block you were already working on.
This means the most important information to get synchronized between nodes is the fact that somebody mined a block. This should be totally independent of the pool, so this can be communicated between nodes even if they are in separate pools.
The other information a node needs to receive is information about which transactions to include in the block. It's no big deal if that information is lagging a bit behind. You could update the list of transactions multiple times while trying to complete a block, but if it lags a couple of blocks behind, nothing is going to break.
That shouldn't be a prerequisite for including it. After all, having the text represented on a computer would be a useful tool in getting to understand it.
I believe 98% of miners are using standard mining tools which communicate with the selected pool only
So, we are dealing with a (minor) weakness in the standard mining tools.
What i'd like to see happen is a pool cross-submission scheme, where: instead of miners having just one pool configured, they have at least 3 configured, and: while they may only be requesting work units from 1 pool; they could send a 'heads up' to all the secondary pools, when a new block is detected...
A miner connected to the bitcoin network AND the pool, could in theory foil the attack.
If you are mining without communicating with the rest of the bitcoin network, you are putting somebody else in charge of that communication, which means you are giving somebody the power to cheat. Any miner not intending to cheat should be considering that to be a vulnerability in the mining software.
In other words, any miner not intending to cheat have an interest in running mining software, that does communicate with the rest of the bitcoin network, even if the rest of the mining pool doesn't.
Take steps to prevent accumulating 51% hashing power, including: not accepting new miners
Why is this even necessary? I was under the impression that a mining pool would not be able to pull off an attack without it being immediately visible to the miners in the pool. Doesn't that mean that having a pool with majority of the processing power isn't enough to pull of an attack, you also need all miners in the pool to conspire to perform the attack?
Think of it this way, when you've worked on code that's 10 years old and you think "this would be so much better if we could throw it away and start from scratch" imagine that Intel thinks the same way with x86 only it's dealing with a 40 year long chain of incremental improvements.
At least AMD64 did do some preparations for ditching some of the cruft. The 64-bit mode of the AMD64 architecture left out some of the features of the original x86 design. If we can get the 16 bit BIOS interfaces replaced with 64 bit interfaces, then it would make sense for the next generation of CPUs to switch on in 64 bit mode. After that, it won't be long before you can completely drop the 16 and 32 bit support from the CPUs. Support for 32 bit user mode on a 64 bit kernel may need to live for a little longer though.
Yup, and the BS about them being first to 64-bit...maybe in the consumer sector, but Intel, IBM and DEC all had 64-bit chips before the Athlon was even designed let alone shipped.
That is true. However AMD were the first to make a 64-bit architecture, which was x86 compatible. And it was also the first 64-bit CPU to be in a price range that was acceptable to average consumer. But most importantly, AMD designed an architecture so successful that Intel decided to make their own AMD compatible CPU. Today Intel probably earns most of its money on CPUs using AMD's 64 bit design.
But if AMD now want to go and build an entirely new design, which is nothing like x86, they may very well be repeating the exact same mistake Intel made to let AMD64 get the lead.
By now it might be safe to ditch all 8, 16, and 32 bit backwards compatibility with the x86 family. But AMD64 compatibility is too important to ignore.
gmail still has it's original old plain HTML interface, although they hide the option to switch to it fairly well.
I know about it, and I did use it for some period when the default interface was unusable for me. But that interface is less functional than the original Gmail interface. It is comparable with webmail interfaces from before Gmail surfaced.
I have been wondering if there is an open source webmail system, I could host myself, which is as functional as Gmail was when it was best.
It's not good enough that something have reached a state of maturity that works well with users, and they like.
That has happened to Gmail multiple times over the years. And each time Google decided that it was time to redesign the Gmail UI. After their last major UI change, I completely gave up on using Gmail to write emails. Now I only use it to read and search emails.
Right now we can't even get to our nearest neighbor(Alpha Centauri) in a lifetime.
Being able to do that would require some major technological advances. But if mankind can successfully colonize a planet orbiting any of the closest stars, then I don't think nearly as large technological advances would be needed to continue throughout the rest of the galaxy. It would basically just be doing the same thing over again using known technology. It may take a long time.
If the trip takes one generation, colonization of a planet takes a couple of generations, and preparing for the next trip takes a couple of generations, the time to move from start to star would seem like an eternity from the individual's point of view. But on a cosmic time scale, it would still be fairly quick, and colonizing the entire galaxy would seem like an inevitable outcome, if the colonization of the first handful of star systems had been realized.
But even if all of that happened, it would not imply that means of intergalactic transportation would be easily within reach. The trip between a couple of stars within our galaxy is much shorter than the trip between two galaxies. Such a trip could take many many generations and would require an energy source for the trip.
At that point, the velocity needs to be computed through general relativity, which is fiendishly more complicated than just v/a.
Doing that division is no problem, and the result you will get is 354 days. Next one has to interpret the result. Now look carefully at what I said about the interpretation of that division. I said you'd be moving at relativistic speed after less than one year.
The definition of relativistic speed is that you are moving so fast, that Newtonian formulas are no longer a good approximation. The Newtonian formulas say you'd be moving at 103% of the speed of light after a year, that is not a good approximation. Hence the speed you will be moving at is by definition relativistic.
Let's put it differently and assume I was wrong. In other words we assume you would not reach relativistic speed. That implies Newton's laws would give a good approximation of the actual speed, and they say you'd have accelerated above the speed of light. Either way, you'd reach relativistic speeds within a year.
Even the speed of light does not seem so fast when compared to 1G. c / 1G = 354 days. The implication of that is that at 1G acceleration, you'd reach relativistic speed in less than one year.
I wonder if the Earth was in orbit around a star that was part of such a cluster, would we notice the effects of such an ejection?
On a related note, I have been wondering if a civilization, that manages to populate an entire galaxy could use such ejections to spread to other galaxies.
It's my understanding that fc80::/64 is assigned automatically by the stack
An address from fe80::/64 is assigned automatically. But by default you'll only get one per network interface. Moreover any application using them must indicate which interface it want to communicate on, as it is intended for communication between two hosts not separated by a router, and addresses could be duplicated on multiple interfaces. That makes it overly complicated to use, if you really just want local communication i.e. between two processes on the same computer.
You got the names and prefixes wrong. fc00::/6 and fd00::/6 is actually the same prefix since they only differ in the 8th bit, and/6 indicates only 6 bits are significant. Also that/6 is not allocated to one specific purpose. Half of it is allocated and the other half is reserved.
Site local used to be FEC0::/10, but it has been deprecated because it was not well-defined, what the boundaries of a site is. It was replaced with unique local addresses, which are only routed locally, but should be globally unique. FC00::/7 has been allocated for this. FC00::/7 was split into two halves with different allocation policy. In FD00::/8 you can create your own/48 by simply generating 40 random bits and append those to the 8 bit prefix. The result could for example be fd1d:19b8:d39f::/48. This allows the scope of such prefixes to overlap, since there will only be a conflict if the two randomly chosen 40 bit strings by chance are identical. Due to the "birthday paradox" you can expect to be part of one million different overlapping scopes before you run into a conflict. If such conflicts should happen, some central management may be needed, which is what FC00::/8 is reserved for.
In the end, hydrogen needs to be bound back to other atoms to be a usable fuel for transportation, some promising uses for H2 could be to manufacture CH4 using CO2 from a cement factory
And of course, the cheaper way that has actually been done on a massive scale for decades, extract hydrogen from natural gas
Natural gas primarily consists of CH_4. So combining those two ideas sounds like turning natural gas into hydrogen and then turning that hydrogen into natural gas.
Getting a new protocol deployed means deploying hardware and software,
Depends on the protocol. For the most part NATs did not require software changes though they break some applications if not done properly.
NAT breaks some applications. You cannot implement a NAT in a way that is guaranteed to not break any applications. Does that mean NAT is never done properly?
Some applications may work through a NAT automatically, while others may require lots of work. In certain situations it is just plain impossible to get an application working through a NAT at all. Application developers are not supposed to spend their time working around NAT. That time should be spend on building new features instead.
If an application works flawlessly without NAT, but fails in the presence of a NAT, that just demonstrates that NAT is a problem.
You can deploy a NAT and still have some applications work without changes. But lots of development time has been wasted the last two decades on working around NAT. NAT could be deployed without needing involvement from ISPs, which is why it is so widespread today. But that is also a significant reason why IPv6 deployment is going so slow. Had NAT never been invented, we could all have been running IPv6 today, and things would work much better than they do.
IPv6 is happening.
I ran IPv6 for a few months last year and kept an eye of how often I was able to establish a connection with it. Answer? Almost never. If you call that "happening" we have a different definition of the term.
Are you asking for servers with IPv6 support? Google, YouTube, facebook, and Akamai are a few examples with IPv6 support. Were you never able to establish a connection with any of them?
I use IPv6 on a daily basis. Whenever I am on a network without IPv6 support, I realize how much more difficult it makes my work, not to have IPv6 access. Luckily Teredo works from most networks (but only for connecting with sites, that care enough about reliability to deploy their own Teredo relays).
The IPv6 head start is so minimal that Linksys shipping a new shimming protocol with its NAT routers would exceed IPv6 usage within six months.
Wrong. Shipping routers with support for a new protocol doesn't make it happen. If that was all it took, we'd all have been running IPv6 years ago. Getting a new protocol deployed means deploying hardware and software, which can support it on the entire route from one end to the other. And it means network operators have to get addresses, setup peerings and turn it on for their customers. There is no way Linksys could achieve all of that within six months.
IMHO that is still the way to go, because IPv6 just isn't happening.
IPv6 is happening. It is happening 13 years later than it should have, but at least it appears it is not falling any further behind. At the current rate we'll reach 50% dual stack by 2018 (and by 2030 we'll probably be 50% dual stack again as IPv4 will be phased out). The question is how bad the network will get in the meantime. Users of any P2P service have already been experiencing problems due to NAT, and that will keep getting worse until those services move to IPv6.
Will it get so bad, that end users realize something has gone horribly wrong, and start demanding somebody take action? Or will ISPs manage to deploy IPv6 with the majority of users being blissfully unaware what is happening?
Suggesting another solution because "IPv6 isn't happening" makes no sense. By the time you'd have a working standard for any alternative to IPv6, you'd be up against IPv6 deployed to half the internet. And deploying it couldn't be significantly simpler than IPv6, which means ISPs would be waiting for a decade to see if anybody else was deploying it first. And why would any ISP want to deploy a competitor to IPv6 which was less tested than IPv6 and did not have nearly the same market share? It took more than a decade to get them moving on deploying one replacement to IPv4, they are not suddenly going to support two replacements.
However even then we could easily have reserved say 255:255:255:8 as the extensible value of the IP address.
It already is! Along with all the other IP addresses in the range from 240.0.0.0 through 255.255.255.254. That's 268435455 IPv4 addresses reserved for extensions. But nobody has been able to come up with a way to utilize those reserved addresses to solve the IPv4 shortage. But that's not the only range that people have tried using in order to solve the problem. The 192.88.99.0/24 range is reserved as well, for a well-defined purpose, which was intended to help getting IPv6 deployed. It did not help, it may even have slowed down IPv6 deployment by 1-2 years because it lead to broken IPv6 connectivity for some users.
The list of header fields, where values have been reserved, in order to help in this upgrade is long.
The version field: 6 through 9 are all reserved for different candidates for the next protocol, but everybody have now settled on one of them.
The protocol field: The value 41 can be used to embed an IPv6 packet within an IPv4 packet. And several other values are reserved for IPv6 related protocols.
IP addresses: As mentioned lots of addresses were reserved from the start with very little success. A much smaller range was reserved later with a bit more success, that unfortunately backfired.
Options: Option type 145 is reserved for extending the addresses in a way that maintained full IPv4 compatibility (until IPv4 addresses are exhausted).
The only gaining any traction was IPv6 and tunneling of IPv6 over IPv4. The lack of IPv6 adoption is not due to any technical issue with IPv6. And none of the other ideas have technical advantages over IPv6, which would have given them better traction. The lack of deployment is entirely caused by lack of incentive, which would be the same regardless of which technical solution was chosen.
By upgrading you are faced with some technical challenges, and there is little benefit to upgrading until a significant fraction of the Internet has upgraded. By postponing the upgrade you are hurting the entire Internet, but as long as you are hurting your competitors at least as much as you are hurting yourself, it still makes sense from a business perspective.
Rationing of IPv4 addresses should not have waited until 2011. Rationing of IPv4 addresses should have started way earlier, by 2004 it was already clear that lack of incentive to upgrade was the main blocker for IPv6 deployment. At that point rationing could have been introduced in such a way as to keep the installed base of IPv4-only hosts constant. The rule should have been, that you new networks could get the IPv4 addresses they needed for dual-stack deployment, and existing networks could get new IPv4 addresses only if they could document, that they had upgraded an equivalent number of IPv4 hosts to dual stack. Had that been done, there would have been 40% dual stack hosts by the time IPv4 addresses ran out.
But pointing out what could have been done smarter in the past is not very productive. I am very interested in hearing any suggestions on what can be done today in order to accelerate IPv6 deployments. What is clear today is that IPv6 is the future. There is no other viable option. The IPv4 network is going to fall apart slowly as more and more NAT is being deployed. And any other protocol, which is not IPv4 or IPv6, is not going to be a real option. Even if a technically superior protocol showed up, IPv6 would still have a 20 year head-start.
If there exists an orbital path which can see the sun 24 hours/day, and that same orbital path lets you see the receiving stations, say, 18 hours/day
You can swap those and look for an orbit that can see the receiving station 24 hours/day and the sun more than 18 hours/day. Geostationary orbit would be an option covering both. To not have a period at night, during which you receive no power, you could have two satellites at different points in geostationary orbit pointed at the same receiving station. Then you will have two periods during the night where only one receive power, but you could position the satellites such that those periods happen when power usage is lowest. The tilt of the Earth's axis might even ensure that the problem of losing power at night is only an issue at certain times of the year.
I am just wondering when (if ever) geostationary orbit will get too crowded.
I'm going to get ahead of the game and work on that "heat death of the universe" limit.
Yeah, we need to find a workaround for that limitation sooner or later. If we don't, it will be the end of mankind. We do have a few other challenges to work on before that though. It would suck to find a solution to the death of the universe only to have life on Earth wiped out be a meteor before the other solution could be implemented.
Slashdot Mirror
Definitely. That is easy to do. However since each transaction can have multiple inputs and outputs, the set of descendants is likely to grow over time, until eventually most bitcoins are descendants of that transaction.
If there isn't any consensus in the "community", then such a blacklist is unlikely to have any effect.
If some miners decide to blacklist transactions involving certain coins, then other miners are just going to pick them up. If only a minority of miners are in on the blacklisting, then this is going to cause a fork in the blockchain. Other miners have to decide, which fork they are going to bet their resources on. If there isn't consensus on what to blacklist, there could be so many forks blacklisting different subsets, that each fork is going to become irrelevant leaving only the chain with no blacklisting as viable.
Even if you could manage to get a majority of miners to agree on exactly what should be blacklisted, it is of questionable value to the miners to attempt blacklisting. It could be seen as introducing a dangerous precedence for introducing blacklists. This would introduce a new and even more unpredictable danger to anybody owning bitcoins.
Traders could decide to blacklist certain bitcoins. This would mean you would refuse to accept blacklisted coins. But if you are selling goods for bitcoins, then you'd have to announce in advance, which coins you consider blacklisted, otherwise you'd have disputes where the buyer of goods says they have paid, but seller of goods says the received bitcoins are no-good. And as receiver of bitcoins you'd also have to decide how diluted the blacklisted bitcoins would have to be, before you'd accept them. And in all, there'd have to be consensus about both the set of blacklisted bitcoins and the dilution threshold. Otherwise nobody will know, if the bitcoins they are accepting are good or not, and without such knowledge blacklisting wouldn't have the intended effect, instead you'd just be rejecting arbitrary payments, you might as well flip a coin and say no-thanks to a certain payment.
I think the only consensus that has a real chance of being reached is that bitcoins are not blacklisted.
True. I was assuming it was obvious, that the communication had to be asynchronous. And I can't see any reason to communicate with other pools more often than once per block.
Once a node has started computing, it should be able to go on for quite a while without any communication. If the node doesn't hear anything else, it should just keep doing whatever it was doing. The only thing that can render the continued computation completely pointless for the node is if a node somewhere (in the same pool or any other pool) successfully mines a block. If communication has been totally dead for an hour, it is probably a waste of energy to keep trying to mine a block, since somebody else likely mined it already. But if you haven't heard anything for five minutes, just keep trying to mine the same block you were already working on.
This means the most important information to get synchronized between nodes is the fact that somebody mined a block. This should be totally independent of the pool, so this can be communicated between nodes even if they are in separate pools.
The other information a node needs to receive is information about which transactions to include in the block. It's no big deal if that information is lagging a bit behind. You could update the list of transactions multiple times while trying to complete a block, but if it lags a couple of blocks behind, nothing is going to break.
That shouldn't be a prerequisite for including it. After all, having the text represented on a computer would be a useful tool in getting to understand it.
Actually it only goes from 0 to 1114111, mainly because that's the range you can achieve with UTF16.
So, we are dealing with a (minor) weakness in the standard mining tools.
Sounds like a reasonable solution.
If you are mining without communicating with the rest of the bitcoin network, you are putting somebody else in charge of that communication, which means you are giving somebody the power to cheat. Any miner not intending to cheat should be considering that to be a vulnerability in the mining software.
In other words, any miner not intending to cheat have an interest in running mining software, that does communicate with the rest of the bitcoin network, even if the rest of the mining pool doesn't.
What's the purpose of sending a shutdown signal to an abandoned probe? If it is abandoned, does it matter if you shut it down or not?
Why is this even necessary? I was under the impression that a mining pool would not be able to pull off an attack without it being immediately visible to the miners in the pool. Doesn't that mean that having a pool with majority of the processing power isn't enough to pull of an attack, you also need all miners in the pool to conspire to perform the attack?
At least AMD64 did do some preparations for ditching some of the cruft. The 64-bit mode of the AMD64 architecture left out some of the features of the original x86 design. If we can get the 16 bit BIOS interfaces replaced with 64 bit interfaces, then it would make sense for the next generation of CPUs to switch on in 64 bit mode. After that, it won't be long before you can completely drop the 16 and 32 bit support from the CPUs. Support for 32 bit user mode on a 64 bit kernel may need to live for a little longer though.
That is true. However AMD were the first to make a 64-bit architecture, which was x86 compatible. And it was also the first 64-bit CPU to be in a price range that was acceptable to average consumer. But most importantly, AMD designed an architecture so successful that Intel decided to make their own AMD compatible CPU. Today Intel probably earns most of its money on CPUs using AMD's 64 bit design.
But if AMD now want to go and build an entirely new design, which is nothing like x86, they may very well be repeating the exact same mistake Intel made to let AMD64 get the lead.
By now it might be safe to ditch all 8, 16, and 32 bit backwards compatibility with the x86 family. But AMD64 compatibility is too important to ignore.
I know about it, and I did use it for some period when the default interface was unusable for me. But that interface is less functional than the original Gmail interface. It is comparable with webmail interfaces from before Gmail surfaced.
I have been wondering if there is an open source webmail system, I could host myself, which is as functional as Gmail was when it was best.
That has happened to Gmail multiple times over the years. And each time Google decided that it was time to redesign the Gmail UI. After their last major UI change, I completely gave up on using Gmail to write emails. Now I only use it to read and search emails.
Being able to do that would require some major technological advances. But if mankind can successfully colonize a planet orbiting any of the closest stars, then I don't think nearly as large technological advances would be needed to continue throughout the rest of the galaxy. It would basically just be doing the same thing over again using known technology. It may take a long time.
If the trip takes one generation, colonization of a planet takes a couple of generations, and preparing for the next trip takes a couple of generations, the time to move from start to star would seem like an eternity from the individual's point of view. But on a cosmic time scale, it would still be fairly quick, and colonizing the entire galaxy would seem like an inevitable outcome, if the colonization of the first handful of star systems had been realized.
But even if all of that happened, it would not imply that means of intergalactic transportation would be easily within reach. The trip between a couple of stars within our galaxy is much shorter than the trip between two galaxies. Such a trip could take many many generations and would require an energy source for the trip.
Doing that division is no problem, and the result you will get is 354 days. Next one has to interpret the result. Now look carefully at what I said about the interpretation of that division. I said you'd be moving at relativistic speed after less than one year.
The definition of relativistic speed is that you are moving so fast, that Newtonian formulas are no longer a good approximation. The Newtonian formulas say you'd be moving at 103% of the speed of light after a year, that is not a good approximation. Hence the speed you will be moving at is by definition relativistic.
Let's put it differently and assume I was wrong. In other words we assume you would not reach relativistic speed. That implies Newton's laws would give a good approximation of the actual speed, and they say you'd have accelerated above the speed of light. Either way, you'd reach relativistic speeds within a year.
Even the speed of light does not seem so fast when compared to 1G. c / 1G = 354 days. The implication of that is that at 1G acceleration, you'd reach relativistic speed in less than one year.
On a related note, I have been wondering if a civilization, that manages to populate an entire galaxy could use such ejections to spread to other galaxies.
An address from fe80::/64 is assigned automatically. But by default you'll only get one per network interface. Moreover any application using them must indicate which interface it want to communicate on, as it is intended for communication between two hosts not separated by a router, and addresses could be duplicated on multiple interfaces. That makes it overly complicated to use, if you really just want local communication i.e. between two processes on the same computer.
You got the names and prefixes wrong. fc00::/6 and fd00::/6 is actually the same prefix since they only differ in the 8th bit, and /6 indicates only 6 bits are significant. Also that /6 is not allocated to one specific purpose. Half of it is allocated and the other half is reserved.
/48 by simply generating 40 random bits and append those to the 8 bit prefix. The result could for example be fd1d:19b8:d39f::/48. This allows the scope of such prefixes to overlap, since there will only be a conflict if the two randomly chosen 40 bit strings by chance are identical. Due to the "birthday paradox" you can expect to be part of one million different overlapping scopes before you run into a conflict. If such conflicts should happen, some central management may be needed, which is what FC00::/8 is reserved for.
Site local used to be FEC0::/10, but it has been deprecated because it was not well-defined, what the boundaries of a site is. It was replaced with unique local addresses, which are only routed locally, but should be globally unique. FC00::/7 has been allocated for this. FC00::/7 was split into two halves with different allocation policy. In FD00::/8 you can create your own
Natural gas primarily consists of CH_4. So combining those two ideas sounds like turning natural gas into hydrogen and then turning that hydrogen into natural gas.
NAT breaks some applications. You cannot implement a NAT in a way that is guaranteed to not break any applications. Does that mean NAT is never done properly?
Some applications may work through a NAT automatically, while others may require lots of work. In certain situations it is just plain impossible to get an application working through a NAT at all. Application developers are not supposed to spend their time working around NAT. That time should be spend on building new features instead.
If an application works flawlessly without NAT, but fails in the presence of a NAT, that just demonstrates that NAT is a problem.
You can deploy a NAT and still have some applications work without changes. But lots of development time has been wasted the last two decades on working around NAT. NAT could be deployed without needing involvement from ISPs, which is why it is so widespread today. But that is also a significant reason why IPv6 deployment is going so slow. Had NAT never been invented, we could all have been running IPv6 today, and things would work much better than they do.
Are you asking for servers with IPv6 support? Google, YouTube, facebook, and Akamai are a few examples with IPv6 support. Were you never able to establish a connection with any of them?
I use IPv6 on a daily basis. Whenever I am on a network without IPv6 support, I realize how much more difficult it makes my work, not to have IPv6 access. Luckily Teredo works from most networks (but only for connecting with sites, that care enough about reliability to deploy their own Teredo relays).
Wrong. Shipping routers with support for a new protocol doesn't make it happen. If that was all it took, we'd all have been running IPv6 years ago. Getting a new protocol deployed means deploying hardware and software, which can support it on the entire route from one end to the other. And it means network operators have to get addresses, setup peerings and turn it on for their customers. There is no way Linksys could achieve all of that within six months.
IPv6 is happening. It is happening 13 years later than it should have, but at least it appears it is not falling any further behind. At the current rate we'll reach 50% dual stack by 2018 (and by 2030 we'll probably be 50% dual stack again as IPv4 will be phased out). The question is how bad the network will get in the meantime. Users of any P2P service have already been experiencing problems due to NAT, and that will keep getting worse until those services move to IPv6.
Will it get so bad, that end users realize something has gone horribly wrong, and start demanding somebody take action? Or will ISPs manage to deploy IPv6 with the majority of users being blissfully unaware what is happening?
Suggesting another solution because "IPv6 isn't happening" makes no sense. By the time you'd have a working standard for any alternative to IPv6, you'd be up against IPv6 deployed to half the internet. And deploying it couldn't be significantly simpler than IPv6, which means ISPs would be waiting for a decade to see if anybody else was deploying it first. And why would any ISP want to deploy a competitor to IPv6 which was less tested than IPv6 and did not have nearly the same market share? It took more than a decade to get them moving on deploying one replacement to IPv4, they are not suddenly going to support two replacements.
It already is! Along with all the other IP addresses in the range from 240.0.0.0 through 255.255.255.254. That's 268435455 IPv4 addresses reserved for extensions. But nobody has been able to come up with a way to utilize those reserved addresses to solve the IPv4 shortage. But that's not the only range that people have tried using in order to solve the problem. The 192.88.99.0/24 range is reserved as well, for a well-defined purpose, which was intended to help getting IPv6 deployed. It did not help, it may even have slowed down IPv6 deployment by 1-2 years because it lead to broken IPv6 connectivity for some users.
The list of header fields, where values have been reserved, in order to help in this upgrade is long.
The only gaining any traction was IPv6 and tunneling of IPv6 over IPv4. The lack of IPv6 adoption is not due to any technical issue with IPv6. And none of the other ideas have technical advantages over IPv6, which would have given them better traction. The lack of deployment is entirely caused by lack of incentive, which would be the same regardless of which technical solution was chosen.
By upgrading you are faced with some technical challenges, and there is little benefit to upgrading until a significant fraction of the Internet has upgraded. By postponing the upgrade you are hurting the entire Internet, but as long as you are hurting your competitors at least as much as you are hurting yourself, it still makes sense from a business perspective.
Rationing of IPv4 addresses should not have waited until 2011. Rationing of IPv4 addresses should have started way earlier, by 2004 it was already clear that lack of incentive to upgrade was the main blocker for IPv6 deployment. At that point rationing could have been introduced in such a way as to keep the installed base of IPv4-only hosts constant. The rule should have been, that you new networks could get the IPv4 addresses they needed for dual-stack deployment, and existing networks could get new IPv4 addresses only if they could document, that they had upgraded an equivalent number of IPv4 hosts to dual stack. Had that been done, there would have been 40% dual stack hosts by the time IPv4 addresses ran out.
But pointing out what could have been done smarter in the past is not very productive. I am very interested in hearing any suggestions on what can be done today in order to accelerate IPv6 deployments. What is clear today is that IPv6 is the future. There is no other viable option. The IPv4 network is going to fall apart slowly as more and more NAT is being deployed. And any other protocol, which is not IPv4 or IPv6, is not going to be a real option. Even if a technically superior protocol showed up, IPv6 would still have a 20 year head-start.
ARIN is not IANA.
You can swap those and look for an orbit that can see the receiving station 24 hours/day and the sun more than 18 hours/day. Geostationary orbit would be an option covering both. To not have a period at night, during which you receive no power, you could have two satellites at different points in geostationary orbit pointed at the same receiving station. Then you will have two periods during the night where only one receive power, but you could position the satellites such that those periods happen when power usage is lowest. The tilt of the Earth's axis might even ensure that the problem of losing power at night is only an issue at certain times of the year.
I am just wondering when (if ever) geostationary orbit will get too crowded.
Yeah, we need to find a workaround for that limitation sooner or later. If we don't, it will be the end of mankind. We do have a few other challenges to work on before that though. It would suck to find a solution to the death of the universe only to have life on Earth wiped out be a meteor before the other solution could be implemented.