See https://en.bitcoin.it/wiki/Transaction_fees

IP addresses.  But that hardcoded list, as you might imagine, gets out of date fairly quickly.

Typically an empty node with an empty peers.dat file gets most of its initial addresses from DNS.

After that, most addresses come via peer exchange, from talking to other nodes.


That is correct.  But let's emphasize that this is the first time startup, so that other readers are not confused.

Too many people focus on the bootstrapping process, when normally most peer addresses come from your local database or other nodes.

Great stuff.  Just sent this news to my G+ and twitter feeds.

Key word "priority"

A transaction with no fees will be accepted...  unless it is too low priority.

Each bitcoin node performs the important task of verifying transaction and block chain data.

For example, if a powerful miner, one day, decided to produce a block that gave himself 100BTC, all the other nodes on the network would ignore that block, because the block reward is currently 25BTC.

Further, running a node helps the network by providing users access to bitcoin data.  If we do not have nodes on the network that accept incoming connections, it would be nearly impossible for anybody to send or receive bitcoins.

Each additional node on the network helps strengthen bitcoin.  Each node is a "vote" for good data.  If we have too few network nodes, an attacker could potentially control the data we see.

No, you do not receive any fees or compensation for simply running a node (besides the satisfaction of knowing you are helping keep the bitcoin network running).

The memory pool.

However, because the state of each node's memory pool is random, your client is expected to retransmit transactions until they appear in a block.


Well, extremely low priority transactions -- those with insufficient fees or otherwise appear somehow "spammy" -- will not be relayed or put into the memory pool.

+1000

It is not an issue of unwieldly block chain, but unwieldly database software.

Upcoming version 0.8 already addresses this issue.

pynode pull requests accepted and encouraged!

Right now, I've been busy with the bitcoin C library implementation and client (libccoin and picocoin), which bumped pynode down on the priority list.

A bit of a non-announcement, as it Just Worked(tm), but picocoin is happily talking to IPv6 nodes on the network.

Tor support (SOCKS5) should be added sometime soon.

Indeed.  Any sort of private key from a gift card (or casascius coin) should be import and then the funds immediately sent to another private key, to prevent the previous private key holder from touching those funds.

In general, deterministic wallets (a) make life easier while (b) increasing the security threat (e.g. decreasing overall security).  Before, if one private key was compromised, others were safe.  Now, the picture is not so clear.

And if the seed is compromised, all keys are thus compromised.

If all private keys are covered by the same master key, then the security situation is largely unchanged, and the threat model focuses on protecting the seed (rather than a wallet full of keys).

However, private keys are not necessarily all tied together.

Thanks for giving it a try.


The developer consensus seems to be that uncompressed form just wastes bytes in the blockchain, which is true, so libccoin was coded to always used compressed form.

However, it might make sense to support uncompressed public keys for use cases such as yours, as long as the code still produces compressed form by default.

Such a change would involve adding "bool uncompressed" (default: false) to struct bp_key, and behaving accordingly based on that.

Someone wrote that a long time ago: the DHT.

If you want to transmit whole blocks, you are looking at 1,000,000 bytes every 10 minutes.

This is turning into an interesting thread.  Although it is now lapsed, I was formerly a licensed ARRL amateur radio operator ("KB4UZB").

Here is a useful, cheap, realistic idea that would help bitcoin survive an Internet blackout:

Have multiple stations broadcast the best known bitcoin block header.

It is only 80 bytes of data, which on average changes every 10 minutes.  That should be feasible for packet radio and other low bandwidth communication streams.

Back in the late 1980s, the BBS days, I remember one FidoNet operator had access to a few unused, off-screen scanlines of a satellite TV channel broadcast all over the world.  If you bought or built a cheap decoder box, and already had a satellite dish, you could receive FidoNet file downloads via satellite.  You had no choice in what you received, of course -- it was whatever the FidoNet operator decided to send that day -- but it was a great alternate one-to-many broadcast mechanism.

One could broadcast the blockchain headers in the same manner, with extraneous satellite bandwidth.  (of course, that is an old trick and probably impossible these days due to tighter resource management)

The internal, in-memory peer address database reads from several sources (in decreasing priority order):

• Your local peers.dat file
• Ask other peers
• Query DNS
• Use hardcoded list, compiled into client

The logic for finding peer addresses should be considered separate and independent of the logic used for connecting to other peers.

Addnode will always attempt to connect to the peer specified with -addnode, and it does not care what is in the in-memory address database.

Similarly, -connect does not care about the address database.  -connect always connects to the specified peer.

Sadly, this is not enough.  pynode is a "full node" implementation.  It fully verifies all bitcoin blockchain data, including scripts and ECDSA signatures.

pynode uses OpenSSL/hashlib for all crypto and ECDSA, which are, of course, C-based python wrapper modules.

CPU profiling of pynode indicates that the vast majority of CPU time -- a significant, noticeable slowdown -- occurs in simple Python data structure copying.  Bitcoin's SignatureHash function requires copying an entire CTransaction, modifying it a bit, then hashing the serialized result.

This would not be noticeable in a lightweight client, but it is the #1 cause of slowdown when verifying a bitcoin block.

That is disappointing, because it pushes users straight into a centralized, non-private, easy-to-monitor solution.  In engineering terms, an SPOF (Single Point Of Failure).

Point users to a decentralized client like MultiBit or Electrum etc.