Because JavaScript doesn't have a 64-bit integer type (all Numbers in JavaScript are double-precision floating point).

If there is a virus on your computer, and your bitcoins are stored on that computer, then there is nothing the bitcoin software can do to prevent that virus from eventually stealing your coins.

That said, allowing you to 'lock' your coins with a password, and requiring that you enter that password to send coins, is high on the list of things I'd like to see bitcoin do.  That would make it harder for a virus to steal your coins.

But even then, a smart virus could lay in wait until you typed your password to unlock your wallet and take that opportunity to either capture your password or send the coins to a bad guy.  If you can't trust your computer, don't store your life savings on it (and yes, bitcoin software also should make it easy to save some of your bitcoins on USB sticks or CD-R disks so they can be stored safely in your safe deposit box at your bank).

https://github.com/bitcoin/bitcoin/pull/88

This makes CTransaction::CreateTransaction use the same rules for what transactions require a fee as CBlock::CreateBlock.

The mismatch was the root cause of the transaction slowness (low-priority free transactions were created but weren't being included into blocks until they 'matured' and had a higher priority).

... and you get 'fatal error, can't create' when you try to compile bitcoin?

Sounds like your obj/ dir is not writeable by whichever user you're using to compile.

I've got a (private so far) patch that creates mass-pay transactions.  API is:
  sendmulti <fromaccount> {address:amount,...} [minconf=1] [comment]

This code in CTransaction::AcceptToMemoryPool will need to change, too:
(a mass-pay transaction will have N+1 OP_CHECKSIGs in it, where N is the number of people being paid).

Replacing in the stock client with something like:
... seems like the right direction to go.

BUT: I think a higher priority is figuring out how to deal with fees for the other two send methods.

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.