Why Run the Bitcoin Client?

[tvbcof]

I run one because it is the only worthwhile contribution to the network that I can easily make at this time (other than trying to soak up some of the currency inflation.)

It's great that people do this but depending solely on self-sacrifice to maintain the network is unreliable, especially since it will become more expensive to maintain relay nodes as the transaction volume increases.

I actually potentially dis-agree.  If a worthwhile system needs merely a couple thousand generous benefactors, it is entirely likely that they will be reliable (given the size of the worlds population.)  I suspect that this will be a more reliable construct than relying on people trying to make a profit since they will vanish as soon as the motive is gone, or as soon as they are offered a bigger profit for actively damaging the system.

Again, I request that the developers put some focus on making it practical and desirable for folks like myself to attempt to provide resource support.

[DeathAndTaxes]

Again, I request that the developers put some focus on making it practical and desirable for folks like myself to attempt to provide resource support.

1) Run the client w/ port 8333 open/forwarded on firewall
2) Done.

You are providing support to the network.

If you want a lower resource option, setup bitcoind to run on boot and delete the client.

[nmat]

1) Run the client w/ port 8333 open on firewall
2) Done.

You are providing support to the network.

You might have to forward ports if your router does not support UPnP

[DeathAndTaxes]

Yeah I thought that was implied by open on firewall but just in case I updated it.

[tvbcof]

Again, I request that the developers put some focus on making it practical and desirable for folks like myself to attempt to provide resource support.

1) Run the client w/ port 8333 open/forwarded on firewall
2) Done.

You are providing support to the network.

If you want a lower resource option, setup bitcoind to run on boot and delete the client.

I've never run anything but bitcoind and I in fact run it on my firewall/router.

You did not read the entire thread.  My request of the developers is that they put some focus on addressing such things as disk space utilization before they become an issue.  I'll add to that the hope that the CPU and memory requirements remain as light as practical.

I am building tiny appliances which are inexpensive to buy and operate and hope that they remain effective as full bitcoin clients.  (In fact, my end goal is to put some FPGA mining cards in them, but it is unlikely that I will get to that point.)

[DeathAndTaxes]

I did read the entire thread.  The blockchain is <1GB. The bitcoind is <4MB.  Given the blockchain contains over 2 years of transactions that is pretty good.

[casascius]

I did read the entire thread.  The blockchain is <1GB. The bitcoind is <4MB.  Given the blockchain contains over 2 years of transactions that is pretty good.

The first two years were pretty slow - it's growing massively - most of the space is taken up by the last 6 months of activity.

On my machine, my blk0001.dat + blkindex.dat are now > 1GB.

[tvbcof]

I did read the entire thread.  The blockchain is <1GB. The bitcoind is <4MB.  Given the blockchain contains over 2 years of transactions that is pretty good.

I broke down and logged into my machine and looked just now.  I have 4G in .bitcoin/databases/* but they are apparently log files which are, presumably, dispensable on a dedicated appliance.

.bitcoin/blk0001.dat is about 750M and blkindex.dat is about 300M.  I agree that this is remarkably good, but I also feel that the economy is .0001% of what it coulda/shoulda been and hopefully will be.

The reason for my imploring of the development team to keep some measure of focus on remaining vigilant about efficiency is that I have seen far to many development efforts forget about scaling issues in a mad dash toward some other more immediate goal (like wallet encryption or some pretty GUI fr'instance.)

[DeathAndTaxes]

I did read the entire thread.  The blockchain is <1GB. The bitcoind is <4MB.  Given the blockchain contains over 2 years of transactions that is pretty good.

The first two years were pretty slow - it's growing massively - most of the space is taken up by the last 6 months of activity.

On my machine, my blk0001.dat + blkindex.dat are now > 1GB.

That is weird.  It is 0.98GB on my machine.  I thought there was only one blockchain.  You trying to pull a 51% attack?

I broke down and logged into my machine and looked just now.  I have 4G in .bitcoin/databases/* but they are apparently log files which are, presumably, dispensable on a dedicated appliance.

.bitcoin/blk0001.dat is about 750M and blkindex.dat is about 300M.  I agree that this is remarkably good, but I also feel that the economy is .0001% of what it coulda/shoulda been and hopefully will be.

The reason for my imploring of the development team to keep some measure of focus on remaining vigilant about efficiency is that I have seen far to many development efforts forget about scaling issues in a mad dash toward some other more immediate goal (like wallet encryption or some pretty GUI fr'instance.)

Well things like encryption and GUI are a non-issue.   You don't need a wallet or GUI as a relay node.  The bad news is transaction volume  will increase and that means the speed the blockchain grows will also increase.  However as long as transaction volume grows slower than Moore's law the cost of storage should remain roughly the same.  You can get a 32GB SSD today for $64.  Likely in 2 years you will be able to buy a 128GB SSD for the same price.

[terrytibbs]

I did read the entire thread.  The blockchain is <1GB. The bitcoind is <4MB.  Given the blockchain contains over 2 years of transactions that is pretty good.

The first two years were pretty slow - it's growing massively - most of the space is taken up by the last 6 months of activity.

On my machine, my blk0001.dat + blkindex.dat are now > 1GB.

That is weird.  It is 0.98GB on my machine.  I thought there was only one blockchain.  You trying to pull a 51% attack?

If you have a node on 24/7 you will receive most of the would-be orphans, while a node asking for the current block inventory will only get the blocks in the longest chain.

[casascius]

That is weird.  It is 0.98GB on my machine.  I thought there was only one blockchain.  You trying to pull a 51% attack?

I guess it depends on how you count it.  Mine's 0.98 binary gigabytes, 1.06 decimal gigabytes.

[DeathAndTaxes]

If you have a node on 24/7 you will receive most of the would-be orphans, while a node asking for the current block inventory will only get the blocks in the longest chain.

Doesn't the daemon scrub orphans after so much time?  I would imagine an orphan for 100 blocks ago is kinda useless.

[terrytibbs]

Doesn't the daemon scrub orphans after so much time?  I would imagine an orphan for 100 blocks ago is kinda useless.

Pretty sure it doesn't.

[casascius]

Doesn't the daemon scrub orphans after so much time?  I would imagine an orphan for 100 blocks ago is kinda useless.

Pretty sure it doesn't.

I'm pretty sure it doesn't too.

Regardless, they are going to be small, like no more than a block or two, once in a while.  Probably less than 0.5% of the file.  I think if an orphan chain managed to get any longer than that, there'd be active discussion about it and everyone would hear about it.

[tvbcof]

Doesn't the daemon scrub orphans after so much time?  I would imagine an orphan for 100 blocks ago is kinda useless.

Pretty sure it doesn't.

I'm pretty sure it doesn't too.

Regardless, they are going to be small, like no more than a block or two, once in a while.  Probably less than 0.5% of the file.  I think if an orphan chain managed to get any longer than that, there'd be active discussion about it and everyone would hear about it.

I ran across some comment somewhere that there will be some 'optimization' on start-up.  Probably it is this, and it would be easier to implement than an optimization thread so that seems likely.

I very rarely re-start bitcoind.  My goal with this (and many other things) is to re-start a process maybe yearly unless I want to compile a newer binary or something.

[tvbcof]

...
The reason for my imploring of the development team to keep some measure of focus on remaining vigilant about efficiency is that I have seen far to many development efforts forget about scaling issues in a mad dash toward some other more immediate goal (like wallet encryption or some pretty GUI fr'instance.)

Well things like encryption and GUI are a non-issue.   You don't need a wallet or GUI as a relay node.
...

The issue I illuded to is that these things may take resources away from considering core network and scaling issues and implementing solutions to them.

So, I reinterate my point.

The bad news is transaction volume  will increase and that means the speed the blockchain grows will also increase.  However as long as transaction volume grows slower than Moore's law the cost of storage should remain roughly the same.  You can get a 32GB SSD today for $64.  Likely in 2 years you will be able to buy a 128GB SSD for the same price.

I would actually prefer avoiding buying new machines every year just to donate support to the Bitcoin project.  Currently I am able to support Bitcoin with a network connection that I already have, and with a spare machine which was modern about a decade ago (and uses just a few watts of power.)  I like that.

The question is how long it will be before people who have a minor interest in supporting the system will no longer to be able to practically do so.  To some extent it depends on the growth in use of the system, but to another huge extent, it depends on the focus that the development team puts into the scaling issues that are going to be popping up.

I feel that we could already be well beyond the point of implosion had Satoshi not carefully considered some of these issues, and had not the current development team continued to consider them.  I have a lot of respect for both for this reason.  I only suggest that the current (and future) teams not lose touch with this aspect of the development of the system.

[DeathAndTaxes]

Well there would be no need to upgrade every year.  Maybe every 5 years but it is almost simply not realistic to think you would never need to upgrade.

[MysteryMiner]

If running the client provides a valuable service to the network, shouldn't that be rewarded?

Should I be rewarded for seeding the torrents I downloaded? They stress my computer even more than Bitcoin. They are less demanding on memory and disc access, but the network is always loaded.

[finway]

Good question, I'm running bitcoin client for several months, but i'm not sure i'll run it if it's getting too big to slow down my computer too much.

[racerguy]

Only problem I have with running the client to support the network is it gives your ip away to would be attackers, I do run the client all the time though through tor, but I don't think the relaying of transactions happens when you do that.