So the longer I think about the block size issue, the more I'm reminded of this Hayek quote:


We can speculate all we want about what is going to happen in the future, but we don't really know.

So, what should we do if we don't know? My default answer is "do the simplest thing that could possibly work, but make sure there is a Plan B just in case it doesn't work."

In the case of the block size debate, what is the simplest thing that just might possibly work?

That's easy!  Eliminate the block size limit as a network rule entirely, and trust that miners and merchants and users will reject blocks that are "obviously too big." Where what is "obviously too big" will change over time as technology changes.

What is Plan B if just trusting miners/merchants/users to do the right thing doesn't work?

Big-picture it is easy:  Schedule a soft-fork that imposes some network-rule-upper-limit, with whatever formula seems right to correct whatever problem crops up.
Small-picture: hard to see what the "right" formula would be, but I think it will be much easier to define after we run into some actual practical problem rather than guessing where problems might crop up.

I think there doesn't have to be One True Answer, and I'd like to see the different clients experiment with different ways of estimating fees.

I like your idea, Jan-- go for it!

I want Consumer Reports magazine to do an article in 15 years comparing bitcoin wallets and figuring out which one gives the fastest transactions for the lowest fees...

You're assuming that miners are completely distinct from the people who want the network to be secure (users/merchants/exchanges/etc).

That is a bad assumption. Nothing stops a merchant who wants more network security from either subsidizing miners (maybe in exchange for a promise to prioritize transactions to them) or mining themselves.

This is already happening, not for reasons of security but for other reasons.

Because dust outputs are more trouble than they're worth. They bloat wallets, cost more in fees to spend than they're worth (unless you go to ridiculous lengths to spend them), and are abused as a side-channel-in-the-blockchain-communication-mechanism.

If I could go back in time, I would go back and try to convince Satoshi to make them non-standard to begin with....

Here's the thumbnail sketch on the code that I think needs to be written to handle fees properly:

1). Memory-limit the memory pool-- the set of transactions waiting in memory eligible to be included in a block. Matt Corallo has been working on that.  The limit should be a small multiple of the median block size of the last few hundred blocks.

2) Use the same algorithm/parameters/etc for adding transactions to the memory pool that we use to fill blocks.

3) Only relay transactions that fit into your memory pool.  This is the DoS prevention, your transaction won't get relayed if your node doesn't think it will end up in a block soon.

4) Estimate minimum transaction fee / priority needed to get into a block, based one:
    a) At startup:  the transactions in the last few blocks
    b) If you've been running long enough to "warm up" your memory pool:  transactions in the memory pool

5) Expose the estimate in the GUI's "suggested transaction fee" dialog.

All of that will give a floating fee that will change based on how many transactions, at what priorities/fees, are currently waiting to get into blocks.

There is one more change I'd like to make that is independent; re-define "dust" based on the floating transaction fee (e.g. a dust output is any output with a value of less than 1/4 the minimum fee-per-kb required to get into one of the next 6 blocks).  And make any transactions with dust outputs non-standard, so they're not included in the memory pool or relayed.

The only security risk with free bitcoin services is that they'll remember your IP address and associate it with the millibitcoins that they give you.

If you're the conspiracy theory type, then here's one for you: a very good way for a Three Letter Agency to create a database that correlates bitcoin wallets to real people would be for them to run a free bitcoin service (along with whatever they're currently doing to correlate IP addresses with real people).

r.willis is confused about the BIP process.

It is not "Write a specification. Submit a BIP.  Argue for a while, revise the specification.  Finalize BIP, then everybody agrees to implement it."

I know there are standardization processes that try to work that way, and they're generally miserable failures. You end up with bloated specifications and implementations that don't work with each other because everybody interprets the spec slightly differently.

I like the IETF model, of working code and rough consensus. So, once the payment protocol is implemented and early adopters have had a chance to play with it, it will become a formal BIP.  Until then, as Mike said, I'll be tweaking https://gist.github.com/gavinandresen/4120476 as I run into issues.

Nice!  We need a good Mac OSX developer, do you know C++?  Are you willing to learn Qt?

My main machine is a Mac, but I'm not an expert OSX developer (I spend all my time in a Terminal window in emacs, pretending my Mac is a Unix machine).

Wiki is out of date. Everybody running their node as a tor hidden service would work just fine as of a couple of releases ago.

So... you complain about development not happening faster, and then you complain that I'm not spending all of my time here on the forums?

"okey dokey"

Transactions larger than 100K are non-standard now, so I doubt the big transaction was ever broadcast. Almost certainly the transaction belonged to the miner, and they paid the fees to themself.

Sure.

First, you need to make sure miners will accept bitcoins with the lower fee.  So lobby your favorite miner or mining pool to set the -mintxfee=  parameter to something lower than the default 0.0005 BTC-per-kilobyte; you can ask them if they will increase the size of the blocks they're creating and include more free transactions, too (those are settings they control).

Then, if you're using Bitcoin-Qt, you can set the transaction fee in the Preferences/Options dialog.

Right now, network peers won't relay low-priority transactions that include a fee of less than 0.0001 BTC, so that is as low as you should go. Fixing that is near the top of the (long) TODO list, but I really want to fix it correctly so we developers get out of the business of deciding what the transaction fees should be, and instead let the network decide.

If you generate a small number of high-bitcoin-value transactions (e.g. you have more than 1 BTC in your wallet and make a few purchases a week) then you should probably leave the Pay transaction fee setting at zero; Bitcoin-Qt will send your transactions without a fee, which will be just fine.

So....  move too fast and we maybe introduce a forking bug or a security vulnerability.

Move too slow and maybe we get fired-- somebody faster at incorporating safe changes releases their own fork.

For me, "move slow" is the right answer.

But I would be completely happy contributing patches to somebody else running a fork who solves the "move fast but be safe" problem.

Not rhetorical: it needs to be fixed, or your blockchain can easily be forked.

Beware of Altchains that are abandoned or neglected by their developers (activity at https://github.com/litecoin-project/litecoin/commits/master doesn't look healthy to me... and now y'all are going to accuse me of spreading FUD, so I'll go away and shut up).

Bitcoin is not a single product any more, so a "Download Now!" button doesn't make sense any more.

Just like bittorrent or linux aren't single products. And if you visit bittorrent.org or linux.org... guess what?  No download button.

Ummm.... speaking of the hardfork, has a version of Litecoin been released yet that fixes the problem?

Straight Bitcoin isn't designed for really small transactions.  If you're sending less than something like $1 worth of bitcoins, you should expect to pay 10% or more in fees. More if you're trying to send $0.10 or less.

There is no magic fairy wand we can wave and make Bitcoin suddenly great for gazillions of tiny transactions; plan your businesses accordingly. As transaction volume increases, there will be more competition for space in blocks and fees are likely to rise.

And please avoid filling your customer's wallets with "dust" that they'll pay huge fees to spend; a payout should be at least a couple of cents, not a fraction of a penny. I think there is pretty good consensus among the core developers that sooner or later we'll make "dust" outputs non-standard, so they are not relayed or mined by default (details to be worked out, we need to implement a good algorithm for auto-adjusting the definition of "dust").

If you're on Linux or Mac, run contrib/tidy_datadir.sh if you want to get rid of old, not-used-any-more files in your data directory.

It will safely remove the blkindex.dat and blk000?.dat files.

If somebody wants to write an equivalent .bat file that does the same on Windows, that'd be fantastic!  I don't know hardly nuthin about Windows batch files.

As deepceleron says, the blk000?.dat files are hardlinks, so even though it looks like they're taking up space they're not. And they're safe to delete (just don't delete anything in the blocks/ or chainstate/ folders).

To be clear: the 'donor' was the EFF, and their only request was that the Bitcoins be given back to the bitcoin community. If you like, think of it as a bulk payment of transaction fees that the faucet would have paid if it had been operating over the last year instead of closed (due to lack of time for me to fight the scammers).

Because it sent tiny transaction amounts, it paid almost as much in fees as it gave out...

Somebody should exploit all the DoS bugs that have been fixed to put the dead altcoins out of their misery, starting with the BDB lock limit bug.

Because if they keep scraping along, the worst thing that could happen would be for them to suddenly get popular-- because then attackers WILL swoop in and cause chaos.