i prefer the amount of warm food as an indicator for poorness - luckily i am a good cook  Can you elaborate? Lots of warm food is poor or rich? I can't understand. |
|
|
|
Just because a lot of nodes happen to be in a single ASN doesn't indicate 'centralization', though. Well, that is, unless you think the people at Hetzner/OVH/Digital Ocean/Linode/Vultr/whatever else are plotting some scheme.
I guess I should also say I have an issue with the daily uptime index, since mine says '0 ms' sometimes, it counts it as being down.
Well, as far as Bitcoin node protocol this is centralization. Bitcoin attempts to spread the outgoing connections by avoiding those addresses that are "close" with regard to IP netmask, it has no access to BGP/ASN tables. Bittorrent does a different decentralization by computing node priority as some sort of hash of IP/port, which is somewhat more tolerant of peers with nearly sequential IPs. Given the current protocol rules I'll say that de-weighting by ASN is a decent attempt at approximating a measure of decentralization. Interestingly I also have latency spikes down to 0ms, but my node's uptime shows 100.00%. |
|
|
|
it'd help if the scoring method wasn't crap, specifically the "ASN index"
It would be crap both ways. "ASN index" weighting tries to promote decentralization. I remember one Bittorrent statistics gaming service that used to run on a single server with the whole "Class C subnet" with 254 IP aliases. It is hard to come up with a really truthful statistics without actually downloading the data from multiple locations around the globe. |
|
|
|
Wonder if Mark A Lowe paid Federal and State income tax on that 3000 BTC like he is obligated to do at the value the DAY HE RECEIVED IT? It does not matter if the value went down later you know. First you have to report the income at that day's settlement price and then if you do not sell and lose money, you have to report that as a capital loss.... Does the IRS have to pay the 15% finder's fee when you report individuals that have perpetrated fraud against the treasury? Or is that only upheld when you turn in companies? I think it includes individuals too since those doctors that got busted had their staff collect the "reward" right? Does California offer finder's fees too? I know it is only $353,000 but given his tax bracket he owed over $170,000 of that to the government. Surely, he reported it right? If not, looks like someone is going to jail  I sure hope he reported it, because once CA or US Treasury finds tax fraud, they can audit all the way back to infinity (the three year rule goes bye bye). Hope he did the right thing OR that he has some good information to trade. This is kinda shortsighted. I believe cypherdoc is an actual licensed medical professional (optometrist or some such). One of the conditions for the license is "good moral character". If you could find somebody who was his patient and whom he sold Hashfast miners that would be pretty much open-ended malpractice liability. You guys should really get some tort lawyer take a look at this case. An active insured medical practice in California could continue to pay damages for many years. No need to settle for measly percentage of a single payment. http://digitalcommons.pepperdine.edu/cgi/viewcontent.cgi?article=1117&context=naalj |
|
|
|
What a stupid advice! This is just a hackers dream: hosted web server that has address, username and password to the machine holding the hot wallet! I'm just going to record for the future reference the two advice givers before they delete their posts. FYI: this needs to be done backwards: the home machine polls the hosted web server's database for any transactions that may require attention/servicing by the Bitcoin client. The web+database server should never have that information stored anywhere. And the home machine should never allow any incoming connections. In fact the home machine probably should explicitly beep and ask the user at home to approve any transaction above certain safety threshold. Hello 1-As others pointed set rpcallow=your_vps_ip and rpcport=desired_port, reboot bitcoin. 2-If you have a dynamic IP (you can use it if you have a static one too) use any service like no-ip.com(free) and set it up properly so it redirects your IP to a domain (it may take some time to propagate trough the internet). 3-Go into the router admin panel and open the desired_port (note that you may need to forward the connections into the LAN IP of your rpc server(ipconfig)). 4-Reboot router. 5-Use any service like canyouseeme.org to check if the port is actually open (opening router port's can be tricky sometimes). 6-From this point you can connect from you VPS to your local RPC server, across the internet. Hope this helps |
|
|
|
As stated the slowdown started at least mid last year and upgrading to 0.10.0 hasn't changed anything noticeably in that regard.
For certain using UDP for VPN basically stopped working a few months back (after further "upgrades" to the GCF).
I think probably the best bet for now would be to run locally (not tunneling) with a list of seed nodes within PRC (if any networking expert plans to come to China for a holiday maybe they could have a play "from the inside").
Look, without you posting packet traces nobody's going to help. People who actually come to China for a short stay tend to use the hotel ISPs where problems like yours are impossible to reproduce. General growth of traffic in China is so high that every couple of months people there do experience problems purely from more competition over the limited resources. Grab some packet captures and post it! You are an experienced programmer not some random newbie! |
|
|
|
Bitcoin testnet seems to actually work much better (but that maybe simply due to much less traffic).
In general it appears since the latest "upgrades" to the GCF your choice of port matters little. Even my client is now having troubles running a (plain HTTP) web-server (and they have tried using numerous different ports).
For HTTPS that goes "outside" of PRC all traffic appears to be throttled (and often sessions get killed) and within China is basically restricted to certain fixed IP addresses.
Bitcoin traffic appears to have started to be targeted by the GCF around mid last year (although I can't remember for certain exactly when I noticed how slow syncing had become).
Without sample packet captures/traces (with the true IP addresses zeroized) nobody's going to help you much. I no longer have access to the front-end routers/statistics at my corporation, but from the little I see in my department there is an ongoing plague of disabling proper http://en.wikipedia.org/wiki/Path_MTU_Discovery together with more and more of Internet hookups supporting less than default MTU (less than 1500). This is done to supposedly protect against DDoS attacks (PMTUD uses ICMP Fragmentation Needed packets). Bitcoin is particularly badly affected by this issue (slowdowns because of MTU too high) because it is tuned to using very large TCP socket buffers and also tends to send humongous amounts of data without any high-level handshaking (unlike e.g. Bittorrent). By the way: how is Bittorrent working for you? Both with UDP transport enabled (best case) and with UDP transportdisabled (to make it more like Bitcoin P2P)? (I'm not talking about udp:// or dht:// trackers, I'm talking about peer-to-peer transport using http://en.wikipedia.org/wiki/Micro_Transport_Protocol .) Finally, did the slowdown started occurring after the 0.10.0 release? I've noticed a great increase of incoming connections from that release on my nodes and my upload bandwidth throttles started triggering all the time after that release. There is apparently Bitcoin-network-wide 0.10.0 abuse going on both on mainnet and even on testnet since last few hours. Edit: To quantify the last paragraph: My nodes average latency was about 200ms (as shown by https://getaddr.bitnodes.io/ ). Since 0.10.0 went public it started peaking above 2000ms, I had to reduce the number of allowable incoming connections and change QoS settings to get it back down). |
|
|
|
Tunnels work but are "slowed down" to the point of 9600 baud in general (as soon as the traffic goes outside of China). The GCF *detects* encryption and either "kills it" or "slows it down to a snail's pace" (I have one other way around it but I am not going to publish that).
We had some of our employees move back to China (rural mainland, don't remember the details) and he had continued to use our tunneling VPN setup. We were using IPsec AH-only (not the most common ESP). This is a VPN technology that doesn't use encryption (Encapsulating Security Payload) but only authentication (Authentication Header). There wasn't any overt blocking or slowing down of our traffic, besides the usual problems one would encounter anywhere with the rural DSL provider. IPSec AH is fully supported in Windows since XP, other OS-es supported it even earlier. It is also well supported by the very cheap Netgear Prosafe VPN/firewall devices, we've used FVS114 and FWAG114. Those are "business class" but have "home/residential" prices. Now they are officially obsoleted, don't know the replacements, but we still have them deployed and in use in many locations. If you want to try it: do test this first on a LAN between two computers and then between same two computers over the same local ISP. Only after those tests are successful try intercontinental tunneling that could be really affected by the Chinese government censorship. AFAIK there are no commercial providers for the AH-only service, you'll have to have your own tunnel exit somewhere in your homeland. My information is couple of years old, Bitcoin did exist then, but probably wasn't an issue. Aside from the regular business use it was used (and it was helping unthrottle) with Bittorrent. Edit: Also, please post some additional information regarding what you are observed as being blocked/throttled: 1) Bitcoin mainnet vs. Bitcoin testnet 2) incoming vs. outgoing connections to/from TCP port 8333/18333 3) does the non-coin-related TCP/IP traffic over the same ports flow properly? |
|
|
|
I, for one, would recommend avoiding all fancy logic for an adaptive block size; just set the maximum block size to the API maximum and be done with it. I also recommend hurrying up to figure out the code to fragment/reconstruct blocks bigger than that.
What is the point of this? The contiguous "block" is just an artifact of the current implementation and will soon be obsoleted. On the storage side the database schema will change to support pruning. On the network side the protocol will be updated to support more efficient transmission via IBLT and other mechanisms that reduce duplication on the wire. In both cases the "blocks" will never appear anywhere as a contiguous blobs of bytes. |
|
|
|
I can't see other way of scalability other than using internet
That you can't see is your problem and your limitation. People who understand the technology actually know that Bitcoin protocol is somewhat inefficient emulation of a global broadcast medium using peer-to-peer gossip protocol. Immense amount of bandwidth and energy could be saved by the technically more advanced use of the well known broadcasting and multicasting media. |
|
|
|
You need internet for Bitcoin to work. By definition, Bitcoin cannot be larger than the internet.
That is actually wrong. Only the current implementation needs Internet. In Finland somebody is already broadcasting the blockchain and transactions over a subchannel of the terrestial TV signal. Jeff Garzik (IIRC) was working on a satellite broadcasting of the Bitcoin blocks and transactions. One could send own transactions to the uplink center for broadcasting via a slow POTS modem, carrier pigeons carrying microSD cards or even printed as a QR codes on a postcard. So the Internet requirement is just a current implementation restriction. Edit: couple of years ago we were discussing here multicasting via a moon bounce (EME). Search for it. |
|
|
|
Oooohkay. Let's consider the effect of a client that accepts and will cheerfully create >1Mb blocks.
Let's say I take a standard bitcoin client (client A) and create a new one (client B) that doesn't have a block size limit. And then I start mining using client B.
Nice analysis, but you omitted the influence of the version field change in the client B. I believe the whole rigamarole with that field is to lock the client B onto the new chain, although I haven't analyzed the details and considered all the possible attacks. |
|
|
|
It would be worth it to me, 5% improvement in efficiency when its hard enough barely breaking even... is all the difference.
I don't want to disagree with you. I just want to give you a different perspective. You probably discounting your per hour work time charge to some very low rate. I presume that the industrial-scale miners will not be able to hire highly conscientious people like you to run their operations. Their employees will be more like Bruce Peterson of the BFL's burn-in-room fame. |
|
|
|
But is it worth it? How much would you gain? If it's less than 5% then it's not such a big gain...
"Worth it" to whom? To GenTrakin personally or to the Spondoolies' Corporation and their future industrial scale mining operation partners? 5% may be nothing to a piker but the same 5% yield improvement at the industrial scale means megabucks. |
|
|
|
^I think you are making a trivial issue into a major product fault that it isnt.
The Sp20 is already leading-edge for efficiency, and while theres a little space to improve efficiency with a little bit finer tuning processes, it might only be by 0.02-0.04w/GH
I think that you are wrong. I'm following this thread from the beginning and observed a very rapid release cycle with multiple regressions which is indicative of the developers thrashing around without understanding what is going on with the product in the field. I also noticed multiple user complaints about things like "entire ASIC loops disabled by BIST". I believe zvisha has already discovered a while back that GO/NO GO BIST that he had inherited from the Spondoolies' hardware designer is counterproductive and overly cautious. The use of BIST (in the field) should be completely abandoned now, it could be still valuable in the factory or in the pre-final-assembly stages. I don't know what is the internal personal dynamics of Spondoolies as a corporation. Does zvisha have enough inside clout to say NO! to some rather trivial support requests via Skype/ssh/Teamviewer? Can he influence the hardware designer to give him more information from the chip that just a single go/no-go bit and a temperature? What is required now is not more of "finer tuning". There's a need to step back and do some real research and appraisal of the entire field and how it is changing to more and more unattended operation. The cute "Thank you for the personal attention!" notices from the customers may be pleasant now, but they are actually indicative of the production problems in the factory. |
|
|
|
Edit: What they said ^ I think the above was just Spondoolies-Tech's slightly unsubtly way of saying: Hey, our software is open source. Here's our git repository. Feel free to fork it, make changes - such as the suggested Nelder–Mead approach for N-dimensional optimization, and submit pull requests, and we'd be happy to review the changes and possible integrate them into our baseline - or you can provide your own custom builds for users who would be interested in it. Code repositories are generally not intended for end-users My not so subtle response to this: Spondoolies hired a single junior/young software developer who had landed far out of his depth with regards to state-of-the-art of the optimization of rather complex analog/digital system. His attempts at one-dimensional optimization problems when searching for the optimal configuration parameters show that he isn't aware of http://en.wikipedia.org/wiki/Golden_section_search known since mid-1950 or mid-1960. And various folks here already started to request optimization in 2 or more dimensions. This is going to end up rather badly with regards to the software quality when the corporation gives his lead developer no time to actually research the problem space. Instead they gave him a mishmash of tasks from the request list that are rather trivial and cosmetic. So my friendly advice to zvisha is: step away from fulfilling trivial maintenance requests and broaden your knowledge with a quick peek into gradient-free/derivative-free optimization methods that I've mentioned. The payoff to him (personally) and the company and its user base will be much higher. My not so subtle advice to Guy: you'll need to give time to your staff to do an actual research as opposed to bogging them down with constant development and maintenance requests. Your company's current work on finding the optimal operating point for your miners is equivalent to the state-of-the-art around World War II. Either give zvisha some time off of D and let him concentrate on R (from R&D) or hire a actual mathematical optimization consultant. This should be quite easy in your location in Israel. I actually don't care if you open source it or keep it as a closed-source module that controls the cgminer through its API. You could probably then charge extra for it or differentiate your product from the competition in marketing. The above was a free advice. If you don't like it just ask and I will give you a full refund of the money paid. |
|
|
|
in my opinion if you limit both max power (too low) AND max voltage, then the machine cannot optimize chip voltage properly and is run (at least sometime) sub-optimally.
You guys should pressure Zvisha and Spondoolies to implement a proper gradient-free multi-dimensional optimization method in their software: http://en.wikipedia.org/wiki/Nelder–Mead_methodDo not reinvent the wheel! |
|
|
|
This is a very important point. mircea_popescu: it was highlighted by intel about two weeks ago, and we're generally tracing it to philippines "top quality" content farms working for a number of (mostly ct and wash based) pr firms.
mircea_popescu: wasn't goping to say anything, but since it's public now.. I don't really understand your (nor Mircea's) point. Are you trying to say that some overt Bitcoin supporters are plants from PR companies doing positive astroturfing/Bitcoin brand amplification? Not just the standard negative trolling of style similar to the Something Awful? |
|
|
|
I can only talk about what I have personally tested:
Cabletica, ICE, Kolbi, Claro, Moviestar all need to be called and asked to open this port.
I have to call to open many ports blocked by default for BTC or other uses like CCTV.
I also see many other posts around the world making the same complaints.
Eh, all in Costa Rica and seemingly none of them have support for English-speaking customers. This isn't a representative sample of the worldwide Internet. And by a margin so wide that it makes your statement laughable. From my experience trying to support the use of Bittorrent (both commercially and individually) and various RPC stacks (commercial support for home workers) I can say that the "complaints" don't equal the real ISP problems. Only somewhere between 1% and 5% are the real provider-caused blocking/interference/mishandling. The remaining 95% to 99% is on the customer-caused misconfiguration or hardware/software faults. |
|
|
|
I'm just quoting two examples of building conspiracy theories on the lack of understanding of the ISP technology. If and ISP blocked a particular port, one would get zero connections on it. It would not surprise me at all to have a max cons set by and ISP. That would explain the why one has difficulty. Each connection uses network resources in a router (yours and your ISP's respectively.) This is what drives me nuts about ignorant people making simplistic calculations of capability based on the download speeds (which are artifacts of a marketing department usually anyway.) Ya, you might be able to get some decent percentage of a pipe in use but only by using multiple streams, and that is particularly the case with TCP on a wan. Anyone who has tried to SCP a large file can tell you this. Nobody is going to be thrilled about Joe Sixpack using a thousand sockets, and crappy consumer grade routers will have difficulty. Probably max-cons is set by the ISP to throttle those trying to do torrents. Same trick here. This certainly illustrates the point I'm making about being at the mercy of network infrastructure providers. IIRC it's even less than that by now. Anyway, I don't have to guess about why this is. It's obviously because for some bizarre reason Satoshi didn't choose to reward transfer nodes in his implementation. Why I have no idea. It's one of the strongest observations supporting the hypothesis that Bitcoin was designed to fail (or at least become centralized and under control.) Not that I believe this to be true, but it is one of the many hypothesis that I continue to hold open. Probably he just ran out of time and patience. If he was ignornant enough to not forsee the difficulties with the block size hard-fork then he may also have imagined that transfer node rewards were something that could be tacked on later. This user is currently ignored.
Save the end of the world prophesies for the speculation subforum please. We could try a proof of troll system, keep randomly saying the same thing over and over and every time a new variation is found its a new block Noticed the same with the ISP's, Ireland's really lax on internet rights and there's lots of weird stuff going on, outages followed by slowdowns on certain sites, everything loading fine except images taking ages, that kind of thing. Obvious what's going on, lots of sites seem to be going offline lately, nothing big but a lot crypto related. Have to get back onto my ISP again now, hadn't realised they'd blocked 8333 again. Second time they've done that, will have to tunnel out to a VPS. That's what the dumbasses don't get, that which doesn't kill us makes us stronger. Anyone can name an ISP that blocks outgoing TCP/IP connections to port 8333? And where such a block isn't a voluntary one (some sort "Internet safety" option) and the unblocking isn't a self-service "turn it off" checkbox? How about incoming TCP/IP connections to port 8333? And where such a block can be lifted and isn't a technical restriction stemming from the use of CG-NAT or DS-Lite? |
|
|
|
|
Show Posts
