Bitcoin Forum
February 28, 2015, 12:40:17 AM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
  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 ... 76 »
1  Bitcoin / Bitcoin Discussion / Re: Block chain size/storage and slow downloads for new users on: February 21, 2015, 02:47:58 PM
A normal thumbdrive would be able to last quite sometime even with high IO usage. A few years is already considered long and flash drives would be much cheaper then.
"A few years"? More like "a few months" or maybe even "a few weeks". A database with write-ahead-logging is a perfect example of pessimal application for flash storage: lots of small writes, forced buffer flushes to permanent storage and never read back (unless the database application crashed).

If "normal thumbdrive" means the typical cheap drive with controller and wear-leveling optimized for FAT32 file system then I wouldn't be surprised if the device died even before the full current blockchain synchronization was complete (when formatted using any modern file system).
2  Bitcoin / Bitcoin Discussion / Re: Block chain size/storage and slow downloads for new users on: February 21, 2015, 05:05:25 AM
Flash media is ideal for that usage because it's cheap, has standard capacities similar to blockchain size, is efficient with random read-only access, and the blockchain copy can easily be updated from time to time with new blocks accumulated on the hard disk. That's also better for your hard disk health and availability.
Unfortunately the very high write amplification caused by bitcoind will also kill any flash device in a few years.

There's quite bit of work that needs to be done to safely run Bitcoin on a flash device for extended time periods. I'm not aware of any open-source flash-specific database engines.
3  Other / Off-topic / Re: The no ad-sigs posters allowed topic - come and not be annoyed by rubbish posts on: February 19, 2015, 08:27:47 PM
the poor people i spoke of dont have enough money and suffer mentally illnesses so they are not able to cook or buy food to cook - its just something i do to help.

in germany anybody can have enough money to get internet, tv, an apartment and something to eat - but some people (which are considered mentally ill by society) are not able to get it or use it the right way
OK, thanks for the clarification. I believe your observation must be specific to Germany or maybe broader to the Western Europe.

In some Asian communities (both in Asia itself and expatriates in other continents) there is an opposite correlation: poor people tend to spend inordinate amount of time and energy&fuel to elaborately cook their ethnic food, to the detriment of their children who are drafted to help. On the other hand reasonably well-off people tend to use quick-food or self-bagged cold lunches to be able to effectively participate in economy and education.
4  Bitcoin / Bitcoin Discussion / Re: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... on: February 19, 2015, 08:18:24 PM
Right now I wouldn't expect the peer-to-peer network to be stable with blocks much bigger than about 200MB, given current bandwidth limitations on most nodes. 
Are you talking about the legacy peer-to-peer protocol in Bitcoin Core or about the new, sensible implementation from Matt Corallo?
5  Other / Off-topic / Re: The no ad-sigs posters allowed topic - come and not be annoyed by rubbish posts on: February 19, 2015, 08:12:22 PM
i prefer the amount of warm food as an indicator for poorness - luckily i am a good cook Wink
Can you elaborate? Lots of warm food is poor or rich? I can't understand.
6  Bitcoin / Bitcoin Discussion / Re: Bitnodes Incentive Program on: February 19, 2015, 06:49:24 PM
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%.
7  Bitcoin / Bitcoin Discussion / Re: Bitnodes Incentive Program on: February 19, 2015, 03:02:24 AM
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.
8  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: February 19, 2015, 01:43:17 AM
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 Smiley   
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.
9  Bitcoin / Technical Support / Re: At home node with external systems needing info from it ? on: February 18, 2015, 11:55:06 PM
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.

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 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 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 Smiley
From the screen shot it seems you tried non-default ports. Why don't you try 8332 for starters?


That is the IP of your VPS, right?

Can you see your node on bitnodes? For example if you put your external IP in the search box here:

Check if the appropriate ports are open:
10  Bitcoin / Technical Support / Re: Any way to improve Bitcoin Core when operating in hostile environments? on: February 18, 2015, 05:17:03 AM
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!
11  Bitcoin / Technical Support / Re: Any way to improve Bitcoin Core when operating in hostile environments? on: February 18, 2015, 04:47:18 AM
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 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 .)

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 ). 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).
12  Bitcoin / Technical Support / Re: Any way to improve Bitcoin Core when operating in hostile environments? on: February 18, 2015, 03:07:00 AM
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?
13  Bitcoin / Bitcoin Discussion / Re: Permanently keeping the 1MB (anti-spam) restriction is a great idea ... on: February 17, 2015, 05:01:09 PM
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.
14  Bitcoin / Bitcoin Discussion / Re: Here's why bitcoin will be bigger than the internet on: February 13, 2015, 12:52:28 AM
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.
15  Bitcoin / Bitcoin Discussion / Re: Here's why bitcoin will be bigger than the internet on: February 13, 2015, 12:45:17 AM
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.

16  Bitcoin / Bitcoin Discussion / Re: Bitcoin 20MB Fork on: February 12, 2015, 12:17:39 AM
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.
17  Bitcoin / Hardware / Re: BFL fucked us over again on: February 07, 2015, 05:36:09 PM
But I would be quite pleased in your shoes; since they haven't payed you yet and they cannot provide proof of cet payment I would pass this letter to a "no-cure-no-pay" collection agency... Then - after collection of cet $822,898 I would be happy to pay the due taxes... Grin
This isn't how the scam works. The usual route would be that they've opened a bank account using Bruno's credentials but without Bruno's presence. This is done using power of attorney or similar procedures required to serve elderly or sickly people. The money was then really paid to that account in Bruno's name and went out of it as a payment for various services (like uninsured's medical care, remodeling to adapt living quarters for disabled, etc) in the actual area near to where Bruno lives.

This is roughly the procedure perfected by the Russian mafia to launder their money, except that the Russians usually find genuine elderly & sickly people and do provide some minimum charity/help to better cover up the whole operation.
18  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: February 06, 2015, 03:34:29 AM
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.
19  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: February 06, 2015, 03:24:52 AM
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.
20  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: February 06, 2015, 02:48:09 AM
^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.
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 ... 76 »
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!