You thought correctly. I don't do chip design, I'm purely a hardware guy. However, most of the companies my company supports *are* in the semi industry ergo my knowledge of where the chip mfg processes comes from. Our end of things is tightly integrated to what size nodes the Foundries can produce. That said, I can tell you it is a fact that you are looking at several million $ to develop a chip from scratch. Even when using foundry or design house supplied pre-made IP blocks, TSMC will not even talk to you about 16nm chips unless the chip quantities are over 100k/month... Push back to 20-22nm and higher and they are much more approachable but that is also outside our target.  Here's my take on the cost: The hashing engine is so small that one could get it developed and samples manufactured for free in the small corner of some bigger project. The mega-dollar capital outlay would be required only in the final stage of mass-production. The semiconductor foundries routinely "waste" much more chip real estate on various testing structures. So why nobody did that? My limited experience shows that the prospective market is so filled out with liars, bullshit artists, con men, mythomaniacs and associated naïfs (that are honest, but completely indistinguishable for the former classes) that it is completely not worth the effort. The only way to do it is as an intellectual curiosity (in secret) or when from the start you plan on ripping off the fools. Please don't go blaming the messenger. This is the reality. I'm not going to claim that I know everyone in the Bitcoin milieu. But I've known enough to come up with some generalizations. |
|
|
|
Certainly, we as a community, can come together to figure out a way to do this. No?
Well, the answer to your rhetorical question is now obvious: NO. This is a high technology endeavor: armies of electrical technicians, screwdriver artists and soldering masters can't overcome the advantage of a single logic design engineer backed with appropriate design toolset and the capital to manufacture it. The last chances for "community effort" was in the FPGA era. They didn't work out. Bunch of tightwads, skinflints and associated naïfs don't make a "community". They are just fodder to be exploited by the more knowledgeable. The reality of electronic industry (in general) and coin mining niche (in particular) is brutal to some. I would just call it "normal", "typical" to any technological endeavors. |
|
|
|
Hi Y'all,
I think the main point has been missed, it may be that regular home computers can no longer run a full bitcoin node. So much for a public, democratic, none elitist, de-centralised distribution scheme!
My Machine has pretty powerful duel core 64 bit CPU;
Model Name: MacBook Air
Model Identifier: MacBookAir5,2
Processor Name: Intel Core i5
Processor Speed: 1,8 GHz
Number of Processors: 1
Total Number of Cores: 2
L2 Cache (per Core): 256 KB
L3 Cache: 3 MB
Memory: 4 GB
When Satoshi Nakamoto started Bitcoin he mined his first coins (lots of them) on a home PC, I think it should be still possible to run a full node on my machine.
There are no capacity issues with CPU / RAM / Network bandwidth @ 65Mps.
I tried Bitcoind twice on my Raspberry PI2 and failed. I tried Bitcoin-QT twice on my laptop and failed, once using a 64GB SD card and once with an external USB3 SDD.
On a healthy laptop surly I should be able to download and install the wallet software and let it synchronise. I don't mind it takes a few days running 24/7 but to fail after many weeks, still being 13 weeks from current is unacceptable.
I sent my crash report to apple and GitHub...
G*
No, mate, it is you who missed the point. Bitcoin was never for a man on the Clapham omnibus who just stepped into an electronics store and purchased some random imported electronics crap. Bitcoin was always for a technically curious person capable of assembling a reliable hardware and discerning and following the reasonable advice like "disable App Nap in Mac OSX". The barrier to entry of being your own bank is no longer financial but intellectual. Bitcoin doesn't require the latest technological toy of chattering classes riding that proverbial Clapham omnibus. The history of computing is full of them: BBC Micro, Sinclair ZX Spectrum and man others. Now they sell Raspbery Pi to that segment. Bitcoin is known to work reasonably well on a reasonably sensible home computer like my old Windows XP machine with original Clawhammer AMD 64 from 2004 or the old Mac Mini Server from 2009. It is always interesting and educational to read on this forum the experiences of the new entrants to the Bitcoin ecosystem. Some are quick on the uptake and nearly immediately learn to be self-sufficient. Other are just capital donors who will incessantly complain about not enough handholding. You'll need to either learn how to use a computer or pay somebody who will run your computers for you. This is a 21st century version of egalitarianism in the knowledge society. |
|
|
|
It kinda depends on what aspect of the "Miner in a Box" you focus on. In my opinion, the whole immersion cooling stuff is squarely aimed at density (i.e. TH per square foot). The rest of the container business has been done by others and was aimed at simplification of installation and setup. Both of those have additional costs over and above the actual mining hardware. We've even seen a "Mining Trailer" that looked like it could easily be move in a day if the connections were right. While interesting, there is precious little value in making a substantial mining "operation" mobile to any significant degree. Yes it make the initial install easier, at a cost, but after that.
I focused on the immersion cooling aspect of this, and it seems fairly costly compared to a more "spread out" facility with lots of air flow. Pumps, radiators, and 3M NOVEC (or Flourinert), aren't cheap at all. They also have a long term run cost compared to fans and a more hospitable natural environment (e.g. a cool/cold climate).
Actually I think you are wrong. Exactly same density can be achieved with plain single loop water cooling, without the expensive two-phase fluid immersion cooling. The target market is the buyer without enough engineering skills to design its own mining hardware based on mining chips individually mounted on small PCBs. The actual strength of the two-phase immersion cooling is for example when you really have to use large PCBs, like e.g. CPU/GPU chips connected to large arrays of DRAM. With speed-of-light limitation you cannot design around that constraint and the 3D designs used in aircraft or missiles would be more expensive than the pricy immersion fluid. Bitcoin mining has no such unusual engineering requirements. So their target market is somebody who really has no way of purchasing regular engineering skills but has large amounts of cash burning in their pockets. Only the usual suspects are left: money laundering for organized crime or some secret departments of small nation-state governments. |
|
|
|
Hi y'all,
Thanks so much for your suggestions and observations. My problem is bigger now, after weeks of downloading and verifying I have a check sum error in my data base;
So 57GB later, I'm drifting down shit creek without a paddle!
DiskUtil checks out 100%, SDD is OK.
I have been trying to run a full node on a Raspberry PI2, this SDD/blockchain was going to boot strap it as it would not load the whole blockchain native on an HCSD card.
I'm beginning to wonder if this tech is stable, scalable and intended for domestic HW?
very disillusioned...
G*
MacBook Airs were never really reliable hardware. In addition, their lightness promotes the abuse. The most common errors are: 1) not waiting for the proper OS shutdown: start a shutdown and then rapidly close the lid before shutdown completes 2) not waiting for the proper Bitcoin-Qt shutdown: unfortunately it closes all its windows before the data is fully committed to disk 3) DiskUtil never in the history of Mac OS's did the proper/full test of disk, it is only rather superficial file system integrity check Compounded with the fact that Bitcoin-Qt has almost no internal error checking and uses the educational toy database engine you are where you are: your own bank where bank manager decided that running backups to Time Machine is an unnecessary expense. |
|
|
|
Is there benefit to running ECC memory with a computer that generates a lot of payment addresses?
I guess what I am asking, is there risk of a faulty memory module with a stuck bit producing an incorrect public key or sha256 hash or ripemd160 hash?
I suspect if the ripemd160 hash is correct, that a stuck bit impacting the sha256 hashes would usually result in a bad checksum, but what about generating the ECDSA public key or the ripemd160 hash of the public key?
Thanks for any thoughts on this, especially from people who know.
Depends on how you generate those addresses. If you have your own code and can add the function to re-check, then no. If you are just running Bitcoin Core then ECC is mandatory for reliable operation. Bitcoin Core lacks error checking in many of its operations. For details check the posts by etotheipi about his adventures with bit-flipping RAM with his non-ECC Intel i7 desktop machine used for development. |
|
|
|
he is now riding the community needs coke-tail..
Ha, ha! A good one! Yeah in 21th century nobody wears tailed coats. I'm quoting it for the future use. |
|
|
|
I'm not sure they want to disclose anything really. I view this as the bitfury lightbulb. They put something out there to make some news, no doubt some sites showed it.
The lightbulb they said they would sell.... and just never came. I predict this container will not even make it as far as the lightbulb. I think it will remain a rendering. If they make one even as proof of concept I will be surprised.
The proof of concept obviously did exist even in the days of ASICMINER. They had some pilot installation with 2 or 3 half-rack vats of Novec cooling then current ASICMINER boards and power supplies. The video used carefully staged angles (and possibly VFX) to make it look that there are whole rows of full racks in operation. The pilot installation was located in Singapore or some such are with extremely limited and valuable real estate. The containers (steel cages) obviously do exist. The second stage water pump and water cooling radiator & fan combos are also standard industrial equipment. I do share your doubt that they will ever close a sale or lease contract. With their sales tactics the whole thing stinks too much of snake oil. It will be hard (but not impossible) to find somebody stupid enough to plunk the money for the full installation. I was actually somewhat disappointed when I read that Bitfury acquired Allied Control. |
|
|
|
Um, tell that to the customers screwed by AMT/Bitmine.ch over the A1 kerfuffle when it was introduced. Inno's A1 failing to meet design specs cost us final customers 100's of k$ in total or more. For most folks it looks like their money is never to be seen again as the lawsuits are in limbo. And ja Bitmine.ch's horrible board design was the icing on the crap cake.
BirFury, Bitmain, et al care very much about spec as that is what they base their miner designs on, eg how many chips in it running what speed will give us advertised throughput/power usage.
Sure miner chips are vastly simpler than the various processors used in mobile devices. Just simple I/O, bit of memory, coms and the SHA256 cores vs hundreds of I/O and scads of different core components including critical L1/2/3 cache memory. That simplicity should in turn give more good chips vs yield from making mobile processors and their ilk.
You are just projecting your misfortune. I'll repeat specifications are worth nothing without the appropriate contract enforcement mechanisms, either legal like https://en.wikipedia.org/wiki/Letter_of_credit or extralegal like  . Both Bitfury and Spondoolies have history of not meeting the predicted specifications. But for them and their customers things worked out because they had the right mixture of business and technical skills. I already wrote about Bitfury, so I'm just going to mention that Spondoolies did things like refunds for underperformance and advised customers to use hair dryers to warm up miners that wouldn't start in the cold climates. |
|
|
|
I estimate that Bitfury can build this containerised system for about $900 k, including 11kV input capability. Of that amount around $550k will be 160,000 chips on plug in modules, so the actual infrastructure costs about $350k. If they build the container with borrowed money at, say 8% then after a year then will have paid for the container and have around $590k in the bank.
I think you may be lowballing the cost and lead time for the required quantities of Novec fluid. Before I knew about Novec as a cooling fluid I though that this was just another reagent used in medical industry. There I overheard people talking about borrowing a 50 gallons drum of some used Novec to keep their medical test processing line up. Novec isn't some neutral or noble fluid. This is some sort of super-solvent that can leach nearly anything out of nearly everything. Keeping it reasonably clean is a tightly controlled information, one that Allied Control/Bitfury folks will not disclose. Anyway my take is that the Allied Control folks are their own biggest enemy. They sales tactics are such that if they were selling illicit drugs to junkies the Narcotics Anonymous would have had a banner year. In the absence of real news, how about a repost from 2013 about ASICMINER DragonFire and ChainForker? Speak for yourselves, I'd like a full rack the size of a refrigerator at minimum. Let BFL and Avalon make the rinky-dink consumer crap. AM should make industrial shit with fat profit margins. Go huge or go home! Like IBM and Oracle, we need to be selling high-ticket Big Iron (and lucrative consulting) to deep-pocket commercial customers. Not Joe Sixcoins. Hoping for something trailer mounted as an upgrade, so I can haul them it to wherever power is cheapest.  20TH ASiCMiNER DragonFire 100TH ASiCMiNER ChainForker |
|
|
|
The 40% yield refers to number of good chips per wafer - not cores per chip. As to what is a good chip, it one that meets spec. Preferably with 100% cores active @ stated speed. From there they will start stepping down the grade hopefully mainly by speed capability instead of by dead cores.
You start sounding weird... Not enough caffeine this morning? Or too much? The whole point of mining ASIC is that there's no "spec". It is 100% self-love. All they have to do is twiddle their own little thumbs really fast and gaze at it's own navel. The theoretically most demanding application for them would be if they are daisy chained and have to talk to their brothers from the same wafer or same batch that is sitting few centimeters away on the same board. No need to interface e.g. a DRAM chip or obey some IEEE standard. The only 3 things that miners care are: 1) Ghash per sec/W 2) Ghash per sec/$ 3) delivery time There's no "stated speed" or "100% cores". Everything else can be and will be worked around at the board layout and software driver level. |
|
|
|
|
Allied Control is not "other people". Bitfury acquired Allied Control some time ago.
|
|
|
|
Less than 10% operating correctly? So, about 820 cores instead of 8200? How's that pass inspection, or am I missing something? Admittedly I know nothing about the logic implementation of hash cores.
It will pass inspection at a lower grade and will be sold for a lower price. But its ratio of hash speed per power used will still be better than the competition. I am making one assumption that somebody's at Bitfury has at least one brain cell working and will include circuitry to disable clock distribution to non-working hashing engines. If they have more than two working brain cells together they will include a way to fuse-out power to the non-working engines and there won't be even leakage. The other thing increasing yield in mining chips is that they are 100% self-love, they don't have to meet any external timing constrains. If the defect is wafer-global, like all transistors have 1/3 of the normal Fmax, the chip is still competitive in GH/J and can be sold at a different price point. The biggest yield differentiator is that SHA-256 is self-testing and requires exactly zero functional testing circuitry. The regular chips made for big-name customers most definitely require that at least the JTAG chain is operational on the whole surface of the chip, even if many functional units are defective and will be disabled when sold. The NAND flash folks have this down to art. 90% chip not working? Sell it as a 10% capacity chip! Chip fails after 10 erases? Sell it to promotional merchandise vendors or as a one-time-programmable! Bitfury folks seem to be rather intelligent. Their first chip included some analog self-test circuitry (ring oscillator?) that allowed for testing of the maximum speed that the chip wants to work (at particular temperature and supply voltage). It may not have worked as intended, but shows the grasp of technology. The opposite can be said of Spoondoolies. They wasted chip estate for including some POST (power-on self test) circuitry. And then their software guy had to write code that re-enabled disabled engines which were failing only when cold and worked fine hot. Edit: Remember the first Bitfury chip? They were 100% defective if one would try to apply traditional test methodologies. But somebody from Poland within first few days reverse-engineered the "defect" which turned out to be some sort of permutation of signals like (15-0) -> (1-16). They added appropriate compensating permutation in the driver and sold all of them. |
|
|
|
90% yield?   That is WAAAAAY off base. That yield is common for higher nodes like 28nm on up but currently 16/14nm production yields are around 40% good dies and lower. They only began to hit 40% late last year... Now the foundries are of course trying to get better but the processes are still under development. Biggest issue is the EUV light source used for the photo lithography. That monstrosity is still pretty hairy to run and is in no way capable of running 24x7. Is more like 8-20hrs followed by around 6 hrs to a full day of cleaning/realignment/process verification before starting another run of chips. 90% is a lowball estimate. The actual yield will be higher. The mining chips are so repetitive that they are commercially valuable even if less than 10% of it is operating correctly. It is the same story as with NAND flash memories. |
|
|
|
I need to preserve more of the resultant chatter on Twitter. This is developing like one of those "The Onion mistaken for a news site" stories. Paul Sztorc @Truthcoin It seems that MP has internalized Bitcoin's full node externality. http://trilema.com/2016/the-necessary-prerequisite-for-any-change-to-the-bitcoin-protocol/ … Initial reaction: "Wow." Retweets 18 Likes 19 Pierre Rochard Andrea Castillo Beautyon Daniel P. Barron CRYPTOSYSTEM BitcoinUncoilVen Cosmic Hemorroid David Francois Paul Sztorc @Truthcoin · 4h4 hours ago @Truthcoin Greg Maxwell, smartest man in Bitcoin, has responded with some technical vetos: https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we … View summary 3 retweets 4 likes Evan Daniel @evanbd · 3h3 hours ago @Truthcoin Fair to conclude from this that MP's confidence is grossly miscalibrated, then?  Paul Sztorc @Truthcoin · 3h3 hours ago @evanbd Of course, but don't believe for a second that MP isn't aware of where he's set the calibration dial. Evan Daniel @evanbd · 3h3 hours ago @Truthcoin Somewhere between "wrong" and "politician"? Paul Sztorc @Truthcoin · 3h3 hours ago @evanbd Somewhere between "Stephen Colbert" and "Bill O'Reilly", perhaps. mdotfallon @mdotfallon · 6h6 hours ago @Truthcoin I'm not sure if that's more surprising or the fact that he said he's open to a block size limit increase if node code made it in Paul Sztorc @Truthcoin · 6h6 hours ago @mdotfallon What is not surprising is that this article is immediately preceded by one which describes a type of inherently-elitist kink. Immanuel Chaiseman @IChaiseman · 5h5 hours ago @Truthcoin Implement this ASAP. The eccentric, weird dichotomy between node & miner resolved, will make arguments more easier to solve. Immanuel Chaiseman @IChaiseman · 5h5 hours ago @Truthcoin Relevant reference on this topic, describing the original tweet in succinct laymanesque detail: http://pastebin.com/ksV2n9y9 David Harrison @tradewithdave · 3h3 hours ago
@Truthcoin @junseth self-proclaimed "dumbest man in #Bitcoin" has responded with FREE baseball caps in the crevice of a tree. #DropZone
Paul Sztorc @Truthcoin · 3h3 hours ago
@tradewithdave @junseth Only the SCAMMIES will decide who is truly the dumbest.
Daniel P. Barron @danielpbarron · 1h1 hour ago
@Truthcoin If he has criticism, he should take it to #bitcoin-assets where bitcoin policy is set; not keep pretending like it doesn't exist.
Daniel P. Barron @danielpbarron · 1h1 hour ago
@Truthcoin What's more, he claims Mircea's idea is like his own from 2013, implying that the entire chain of blocks is like the last two.
|
|
|
|
This proposal is actually worth quoting in full before its get deleted or changed. If one takes the claim that this proposal was discussed at length in Mircea Popescu's group, then the conclusion is that his group doesn't have even a single student of cryptology, not to mention an amateur or professional cryptologist. I'm going to discount to zero the possibility of intentional weakening or intentional misrepresentation; the mistakes are too elementary. Certainly there wasn't a proof-of-concept implementation done. The following quote was slightly reformatted to conform to the markup limitations of this forum's software. The necessary prerequisite for any change to the Bitcoin protocol
Monday, 01 February, Year 8 d.Tr. | Author: Mircea Popescu
Summary :
All blocks must include a SHA3(I)-512 digest calculated over a bitfield composed out of the nonce-th byte out of every preceding block, wrapped.(ii)
Rationale :
The issues being resolved have been discussed at length in #bitcoin-assets, whose logs you are invited to read - right now, and in integrum.(iii)
This notwithstanding, an unbinding summary is that the miner-node division(iv) is both an unintended consequence of the poor design and inept implementation of Bitcoin by its original author as well as the single known possible threat to its continued survival. This measure heals that rift, by making it impossible for miners to mine without nodes(v)) ; and by giving nodes a directly valuable piece of information they can sell.(vi)
The Vatican's Armored Divisions(vii) :
I won't bother with parading for your benefit, nor will I recount the sad story of "what happens when you don't do what MP says". If you've done any reading worth the mention you should know all that by now ; if you need any explanation as to why my pronouncements are binding, you necessarily have no clue about Bitcoin-anything. See here instead.
I will however say that details(viii) are negotiable, on one hand, and that I am open to considering other changes be bundled with this change, possibly including an increase of the blocksize. I will however, attack and sink any other change whatsoever, without regard to who proposes it, who supports it, or what it contains. The only way to make any alteration whatsoever is to make an alteration that includes this one.
And now that we understand each other, back to your regularly scheduled program.
———
(i).The principal consideration is that unlike the rest of the SHA "family", the keccak function takes unlimited input. Bitcoin is forever after all.
The political importance of not using NSA/NIST crapolade is a secondary concern, even if it makes a very valid, muchly needed statement, namely that the United States has no future in technology just like it has no future in political geography. ↩
(ii).Exempli gratia : if the fourth block is added to a blockchain consisting of
i.60 bd e7 67 77 70 20 b2 e6 7c 46 c3 (12 bytes)
ii.75 80 d2 b0 6e 6c 6d a9 5d 12 98 fe bf (13 bytes)
iii.df fc 22 5f 2a 4d 50 d6 f3 fc c3 (11 bytes)
Then should that block use a nonce of 17, it must include a field equal to sha3-512(70 6e 50), whereas should that block use a nonce of 11, it must include a field equal to sha3-512(c3 fe df). ↩
(iii).The notion that you might be participating in Bitcoin in any capacity or to any degree without keeping up with the logs is not unlike the notion that you're participating in the political process through "reading newspapers" or whatever it is you do. ↩
(iv).There's multiple aspects to the issue.
One aspect is that while nodes - no, not "full" nodes, simply nodes ; everything else is not a node at all - do provide useful service, they have no way to extract payment in exchange. This takes us to the present, sad situation where the network barely consists of a few hundred nodes, and on the strength of that alone could be toppled by a fart. (Yes, supposedly significant reserve capacity exists. Let's just hope nobody actually gives this a run for its money.)
Another aspect is that new blocks are mined by one group (miners) but have to be stored in perpetuity by another group (nodes). This creates a situation where X (users) pay Y (miners) to inconvenience Z (nodes), which is unsustainable not to mention sheer nonsense.
It is true that so called "solutions" to this fundamental problem have been pluriously presented by Bitcoin's enemies in sheep's clothing. Nevertheless, they all reduce to attempts, more or less blatant, to leverage this weakness of the protocol into further damage - not a single one of them is to any degree an actual solution or even vaguely addresses the problem at all. ↩
(v).For reasons that I think obvious, mining will continue on ASICs, even if this change will require new ASICs be baked. Nevertheless, for technological reasons it will be impossible to include the generation of this bitfield in the ASICS in question - instead, they will have to depend on importing it from outside.
Whether miners will run their own nodes or allow a decentralized market of "subscription information services" to spawn up will remain to be seen, but if you do believe in the economic superiority of decentralization then you're stuck believing this will happen necessarily.
In any case, a word to the wise : if you are designing ASIC chips, and you are not including the possibility of feeding a bitfield like this in blocks, you are deliberately ensuring failure not just for yourself, but for your customers as well. This change WILL eventually come in, start planning accordingly, today. ↩
(vi).Logically what you'd do as a node operator is create KNBs (known nonce blocks) every time a new block is found. Depending how fast your machine goes, you should be able to output thousands of these per second. A miner that has to feed its rigs something will then buy these blocks from you and proceed to use them (and possibly announce them afterwards too, to protect other miners from being scammed with the same nonce block).
This forces a minimum population of nodes to exist in order for mining to even be possible - what use is more hashing if there's nothing to hash ? ↩
(vii).Is there any сталин in the house ? ↩
(viii).Probably the most important of which, shifting the nonce before taking the nonce-th element. Taking the nonce as-is requires strict parity between each hash and the calculated digest, which would require 64 MB of information be available to the miner for each Mhash. This is perhaps not practical - although it does have the marked advantage of making ASICs altogether impractical for mining, and returning that process to more traditional computers. A rather generous eight bit shift would mean the miner needs 64 bytes every Mhash, meaning that each Phash chip must have 64 GB/s worth of data to work its magic. ↩
|
|
|
|
You clearly already know everything and don't need any help. Sorry to disturb you. Have a nice day! If you configured you IPv6 addresses by hand then your deployment wasn't canonical. The normal, expected way of deploying IPv4 is DHCP; the normal, expected way of deploying IPv6 is DHCP6 or SLAAC. I am not sure which parts from my information made you came to this wrong conclusion. As I clearly wrote that this is a VPS or a server, I don't need DHCP6 to configure IPv6. As I also wrote above, I got /64 subnet of IPv6 addresses from my VPS providers. So I can use any of 18,446,744,073,709,551,616 IPv6 addresses that my VPS providers gave me. And this is the normal way of configuring IPv6 on servers. The temporary and permanent IPv6 addresses are described in RFC 4941 http://tools.ietf.org/html/rfc4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". There's plenty of tutorials available if you find reading RFCs too difficult. If you had been given a subnet of IPv6 address, the permanent or temporary addresses (in your term) are not really relevant any more. I think you misunderstood the information that you mentioned. My guess is that your nodes are operating properly, although maybe non-optimal. You probably simply don't understand some wrinkle in the expected network deployment procedures. The IPv6 represents return to the normalcy, auto-configuration is default, like it was in nearly every network protocol stack like DECNET, Novell, AppleTalk, etc. IPv4 was the odd one requiring so much manual settings.
I have been using and working on IPv6 at work in the last 5 years. And 3 years ago, my ISP provider deployed IPv6. So I am quite familiar with it and I understood enough about the settings related to that. What I would actually recommend is that you rent a Windows VPS for a short term evaluation, just to understand how it should be done. It somewhat pains me to be recommending Windows, but that is the reality: Microsoft did it right while most of Linux distributions screwed up.
This is really interesting comments There are 5 PCs in my home and none of them is using Window$ OS. I use Window$ PC at work as I have to. There are countless problems on Window$ in regards to IPv6 setup on servers and workstations in my office, which Microsoft certified engineers cannot even fix properly. There is no IPv6 related issues on Linux PCs that I cannot fix myself. I guess this discussion goes out of topic too far. |
|
|
|
On both my VPS' of Bitcoin nodes, I have a single eth0 interface with 1 IPv4 and 4 IPv6 addresses.
And my setup on IPv6 was initially "standard". But I thought that causes the problem on IPv6 Bitcoin node connections as the the outgoing packets use different IPv6 address than the IPv6 address used by the incoming packets which Bitcoin node listens to. That is why I made sure that Bitcoin only uses a single IPv6 address for both incoming and outgoing packets. But this turned out to be in fact an issue according to you.
I am not sure what you meant by "permanent" and "temporary" addresses. All IPv4 and IPv6 addresses on my eth0 are all permanent addresses. Perhaps the "temporary" address that you meant is the "link-local addresses".
This becomes more confusing than I expected. Unfortunately, there is no documentation related to this that I can find.
If you configured you IPv6 addresses by hand then your deployment wasn't canonical. The normal, expected way of deploying IPv4 is DHCP; the normal, expected way of deploying IPv6 is DHCP6 or SLAAC. The temporary and permanent IPv6 addresses are described in RFC 4941 http://tools.ietf.org/html/rfc4941 "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". There's plenty of tutorials available if you find reading RFCs too difficult. My guess is that your nodes are operating properly, although maybe non-optimal. You probably simply don't understand some wrinkle in the expected network deployment procedures. The IPv6 represents return to the normalcy, auto-configuration is default, like it was in nearly every network protocol stack like DECNET, Novell, AppleTalk, etc. IPv4 was the odd one requiring so much manual settings. What I would actually recommend is that you rent a Windows VPS for a short term evaluation, just to understand how it should be done. It somewhat pains me to be recommending Windows, but that is the reality: Microsoft did it right while most of Linux distributions screwed up. |
|
|
|
I set 4 IPv6 addresses on the /64 subnet that I got from my providers. But I use only 1 IPv6 address for the node and I made sure that both incoming and outgoing Bitcoin packets use that particular IPv6 address via ip route and iptables settings.
According to what you mentioned, does this mean we should not set 2 different IP addresses on a single Bitcoin node even they are on different network, i.e. IPv4 and IPv6?
If you have single IPv6 address per interface then your IPv6 deployment is somewhat nonstandard. The canonical way of deploying IPv6 is with at least two IPv6 aliases per interface: one "permanent" and at least one "temporary" that is changed on a regular schedule. The "permanent" is mostly for incoming connections, the "temporary" is mostly for outgoing connections. If you have man long-lasting outgoing connections (like e.g. Bitcoin, unlike e.g. HTTP) you should have multiple simultaneous "temporary" IPv6 addresses active on the interface. There are so many Linux distributions that I can't give you the specifics for yours. I happen to know that Windows do come out of the box with well optimized canonical IPv6 setup. However if you really want to understand what is going on locally with your node you will have to delve into reading the Bitcoin source. As far as Bitnodes they are not to be 100% trusted. They have been subject to Sybill attacks by people trying to game the node version statistics. They deployed some secret anti-Sybil and anti-DDoS code with the net effect that they undercount the real reachable nodes. This is a well known and well discussed issue with Bitcoin: the nodes really mean nothing without proof-of-work. So there's no easy, simple, obviously right way of counting Bitcoin peers. It really depends on the particular configuration of your machine as well as on the configurations of any possible Bitcoin peers using the same ISP as you. |
|
|
|
Bitnodes is quite buggy/unreliable, essentially I wouldn't count on it. I haven't kept exact statistics but my rough guess is that it undercounts nodes 25% to 75%, depending on the exact routing between their prober and your client. Also, Bitcoin client isn't working really well with IPv6. If the IPv6 address privacy is enabled (practically all Windows machines) it doesn't update its own "temporary" IPv6 address properly. Additionally if you have e.g. a laptop with both wired and wireless port on the same LAN (e.g. docking station to recharge) it doesn't properly pick up between multiple available IPv6 adapters and doesn't track the changes (visible via getnetworkinfo localaddresses). The general idea was that Bitcoin client is supposed to randomize its outgoing IP address usage to avoid constantly connecting to the same subnets. The code is a little weird, it avoids connecting to the same /16 subnet over IPv4, what it effectively does with IPv6 I did not analyze. But even with regularly changing IPv4 addresses (like vast majority of xDSL deployments, every 24 hours) it doesn't operate well, certainly is much worse than Bittorrent at locating and connecting to peers. |
|
|
|
|
Show Posts
