RE: limitfreerelay:

Agreed, that's better.  I think we should start soft-coding the amount that is considered "free" instead of hard-coding CENT, and make the default less than 0.0001 BTC.

Separate subjects:

The entire transaction memory pool should be size-limited, with lower-priority transactions dropped.

I agree with Steve-- free transactions are a HUGE selling point, and I think rational miners should realize that their bitcoins will be more valuable if there are more users.  And there will be more users if "free transactions" is a feature.  I think we can come up with a solution where "normal" transactions are free, but spam or abnormally complicated transactions (yes, like those bitpenny rewards pooled mining participants are currently getting once a day) "require" a fee (where "require" is really "if you don't include a fee your transaction will probably never be confirmed.")

And finally... we've got a problem right now; lets think about what fix(es) move us in the right direction quickly, or think about fixes that will solve the current problem (that we may need to undo/rework later).

No.  The only way to "break your stash" is to create transactions that are broadcast; splitting your wallet into lots of small transactions makes the problem worse for you and everybody else (it is more 'expensive' to handle fistfulls of nickels and pennies, even in the bitcoin world).

Thanks for the donations, everybody!

Catching up on questions:

Is the faucet supported entirely by donations?  Not entirely-- the captchas have generated about $100, which will go into refilling it.  It looks like captcha revenue is only covering about 1/4 of the cost of the coins, although the company that does the money-for-captchas is a startup looking for more advertisers.  Actually, if you want to advertise a bitcoin-related business you should talk to them... (they're adscaptcha.com)

Was somebody abusing the faucet?   Yep, somebody was exploiting a weakness in my IPv6-handling code.  I've fixed the weakness (the faucet is now much stricter about what it considers "different" IPv6 addresses), but I think I'm fighting a losing battle-- the next step will be to require you to login with a valid google account to get coins.  I hate to add another hoop to jump through...

Is it time to reduce the payout?  Maybe soon, but I'd rather wait until the next release is out and then reduce the payouts another factor of 10 (so 'standard' payout if balance was above 500BTC would be 0.05BTC, and 0.005 when it was running low).

Can I add a link to bitcoinmonitor.com?   Done.

You can generate a 1MB block with only free transactions in it and it will get accepted (maximum block size is 1MB, although the standard bitcoin client will never generate blocks larger than 500K).


The problem isn't the pool payout-- the problem is that people participating in the pool end up with wallets full of tiny (e.g. penny-size) transactions.  When they go to spend those tiny transactions, they're bundled up together to make a transaction that is small in value but large in size.

Pools can mitigate the problem by requiring larger minimum payouts (e.g. 1 BTC instead of 0.01 BTC).

This definitely needs fixing; it is another "people getting lots of very small change from mining pools" issue.

The code that controls this is CTransaction::GetMinFee() in main.h and CreateNewBlock() in main.cpp.

We should think about:

+ Is setting aside a specific amount of space for free transactions the right thing to do?  Maybe blocks should just get filled in reverse priority order (with transactions with fees at the front of the line)

+ What to do with the current transaction backlog.
If old, big, low-priority transactions get flushed, then there needs to be some way for the bitcoin client(s) that sent them to reclaim those coins.  Perhaps the client should stop retransmitting, and reclaim, transactions if, oh, 5,000 blocks go by without the transaction getting accepted.

Or maybe it makes sense to let those old transactions trickle in; perhaps the next version of bitcoin should take the oldest transaction in the memory cache and add it to the generated block.

This is:  https://github.com/bitcoin/bitcoin/issues#issue/86

currently (2011/03/01) a backlog of transactions that dont seem make it into blocks is building up (according to ArtForz now 670 transactions).

People are starting to complain, see http://bitcointalk.org/index.php?topic=3835.msg57031#msg57031 for an example.

This was discussed on #bitcoin-dev

ArtForz> that tx should have a score of 20567855
ArtForz> so it falls short of the dPriority > COIN * 144 / 250 test
ArtForz> and as tx size is > 4000, fAllowFree is never true for it
theymos> Ah. So it will never confirm?
ArtForz> probably not

ArtForz> looks like the tx-sending code needs some fixing
molecular> like not generate a tx with a score too low, or suggest to add a fee?
ArtForz> yep
ArtForz> check size and priority of transaction, if it's > 4kB and score < 57600000 require min fee
ArtForz> maybe reduce the size limit to 3.5k or so, otherwise it can only get into an otherwise empty block

Maybe the transaction cache should not be unlimited?

Actually, I'm considering turning on transaction fees for the Bitcoin Faucet because small transactions with "new" coins are given very low priority, and recently new users are noticing that their Faucet coins are not arriving promptly.

Good Idea.  You should do that.  Maybe marking issues at github with a "Launchpad" tag would be a good system?

I was tempted to do more than fix the rounding problem...
... but then sanity overwhelmed me.

If you'd like to start a discussion of whether or not it is a good idea for one-thousand German bitcoin amounts to be displayed as "1.000,00", be my guest.  I think there was such a discussion in the past, but I didn't pay attention to it.  I think it would be nice if an amount like "1.001 BTC" (or even "1.001 tonal bitcoins") was unambiguous.

RE: subcent throwaway change:  turn it into a proper PULL request (yes, you'll have to-- horrors! -- use that evil, not 100%-pure-open-source github) and it'll happen faster.

80 transactions per second is 6.9 million transactions per day.  That is a LOT.

PayPal was doing about 2 million transactions per day in 2008; if there are three times as many bitcoin transactions as PayPal transactions in a few years that would be a very good problem to have, and I'm confident "we" would figure out how to deal with lots of transactions.

It was LC_NUMERIC, I bet... (I'd just set LANG and unset the rest and assumed they'd all get picked up; internationalizing C++ applications is something I know very little about).

I modified the patch to format numbers the way they were formatted before:  always , for the thousands separator, and . for the decimal point (instead of letting sprintf try to do the right thing).

So?  So?!?  11 is my favorite number!

Are you setting the ContentType as described here:
  https://en.bitcoin.it/wiki/API_tutorial_(JSON-RPC)#.NET_(C_)

Can anybody else reproduce this?  It works for me:

The official client uses an older version of Berkeley DB (4.8, according to build-osx.txt).

You're linking to Berkeley DB 5.1.19, so when you run your client it upgrades the bitcoin database files, which makes them incompatible with the official client.

No.  Generated coins need a place to go (they're credited to the "" account), and coins you send using sendtoaddress (where you don't specify an account) need to be debited from somewhere (they're debited from the "" account).

And it's theoretically possible somebody might could use one of your hidden "change" bitcoin addresses to send you coins; they'd be credited to the "" account, too.

JollyGreen was asking about 'typical people'.  And I think he was asking about "right now".

Typical people aren't going to distinguish the currency from all of the financial services that make the currency safe, convenient, etc.  And I think we should be honest-- bitcoin-the-currency needs more mature financial services before bitcoin-the-system makes sense as a payment solution for typical people.

Saving for the future:  bitcoins are designed to be like gold: durable, only a limited supply.  They have some advantages over gold-- they're much easier to store safely (you don't have to buy a bank vault or hire guards or trust a storage company) and, because they're electronic, they can be backed up.  And when it is time to sell them the transaction costs are very, very low.

Buy some goods online:  I don't think bitcoins have any significant advantage... yet.  Transaction fees are lower once you get bitcoins, but the transaction fees to get bitcoins probably eliminate that advantage.

I think Bitcoin's real, hidden advantage is the fact that you don't have to ask anybody's permission or fill out any paperwork to start doing creative, innovative things with them.  Lots of people are doing lots of innovative things with bitcoins, and while most of those innovative things will probably fail (most startups fail), I'm optimistic that some will succeed and in 5 years we'll be using bitcoins in some way we haven't even imagined yet.  I'm not going to pretend to know which market niches bitcoin will fill-- maybe it will be migrant workers using bitcoin to send money back home and avoiding international wire transfer and currency conversion fees.

Maybe teenagers in China will use them to buy stuff online because they can't get a credit card.

Maybe big multinational corporations will decide to use bitcoins to pay their supply chain to avoid currency exchange risk and save 0.1% on their transactions.  Who knows?  Even if bitcoin turns out to be just "a better store of value than gold" it will be hugely successful.

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

The exact hash done is double-sha256: sha256(sha256(block_header_data))
See:
 http://en.wikipedia.org/wiki/SHA-2

... for information about sha256

Great suggestion, I will modify the code to refund the escrow fee (if any) and donate the rest.


I have some preliminary plans for mediated escrows that will require all three parties to have ClearCoin accounts.  I'm still thinking about how to make it as simple to use as possible.

Great idea, I'll put it on the "nice to have" list.

Easy to do.  How critical is time?  Plus or minus 1 hour would be easy (there's a 'cron job' that runs once per hour to process refunds), but I don't want to make the Create an Escrow page more complicated than it really needs to be.

I'll probably target transactions under $50 remaining free, and I'm thinking of capping fees at $4... but it is likely I'll experiment with different pricing models as I fill out features.  Paying mediators (before and/or when mediation is required) adds lots more wrinkles...
Nope.  Maybe I'll franchise later if Bitcoin and ClearCoin really take off.
No-- what authentication method would you like to see?  I don't like the idea of supporting arbitrary OpenID authentication, because it is so easy to create throwaway OpenID identities (creating throwaway Google identities is at least a LITTLE bit harder...).