WARNING! Bitcoin will soon block small transaction outputs

[DeathAndTaxes]

All the faucet sites have to implement off chain money boxes now

Or just .... I don't know dispense 0.06 mBTC or more at once (I know an utterly staggering sum of roughly half a penny).

[1714150089]

1714150089

[1714150089]

1714150089

[wolongong]

That, or resort to a "spinoff" like http://www.coinbox.me/ ..

[firefop]

Bitcoin is not suitable for micro transactions. This is all. Nothing new  here, it was pretty obvious from the very beginning that all those dusters are allowed to shit into blockchain only until there are not enough more serious transactions to fill the blocks.

If you want to spam blockchain, patch the client or use another one and hope that miners will be amenable to serve you for free.

I agree! I don't understand the querulous people. Bitcoin still suitable for micro transactions. But 54 uBTC is 0.000054 which is 0.006728 USD in the current exchange rate.

Micro transaction is 0.99 USD or 0.50 USD or 0.25 USD. Maybe 0.01-0.10 USD. But less than 0.01 USD is not micro. It is dust. Fragments.

By the way, the banks steal the cent fragments. The client only blocks them until their value increases enough.

This entire idea of limiting the size of transaction is a non-solution solution. Pure developer laziness imo. What really needs to be developed is a technical solution to the ever increasing block-chain-size. Some sort of native client support for truncating it in some way (while still having the option to get/keep the entire thing). Then the 'dust' as we're calling it can fall where it may according to free-market principles.

I will not be supporting this change and encouraging the bitcoin users I know to do the same.

[Inaba]

Yeah, this change is causing problems for me as well on EMC.  I definitely do not support it at this point.

I agree with Firefop.  A solution needs to be found that addresses the problem, not covers it up and ignores it.  At some point, even large transactions are going to bloat the block chain if bitcoin becomes popular enough... so it's a problem regardless of transaction size.

Even sendmany is rejecting payments less than the specified amount, when there are many, many other, larger values - that makes absolutely no sense.

[jgarzik]

This entire idea of limiting the size of transaction is a non-solution solution. Pure developer laziness imo. What really needs to be developed is a technical solution to the ever increasing block-chain-size. Some sort of native client support for truncating it in some way (while still having the option to get/keep the entire thing). Then the 'dust' as we're calling it can fall where it may according to free-market principles.

A "solution" of this type would simply not be bitcoin.  An ever increasing blockchain is an integral part of the system that you bought into.  Any other solution is no longer the zero-trust system Satoshi invented and that we all bought into.

Further, you cannot handwave away the problem that, if transactions is infinitesimally cheap, people will abuse the system by sending non-currency data messages. Lots of them. Gigabytes worth, as other alt-chain field experience has proven. To the point that bitcoin-the-currency transactions are impacted.

"I want a system that can process infinite amounts of traffic" is in the land of unicorns.

The accusation of dev laziness is particularly rich, given that SatoshiDICE abused the blockchain in this way, by sending informational messages (IM "You lost a bet") via the blockchain.

If you want an infinite amount of transactions per 10 minutes, you have just reinvented the Internet... over the blockchain. Poorly.

All that said, block chain size has an easy solution for the individual user -- use an SPV wallet.  And for the medium term, there are plans for distinguishing between archive nodes (those that store the full chain) and validating nodes (pruned).

[DeathAndTaxes]

This entire idea of limiting the size of transaction is a non-solution solution. Pure developer laziness imo. What really needs to be developed is a technical solution to the ever increasing block-chain-size. Some sort of native client support for truncating it in some way (while still having the option to get/keep the entire thing). Then the 'dust' as we're calling it can fall where it may according to free-market principles.

This has nothing to do with blockchain size however even the PRUNED blockchain needs the UXTO.  In economical transactions outputs have a high probability of being spent (become inputs on new transactions) thus while the blockchain may grow very fast the UXTO grows much slower.  This is a far more critical resource and will remain so even in the block limit is raised 10x or 100x larger.  

Uneconomical transactions (transactions which would require a fee larger than the value of the output to spend) are almost never spent.  Roughly half of the UXTO is transactions below 1 mBTC and roughly a quarter is below 0.01mBTC.  Since users will probably never spend them they remain unspent outputs and thus can't be pruned away.  They are necessary to validate blocks on the off chance someone ever does spend them in the future.  Nodes can't forget about them because it would be erasing Bitcoins and worse if some nodes did and some didn't then you would have a hardfork.

This means every node pays a perpetual cost for a transactions which never made economical sense to begin with.  

0.8.2 doesn't prevent spending dust it prevents (for nodes which agree to the default) relaying and including in blocks transaction which create NEW dust where dust is defined at 54.3% of min mandatory fee on low priority transactions.   

[kokjo]

for the medium term, there are plans for distinguishing between archive nodes (those that store the full chain) and validating nodes (pruned).

Could transaction format be changed to transmit less data? Here is one of raw transactions from Testnet:

Code:

{
  "hash": "f6c78bb23d47d129d24bf0774894e986e71ba73dd63f82419d9d537daa50c3a0", 
  "in": [
    {
      "prev_out": {
        "hash": "78d193036ee2815ae40265a486a859bb334b1853590da967f6ae8d64ca73f1a0", 
        "n": 0
      }, 
      "raw_scriptSig": "48304502207cdc4498097bab7efe2bb4db449b3fbd075b4d4bb8730bade12aad604b58...", 
      "sequence": 4294967295
    }
  ], 
  "lock_time": 0, 
  "out": [
    {
      "raw_scriptPubKey": "76a9148a84d1a0202fd4b77f9d0a84054e353f2732792a88ac", 
      "value": "48.99000000"
    }, 
    {
      "raw_scriptPubKey": "76a9147abf72ef083647cd2cb792c9435ce854bee00aee88ac", 
      "value": "1.00000000"
    }
  ], 
  "size": 192, 
  "ver": 1, 
  "vin_sz": 1, 
  "vout_sz": 2
}

I don't know what is "live" format for transactions Bitcoin clients receive and send, but if all data above is sent than I see a room for reduction.

its all the data above, but packed in a binary format.

the proposal is not to reduce a single transactions size. But let nodes choose which transactions which they want to receive, thus reducing bandwidth.

[solex]

Yeah, this change is causing problems for me as well on EMC.  I definitely do not support it at this point.

I agree with Firefop.  A solution needs to be found that addresses the problem, not covers it up and ignores it.  At some point, even large transactions are going to bloat the block chain if bitcoin becomes popular enough... so it's a problem regardless of transaction size.

Even sendmany is rejecting payments less than the specified amount, when there are many, many other, larger values - that makes absolutely no sense.

Doh! Just truncate BTC amounts to zero which are less than US 1 cent equivalent! And don't send that particular payment.
That is what every other company in the world does. Ever received a dividend check for 0.78c?
Just leave a credit amount on the client's account until/if it ever gets absorbed into other larger transactions.

[DeathAndTaxes]

You mean apostrophes, blanks, EOLs, trailing zeroes and long variable names are actualy part of transaction? If that is true, it is horrible deal.

No none of that is in the raw transaction.  That is simply formatting to make it easier for humans (like you) to parse the transaction. The format is somewhat complex but simplified version is take only the data above remove all formatting, white space , brackets, quotes, and all text.  That is the transaction.

[firefop]

This entire idea of limiting the size of transaction is a non-solution solution. Pure developer laziness imo. What really needs to be developed is a technical solution to the ever increasing block-chain-size. Some sort of native client support for truncating it in some way (while still having the option to get/keep the entire thing). Then the 'dust' as we're calling it can fall where it may according to free-market principles.

A "solution" of this type would simply not be bitcoin.  An ever increasing blockchain is an integral part of the system that you bought into.  Any other solution is no longer the zero-trust system Satoshi invented and that we all bought into.

Further, you cannot handwave away the problem that, if transactions is infinitesimally cheap, people will abuse the system by sending non-currency data messages. Lots of them. Gigabytes worth, as other alt-chain field experience has proven. To the point that bitcoin-the-currency transactions are impacted.

"I want a system that can process infinite amounts of traffic" is in the land of unicorns.

The accusation of dev laziness is particularly rich, given that SatoshiDICE abused the blockchain in this way, by sending informational messages (IM "You lost a bet") via the blockchain.

If you want an infinite amount of transactions per 10 minutes, you have just reinvented the Internet... over the blockchain. Poorly.

All that said, block chain size has an easy solution for the individual user -- use an SPV wallet.  And for the medium term, there are plans for distinguishing between archive nodes (those that store the full chain) and validating nodes (pruned).

The assumption that SatoshiDICE is 'abusing' the blockchain is patently false. It's a consent driven network - users should be able to use it in any way they like without artificial barriers like this being put in place.

As for handwaving (and unicorns) - There are solutions that would be possible given existing tech and being novel in it's application and methods.

If bitcoin goes this route it will doom itself to a series of hard forks followed by eventual regulation and failure. Instead of trying band-aid fixes lets actually address the problem which is (blockchain) size. How much of it would a client actually need to store? What about compressing the blockchain after the fact... simple groupings of balances by value as an index might help for starters. I really doubt we're storing it in the most effecient way possible.

Another thing is - once you've got the network agreeing on a truncated format for old (archived?) blocks - it's easy enough for someone to later use the dust - all that changes is that entry would be absent from the value index at the next demarkation.

So lets start thinking in terms abstracting the blocks in the chain once they get past a certian 'age' and actually develop a technical solution instead of heading down this road.

[scintill]

Yeah, this change is causing problems for me as well on EMC.  I definitely do not support it at this point.

I agree with Firefop.  A solution needs to be found that addresses the problem, not covers it up and ignores it.  At some point, even large transactions are going to bloat the block chain if bitcoin becomes popular enough... so it's a problem regardless of transaction size.

Even sendmany is rejecting payments less than the specified amount, when there are many, many other, larger values - that makes absolutely no sense.

Doh! Just truncate BTC amounts to zero which are less than US 1 cent equivalent! And don't send that particular payment.
That is what every other company in the world does. Ever received a dividend check for 0.78c?
Just leave a credit amount on the client's account until/if it ever gets absorbed into other larger transactions.

Agreed.  I understand Inaba's frustration in being burned by this once, but it should be pretty easy to update your code to just filter out tiny payments.  Alternatively, remove the dust threshold and mine the payouts yourself, but please consider DeathAndTaxes' stats (I haven't verified them myself) about how tiny outputs hardly ever get spent -- your own mining nodes will bear the permanent UTXO bloat cost of uneconomical payouts to your users.

[Peter Todd]

Yeah, this change is causing problems for me as well on EMC.  I definitely do not support it at this point.

How is this a problem for you? EMC is a mining pool and can mine whatever transactions they want.

[Inaba]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

[Peter Todd]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

Unfortunately if you relay a transaction that is unlikely to get mined you make the whole Bitcoin network vulnerable to DoS attacks by flooding it with transactions; essentially you are using network bandwidth without paying for it. Gavin wants to make the dust limit adaptive to what miners actually mine, but doing so won't be easy and P2P layer changes are always risky.

As always, if you feel strongly that you want your pool to mine such transactions and want to let people create them, you can always advertise a node to submit such tx's to directly. In fact I think it's enough to just connect your pool's nodes to 173.242.112.53, which relays any transaction indiscriminately regardless of fee or even if it passes the IsStandard() test.

[DeathAndTaxes]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

Well at this time the client doesn't "know" if a miner will include a particular transaction or if it will even be relayed to a miner.  The end state is like a higher level "fee/node/miner discovery" protocol which would allow the client to make intelligent predictions on if a transaction will be relayed/mined, how long it will take and how much improvement in expected confirmation time an increased fee produces.

[kjj]

Mining of transactions aren't a problem, and EMC continues to mine dust outputs.  However, I keep a reference client to make sure things are working properly and I can no longer use sendmany to send small outputs without modifying the reference client.  That's my issue/beef with this.  The client is artificially being forced to prevent sending, disregarding whether or not a miner will include it in a block.

The solution is to let the miners decide, not force the client into a specific course of action, thereby taking the decision out of the hands of the miners.

Or, you could just set your -minrelaytxfee option to something lower than the default.  Much easier than "modifying the reference client".

[Eri]

Im Pro dust! etc etc

Im Anti dust! etc etc

Hi, im just curious where exactly your pool stands on this issue.. so let me ask...

If i have 500 dust transactions sitting in my wallet and i wanted to tidy them all up. Can i make a transaction sending them all to one address and include no fee.. (or just the default fee of .0001 and have your pool mine it?

[kokjo]

its all the data above, but packed in a binary format.

You mean apostrophes, blanks, EOLs, trailing zeroes and long variable names are actualy part of transaction? If that is true, it is horrible deal.

do you have a problem reading, sir?

go educate yourself: https://en.bitcoin.it/wiki/Protocol_specification

[MrKain]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

Again, I dont understand - how can Gavin change anything, other than what a new release
of a client does -
If I continue to use an older client , why / how would my small transactions be blocked ??

[Eri]

Gavin Andresen has changed the Bitcoin code to block any output with a value of less than 54uBTC:

Again, I dont understand - how can Gavin change anything, other than what a new release
of a client does -
If I continue to use an older client , why / how would my small transactions be blocked ??

The short answer is Gavin gave us the tools to choose. He gave us free will with regard to bitcoin.  Picture a football field filled with 10,000 people, each one keeping track of transactions, Your the guy on the 10 yard line next to the guy in a wheres waldo outfit.

With this change you as an individual can choose what message you will or wont pass on to the people around you. Before the change you didnt have this choice, you didnt have free will. you had to blindly pass on what was given to you.

If enough people choose to not pass on certain transactions the message wont go anywhere even if you send it. But its not as simple as blocking stuff to be mean. its a matter of each individual deciding what is and isnt good to send. If you cant make this choice due to lack of information, they are kind enough to have a default set. (Keep in mind, in versions before 0.8.2, you had no choice in this. Your client had a built in number, you either used it or you didnt use bitcoin.)

This number was set to a default value that fits bitcoin at its current value. That means if you try to send something below that value, the network would ignore it. if its over that value, they pass it on. But everyone can choose what to set, What they will ignore and what they will pass on.

being against the change is being against your ability to choose.