It's the only reliable way of determining who paid you, anyway.

It's chosen by miners. Miners could fill blocks to 1MB with free transactions if they wanted.

That block was probably solved by an old client. The current free limit is 27 kB. It was originally 200 kB, and there were some intermediate adjustments between those.

It's to allow for high latency between nodes. If it was one minute, a few seconds of latency between ends of the network could give someone with good network resources a better chance of winning blocks, damaging the "one vote per CPU" principle.

Also, remember that a confirmation is valuable because it represents some CPU power. If it took a minute on average to get a confirmation, you'd have to get 10 confirmations to match the protection of a single 10-minute confirmation. 1-minute confirmations might even be less valuable than 0 confirmations in such a system because it could be cheaper for an attacker to solve the required number of blocks than to overcome the TCP network.

You'll keep resending it forever until it gets in a block.

I tend to think that dedicated miners will have more computational power than the entire rest of the Internet, which would make the chance of volunteer takeover low. But if this is not the case, I can easily imagine a network dominated by volunteers. There are a lot of people who compute for @home projects, and it's in the interest of fee-charging pools to spread propaganda about how mining helps "keep your money secure". It's not even altruistic from the perspective of these miners, since they believe it will help a system they rely on.

Beyond efficiency, volunteer mining frequently also centralizes control with pools and gives some power to people (the miners) who don't really understand Bitcoin. It moves us away from my picture of the optimal end-game: a few hundred private, competent, for-profit miners operating outside of a pool.

A few people won't hurt, but lots of people will. It's a bad trend. I want to discourage it before efficient miners are pushed out of the market by huge pools of inefficient miners, which I consider entirely possible.

Why do you think this isn't likely?

The data is available on the network. See:
http://blockexplorer.com/address/18dts6fXXA7jVKfYMBpsFqx7iZCELCfDpk

This is only safe if the senders all use standalone clients, though. EWallet users will not send from their own addresses.

You can move the topic if you want. I don't think this is necessarily the wrong category.

For that, you would:
- Collect the user's address, and have them fill out a CAPTCHA so they don't generate a million addresses
- getnewaddress from Bitcoin
- Poll "getreceivedbyaddress <address> 0" to tell the user when their transaction is received
- Poll "getreceivedbyaddress <address> 6" until the amount is non-zero. Then "sendtoaddress" the amount to the given address.

You must wait until transactions get 6 confirmations or else Bitcoin will choose transaction inputs in such a way that you will certainly lose money on fees (which are paid automatically, without confirmation).

I like SMF.


SMF also supports this (through a mod). This forum just doesn't have it enabled.


You can get notifications without posting.

It hurts because it can potentially increase difficulty for miners that are mining much more efficiently. If a lot of people do this, efficient miners may be pushed out of the market.

If I remember correctly, you use multiple parameters like this:

It also might be an array:

After converting to decimal, make sure you round to 8 decimals of precision to fix any float errors.

It only does it on startup, so the file might actually get bigger than 10MB.

Wait for Bitcoin to download the blocks again.

I would not have returned the funds, since doood did not prove that he was the one who actually sent the coins. Maybe he only observed the transfer on the network. You also had no prior agreement.

I'm not talking about small transactions, but free transactions of any size. Anything that is free will be completely used. If free transactions could fill blocks to 100 GB, I have no doubt that many blocks would be 100 GB. Even when Bitcoin has a client mode, the network will only be able to handle so many transactions.

This topic is about allowing minimal use of free transactions for as long as possible by preventing individuals from sending dozens of free transactions per second at no cost. "limitfreerelay" increases the cost, but I don't think the way it does this is effective in prioritizing users who send only a few free transactions over those who send many.

Another way of improving limitfreerelay would be to randomly drop free transactions at an automatically-adjusting probability. High-priority transactions could have lower drop probability.

I agree. In-depth technical stuff is best done through lectures or text.

Gavin's idea for left-oriented propaganda sounds nice. An overview of the economics for skeptical libertarians would also be good.

If you keep sending 0.04, Bitcoin will keep re-using the same coin because it's the best fit for a send of 0.04. If you have two 0.04 coins and make several 0.04 sends, you would see that Bitcoin chooses between them randomly. If you have a mix of coins with no exact matches, it gets even more unpredictable.

Bitcoin offers no ability to choose the sending address.

It tries to choose coins that add up to not much more than your send amount. There's also randomization involved.

It doesn't work like that. The money is sent from arbitrary addresses.