Bitcoin Forum
February 06, 2016, 11:33:15 AM *
News: Latest stable version of Bitcoin Core: 0.11.2 [Torrent]
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 91 »
1  Bitcoin / Mining speculation / Re: Bitfury Containerized Plug and Play Datacenter on: February 05, 2016, 10:50:55 PM
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.
2  Bitcoin / Technical Support / Re: Slow synchronisation - on: February 05, 2016, 10:08:27 PM
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.
3  Bitcoin / Bitcoin Discussion / Re: Bitcoin and ECC memory on: February 04, 2016, 05:18:38 PM
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.
4  Bitcoin / Bitcoin Discussion / Re: Is it good or bad that Core development is virtually controlled by one company? on: February 04, 2016, 04:29:53 PM
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.
5  Bitcoin / Mining speculation / Re: Bitfury Containerized Plug and Play Datacenter on: February 02, 2016, 10:41:01 PM
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.
6  Bitcoin / Hardware / Re: Bitfury: "16nm... sales to public start shortly" on: February 02, 2016, 09:38:54 PM
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.
7  Bitcoin / Mining speculation / Re: Bitfury Containerized Plug and Play Datacenter on: February 02, 2016, 09:28:27 PM
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
8  Bitcoin / Hardware / Re: Bitfury: "16nm... sales to public start shortly" on: February 02, 2016, 06:18:23 PM
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.
9  Bitcoin / Mining speculation / Re: Bitfury Containerized Plug and Play Datacenter on: February 02, 2016, 01:23:19 PM
Allied Control is not "other people". Bitfury acquired Allied Control some time ago.
10  Bitcoin / Hardware / Re: Bitfury: "16nm... sales to public start shortly" on: February 02, 2016, 06:25:10 AM
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.

11  Bitcoin / Hardware / Re: Bitfury: "16nm... sales to public start shortly" on: February 02, 2016, 03:47:22 AM
90% yield?  Cheesy Roll Eyes
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.

 
12  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: February 02, 2016, 03:30:55 AM
Salient Point. For those of intrest in why -

https://www.reddit.com/r/Bitcoin/comments/43qisj/paul_sztorc_on_twitter_it_seems_that_mircea/czka9we

My guess is that MP ego far exceeds his ability and it wasn't widely discussed ... although the lack of comments correcting MP is of concern.
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.

Quote
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? Smiley

 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
Quote
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.

13  Bitcoin / Development & Technical Discussion / Re: Wondering out loud: Which should Chinese miners support - Core, Classic or another? on: February 02, 2016, 01:10:45 AM
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. ↩
14  Bitcoin / Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: January 31, 2016, 10:51:18 PM
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 Smiley 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.
15  Bitcoin / Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: January 31, 2016, 09:03:00 PM
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.
16  Bitcoin / Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: January 31, 2016, 07:00:24 PM
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.
17  Bitcoin / Technical Support / Re: Bitcoin full nodes with IPv4 and IPv6 - Why most peers are on IPv4? on: January 31, 2016, 06:18:26 PM
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.

18  Bitcoin / Hardware / Re: Bitfury: "16nm... sales to public start shortly" on: January 31, 2016, 07:36:05 AM
I get fed up saying this but people should read a lot more before shooting their mouths off. No one has laid a chip out by hand since the late 1970's - probably about the time your parents were born. This statement was just another piece of bullshit from Bitfury trying to make their chip sound 'special' in some way.
I, on the other hand, would put this to a combination of "figure of speech" and "language difference".

https://en.wiktionary.org/wiki/%D1%80%D1%83%D0%BA%D0%BE%D0%B2%D0%BE%D0%B4%D0%B8%D1%82%D0%B5%D0%BB%D1%8C

One way of translating English "director" to Russian would be "руководитель", which in turn translated literally back to English would mean "the one that leads by the hand". In many Slavic languages the equivalents of English "by hand" and "manually" have much wider, figurative use. For example the title of this old thread https://bitcointalk.org/index.php?topic=49971.0 "Algorithmically placed FPGA miner" could be translated to Russian and back to English as "Hand tailored (or Hand cut) FPGA miner". Somewhat more humorously, some not-that-well translated software documentation uses the above Russian word for the "device driver".

Even native English speaker constantly communicating with bilingual or multilingual people will subconsciously pick up their speech patterns and figures. My favorite example is: the equivalent of English "all thumbs" in several other European languages is "two left hands". Both of those phrases aren't meant to be literal, they are just figures of speech describing a person lacking in manual dexterity.

So my guess is that the PR blurb-writer picked up this hyperbole from the native speakers of Slavic languages who only know English as their 2nd language.

Edit: I've forgotten to add that the in my favorite example to cognitive adaptation is not only linguistic but also involves the associated hand gestures. The "all thumbs" is gestured by curling 8 non-thumb fingers at the knuckles to match the length of the thumbs. The "two left hands" is gestured with showing both hands with thumbs pointing to the left.
19  Bitcoin / Project Development / Re: Indexing technology used on BTC/altcoins on: January 31, 2016, 01:26:54 AM
Man, that is really a very uneducated and unwarranted attack. My background is in high performance memory based database systems. I am questioning whether a fully fledged database system is really needed in preference to a more optimised data storage structure more suitable towards blockchain technology. At no point have I suggested the use of a serious DBMS, quite the opposite. I was simply tying to get an understanding of the technology requirements. I would seriously question why a system requires over 6 GB/s of disk writes to secure less than 132 MB of data, and why I simple computer crash requires a complete rebuilding of the blockchain index. There is possibly great potential to improve in this area, but without understanding the full requirements I cannot state there definitely is.
Man, I'm sorry to have stepped on your toe. You really seem to have proper technical outlook on the issue. But you seriously lack in the "street smarts" department. The salespeople must love you. You just telegraphed your insecurity in the first two sentences.

In case you didn't read my first post: I haven't questioned anything technical in your observations. You just missed the proverbial forest for the trees. There are multiple areas in which the Core Bitcoin client has "possibly great potential to improve". But very few people care, the issue is about who has the control of the direction of the project. The existing bugs and deficiencies are carefully maintained through the code pulls to preserve the future opportunities for soft forks.

Couple of years ago I had to quickly help a friend with reviving his ailing Windows machine. Every hour counted, we decided to buy the required discrete graphic card in the nearby mall's store catering to computer gamers.  Unfortunately we hit it during really busy time, the checkout line was over 1 hour. During that time I learned that many average teenage boys have good handle on the politics of various 3D graphics APIs (e.g. Microsoft DirectX vs. OpenGL) and various quirks of how they affect games releases, prices, platform availability, etc. They were quite "street smart" despite shopping in the typical mall under watchful eyes of their parents.

Edit: Since your background is in high performance memory based database systems, here's the idea: open a new thread about replacing mempool with a general memory-based database. Stick to the technical benefits. And then watch the comments flow about how not using a sensible database for mempool is crucial about maintaining the security of Bitcoin. Maybe that will open your eyes to what is really going on here.
 
20  Bitcoin / Project Development / Re: Indexing technology used on BTC/altcoins on: January 30, 2016, 09:42:30 PM
Man, you seem rather nave. The non-use of serious database technology and deep enmeshing of educational-toy database engine (LevelDB) into the Core client source code are the key ways maintaining control of the project within the small core team.

It is kind of article of faith and a way of keeping the anarchist spirit of the project: if you want to use a serious DBMS you are a corporatist shill and a bankster bent on taking control of the project from the people!

Also, don't even think of abstracting the storage layers used by Bitcoin Core! Look at what happened to etotheipi and his company when he decided to switch.

Edit: The Core Team has actually achieved the holy grail of billing-by-the-hour software consultants: they included their own fork of LevelDB into the Core and maintain it separately from the Google's one.

Another issue is during a computer crash, bitcoin core frequently requires a full database reindex. This is bad now, and will become an absolute unmanageable nightmare as the blockchain grows.

So does Bitcoin really need to use a fully fledged database system? If not, a specialised data structure could be the way forward. Period local syncing of last known good blocks would mean in the event of failure, a full reindex would not be required; it would simply redownload blocks from the last sync point on recovery. This would also keep small disk writes to a minimum, using periodic linear disk writes instead.

I think there needs to be improvements made here, and depending on the requirements there could be the potential for significant performance and resilience improvements.
Based on a 22 hour catch up, that would be 1MB * 6 * 22 = <132MB average block data.
Running on SSD write enabled cache, catch up took over 2.5 mins, with writes in 25 - 55 MB/s range. Maybe 40 MB/s on average. So as a rough guestimate we are talking over 6GB of disk writes to catch up on potentially 132MB of data. A lot if users with mechanical disks do not want to run a full node now, and it is the catch up time rather than network bandwidth and storage space which is the biggest issue for some.
Does bitcoin core use a full database implementation, or just implement the indexing technology?


Sorry if this topic has been covered before or is in the wrong place, but a search brought back a lot of results.

One of the important design goals of bitcoin is decentralisation. However, running a full bitcoin core node is proving very heavy on the average users PC.
The block size is only 1 MB, produced once every 10 mins on average. This really is not a lot of data to write to disk, and most users have the capacity to store the block data.
When I am catching up on the block chain, I am finding huge amounts of disk writes, magnitudes in excess to the actual data being downloaded. This leads me to believe that it could be the indexing technology that is causing a lot of disk data reorganisation. Is this the case?
I would have thought that the block chain indexing requirements should be quite simple, being rather linear apart from a few forks. Performance could be improved significantly by index technology dedicated to the task. I would look at a virtual memory mmap solution.
Are there any developments in this area?


Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 91 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!