I thought the idea was to prune spent outputs, not block new transactions?

[mustyoshi]

I thought the general consensus on blockchain size management was to prune spent outputs from the earlier blocks, so that the blockchain's size would be related to transaction volume instead of a history.

[1714949927]

1714949927

[1714949927]

1714949927

[jdillon]

I thought the general consensus on blockchain size management was to prune spent outputs from the earlier blocks, so that the blockchain's size would be related to transaction volume instead of a history.

The rational behind blocking is because the transaction would cost more in fees to redeem than it is worth, so they won't be spent and they'll have to be carried around forever.

[benjamindees]

That's not really a legitimate rationale.  Who's to say that, in the future, one Satoshi won't be worth enough to buy a meal and pay the transaction fee?

I had typed up a bunch of things to say about this, but they are premature.  Let's just say that this is just another datapoint in a worrying trend.

I would like to see a statement by the devs that this limitation is temporary, implemented for technical reasons, and subject to removal in the future.

[Blazr]

That's not really a legitimate rationale.  Who's to say that, in the future, one Satoshi won't be worth enough to buy a meal and pay the transaction fee?

Well of course then the patch will be removed and the tx fee structure changed appropriately, but for now we definitely need this patch as all of our wallets are full of unspendable dust thanks to SatoshiDice.

[benjamindees]

Well of course then the patch will be removed

You say "of course," but that isn't what has happened in the past.  Artificial, "temporary" technical limitations are now bandied about by "core" developers as "economically limited resourc(es)" for greedy, short-sighted miners and investors to fight over.

[Blazr]

You say "of course," but that isn't what has happened in the past.

Well if they don't remove it I'll fork the project on github and remove the patch myself, everyone can download an unpatched version then (nodes still relay the tx's, don't they?)

[etotheipi]

Small transactions are not blocked.  They will be discouraged by default, and now configurable by the individual miners.   But this is not even close to the kind of change that people have led themselves to believe it is.  This doesn't cause forks, and does not make any un-revertable change.  It simply adds a knob to the miner's software, preset to a a sane level to discourage creating coins that cost more to move than they're worth.  If people don't like the change, they can turn the knob back to the way it is right now.

Simply put, the default "knob setting" is to reduce propagation of transactions that are dust.  If you send out outputs that actually cost external coins to spend (which was determined to be approximately 54 uBTC), then nodes won't propagate it, and miners won't include it unless they have used their new configuration option to allow it.  Undoubtedly, if there's a lot of demand for these types of transactions to continue, many miners will choose to accept them, and many nodes will choose to relay them.  This means that your dust transactions won't get full hashing power, and might take a couple dozen blocks to make it into the network.  They are still valid, acceptable transactions, but may be difficult to send, and take a while to be accepted -- which actually seems like a good balanced level of discouragement.

If conditions change in the future such that 54 uBTC is a lot of money, miners will dial down that knob, and the developers will make the next release with a new default setting to accommodate the reality of that month. 

[gmaxwell]

I wanted to echo everything etotheipi said and point out that this is complementary with pruning.  Pruning deals with spent— historical— transaction outputs... but when there are transaction outputs which are not worth redeeming or are technically undependable (but not detectably so, e.g. because they are really just sneaking data into the block-chain) then those outputs can never be pruned.  As such, it's really important for us to be mindful of the txout bloat, since it doesn't have pruning as a tidy way to improve it.

[Remember remember the 5th of November]

Small transactions are not blocked.  They will be discouraged by default, and now configurable by the individual miners.   But this is not even close to the kind of change that people have led themselves to believe it is.  This doesn't cause forks, and does not make any un-revertable change.  It simply adds a knob to the miner's software, preset to a a sane level to discourage creating coins that cost more to move than they're worth.  If people don't like the change, they can turn the knob back to the way it is right now.

Simply put, the default "knob setting" is to reduce propagation of transactions that are dust.  If you send out outputs that actually cost external coins to spend (which was determined to be approximately 54 uBTC), then nodes won't propagate it, and miners won't include it unless they have used their new configuration option to allow it.  Undoubtedly, if there's a lot of demand for these types of transactions to continue, many m
iners will choose to accept them, and many nodes will choose to relay them.  This means that your dust transactions won't get full hashing power, and might take a couple dozen blocks to make it into the network.  They are still valid, acceptable transactions, but may be difficult to send, and take a while to be accepted -- which actually seems like a good balanced level of discouragement.

If conditions change in the future such that 54 uBTC is a lot of money, miners will dial down that knob, and the developers will make the next release with a new default setting to accommodate the reality of that month. 

I'm a miner but I can't do shit about anything. Oh wait, you mean pools, so we essentially let 10 people(read pool ops) control us?

[anti-scam]

Small transactions are not blocked.  They will be discouraged by default, and now configurable by the individual miners.   But this is not even close to the kind of change that people have led themselves to believe it is.  This doesn't cause forks, and does not make any un-revertable change.  It simply adds a knob to the miner's software, preset to a a sane level to discourage creating coins that cost more to move than they're worth.  If people don't like the change, they can turn the knob back to the way it is right now.

Simply put, the default "knob setting" is to reduce propagation of transactions that are dust.  If you send out outputs that actually cost external coins to spend (which was determined to be approximately 54 uBTC), then nodes won't propagate it, and miners won't include it unless they have used their new configuration option to allow it.  Undoubtedly, if there's a lot of demand for these types of transactions to continue, many m
iners will choose to accept them, and many nodes will choose to relay them.  This means that your dust transactions won't get full hashing power, and might take a couple dozen blocks to make it into the network.  They are still valid, acceptable transactions, but may be difficult to send, and take a while to be accepted -- which actually seems like a good balanced level of discouragement.

If conditions change in the future such that 54 uBTC is a lot of money, miners will dial down that knob, and the developers will make the next release with a new default setting to accommodate the reality of that month. 

I'm a miner but I can't do shit about anything. Oh wait, you mean pools, so we essentially let 10 people(read pool ops) control us?

Why don't you use P2Pool instead? Then you have complete control.

[mezzomix]

I'm a miner but I can't do shit about anything. Oh wait, you mean pools, so we essentially let 10 people(read pool ops) control us?

Why don't you use P2Pool instead? Then you have complete control.

100% ACK. You want to be a miner?! So do your work and mine!

At the moment you're selling your hashpower to a pool. That is different from beeing a miner.

[theymos]

Bitcoin-Qt will throw away these dust outputs (as fees), which will allow them to be pruned.

[Remember remember the 5th of November]

Will that let me control what TXs go in the block? Even when I didn't find it?

[mezzomix]

No. You control what you find. But at least you vote with your share of the hash power. If you are using another pool, the pool operator uses your hashpower and votes without asking you.

[Remember remember the 5th of November]

No. You control what you find. But at least you vote with your share of the hash power. If you are using another pool, the pool operator uses your hashpower and votes without asking you.

Then p2pool fixes nothing.

[tysat]

No. You control what you find. But at least you vote with your share of the hash power. If you are using another pool, the pool operator uses your hashpower and votes without asking you.

Then p2pool fixes nothing.

Or you don't understand how bitcoin/democracy works... your vote here is your hash power.

[kjj]

No. You control what you find. But at least you vote with your share of the hash power. If you are using another pool, the pool operator uses your hashpower and votes without asking you.

Then p2pool fixes nothing.

Except that p2pool blocks are generated locally.  There is no pool operator, just a consensus of what the payout transaction should look like.  Each p2pool user can set their own policy, and as long as they agree to pay the other users when they find a block, other users will pay them too.

[mezzomix]

Then p2pool fixes nothing.

How can you expect to get a larger piece of the cake than every other users?! You provide the hashing power and decide with your share of the hashing power what goes into a block or not.

If you mine at a large pool you pay a fee to the pool operator and have no vote about the transactions in a block.