You can send a billion small transactions, it doesn't slow anything down, except the user interface because you end up with a ton of items in the list.  Just go ahead and try it, see for yourself.

All of the transactions are included by nodes that are attempting to generate the next block and only the header is hashed so it is not harder to generate a block that represents a million transactions than it is to generate a simple coinbase only.  This is what the confirmations are, blocks that include your transaction.

Sorry I misread, it's possible that you just weren't connected properly and it couldn't broadcast a transaction, what was the exact wording of the message?  Can you include a screen shot?  I might have been describing a different problem than you were having especially if it cleared up after restarting..

It is normal for some blocks not to be accepted.  One connection is enough, the others are just redundant.  The client will make 8 outbound connections but will accept all inbound connections (on port 8333).

The blocks are generated in sequence so if two nodes happen to generate at almost the same time there will be a collision and one or the other will win.  If the current block count is 5000 and your node finds a suitable block 5001, but meanwhile some other node already created a 5001 and your node just didn't know because it's on a laggy connection possibly, your block won't be valid and you have to start searching for 5002.  I think this is explained in the pdfs, I'm not sure.

Are you seeing a lot of these happen or was it just one?

Please try running with 'nice -n 19 ./bitcoin'
or renice +19 1234 where 1234 is the pid of the running bitcoin.

There is a bug in the released linux version which prevents it from successfully lowering its own priority.

Are you using some sort of alternate permission framework like selinux?  I believe some linux distros like ubuntu come with this by default.  Per the man page for setpriority (even on ubuntu), only root can lower (make more favorable) the priority so it should not be possible for the adjustment to work on linux.  Anyway the reason it tries to raise its scheduling priority is so that it can quickly save a generated block and then go back to low priority for generating again.  Your issues should all be fixed in SVN and you shouldn't have to manually set the priority anymore - you can just change the PRIO_MIN to your preferred priority, or use the PRIO_MAX macro.

http://www.kernel.org/doc/man-pages/online/pages/man2/getpriority.2.html

Why do you say that?  Pretty much every P2P system works by replicating the information across all the participating nodes, even 100G movie packs for BitTorrent - we're talking about less than a kilobyte of information for a transaction.

This is fixed in SVN but I think that was after the release was cut. 

The workaround is to run bitcoin like:

..otherwise it hogs the CPU as you noted.

I spent some time experimenting with this and contrary to what the documentation states, on ubuntu you can actually adjust the priority to be more favorable (numerically lower) after raising it to a higher number.  I believe this might be due to selinux?  That seems non standard and I think on any 'normal' system using the usual behavior the generating thread will end up staying at the less favorable (numerically higher) priority even when an attempt to change it is made.

I think it is similar to IRC.. I haven't measured it but the bandwidth requirements are very low.  The messages are very short like chat messages, just containing a few bytes.  Nodes ask for addresses all the time, and new blocks are broadcast regularly, so think of it like being on a few very active IRC channels where people are talking all day.

It is however very active on the disk I/O because it flushes the database to disk every transaction - this is what iTunes does too every time you change tracks.

I think loans would be useful, that way if I want to go on a pizza binge I can buy a bunch of it and pay it back later.  I don't think you would want to give someone a loan anonymously though, you'd want to know where they live so you can break their legs, etc.

I think interest would be cool too - like a certificate of deposit?

I don't mean to be a hater, but I really dislike anything that wants me to update.  I don't mind having a 'check for update' option but I really don't care if a new version is out if I'm happy with the current one.  If I actively use something I will likely check the site for news when I feel like it, not when the software pops up something.  If I don't use it much, then I really don't care if I have an old version..  If my old version stops working because the network has been upgraded, then I will probably want to check for a new one anyway.

It may also be seen as a breach of privacy if the software 'calls home' to check for a new version, at least that's how I feel about all those Adobe products and other stuff that always wants to install some kind of update checker or download manager or other useless (in my opinion) junk.

The addresses are valid forever unless you lose your wallet.  The only disadvantage is that the address receiving a transaction is visible to all nodes.  It is easy to automatically generate a new address each time a page is refreshed on a donation page using the JSON RPC interface.

The windows thing is a function of having different operating system versions.. on Vista at least it goes into this Roaming directory, because they reorganized it and wxWidgets is just using the OS standard place.  There is a -datadir option you can use to keep it on the desktop or whatever.  I believe if you use the token %APPDATA% in your script, or $APPDATA if you're using cygwin/msys, then you will always have the right place regardless of XP/Vista.

So something simple like a scheduled task on windows or a cron job on another system like Mac OS or a BSD/Linux distro..

Windows batch file style with another windows machine as a file share, going from the bitcoin host to a file share:

Shell script style, still initiated from the bitcoin machine - set up public key auth so no password is needed first

You can change it to print it every 30 seconds or whatever if you edit the code.. but it's really not going to change except when the computer is busy.

It really only makes sense for nodes with the port forwarded to remain on the IRC channel, right?  Maybe it could just ping a php script or another node randomly (this might be a better idea) which tells it YES/NO on whether the connect-back is working, and then just terminate the IRC thread if it's not needed anymore.  It could re-probe every 6 hours or so in case the user changes their port forwarding settings, or it could just be an option even..

Pretty much all of the encryption software in use on the internet takes advantage of a trapdoor function - you can multiply 2 numbers together but you can't easily determine what the 2 factors were if all you have is the resulting product.  As it is today the only way most of us know to do it is to try every number.  If someone were to figure out a better way that took less time, it would make it easy for a regular guy like me to use that method in some software to decrypt HTTPS traffic and such.

Hashing is slightly different but the idea is the same - it is not possible to work the hash in reverse to determine what the possible inputs were, you just have to try every plausible input and compare your hash.

None of these things are perfect but bitcoin is only taking advantage of existing methods that are in use by a lot of other software which has been accepted for a long time.  If a basic flaw is found, bitcoin is probably the least of anyone's worries

Other nodes don't have to accept your transactions.. but many will want to use the official well behaved software anyway so there should always be some people who will accept them.

I think it's similar in some ways to web browsers - a web site author wants you to see a bunch of ads so he created something that uses javascript and opens pop under ads.  You're using a browser that doesn't have javascript so you don't see the ads.. but then he has this cool page that lets you pan a webcam around and it uses javascript but you can't use it.  So maybe you outsmarted the system by avoiding the ads but you end up losing out on the webcam panning page so you're just hurting yourself with your modified browser.

There are similar things you can do in bitcoin but I think the author has designed it to be pretty well protected against the kind of things that would allow someone to subvert the whole system or profit from it.  You might reject everyone's generated coins and not include them in your blocks, but it doesn't make you any richer, and some other nodes will accept them anyway.  You can send garbage and find ways to crash them but then those nodes will just blacklist you.  These protections will be implemented as needed I think, since it's hard to know ahead of time what types of things to protect against.

BitTorrent clients are a good example to look to - they disconnect and blacklist clients that are sending them bad data.

The majority of the network will likely always be comprised of cooperative nodes.

So would there be any legal issues (int the US or elsewhere) with running a bitcoin lending service similar to a traditional bank?

You can't destroy them all, more will be generated constantly.  That 21 million number is not going to be reached in the foreseeable future.  As you know, the generation algorithm adjusts itself to slow the generation rate intentionally.

I don't think you understood my point.

It is a lot easier to arrest and lock up the prominent bitcoin users than to manipulate the market.  Like it was pointed out, a market is not just a single currency, it can be a lot of different types of currency and goods.  Trying to manipulate one end or the other would be difficult.  It is better to just get the people - fear of being arrested is much more effective than trying to shake up confidence in the currency.

Destroying a large amount of currency just causes deflation and makes the remaining currency that much more desirable - imagine if you had a pallet of gold bars in your garage and nobody else did.

Maybe you don't agree with my assessment of the situation but what you posted was far from constructive.

In response to your original post, I don't believe the situation you describe is a big risk.

My daughter ripped a dollar bill in half earlier when she got into her mom's wallet.. It's not really worth it for me to try to get a dollar bill replaced by the treasury so I just consider it destroyed - but it's not really going to affect my budget and certainly not the economy of the United States.  There are about 65000 blocks so over 3 million bitcoins have been in circulation.  Many of them have probably been destroyed by accident when someone lost a wallet file or whatever..

If you want to buy a bunch of bitcoins (or dollar bills) from me and destroy them let me know, I can give you a good exchange rate for bulk transactions like that

For dollar bills I would charge 1.03 to make it worth my while but I will have them sent by air mail or courier depending on the distance.


I think if a government wanted to get rid of bitcoins they would just take us away in black helicopters - probably Satoshi first..