Seed Ratio: 1809 Current Bandwidth: 650kB/s Connected to 5 peers
I was going to shut my seed down but I won't just yet.
|
|
|
My seed ratio is up to 681 now. If anyone wants to setup seeders the cheapest way I found was on a AMD Athlon 64 5600+ X2 at https://robot.your-server.de/order/market . EUR 25 a month for a dedicated machine with serious bandwidth. Setting up transmission-cli under screen isn't difficult.
|
|
|
I've been seeding the new torrent for 2 months now on a well connected server and have a seed ratio of 548. That's about 12 TB uploaded by one server in 2 months. I'm wondering if this is all due to people setting up full nodes, or if something else is happening here.
If you are a long term seeder are you getting similar results?
|
|
|
your age : 53
status : Employed as President of the United States of America
how much you earn a month : Officially $33,000 a month. Unofficially around $500,000 a month plus all living costs are covered.
Seriously, no-one sensible will answer your questions honestly.
|
|
|
Who cares about some arbitrary "ratios" displayed locally in a client?! What matters is how much you actually do upload...
The only thing that really matters is that anyone who wants the data should be able to get hold of it as fast as possible. The more bandwidth we have seeding the better but if anyone really can't seed they should not feel bad about it. It's not an obligation.
|
|
|
Like I mentioned already, as it is right now, it seems to be more suitable for geeks (preferably with a second computer). It shouldn't be like that. It should be also for the average user.
The thing is running full nodes really is for bitcoin geeks. We want as many people running them as possible but the fact is that it's just not the right solution for most casual bitcoin users who just want to use bitcoin rather than run the infrastructure behind it. The right solution for you is Electrum, Multibit, or some other light client. They still do the signing on your hardware with private keys only you have access to, so they really are as secure as a full node. I don't know why Electrum doesn't work for you, I thought it was quite reliable on windows.
|
|
|
I agree keeping the process automagically performed is better for new users.
Absolutely. Using a torrent at all is a hack and a (small) barrier to entry that should be removed if possible. But if using a torrent is the current plan I can throw bandwidth at it. There seem to be more downloaders than seeders on the new torrent right now. After changing torrents I'm downloading at 0kB/s and uploading at 1 MB/s.
|
|
|
Is it possible to patch the memory allocation bug manually, in the previous version of electrum-server? I attempted to update to the new version but ran into problems, including permission errors.
I really think what this project needs is a release cycle. The version on github is a development version. That's fine but we are going to get frustrated if we try and use it as a production version. I gave up running the new server, if there was a stable tag I would have gone back to that. I did think of taking a known good version, scripting all setup, and putting it in a docker container. That way setting up a new server would be as easy as 'docker run blahblah/electrum-server' and waiting until it set itself up.
|
|
|
I fixed setup.py yesterday.. let me know
I get different problems now. zipimport.ZipImportError: bad local file header in /usr/local/lib/python2.7/dist-packages/electrum_server-0.9-py2.7.egg
This apparently means there is a syntax error somewhere, possibly python code that only works with a higher version. The error message makes it look like a ZIP error, which it isn't. If I run 'python setup.py install' again it seems to work and it seems to run. I can't connect but that may be because it's updating. I really need to test this on a clean machine.
|
|
|
Give Thomas few days, it is completely new version of the server  I will install it soon and I might be able to improve the docs. I got it running with some minor hacks. I didn't see any tags in the repo. Release tags might be a good idea so if something doesn't work I can just go back to the last tag. EDIT: Actually, no I didn't get it running. It's choking on a futex.
|
|
|
Thomas,
You put a lot of great work into Electrum but it's all a bit lost if people can't easily get the server running. Can you update the install instructions? Right now HOWTO.md references start and stop scripts that don't exist. The TLDR section at the top of INSTALL doesn't result in a running server, nor do the full instruction in that file.
I tried to do it myself and send a pull request but I've no idea what the instructions should be. Whatever I try 'python setup.py install' won't install the src module on ubuntu 14.04 so electrum_server.py won't run. It was all working so nicely until I upgraded.
If you want people to run servers it should be as easy as possible for those guys.
|
|
|
And lose my seed ratio of 115!? I suggest some of us keep seeding the currently live version until the demand for it drops off.
|
|
|
I'm running the most recent electrum server from GIT. The logfile seems to be missing blocks, is the following normal? [25/07/2014-20:48:22] blockchain: 312457 (82.964s) [25/07/2014-20:58:35] blockchain: 312458 (194.778s) [25/07/2014-21:02:21] blockchain: 312460 (128.478s) [25/07/2014-21:10:27] blockchain: 312462 (250.398s) [25/07/2014-21:16:38] blockchain: 312463 (166.109s) [25/07/2014-21:22:49] blockchain: 312464 (212.260s) [25/07/2014-21:51:48] blockchain: 312466 (670.598s) [25/07/2014-21:56:06] blockchain: 312468 (168.989s) [25/07/2014-22:04:08] blockchain: 312469 (166.773s)
Why do I not get a log message for every block?
|
|
|
Would be too much to ask if they added like, not daily but maybe weekly updated blockchain file? Everytime someone new comes to Bitcoin, the first thing they say is how much of a pain in the ass it is to sync, unless they are using 3rd party wallets that is, but im too used to the simple niceness of the classic wallet to change  There isn't a 'they', there is only an 'us'. If you think it should be done then do it. I was going to but my tests showed that using a bootstrap file doesn't load data into bitcoind any faster than pulling the data from the live network for blocks beyond 295000. The recent blocks seem more complicated than earlier ones. Maybe a bigger bootstrap file would still be useful to some people. I really think that most users should be using a light client like electrum anyway. Interested companies, organizations, and technical users should be running the full nodes, not every guy who wants to make small purchases.
|
|
|
One flaw in your test...
I didn't go into exact details about how I tested because discussions like this tend to never end. If there was a significant advantage or disadvantage to using the torrent I think I would have seen it. Please do treat my results with scepticism and test yourself.
|
|
|
The verification speed when verifying blocks past the latest checkpoint is far slower than getting the blocks from the network usually.
Experimentation being the basis of science I tested your theory. I used a AWS m3.xlarge with a 60GB SSD block device for the bitcoin client. I created a bootstrap.dat for block 305000 and compared the time it takes to update from block 295000 to 305000 via my bootstrap.dat and by pulling blocks from the live network. It turns out you are right. Time to update from 295000 to 305000 with a custom bootstrap.dat: 3845 seconds Time to update from 295000 to 305000 by connecting to the live network: 3848 seconds As a 3 second difference on a 1 hour load is meaningless I can only conclude there is no reason to update this torrent. I'll keep throwing bandwidth at it.
|
|
|
After checkpoints there is little need to get data from a torrent file instead of the network itself, since it is likely a CPU or disk IO bound operation, not network speed.
Also with this other torrent file, there is no way for me (other than downloading the whole file and decompressing it) to recreate + verify it locally.
Network speed is an issue, that's why we are using a torrent. There are currently 14620 blocks between the end of this torrent and the end of the blockchain. Bitcoind should download about as fast as torrent does, but sadly it doesn't. Bitcoind verifies this data when it imports it, just like when it verifies data it pulls off random network nodes. The only possible attack is a 50%+1, and if an attacker could pull that off they would do it on the main network, or more likely they would just mine half the coins instead. EDIT: For clarity
|
|
|
I'm not going to seed some random stranger's torrent, sorry.
If you connect a full node to the bitcoin network you also download data from random strangers. As I understand it the data in this file is subjected to exactly the same checks as data downloaded by the bitcoin client itself. Should the data be misformatted it will be rejected. If some of the end blocks got reorganized the client will sort it out once it connects to the network proper. Of course you are right to be paranoid but I don't see the need for this torrent to align with checkpoints in the code itself.
|
|
|
It's working great now. It looks like it was either a DDOS or a cloudflare freak-out.
|
|
|
Is bitcoin.de down? All I get are endless cloudflare CAPCHA's.
EDIT: Wow, I had no idea cloudflare could be so annoying.
|
|
|
|