WARNING! Bitcoin will soon block small transaction outputs

[gmaxwell]

Yes there is. It is defined by changes in the reference client, but not all reference client code dictates the protocol. Please grasp that protocol and policy are different things.

Right. "Protocol" in our normal dialong is stuff you MUST do or you're incompatible, will end up on chain forks, etc.  Policy is just decision you make on your own which don't need to be consistent.   Mining and relay rules are a little on the line, and thats probably causing some confusion here— they are not protocol, they are policy— but they are policy that has impact on third parties, not just yourself.

[1714278109]

1714278109

[gmaxwell]

Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

Maybe gamblers (SD and similar) and small miners.

It should not have any impact on these parties. It's sad that people are getting worked up here over confusion and misguided guesswork.

[caveden]

If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue. If we ( and I include myself in this) don't like it, then it should incentivize us to create competing bitcoin clients.

I agree with you, but it's still sad to see biased behavior being embedded in the reference implementation. It's like bitcoin.org. Not a monopoly, but still, the "reference". I'd very much prefer if it remained the most unbiased possible.

[Come-from-Beyond]

If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue.

This is not a protocol change.

This is a client change.

There is no such thing as a protocol in Bitcoin. It's defined by all changes in Satoshi client.

Yes there is. It is defined by changes in the reference client, but not all reference client code dictates the protocol. Please grasp that protocol and policy are different things.

Thank you. I was sure Satoshi had not published the protocol.

[gmaxwell]

If somebody is paying fees to store arbitrary data in the blockchain, just let him be.

First, Bitcoin is a decentralized currency. It is not a data storage service. Bitcoin would be a very bad design for a storage service, and it's only attractive to some for this purpose due to the non-consensual aspects of it.

As far as fees go— there is no automatic moral righteousness that comes from paying fees: If I pay a big enough fee to your neighbor should I be able to show up and drill holes in your head?  Why not?? I paid a fee!!!!

The costs of data storage are not just borne by the single miner that accepts the transaction and has arguably been paid for their trouble they are imposed on the entire network— all current and future users of Bitcoin— for all time. Of course, miners who don't agree with the policy are free to adopt other fee policies— there is even a config file setting for it but I expect that few to none will— because they care about Bitcoin as a currency and want the bitcoins they mine to be valuable.

You can expect that the core development team will continue to defend Bitcoin against non-currency usage at least to the extent they believe and there is evidence that the non-currency usage is non-trivially harmful to the usage of Bitcoin as a decentralized currency.  If you don't like it, you should probably find other software to run. (And probably another network: I doubt you'll find many Bitcoin users who are friendly to chewing up their bandwidth, diskspace, and processor cycles to store data that you're not paying them to store)

Finally, even with this change people can still create stupid data bloating transactions— but they need to put as much bitcoin value in their unspendable outputs as a plausibly real transaction does. This is a 5000x disincentive and the result is effectively paying all the current and future users of Bitcoin through increase scarcity.

Will bitcoind also disconnect from nodes that don't respect this policy, à la FATCA style?

No, nodes relaying non-standard transactions are not disconnected. That would make it infeasible to have inconsistencies in policy. Part of the point of policy vs protocol rules is that policy isn't required to be completely consistent for correct operation.

I agree with you, but it's still sad to see biased behavior being embedded in the reference implementation. It's like bitcoin.org. Not a monopoly, but still, the "reference". I'd very much prefer if it remained the most unbiased possible.

Biased how? As I posted in these threads— Bitcoin is _full_ of restrictions, its value is— in fact— derived almost entirely from restrictions.   Discouraging the creation of transaction outputs that yield fewer Bitcoins than they cost to spend is pretty "value neutral". It's a little insane that they can be created at all. As far as I'm aware a policy to restrict them doesn't discriminate against any kind of usage other than the "usage" of forcing hundreds of thousands of machines to archive non-bitcoin data against their operators consent. As far as I know it won't interfere with any publicly (or privately, for that matter) known service. So whats this bias that you speak of?   Please— point me to a currency use of Bitcoin that this will break, because if there is one then we need to figure that out! If it's something private, reach out to me via gpg encrypted anonymous email.

[gogxmagog]

why the fuck would you send less than 5uBTC to ANYBODY?

[gmaxwell]

why the fuck would you send less than 5uBTC to ANYBODY?

Lemme try to guess a few:

If you send them a whole bunch of really tiny outputs you can make their wallet really slow.

You could trick new users into solving captchas for very tiny payments because they don't realize that they won't be able to actually spend them.

If you send names you know lots of small payments you can hope that they get pulled into other transactions they make, cross linking their addresses, and deanonymizing them.

As far .. you know, actually paying someone? I haven't a clue.  Sufficiently small transactions, for some definition of sufficient, have 0 value if anything they have negative value, they aren't a payment.

[muyuu]

Can you walk me through who these people are, what they are doing, and how Bitcoin will be ruined for them?

Maybe gamblers (SD and similar) and small miners.

It should not have any impact on these parties. It's sad that people are getting worked up here over confusion and misguided guesswork.

Really small payouts for CPU miners?

Anyway, I don't think it's a problem but it should have been mentioned somewhere more public. "Transfers under 540 satoshis might struggle to get in the blockchain after XX date".

It's bad PR that someone breaks it to the forum like this, because it's a relatively substantial change in bitcoind.

[gmaxwell]

Really small payouts for CPU miners?

I don't believe any pool will pay less than 0.01 BTC except P2pool and even P2Pool's smallest current payout is 0.00253075 BTC right now (_well_ over the limit). It wouldn't be in the interests of the users to send them smaller amounts, because really tiny amounts cost more in txn fees to spend then they are worth. Not only that, if some pool did want to pay out less than 0.01 they still can— they're miners, they can mine whatever that want— this doesn't inhibit them.

Anyway, I don't think it's a problem but it should have been mentioned somewhere more public. "Transfers under 540 satoshis might struggle to get in the blockchain after XX date".

Would have been, and still will be— but 0.8.2 isn't even in RC yet. The change was merged to the development code shortly before this thread was created. (Actually, I hadn't even realized that it was actually merged yet when I joined in the discussion here).

[muyuu]

Looks like it was well decided 10 days ago (seeing the github conversation) and this thread was opened yesterday, basically when the code was already in.

This is something to announce on decision rather than on execution.

[Come-from-Beyond]

Doesn't this update create one more way to cheat merchants with 0-confirmations?

1. Send a transaction with one of the outputs below the threshold.
2. If it's not relayed to the merchant then connect to other peers and repeat step #1.
3. Enjoy free goods because ur transaction will likely not be included into a block.

[mollison]

Why not just decide an acceptable rate of growth for the blockchain per annum (e.g. 10 GB), limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

This seems to directly address the fundamental issue (the concern about too much data in the block chain), which we will eventually face anyway if bitcoin is successful.

[kokjo]

Why not just decide an acceptable rate of growth for the blockchain per annum, limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

This seems to directly address the fundamental issue (the concern about too much data in the block chain).

no that would be deflationary. we need to cut the block size in half every 8 years, its creates incentives for the miner to only include huge fee transactions.

[2D]

So why even have 8 decimal places in the first place then?

[muyuu]

So why even have 8 decimal places in the first place then?

This is a configurable variable. If valuation is so high 1 Satoshi is a non-negligible amount, there won't be spam at all and this variable could be set to 0.

[solex]

So why even have 8 decimal places in the first place then?

Because some time in the future 1 BTC just might be worth $1,000,000.00 (i.e. 1 satoshi = 1 cent).
However, Bitcoin will not get to this truly excellent state if it is suffocated in infancy with transactions which existing fiat systems deem too stupid to bother with.

why the fuck would you send less than 5uBTC to ANYBODY?

Exactly! Can anyone detail any previous fiat transaction they had for an amount < 1 cent?

[mollison]

Why not just decide an acceptable rate of growth for the blockchain per annum (e.g. 10 GB), limit block sizes accordingly, assume all blocks will potentially be completely filled up, and be done with it?

I need to update my suggestion. I have been told on IRC that the real problem is considered to be that unspent transaction outputs have to be stored in every fully validing node's memory. As opposed to the problem being total block chain size.

So my new suggestion is: Set a safe upper limit on the number of transaction outputs per block. Blocks with more outputs would be invalid and rejected by the network.

Advantages: Miners would optimize such that you need to pay a higher fee if you take up more of the unspent outputs in that block. Now, we let economic feedback kick in and we address the problem head on, rather than waiting for it to bite us as bitcoin usage grows and limiting dust transactions is not enough, since it only indirectly solves the problem.

Actually, you could do _both_ - set a safe upper limit on the block size to deal with storage issues and a safe upper limit on unspent outputs per block, too. Then you'd be totally safe.

[ABitBack]

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

[Matthew N. Wright]

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

That's exactly what Gavin referred to it as.

[Come-from-Beyond]

Not that it will affect me but this is absolutely not the right way to go about this. This has to be a temporary fix until they figure out what to do with the massive blockchain.

My experience says that temporary fixes stay forever.