I'm still against that. Until there is some out-of-band method for lightweight clients to be notified of their own transactions, the max block size must be kept low enough for everyone to keep up with blocks. It's not reasonable to expect every client to download 100MB per hour (or whatever).

Automatic adjustments might be OK if lightweight clients can find their own transactions without downloading full blocks. Then only miners would have to worry about network and disk space usage. But when the max block size is over 10MB, the massive disk space requirements (500GB per year) will cause there to be only a handful of miners, and at that point all the miners will be able to come to an agreement about block size with relative ease due to their small number.

The client has to do all the verification and processing for blocks/transactions, anyway, so I don't see the harm in providing the necessary info to separate mining software. It's certainly not something every mining program should have to handle.

Currently clients will not even relay transactions if their fees are "too low". This needs to be changed for the fee market to work.


The user should never be able to change the max block size without significant effort. You're pretty much guaranteed to end up on a separate chain sooner or later if you change this value.

Having an "include transaction fee" option (with explanation) would be useful to introduce newbies to the fee feature.

The addresses don't take up all that much room. The wallet.dat size is mostly all the sent/received transactions of yours.

Most miners (including slush's pool) use Bitcoin's getwork, so default fees are important. The ability to modify fee rules would be nice, though.


Setting aside space for free transactions is needed because otherwise someone could waste lots of disk space by sending endless free transactions. The 4kB priority limit should be removed, though -- let the 27kB free space be sorted by priority. The free space should also be increased to 50kB, IMO.


Good idea. There should also be a manual reclaim ability.

There's 27kB for free transactions, though only 4kB for low-priority free transactions.

The maximum block size is 500 kB (1MB receiving), but if the block size is over 4kB, low-priority free transactions will not be accepted. It's possible to create a transaction over 4kB that always triggers this and never gets in a block until its priority rises with age.

This seems to be the cause of all the recent problems. The transactions will confirm eventually, but it will take at least several days.

The Faucet only gives out so many coins per day, and then all future "orders" are queued. You'll get it eventually.

You misspelled the domain.

Miner-TE:
The input for one of those transactions hasn't been confirmed yet, and the input for the other one was confirmed just now. Probably the pool sends a ton of transactions with very low priority that depend on each other, so they all get delayed significantly.


It'd be rejected until the network forgot about the old version in about a week. There's no way of doing it without messing with your wallet, either.

The credits shouldn't be "blocked" by the debit. Are they on Bitcoin Block Explorer? There have been some problems with clients not seeing confirmations.

ArtForz discovered that there is a bug in sending: Bitcoin should have asked you to add a fee. Your transaction has low priority due to its many small inputs, and it is over 4kB, so it always triggers the rule that free transactions must have a certain priority level when the blocksize is over 4kB. It will not confirm until its inputs "age" enough to give your transaction more priority, which ArtForz estimates at 190 blocks from now.

This will be fixed in a later version.

I received your transaction around block 111026:

It's "out there", so it will get in a block eventually. It shouldn't take so long, though. This might be caused by a bug in the network. Other people also seem to be having this trouble:
http://bitcointalk.org/index.php?topic=3835.0

Edit: ArtForz reports that it is in his transaction queue, so it will be included soon. There might be a bug in priority handling that caused this.

If they're not running Bitcoin, then you won't be able to communicate with them to get the public key to send to. The transfer will fail.

There is no encryption. You can't encrypt with ECDSA keys. Satoshi planned a system where a "Bitcoin signing address" could be listed with an IP address so man-in-the-middle attacks wouldn't be possible, but this was apparently abandoned along with the rest of the feature.

Try adding a fee to a new transaction to see if it's a fee problem.

Keep Bitcoin open so it can keep trying to resend it. Make sure you have several connections; if not, connect to a fallback node. If it still doesn't clear after a few hours of leaving Bitcoin open, run Bitcoin with the -debug switch, double-click the transaction, and paste the transaction dump here.

Bitcoin doesn't have an option to change its own port. Possibly by doing this you told Bitcoin to use a proxy, which would cause you to be unable to connect (since you don't actually have a proxy).

I suppose being able to verify that a transaction is still unspent without downloading the block chain is valuable. But you can already do that with Bitcoin Block Explorer...