Treat dust outputs as non-standard, un-hardcode TX

gavinandresen commented at 2:35 pm on April 26, 2013: contributor

This is a quick, safe fix for transaction fee handling. A riskier, more complicated fix still needs to happen, but will take more time to code/test/etc.

Two motivations for this pull:

First, to discourage people from bloating users’ wallets and the UTXO set with tiny outputs.

This pull defines ‘uneconomic dust’ as 54.3 uBTC (5430 satoshis, about $0.007 at current prices), and treats any transaction with outputs less than 5430 satoshis as non-standard (won’t be relayed, won’t be mined). 5430 satoshis is derived from the cost (in fees) to spend a TxOut/TxIn. See https://people.xiph.org/~greg/txouts2.png for proportion of recent outputs this will (eventually) affect.

Second, we have no idea what will happen to Bitcoin prices or transaction volume / competition for space in blocks. So this patch lets users and miners specify the minimum transaction fees at startup, using the -mintxfee / -mintxrelayfee options (which I’m intentionally leaving undocumented for now). The dust/nonstandard test is based on the -mintxrelayfee.

Qt and RPC both now tell the user why CreateTransaction fails, if it fails; Qt error reporting is a little wonky (try to send one satoshi, and you get two modal dialog boxes, one after the other; I don’t care enough to try to fix that).

Note: I spent several hours trying, and failing, to create unit tests for this patch; CWallet::fFileBacked is ignored by several of the wallet routines used by CWallet::CreateNewTransaction. In the end, I decided thatrefactoring CWallet to support unit testing would be much more extensive and riskier than these changes.

laanwj commented at 2:38 pm on April 26, 2013: member

We’d also want to change #2576

jgarzik commented at 3:21 pm on April 26, 2013: contributor

ACK

gmaxwell commented at 3:24 pm on April 26, 2013: contributor

Gavin, Can you make IsDust() return true for zero no matter what value MIN_RELAY_TX_FEE is or just make the ==0 test separate? I don’t want to open up zero value floods for people who decide that they want to lower mintx/mintxrelay and find that 0 is easier to type than 0.0000001.

gavinandresen commented at 3:38 pm on April 26, 2013: contributor

It won’t open up flooding if the rest of the network refuses to relay or mine those transactions. And I hate making code that I’m planning on replacing soon more complicated.

in src/qt/walletmodel.cpp: in 8ab26ffbcc outdated

189@@ -189,6 +190,7 @@ bool WalletModel::validateAddress(const QString &address)
190             {
191                 return SendCoinsReturn(AmountWithFeeExceedsBalance, nFeeRequired);
192             }
193+            emit message(tr("Send Coins"), QString::fromStdString(strFailReason), CClientUIInterface::MODAL);

Diapolo commented at 4:03 pm on April 26, 2013:

Gavin, if you want this to be an error please use CClientUIInterface::MSG_ERROR or CClientUIInterface::MSG_WARNING for a warning :).

in src/init.cpp: in 8ab26ffbcc outdated

560+    // If you are mining, be careful setting this:
561+    // if you set it to zero then
562+    // a transaction spammer can cheaply fill blocks using
563+    // 1-satoshi-fee transactions. It should be set above the real
564+    // cost to you of processing a transaction.
565+    if (mapArgs.count("-mintxfee"))

Diapolo commented at 4:04 pm on April 26, 2013:

These 2 switches are not mentioned in our init.cpp help-message, is this intended?

gmaxwell commented at 4:10 pm on April 26, 2013:

(which I’m intentionally leaving undocumented for now)

Yes.

gavinandresen commented at 4:58 pm on April 26, 2013: contributor

Rebased to make the qt an Error as suggested by @Diapolo, and tell the user they screwed up if they give bad -mintxfee/minrelaytxfee values.

Don’t know why github is confused about the commits…

gmaxwell commented at 5:14 pm on April 26, 2013: contributor

ACK on approach now. Will test.

petertodd commented at 8:39 pm on April 26, 2013: contributor

You still need to change CWallet::CreateTransaction() so it doesn’t create dust change txouts; see https://github.com/petertodd/bitcoin/commit/0df65da397f5b1927783f7a8dba2f69e1cfef3ff#L1L1192

EDIT: no, actually that’s specific to the way my patch works, because in it dust could be defined as greater than nMinFee, so you are correct.

luke-jr commented at 9:04 pm on April 26, 2013: member

Will this prevent spending from transactions with dust outputs as well (since we now check that inputs are standard)?

petertodd commented at 9:07 pm on April 26, 2013: contributor

No.

See CTransaction::AreInputsStandard()

gavinandresen commented at 0:59 am on April 27, 2013: contributor

@petertodd : I added belt-and-suspenders code, since we don’t have good CreateTransaction unit tests. @sipa: why not indeed.

I’ll squash the two commits before final pull.

BitcoinPullTester commented at 1:59 am on April 27, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/9ac9a459c3fcab63e70d3780d730744cc55ba76f for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

in src/qt/walletmodel.cpp: in 9ac9a459c3 outdated

189@@ -189,6 +190,8 @@ bool WalletModel::validateAddress(const QString &address)
190             {
191                 return SendCoinsReturn(AmountWithFeeExceedsBalance, nFeeRequired);
192             }
193+            emit message(tr("Send Coins"), QString::fromStdString(strFailReason),
194+                         CClientUIInterface::MODAL|CClientUIInterface::MSG_ERROR);

Diapolo commented at 3:41 pm on April 27, 2013:

@gavinandresen CClientUIInterface::MSG_ERROR includes CClientUIInterface::MODAL, that’s why I mentioned it the first time :).

mikehearn commented at 3:57 pm on April 28, 2013: contributor

What is the longer term plan for this? 0.007 dollars is not very small. It only takes one doubling of the price to mean you can no longer send a payment of 1 cent, which is pathetic, even physical cash can handle that. And in the past we’ve seen 10x increases in price happen extremely fast. 1 cent isn’t even a micropayment, that’s just “payment”.

Whatever the ultimate plan is, it doesn’t seem like this intermediate state is going to be very helpful. It’ll just result in the same problem we have today, hard-coded magic numbers that become inappropriate much faster than they can be changed. Do you really see node operators changing the command line flags?

I really think we should scrap the word “dust”. It implies some kind of constant valuation, which Bitcoin doesn’t have. What looks pointless today can look useful tomorrow.

mikehearn commented at 4:21 pm on April 28, 2013: contributor

OK, to clarify, I agree that this change is an improvement over the old state in that it at least reduces the quantity of magic numbers and makes them derived from a single value. But it’d be nice to know the roadmap here.

johndillon commented at 5:42 pm on April 28, 2013: none

Ack

Yesterday the fingerprints of every key in the PGP strong set as well as every key on bitcoin-otc were timestamped permanently in the blockchain for a cost of only $150 or 0.3 cents per timestamp. (I also paid 1.5BTC to the person who did it for me for their time)

50,000 new entries in the UTXO set that all validating nodes will forever have to have a copy of unless Bitcoin develops centralized blacklisting schemes. (yes I know you can use the data to prove it doesn’t belong in the blockchain, they are SHA1 hashes so have fun if SHA1 is broken)

According to my PGP keyserver data dump there are 3.2 million PGP keys floating around on keyservers. Timestamping every last one of them would just cost about $32,000 at a penny each for fees and vanished bitcoins, and add 120MB to the txout set. $32k may buy a lot of harddrives, but it doesn’t buy enough harddrives to really pay the cost of storing those transactions forever.

Notice how I didn’t say “attacker”. Timestamping is just one of many reasons why demand for transactions is unlimited.

The developers are absolutely right to price such junk out of the blockchain but aren’t going far enough.

MeniRosenfeld commented at 5:43 pm on April 28, 2013: none

This will make it impossible to use Bitcoin for colored coins, and some other applications which have information content beyond the mere transfer of value.

I am of the opinion that people should be able to do what they want in the transaction, as long as they pay for the resources consumed.

gavinandresen commented at 5:43 pm on April 28, 2013: contributor

Road map:

Re-implement the memory pool, and keep statistics on transactions that enter and then leave by being included in a block. Protect CTransaction::nMinFee/nMinRelayFee with a mutex, and modify those by that memory pool code.

So IsDust() will be based on what is actually being accepted into blocks, and will adjust appropriately.

Do the same for free transactions (estimate priority needed to get included in block).

Modify the RPC code to either send for free (if priority is high enough, based on estimate) or send with reasonable fee (based on fee estimate).

And modify GUI code to either just send for free or recommend sending with a fee.

johndillon commented at 6:45 pm on April 28, 2013: none

@gavinandresen Nice technical details. But how expensive do you expect a transaction to be? That is the real issue and that is the one that drives scalability. What are you going to tell the people doing tiny transactions like tipjars, just leave Bitcoin?

gavinandresen commented at 8:26 pm on April 28, 2013: contributor

@johndillon : Bitcoin is not appropriate for transactions less than a penny or three.

If Moore’s Law continues to hold, then one day it might be.

That is all out of scope for this pull request; if we do nothing, then we are stuck with MIN_RELAY_TX_FEE=0.0005 BTC.

jgarzik commented at 8:30 pm on April 28, 2013: contributor

@gavinandresen ACK general roadmap

johndillon commented at 2:48 am on April 29, 2013: none

@gavinandresen Good to hear. When people try to get the blocksize raised for the sake of penny transactions I’ll be able to tell my fellow investors that people are trying to fundamentally damage Bitcoin’s decentralization for the sake of penny bets.

Moore’s law doesn’t apply to bandwidth, and Moore’s law is on it’s last legs anyway.

petertodd commented at 3:28 am on April 29, 2013: contributor

@johndillon Seriously, take politics off github.

mikehearn commented at 9:48 am on April 29, 2013: contributor

Sounds good to me.

Minor detail: the formula doesn’t take into account that pay-to-pubkey outputs can be spent with smaller inputs, but I suppose it doesn’t matter at this point given the dominance of pay to address.

Could we bump the protocol version too? I know it’s kind of a hack but it might make it easier during the deployment period - otherwise wallets might create transactions too small to get relayed if they’re newer than most of their peers. I’ll file a bug in bitcoinj to implement these rules.

simondlr commented at 10:03 am on April 29, 2013: contributor

Question. If I understand this correctly. Acceptable mintxfee/minrelayfee will now be determined by the miners (default is 0.0001 BTC)? However, currently, there would be no way to know what’s the minimum fee to be reasonably included (http://bitcoin.speedstats.org/) in the next block? I see that’s on the roadmap.

But for now, it would just be best to stick with 0.0001 BTC/KB for doing transactions?

luke-jr commented at 12:56 pm on April 29, 2013: member

It makes no sense to bump the protocol version, as there are no protocol changes here…

petertodd commented at 3:55 pm on April 29, 2013: contributor

@simondlr http://bitcoin.speedstats.org/ is quite wrong. The cost to send a transaction is related to it’s size, not it’s value. (there are some exceptions to deter abuse of free or spam transactions) Transaction fees are a process where you bid for a limited amount of blockchain space, so we can’t tell you an exact number and demand for blockchain space changes day by day and hour by hour. @mikehearn Bumping the protocol version doesn’t help much because nodes can only use that information with a code change, in which case they should just follow the new rules instead.

simondlr commented at 4:27 pm on April 29, 2013: contributor

@petertodd ah yes. Of course. Thanks! Isn’t the plan with the memory pool to dynamically check what tx fee (per kb) is needed to be included in the block? Thus you will know by the hour (or per block)? Or am I getting it wrong? I tried finding the discussion on the memory pool, but couldn’t find it. Can someone link it to me please?

mikehearn commented at 5:02 pm on April 29, 2013: contributor

The protocol is changing because the IsStandard rules are changing. The problem is version skew. We don’t know when this new code will be released and we don’t know how fast people will upgrade. So my problem is, let’s say we release new Android apps tomorrow that think the fee is now 0.0001/kb. People will start complaining that their sends don’t go through. If there’s a new protocol version the app can just measure the majority version and when it seems most nodes have upgraded, switch to the new rules and assume that 50% nodes will allow good enough propagation to the miners.

petertodd commented at 5:19 pm on April 29, 2013: contributor

I think we’d all prefer that nodes just follow the new rules regardless of what the majority are doing…

That said does bitcoinj and by extension the Android wallets have any mechanism to tell the user when the majority of bitcoin nodes they are connected to are of a higher protocol version number than expected? It’d be a perfectly good “you might want to upgrade your software” mechanism, albeit one that can have false positives.

In general though we should not bake in an assumption that propagation of any given transaction is reliable enough to just send and forget. Watching for transactions coming back to you from other nodes is a very good practice. For instance, send the transaction to one peer first, and see if your other peers broadcast it to you before you try them as well.

schildbach commented at 5:43 pm on April 29, 2013: contributor

@petertodd Nothing like that yet in Bitcoin Wallet. It updates when a new version is uploaded to the market. So this 50% switch thing could be implemented manually by uploading the right version at the right time.

mikehearn commented at 6:26 pm on April 29, 2013: contributor

Yeah, we already watch for propagation which helps, but if it doesn’t propagate then the user is still out of luck. We can indeed do what we did fore bloom filtering and just wait, but even for that we had version gating because the peer selection is sort of random. Bumping the version doesn’t cost anything so why not do it? On 29 Apr 2013 19:20, “Peter Todd” notifications@github.com wrote:

I think we’d all prefer that nodes just follow the new rules regardless of what the majority are doing…

That said does bitcoinj and by extension the Android wallets have any mechanism to tell the user when the majority of bitcoin nodes they are connected to are of a higher protocol version number than expected? It’d be a perfectly good “you might want to upgrade your software” mechanism, albeit one that can have false positives.

In general though we should not bake in an assumption that propagation of any given transaction is reliable enough to just send and forget. Watching for transactions coming back to you from other nodes is a very good practice. For instance, send the transaction to one peer first, and see if your other peers broadcast it to you before you try them as well.

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17180671 .

petertodd commented at 6:30 pm on April 29, 2013: contributor

Among other things it makes it easy for implementations to find nodes that don’t follow the new rules to try to get their non-compliant transactions propagated. Just follow the new rules and be done with it.

jspilman commented at 7:37 am on April 30, 2013: none

No response to MeniRosenfeld’s comment about colored coins? IsDust -> NonStandard ban-hammer seems unnecessarily opinionated when you can just directly charge for the resources being consumed.

If cost is a factor of bytes and UTxO, it seems reasonable that fee should be based on bytes and the UTxO growth (OutCount - InCount). Yes, if InCount > OutCount then it could offset the the byte fee.

For example, donating spare change to miners is still a good idea if you pay less overall fees for having one less output.

petertodd commented at 8:14 am on April 30, 2013: contributor

You know, if the colored coin people can’t figure out how to make colored coin systems work with this patch, screw them. I’ve told them how to do it right multiple times and they don’t listen, which is plenty enough evidence that they’re amateurs who don’t understand what they’re doing. So why let their lack of imagination threaten Bitcoin?

mikehearn commented at 8:58 am on April 30, 2013: contributor

Huh? If an implementation wants to try propagating a non-standard transaction it can just blast it out to half its peers and see if it hears it back on the other half. Or it can time how long it takes for those transactions to appear in the chain, or submit directly to a pool that accepts them, or many other things.

It’s not like we’re going to run out of version numbers. As a client implementor, I’m saying it would help in the case where release schedules aren’t aligned.

petertodd commented at 5:14 pm on April 30, 2013: contributor

Tell you what, lets go a little farther with your idea and add a new service bit NODE_RELAYCOST. Nodes with that service bit set will also advertise the minimum txout value they will propagate, as well as the minimum fee/KB or priority/KB required for them to relay a transaction. We can then hardcode the current defaults as the assumption for nodes that do not have that bit set.

BlueMeanie commented at 6:09 pm on April 30, 2013: none

@petertodd , with all due respect, could you please link us to your proposal re. Colored Coins? I have been participating in the discussion on the Google Group, and I pointed out the problem re. Microtransactions about a week ago. I agree with many of your stated frustrations. Thanks.

dacoinminster commented at 6:56 pm on April 30, 2013: none

Please don’t treat micro-transactions as non-standard. A small amount of bitcoins can represent large amount of value in higher protocol layers. Colored coins is just one example.

Could we perhaps just raise the suggested fee on transactions which contain “dust”?

gmaxwell commented at 6:59 pm on April 30, 2013: contributor

@dacoinminster instead of raising the fee— funds you lose forever— just increase the value of the tracking txouts you use. This avoids the problem of creating perpetual txout set data-bloat which will never be swept up because doing so costs more than the redeemed output yields. No amount of txfee increases can approximate that.

petertodd commented at 7:21 pm on April 30, 2013: contributor

@BlueMeanie Sure: https://github.com/petertodd/trustbits/blob/master/fidelitybond.md#contracts It’s from my fidelity bonds stuff, but the mechanism is just a way of doing colored coins really. The advantage is that because value isn’t a fixed ratio of shared to satoshi’s you can divide however much you want and still avoid dust rules, and it’s friendly to SPV nodes. Now if your bond value is smaller than a tx fee, well, use a off-chain tx system that’s compatible with Bitcoin transactions, basically a blockchain who’s contents is guaranteed by a third party. @gavinandresen commented on the forums that miners can sybil the network and create nodes that lie about RELAYCOST to, say, drive up fees, but equally miners can create nodes that just don’t relay transactions with low fees to others with the exact same effect.

gmaxwell commented at 7:25 pm on April 30, 2013: contributor

I think the motivational structure about lying about relay cost is different than actually not relaying. The issue is one of market segmentation, e.g. by actually not relaying you block all stuff, vs lying about costs you get all that are willing to pay to pay it. Observation is better than announcement. OTOH it may be possible to only have relay cost lower some sane default.

katuma commented at 8:28 pm on April 30, 2013: none

@BlueMeanie: Impact on colored coins does not really belong here, this has been brought up a week ago on the mailing list you mention, without any satisfactory answer. Peter’s way seem plausible on paper, but it’s yet to be seen about implementation. After all, when you see retep’s code, it’s christmas.

BlueMeanie commented at 8:41 pm on April 30, 2013: none

@petertodd , thank you. There is some follow up on your ideas and their relevance for Colored Coins here

petertodd commented at 8:43 pm on April 30, 2013: contributor

@gmaxwell That’s a good point, although I’m also thinking farther into the future where transaction replacement may mean that nodes want to limit the traffic from replacements that they’re getting. @BlueMeanie Um, no, that’s not what I’m suggesting, just a part of it. Read that paper please…

killerstorm commented at 10:19 pm on April 30, 2013: none

I don’t think this change will create significant problems for “colored coins”.

I mean, it’s strange that you’re doing this, but I guess we can live with it. @petertodd Your mechanism cannot handle more than one color in one transaction without mandatory tagging, which adds to blockchain bloat. I see no advantages over order-based coloring. We considered odd-even, tagging and similar ideas. Order-based scheme is the most straightforward and carries minimal overhead.

petertodd commented at 10:53 pm on April 30, 2013: contributor

@killerstorm I outlined a mechanism where the tagging is integrated into the pubkey; no extra bytes at all in the blockchain. If that’s too complex you can use a OP_RETURN <20 bytes> txout to mark txouts with data that can be immediately pruned.

BlueMeanie commented at 4:24 am on May 1, 2013: none

@petertodd I do agree that the concept they are currently running with @BitcoinX/Color Coins ignores the economics of transaction processing. It’s exploiting the fact that transactions of any size are processed without discretion. The points made in this thread show that this model is not viable, and not acceptable for the Bitcoin community. There is more detail in my posts on the Google Group.

killerstorm commented at 7:02 am on May 1, 2013: none

@BlueMeanie LOL. You failed to understand that Peter’s contract value accounting also uses satoshi value of unspent transaction outputs. It is just that it uses a different encoding scheme, a scheme which provides better divisibility.

I don’t think there is a problem with “the economics of transaction processing” in either of these schemes. That’s just your opinion, do not pretend that it is widespread.

Let’s close this discussion here (I mean discussion of ‘colored coins’ and related), there is a mailing list or a forum for that.

BlueMeanie commented at 11:59 am on May 1, 2013: none

@killerstorm seems the discussion on that list involves those who are invested in particular ideas about colored coins. I reviewed @petertodd’s idea, personally I think that a ‘colored coin’ solution lies in alt-chains and using the main BTC block chain is not appropriate for this application. If someone can convince me otherwise in a credible way, I’m all for it. I have yet to see that. This is the place to raise these points because the plan that currently dominates on the list affects the issue of Coin Dust and Tx fees directly. Personally I think most are avoiding the topic on the list.

Define dust transaction outputs, and make them non-standard 8de9bb53af

CreateTransaction: return strFailReason on failure 1f00f4e9c9

Un-hardcode TX_FEE constants

Allow setting of MIN_TX_FEE / MIN_RELAY_TX_FEE with
-mintxfee / -mintxrelayfee

Default values are the same (0.0001 BTC).

000dc55181

gavinandresen commented at 2:55 pm on May 3, 2013: contributor

Rebased and picked a couple of nits. Can I get some final ACKs ?

jgarzik commented at 3:15 pm on May 3, 2013: contributor

ACK

BitcoinPullTester commented at 4:04 pm on May 3, 2013: none

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/000dc55181f77cd96076c76b2cc13f8bcbe4146e for binaries and test log. This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/ Contact BlueMatt on freenode if something looks broken.

sipa commented at 10:05 pm on May 3, 2013: member

Code ACK; I haven’t thought enough about the policy itself to comment, but don’t let that stop you.

gmaxwell commented at 10:29 pm on May 3, 2013: contributor

ACK. Even if the exact policy turns out to have been ill-advised in retrospect the threshold is so small that its unlikely to cause substantial harm, and the increase in cost for flooding is a nice result.

gavinandresen referenced this in commit 33edd0a477 on May 4, 2013

gavinandresen merged this on May 4, 2013

gavinandresen closed this on May 4, 2013

pentarh commented at 7:00 pm on May 5, 2013: none

Guys, you are breaking the bible.

“Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services. "

Satoshi Nakamoto whitepaper

gmaxwell commented at 8:38 pm on May 5, 2013: contributor

@pentarh I disagree. Sending a flood of femtocents at someone isn’t a “transaction”. Bitcoin has long had limitations on the sending of very tiny transactions— the original ones added by satoshi himself.

pentarh commented at 8:55 pm on May 5, 2013: none

@gmaxwell I agree that spam is an issue, but it should be changed in different way. Breaking fundamentals is a bad way IMHO, because its a precedent for further breaking. Does youtube banning out small and not popular videos? No. Youtube just extending storage. I think Bitcoin needs scalable distributed DHT-like block chain storage.

gmaxwell commented at 9:08 pm on May 5, 2013: contributor

@pentarh Perhaps you misunderstand what this does. This is not a protocol-rule change. Miners can still include the same transactions they can now, though this pull makes ‘picocent’ payments not get included by default unless they change a threshold setting (useful if the value of Bitcoin changes greatly).

“scalable distributed DHT-like” is a total arm-wave. DHTs are not strongly attack resistant and are generally not very suitable for the interesting challenges in the Bitcoin system. In order to be a decenteralized system all full nodes must inspect all transactions and have rapidly reliable access to the set of spendable outputs. You can make various storage vs bandwidth tradeoffs, but we’re constrained on both.

The obvious alternative to abuse based on tiny worthless outputs is to add fees, which was satoshi’s solution. But with sendmany Satoshi’s solution was obviously not aggressive enough (you’d send one fee and N junk outputs). Litecoin addressed that by multiplying the fee by the number of outputs but this quickly becomes obnoxious and still doesn’t prevent the abuse. Better to address the creation of worthless tx outputs directly and better to send most of your anti-abuse ‘fee’ to your destination in order to make the abuse not abuse rather than give it away to a third party.

jgarzik commented at 9:18 pm on May 5, 2013: contributor

It is not breaking fundamentals – bitcoin has never ever been a micro-transaction or micro-payment system.

johndillon commented at 9:37 pm on May 5, 2013: none

It is not breaking fundamentals – bitcoin has never ever been a micro-transaction or micro-payment system.

Good, but we need Gavin to explain that publicly, explain what kind of fees he is expecting in the future and why, and explain what trade-offs he is willing to make between decentralization and low fees. Or, if you want, all core developers can make some public statements about this.

But to just surprise people with a change with no warning or any sense of what they should be doing to keep their businesses running isn’t acceptable.

awfm9 commented at 11:31 pm on May 5, 2013: none

I’m currently starting a company that I hoped would bring innovation and diversity to the landscape of the Bitcoin economy, and this comes as a huge shock to me.

Neither this, nor the MIN_RELAY_TX_FEE=0.0005 BTC are required, Gavin. It’s ridiculous that you claim they are. If people agree the dust transactions are a problem, then find a real solution. An effortless one, that is as well designed as Bitcoin itself.

This is something that should be 100% up to the miners to decide on. If you go through with this, you join the game of doing politics, and it’s not your place to do so. It’s not up to you to decide whether Bitcoin is a micro-transaction system. It’s up to the users and the innovators.

I swear, if this happens, Bitcoin is dead to me. I will direct all efforts and all capital of my company onto an alternative crypto-currency the second this is released as standard in any Bitcoin version.

cjdelisle commented at 0:05 am on May 6, 2013: none

ACK The code looks good, this is a reasonable approach to preventing dust spam and raising the bar for people crapping up the chain with arbitrary data.

This does not materially affect “deterministic satoshi tracking” colored coin implementations, which is IMO the only sane design for a number of reasons.

gmaxwell commented at 0:09 am on May 6, 2013: contributor

@awishformore uh. Perhaps you too are confused. This is not a protocol rule, it’s a default behavior which is configuration adjustable. Miners can still happily mine transactions not meeting this rule if they choose to.

Weird to here you talk about other cryptocurrencies, as many (most? all?) have much more aggressive anti-dust rules than Bitcoin. We previously declined to merge the ones from litecoin.

awfm9 commented at 0:12 am on May 6, 2013: none

@gmaxwell then it should be off by default, not on. Yes, you don’t change the protocol. What you do is even worse - you pretty much disable something that is considered legal and valid by the protocol.

If you declined to merge the Litecoin approach, I really don’t get how you can even consider implementing such an ill-conceived dirty fix into Bitcoin, which should be the flagship crypto-currency.

petertodd commented at 0:15 am on May 6, 2013: contributor

@awishformore We do need better communication of this stuff, and that includes doing things like taking “Low or zero processing fees” off of bitcoin.org and not talking about microtransactions.

Just the other day I was on the phone with an investor working on some payment system thing who had never heard of the blocksize limit at all.

robbak commented at 0:18 am on May 6, 2013: contributor

@awishforme: If you are creating a business that relies on creating many unspendable outputs, and this patch persuades you not to do so, then I’d say it has done it’s job. The growth of unspendable and near unspendable outputs is a real and growing problem. On 06/05/2013 9:31 AM, “awishformore” notifications@github.com wrote:

I’m currently starting a company that I hoped would bring innovation and diversity to the landscape of the Bitcoin economy, and this comes as a * huge* shock to me.

Neither this, nor the MIN_RELAY_TX_FEE=0.0005 BTC are required, Gavin. It’s ridiculous that you claim they are.

This is something that should be 100% up to the miners to decide on. If you go through with this, you join the game of doing politics, and it’s not your place to do so.

I swear, if this happens, Bitcoin is dead to me. I will direct all efforts and all capital of my company onto an alternative crypto-currency the second this is released as standard in any Bitcoin version.

— Reply to this email directly or view it on GitHubhttps://github.com/bitcoin/bitcoin/pull/2577#issuecomment-17461469 .

ghost commented at 1:15 am on May 6, 2013: none

Why are you leaving it undocumented? Everything should be documented. People should know what is going on and change what behavior they don’t find acceptable.

mikegogulski commented at 1:29 am on May 6, 2013: none

@pentarh Fuck the “bible”. Even Satoshi, peace be upon Him, can be wrong, mistaken or can fail to anticipate certain aspects of things. In any event, He is not here to guide us, so we must to the job ourselves, with all of our own faculties. @gavinandresen My trust level toward you is extremely high. I see a lot of rubbish in this thread that unjustly questions your judgement. Even so, your initial comments are a bit worrying to me, and make me dream of a better reality. That is, when we recognize that what we have now is rather screwed up, we are best served in the long run by fixing the problem at its root rather than hacking at the branches; antivirals and antibiotics, not analgesics and Band-Aids(TM). I feel you’re probably right going this way now on this decision. It’s more or a less a “gotta be done” thing. But I really wish that folks who are submitting and committing new code will devote equal energy to deeply examining and then refining old code so that the kind of dilemma you faced here doesn’t occur.

(topically tangent aside: I wrestled for a couple of weeks in January refactoring parts of the RPC code, including where it touches the interfaces to the CWallet object. I got some great feedback from @sipa, but not much more attention to my diffs, and I gave up a bit later on when other changes to the RPC code broke the build on my branch. I am not a coder on the level of any of the core devs, but I do know well how to look at a code base that I’ve come to understand and then identify and fix problems around unit tests, modularity and separation of concerns. I have zero animosity about “wasted” work or whatever, but I feel very strongly that not enough attention is being paid to those kinds of issues in the existing codebase. I imagine, given your statement above, that you share the same sort of feeling.)

felipelalli commented at 1:31 am on May 6, 2013: none

This is sad. Goodbye Satoshi. Agreed @pentarh

luke-jr commented at 1:50 am on May 6, 2013: member

The Satoshi-is-God voices here, besides being fundamentally flawed in reasoning, seem to be confused in some other way(s) as well. Satoshi himself approved the “valid but non-standard” exclusionary function originally, for exactly problems like this. Since 0.3.18, bitcoind has refused to relay (or mine) transactions not matching a set of well-defined attributes; this pull request just extends that to include the latest problems.

BlueMeanie commented at 2:04 am on May 6, 2013: none

The kind of transaction discrimination reflected in this recent merge is inevitable. It’s important to note however, that many ideas for the future of bitcoin rely on a flexible policy regarding what makes it’s way into the block chain. I agree with @gavinandresen - these new measures are required.

johndillon commented at 2:20 am on May 6, 2013: none

@gavinandresen

So IsDust() will be based on what is actually being accepted into blocks, and will adjust appropriately.

How is this going to work given that miners only have an incentive to charge per KB? (using UTXO space after all is treated no differently than using blockchain space)

drwasho commented at 2:33 am on May 6, 2013: none

@gmaxwell receives the prize for the most intelligent comment:

“Perhaps you misunderstand what this does. This is not a protocol-rule change. Miners can still include the same transactions they can now, though this pull makes ‘picocent’ payments not get included by default unless they change a threshold setting (useful if the value of Bitcoin changes greatly).”

This doesn’t seem to be the Bitpocalypse that people are making it out to be.

To Bitcoin miners thinking of boycotting the new version, a better way to protest would be to change your default settings to process these microtransactions. If most of the miners make these changes, then this controversy truly becomes irrelevant.

johndillon commented at 2:35 am on May 6, 2013: none

To Bitcoin miners thinking of boycotting the new version, a better way to protest would be to change your default settings to process these microtransactions. If most of the miners make these changes, then this controversy truly becomes irrelevant.

It’s interesting to watch the developers continually overlook the fact that without relay nodes the transactions will never get to the miners regardless of what settings they use, and there is no way to find nodes to relay your transactions. As I have said before I agree with the patch, but the subterfuge used to get it implemented is worth noting.

mikegogulski commented at 2:44 am on May 6, 2013: none

@petertodd No, and screw you for demanding. We will not leave politics off GitHub. @johndillon Subterfuge? O’RLY? WTF? @felipelalli (My apologies if I am not reacting to the @pentarh comment you were reacting to. I hope that folks will find this useful in any case.)

In the late 1950s to late 1970s, The Establishment, aka The Man, aka The Conspiracy, aka the FBI (Fucking Bavarian Illuminati) and the CIA (Cocksucking Illuminati Assholes) identified, targeted and destroyed the leading lights of a nascent, shining shining movement toward global illumination: MLK. Leary. JFK. Morrison. Malcom X. Lennon. and on and on. The dawning of the Age of Aquarius was strangled in the crib.

The failure of that time, which culminated worldwide in ‘68, was that the movement had FACES, and faces are targets. Destroy the faces, destroy the movement. Take all of the trappings of the new consciousness and recast them as cheap marketing gimmicks: subversion complete. The Hippie pioneers did not drive Volkswagen Beetles because they were some kind of status symbol or mass-consumer-culture signifier. They drove them because they were cheap, simple, minimalistic, trivial to repair and infinitely customizable. It was only later that the cultural imperialists sucked everything good out of the times and pushed it through the marketing meat grinder, until: Fahrvergnügen.

Today, I believe, a few of the surviving “secret chiefs”, if you will, who were active back in ‘68 and before are working as cleverly as they can, before they die, to levitate the Pentagon^w^w^wshift global consciousness in much the same way, but with a fundamentally different and more effective strategy: No more faces. Anonymous. Alan Moore’s Guy Fawkes mask. The unknown hero, the nameless brother, the faceless Samaritan. When The Man can’t target a Face, it doesn’t know what to do, and the field is open for massive gains on the side of the regular people. Today, we don’t venerate the Faces. We don the mask. And this Face Book? Oh! Do you jest, or do you not feel the power you have lost?

Whoever or whatever Satoshi is or was knew this, and acted right from the start on that knowledge. No face, no target. Produce brilliance, show some people, fade away into legend.

There is a teaching in Zen Buddhism which I will paraphrase here: If you meet Satoshi on the road, KILL HIM.

BlueMeanie commented at 3:37 am on May 6, 2013: none

also: I do agree with @pentarh , I think we need some innovation in the storage technology. All transactions should be accessible on some level of resolution, but really these problems are outside the scope of Bitcoin and @gavinandresen is doing the right thing. Just because some parties want Colored Coins or Distributed Exchanges to work with the existing block chain does not mean it must be worked into the core code, certainly not at the expense of basic features. I think all this discussion points to some goals for Bitcoin 2.0. Having multiple user-defined asset types is really a very valuable use case and opens up a whole world of possibilities for finance, truly making money accessible for everyone.

gmaxwell commented at 3:45 am on May 6, 2013: contributor

@johndillon I’m hurt. The accusation of subterfuge is misplaced. In the same breath I’ve been talking about this I’ve talked about the other kinds of non-standard transactions— which work exactly the same way. If you don’t think I’ve been clear enough about it— okay, so point it out to me and I’ll fix it. I certainly have no reason to deceive anyone. None of us in support of this change profit from it— beyond the hope that it stops some of the abusive use and keep bitcoin humming nicely.

Presumably anyone agreeing to process a non-standard transaction will direct you to addnode something that will take them for them (https://en.bitcoin.it/wiki/Free_transaction_relay_policy), which can now even be added without restarting the software .

josephagoss commented at 3:45 am on May 6, 2013: none

@gavinandresen Couldn’t you finally increase the divisibility of Bitcoin down to a larger amount of decimal places, making a “Satoshi” divisible would help make that unit useful and no longer dust.

If a Bitcoin could be split into a trillion places, and define dust as being several digits from the new smallest unit, this would leave all the units we deal with as useful, including the “Satoshi” unit.

johndillon commented at 4:02 am on May 6, 2013: none

@gmaxwell I am of the position that I solidly think the change is a good thing, but I also feel that it is simply not communicated to the wider community at all. That my little post on the forums lead to 7000 views in just a few hours shows how little people know and understand about these changes even taking trolls into account. @petertodd is right to point out how few people understand these issues in the wider community and how we still present this misleading “low or no fees” message without any plan for how that will actually be achieved. If investors are putting money into Bitcoin thinking it is something it is not, this is a serious problem. What I see is people sinking money into Bitcoin assuming it will be a cheap payment platform, and people sinking money assuming it will be decentralized, and the way things are going with the foundation and Gavin I do not see how it will be both, but none of this is being effectively communicated outside of a small number of developers and the occasional interested person like myself.

Also without a way for nodes to relay dust transactions, given that 0.8.2 nodes will not identify themselves, yes, the change really is blocking dust entirely. I think that is a good thing to do, but don’t go off on forums soothing peoples feelings by telling them untruths like it’s just a miners choice. Consider this very wrong post byTradeFortress : https://bitcointalk.org/index.php?topic=196482.0 Even @jgarzik isn’t really being honest here: https://bitcointalk.org/index.php?topic=196138.msg2043040#msg2043040 Again, if the network is ignoring your transaction, from the users’ point of view it is a protocol change.

BlueMeanie commented at 4:17 am on May 6, 2013: none

@johndillon , it is entirely true that Bitcoin should not be seen as no-transaction-fee technology, although it appears that way because the incentive is(temporarily) coming through an inflation vehicle(the coins created with each block in the chain). Obviously problems arise when, in the case of color coins, they are actually multiplying the BTC value of a very small amount(ie. 0.000001 BTC is colored to be worth 1 silver gram which has it’s own BTC value of 0.2039 - at the time of writing) - this will clearly have fatal effects on the mining economy because you have detached real value from BTC units. Various ideas have been proposed to circumvent any kind of regulations, but no proposals offer a way to create a long-term viable transaction economy that reflects the actual consent of the users.

gmaxwell commented at 4:20 am on May 6, 2013: contributor

@johndillon I agree it could be communicated better. I didn’t realize that it was pulled already until mid-discussion today, and I thought it had been posted (thus the discussion above about colored coins), or I would have prodded for it to be more widely advertised myself.

I pointed out in the threads— someplace— that you can’t tell when it’s being dropped. I do think you need to be careful with “blocked”. “You have to change the setting, and addnode a cooperating miner, and then it works fine”, it’s not the same as blocked. We probably need better language to discuss this, as there are absolutely people thinking that its blocked in a protocol rules sense (saying ‘miners have no choice because they can only run bitcoind’ and such) and I don’t think it’s wrong or misleading to respond to that saying it’s not blocked.

petertodd commented at 4:34 am on May 6, 2013: contributor

@gmaxwell Points for a proper press release about this:

Main thing driving this: make data spam more expensive in a way that doesn’t make regular transactions more expensive. The minimum output does this because data spam doesn’t spend outputs.

Options for affected businesses: combine payments together so that the lump sum is >54uBTC or connect directly to a miner willing to mine your transactions. Off-chain is possible too with something like EasyWallet, but then your customer needs an easywallet account. (they have an API) Consider that Bitcoin may not yet be right for you.

Long-term outlook: We don’t really know yet. If tx fees rising can threaten your business take into account that they may be more expensive in the future (10x is quite possible) and there may be very little you or the development team can do about it.

I’ve got better things to do than post it though: http://www.reddit.com/r/Bitcoin/comments/1dqsul/warning_if_you_use_microtransactions_they_will/c9t4ea5

jgarzik commented at 6:35 am on May 6, 2013: contributor

I note the distinct lack of discussion surrounding https://bitcointalk.org/index.php?topic=130450.0 and its pull request.
This issue certainly deserves better communication, but think the trolling (reddit/bitcointalk) by @johndillon was premature and exaggerated, because there is still plenty of time and opportunity in the release cycle for comments. Usually the time prior to -rc1 release is used to write the communications that appear in -rc1. The -rc1 release announcement then describes the changes, including rationale and impact.

-rc1 release initiates a phase of public testing and comment. If the community really dislikes a particular change, this testing phase is yet another opportunity to make that known.

Most importantly…

The vast majority of remote workers (miners) do not seem to care at all about mining policies, in practice. Pools’ mining policies are incredibly opaque, few miners show deep interest in mining policy, and few pool operators show much interest in deep thinking about mining policies, transaction selection, and various economic incentives. Even a lot of smart, engaged pool operators wind up preferring unmodified (or close to it) bitcoind for reasons of reduced complexity.

Therefore, just wanting – quite rationally – to get paid for mining, it is the sad reality that the block subsidy (currently 25.0 BTC) reduces transaction fees to the economic equivalent of statistical noise. The long term cost of generating and storing economically worthless transaction outputs is simply not transmitted to users or miners. Nor, really, is the short term cost. The economic signalling of the block subsidy drowns the rest out.

The cost is currently borne entirely by “the cloud”, the all-volunteer P2P network of full nodes. The only modicum of behavior signalling we see there is a decreasing number of full nodes, and an increasing amount of P2P traffic.

What does all this add up to? The answer is lies in the free market. Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners.

These hardcoded anti-spam limits have existed for years, originally starting out at 0.01 BTC. Transactions have always been filtered. Anything outside a small set of “standard” transactions are deemed “non-standard”, and will be filtered (not relayed). Again, policy has been in place for years.

The fee limits were lowered over time, but still hardcoded. This latest change makes this limit configurable, moving one step closer to the goal of users being able to react rapidly to changes in miner policy or bitcoin value. One step closer to a freer market.

Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it. This rule self-adjusts over time, as the “tx fee required to send” changes over time. In a dynamic fee market, it might change a lot.

It is unavoidable that tiny transactions worth fractions-of-a-penny may be easily abused for data transmission and storage. We have already been burdened with megabytes worth of wikileaks data, GPG encrypted data, and the PGP fingerprint strong set, so this is not a theoretical problem. These files are stored as bitcoin transactions with values around 0.00000001.

petertodd commented at 6:59 am on May 6, 2013: contributor

@jgarzik That discussion was on the development forum, around the holidays. As I said above, I’ve run into people putting serious effort into starting payment-dependent Bitcoin businesses who don’t even know that there is a blocksize limit.

http://blockchain.info/charts/cost-per-transaction

If the block subsidy was not statistical noise, transactions would have to cost something more like $1 each for 1MB blocks, $10 each to equal the block subsidy. On the other hand, if transactions were still cheap, say a penny each, well, you’ve just made the data storage problem something like 100 to 1000 times worse.

If you don’t want the blocksize to grow at the maximum rate possible, 52GB/year, the answer does not lie in the free market until genuine economic activity is such that transaction fees are expensive. It relies on taking advantage of miner persuasion, as we already do.

Anyway users can’t react rapidly to changes in miner policy or Bitcoin value without reasonable alternatives. I suspect without alternatives blockchain space is more like diesel and gasoline in terms of supply and demand - you absolutely need it and if you can’t get it you just close up shop instead and that section of the economy goes out of business. (FWIW why I think calling @johndillon a troll is over-simplifying things)

jgarzik commented at 7:15 am on May 6, 2013: contributor

A big blaring “WARNING” on multiple fora is definitely trolling, particularly when it lacks any companion effort to figure out a better method of communication.

jgarzik commented at 7:28 am on May 6, 2013: contributor

@petertodd The goal is a free market. It is a long road to get there, and we don’t ultimately get there until the block subsidy is tiny, years from now.

This change is one small constrained step, not the end goal itself.

petertodd commented at 7:42 am on May 6, 2013: contributor

That’s not true either. Provided there is genuine economic demand for 100% of the blockspace available the mining-side code implements a perfectly reasonable free market as-is, and that demand could show up tomorrow for all we know. Client-side needs fixing, but that’s another matter. The block subsidy has nothing to do with that - while hashers don’t care much, mining pool operators care a lot about that extra percentage point that fees can get. Of course, they also care about orphans, so with the big subsidy economically rational fees are actually going to remain high for most miners no matter what, especially if Bitcoin mining is as decentralized as it should be.

jgarzik commented at 8:00 am on May 6, 2013: contributor

“Client-side needs fixing, but that’s another matter” – That is precisely the matter at hand. The individual miner market is already done, but the client side necessarily proceeds in fits and starts.

killerstorm commented at 8:00 am on May 6, 2013: none

@cjdelisle Can you please explain how “deterministic satoshi tracking” colored coin implementations are not affected? I think I know what you’re talking about, but I don’t see how they are not affected.

If possible, please reply in “colored bitcoin tech discussion” on forum.

(I know that coloring schemes which will work fine despite this change are possible, but I don’t see how it applies to “deterministic satoshi tracking”.)

awfm9 commented at 8:06 am on May 6, 2013: none

My business would not rely on micro-transactions at all, and the fact that no one is getting why I’m still going to move away from Bitcoin if this goes through is what should worry everyone @gavinandresen @gmaxwell All you are discussing and discussing is whether this change is sound technically. Since you already admitted in your own words that this change is supposed to be temporary and should be replaced by a solid system later on goes to show that no, it’s not. It’s a dirty, quick fix for a problem that goes way beyond a simple quick change - and it should never be approached in such a half-arsed way.

However, this is not even relevant. What is relevant here is that you both suffer from something I like to call “developer-blindness”. You think you know better than anyone else, and maybe you do, but that does not matter. The majority of users does not want this change. In fact, the majority of users are opposed to this change citing various real arguments. Arguments you might not agree with. Arguments you might consider less relevant than your own. Arguments nonetheless.

It is not and should never be your place to impose a change on the community that is clearly not wanted. Again, if miners would have such huge trouble with these transactions, they would end up implementing their own filter. What you are doing is to massacre the protocol for everyone. Even worse, by dictating such an unpopular change, you kill the credibility of Bitcoin as a whole.

I, personally, will never trust the potential, aspiration and philosophy behind Bitcoin again if this gets implemented, and I’m not the only one. I don’t need to tell you how vulnerable Bitcoin still is. Right now, Bitcoin is growing tremendously, not because the software behind it is mature in every possible way, but because of the idea behind it. You are risking to put this idea in danger.

awfm9 commented at 8:10 am on May 6, 2013: none

And I would beg everyone here to stop acting like the average user is somewhat capable of still using micro-transactions. Bitcoin is getting closer and closer to mass adoption. Unless you are a developer yourself, you won’t be able to use micro-transactions anymore, which de facto eliminates them from use.

Now that is trolling.

mikehearn commented at 8:16 am on May 6, 2013: contributor

This thread is (once again) devolving into uselessness.

If you don’t like the decisions Gavin makes about this codebase, please fork it. Arguments that aren’t rooted in technology like “this isn’t what the majority of users want” aren’t likely to have much impact.

This is the first change of several related to fees. It’s not the end state. Rest assured, there are plenty of people who want to see Bitcoin scale as effectively as possible, and with a market-based solution to fees we will eventually find out how scalable it can be.

awfm9 commented at 8:25 am on May 6, 2013: none

This change should already be a fork, not the reference implementation.

petertodd commented at 8:31 am on May 6, 2013: contributor

@jgarzik Client side fee stuff is just a few months of work. It’s really not a big deal technically, the issue is the politics of accepting that fees and limits are a necessity. What will probably be very interesting is watching all the deliberate attacks that will come from people like @johndillon and evorhees (hi luke!) to show anything but fixed limits are insane.

ripper234 commented at 1:54 pm on May 6, 2013: none

@MeniRosenfeld, colored coins is a side project, it’s not something that Bitcoin should necessarily support. Still, trading colored coins is still possible, it just possibly gets a bit more expensive.

As much as my opinion counts for anything here, I think we should consider Bitcoin and Bitcoin dust/fees first, and as it is know that Bitcoin was never meant to handle microtransactions … go forward with this pull request & Gavin’s roadmap.

gavinandresen deleted the branch on May 6, 2013

cjdelisle commented at 5:29 pm on May 6, 2013: none

@killerstorm As a proud non-member of the forum (because of threads like this) I won’t be able to post about it. I did just subscribe to the bitcoinX google group (the subscribe email bitcoinx+subscribe@googlegroups.com should be prominently displayed) and I will write my understanding there.

patcon commented at 6:30 pm on May 6, 2013: none

:+1: looks good :)

petertodd commented at 8:57 pm on May 7, 2013: contributor

@SergioDemianLerner Huh? You can spend transaction inputs regardless of how small they are with this patch, and we have every reason to make that possible, even easier, to try to reduce the UTXO set size.

The only time what you are suggesting might apply is if we were desperate enough to reduce the UTXO set size that we were willing to make old coins unspendable, and we’re literally multiple orders of magnitude away from even considering that step. Not to mention you said “store coins forever”…

Don’t confuse people.

gmaxwell commented at 8:58 pm on May 7, 2013: contributor

@SergioDemianLerner This doesn’t inhibit spending in any way. It inhibits the creation of new dust outputs— paying. Spending them is important, in part, because it’s important that they get swept up. I’m not sure what you’re talking about here, but it’s not this pull.

SergioDemianLerner commented at 9:05 pm on May 7, 2013: contributor

My post was not strictly related to the patch and does not belong here probably.

satoshiroulette commented at 5:45 am on May 9, 2013: none

As a casino operator that creates dust I have mixed feelings about this.

I have to comment the litecoins anti dust patch can EASILY be worked around as we have done for our own casino and we would have applied the same hack to the bitcoin casino were you to use their patch. The end result being is that normal users are discouraged from sending dust and automatic services simply work their way around the new rules.

I do not see this patch reducing spam for games like satoshidice and our own reverse dice as operators are likely to increase the loss payout multipler to be higher than 0.000055 btc. The main game that it will effect (for us) is our roulette game, if this is the way forward for bitcoin then we shall have to adapt.

gmaxwell commented at 5:58 am on May 9, 2013: contributor

@satoshiroulette I had no idea that you still created outputs smaller than this. Satoshidice does not (their smallest is right on the boundary). Creating very tiny outputs— independently of how many are created— is harmful because it costs users more in fees to clean them up then they yield, so they never get cleaned up. Actual economic transactions are not intended to be effected by this, so I think your commentary about “I do not see this patch reducing spam” is confused. This change in behavior targets exactly the specific activities it is intended to target. The intended effect is to decrease the amount of outputs which are too worthless to redeem (negative-effective-value-payments) and the unredeemable data storage transactions.

Services which simply inefficiently generate large numbers of transactions (I assume this is what you mean by spam?) get to compete with fees and priority for space in the blockchain. This patch isn’t intended to do anything with respect to that.

satoshiroulette commented at 8:36 am on May 9, 2013: none

@gmaxwell we wont be creating them for much longer ;)

Previously we used to reforge our dust into a whole piece of bitcoin again by using raw transaction api and sending to a new address in the same wallet with no fees.

Thanks for the early warning, we shall get to work updating our game configs so we are ready for this change.

paraipan commented at 4:48 pm on May 10, 2013: contributor

NACK, you don’t solve the spam problem by including more “magic” numbers

gmaxwell commented at 6:24 pm on May 10, 2013: contributor

@paraipan There are no more magic numbers.

paraipan commented at 6:38 pm on May 10, 2013: contributor

Well that is strange, I though you guys called “magic” all arbitrary values in bitcoin source code.

petertodd commented at 6:44 pm on May 10, 2013: contributor

@paraipan We already have a “magic” number for minimum allowed txout value, and that magic number was 1 satoshi. This patch changes that magic number to 5430 satoshis; no new magic numbers are being added.

edit: as sipa and gmaxwell point out, this isn’t strictly correct. I should have said “This patch changes the default setting of that magic number to 5430 satoshis, and additionally lets you easily change it with a configuration setting. (although, please don’t unless you know what you’re doing)”

cjdelisle commented at 7:00 pm on May 10, 2013: none

If you read the patch, you’ll see that the 5420 number is not actually hard coded (“magic”), it aims to prevent payments where spending that payment requires a fee of more than 1/3 of the payment itself. Since “typical fees” are based on the number of bytes of transactions which bid for the 1MB per block limit, the number is arguably less magical than it was before.

Yes gmaxwell, I know that minimum fees are hardcoded but when we reach a point where there are more transactions than there is block space, those hard numbers will become meaningless as transactions which pay the minimum begin to be delayed/dropped.

gmaxwell commented at 7:01 pm on May 10, 2013: contributor

@petertodd @cjdelisle

No, not even that. The patch replaces a hardcoded base fee value with a configurable one, and makes the hardcoded dust value just be a fraction of the base fee value. So nothing is hardcoded except a fraction off a configured value…

sipa commented at 7:03 pm on May 10, 2013: member

I On 10 May 2013 20:44, “Peter Todd” notifications@github.com wrote:

@paraipan We already have a “magic” number for minimum allowed txout value, and that magic number was 1 satoshi. This patch changes that magic number to 5240 satoshis; no new magic numbers are being added.

That’s not even true. It changes the minimum output side to whatever is at least 3 times the fee necessary according to the active policy to spend it. For a fee rule of 0.0001/kB, this results in 5240 satoshi. This 5240 itself is not a constant.

And even better, this patch makes the fee policy rule configurable. So no, this patch strictly reduces the magic numbers.

paraipan commented at 7:03 pm on May 10, 2013: contributor

Thank for clearing it out guys.

petertodd commented at 7:10 pm on May 10, 2013: contributor

@gmaxwell @sipa Sorry, I should have taken the time to write a more detailed response than my quick approximation.

jspilman commented at 9:06 pm on May 10, 2013: none

@caleb: It aims to prevent payments where spending that payment requires a fee of more than 1/3 of the payment itself.

@sipa: It changes the minimum output side to whatever is at least 3 times the fee necessary according to the active policy to spend it.

Yes, and yes. Well sort of…

IsDust = 1000 * TxOutAmount / (3 * (TxOutBytes + 148)) < MinRelayFeePerKB

Easier on my eyes this way:

IsDust = TxOutAmount < 3 * MinRelayFeePerKB / 1000 * (TxOutBytes + 148)

Given nMinRelayFeePerKB of 10,000, that makes IsDust 4680 Satoshi, plus 30 Satoshi / byte for the ScriptPubKey.

Standard ScriptPubKey is 25 bytes, resulting in minimum output of 5430. But hey, a P2SH output would save you 2 bytes and lower the minimum by 60 Satoshi to 5370! However, if I understand correctly, minimum actual fees paid still assumes transactions are at least 1KB:

Line 600: int64 nMinFee = (1 + (int64)nBytes / 1000) * nBaseFee;

So in practice, the minimum standard outputs will actually cost ~2x their value in fees in order to spend them. Is there any plan to update Line 600 as follows for 0.8.2:

nMinFee = (int64)nBytes * nBaseFee / 1000;

petertodd commented at 10:58 pm on May 10, 2013: contributor

@jspilman By “cost to spend” we mean the marginal bytes required to spend a transaction input * the fee/kb when added to an existing transaction, like one combining a whole bunch of dust outputs together, not the cost to simply create a transaction re-spending the dust output with a single input and single output.

ABISprotocol commented at 7:59 am on May 19, 2013: none

Let me lay it down for @gavinandresen , @gmaxwell , @petertodd , and all you others who thought you could hammer this out on github over the holidays, close it, and then not get any objections, you know, like this:

https://bitcointalk.org/index.php?topic=196138.0;all

Some bazillion (that’s not a real number) of posts later, you get the gist: People are looking at what you’ve done, and they are saying: WTF?

It doesn’t matter what nice formulas you’ve come up with.

It doesn’t matter if you are going to justify it by saying that this avoids the problem of bitcoin getting DDOS’d.

It doesn’t matter if you felt it needed to be done for some other purpose, like “to increase potential investors’ confidence” or something, ahead of #Bitcoin2013.

None of this matters.

What does matter is that this is not truly open and that there are literally millions of users (estimate, but not a bad guess) you are closing out of the system who have, and always will have, a lower figure in their bitcoin wallet that hovers somewhere between .01 BTC and .003 BTC, because they have started with a small amount from faucet and used bitcoin primarily for transaction (not for storage) and / or because they access and use sites that pay in uBTC for site visits or microtasks.

I don’t think you did any kind of epic polling of the millions of users or, for that matter, the many thousands of businesses / website owners that have sprung up who pay based on bitcoin microtasks or views. I would submit that most of us who are on bitcoin today have obtained their first portion of a bitcoin not because they mined it straightaway, but because they obtained it through a BunnyRun or a website visit that paid out in uBTC for visits, views, or microtasks performed. Speaking on the latter, whether or not you consider them a significant part of the bitcoin economy is irrelevant. You have disregarded their voices by acting in an “open” forum to act in this way without a more open consultation.

Github is not a proper forum to discuss this kind of matter. It is the place where changes are ultimately made that affect the code, yes. But when such changes are so large as to concern the manner in which an entire user base can utilize an increasingly trusted method of transaction, and the development under discussion is a surprise or even completely unknown to many who are about to be affected by it, in no small part because of the behavior of the developers, this is entirely unacceptable. The behavior I am seeing here in the development of this pull request, is reminiscent of the behavior not of the open community of coders and innovators, but rather reminds me of the ITU (International Telecommunication Union), the closed-door body for which only governments have a vote.

No, this is not an issue of numbers, or formulae, or how to best prevent bitcoin from being DDOS’d.

The issue here, at its core, is was this a legitimate way to address the microtransaction issue?

Was Github truly used to solicit views and ideas of Bitcoin users?

The answer is no. A small group of developers huddled together and pushed this through. This change should be pulled back until the larger community’s views can be taken into account and votes on the matter can be taken outside of Github. There are a number of online deliberative tools that are available to perform such tasks. Solicitation of ideas from a larger community, prioritization of appropriate solutions, and larger community selection through ranking or vote on which solutions are the best to address a problem facing the community, this must always come before decisions are made.

This is not like other things. You are not developing a fix for Cryptocat or talking solutions for libpurple problems in Pidgin / OTR.

There is a larger community, whose voice must be heard, outside of Github.

This is Bitcoin.

paraipan commented at 8:35 am on May 19, 2013: contributor

Me and my social network will not upgrade the client, because I oppose this arbitrary change. You’re losing it Gavin!

Let users control the limits from the GUI and the network will find it’s equilibrium, you’re not the one who has to make these decisions.

sipa commented at 2:38 pm on May 19, 2013: member

I am somewhat surprised by the outcry against this, and I wonder whether it is because of the way this decision was made, or because you believe Bitcoin should support output coins that cost ~ as much to spend as they are worth.

In any case, please realize that this is just a policy change. There are no network rules affected, and everyone is free to set whatever relay fee price they believe is right for the network. I encourage you to do (and if that means not upgrading, so be it) - that’s exactly something this patch makes configurable. However, it is just a stopgap solution and the intention for the near future is replacing it with a mechanism to detect what fees get confirmed and which don’t and set the relay policy based on that, so we can evolve towards a free market where users bid for space in blocks.

paraipan commented at 4:19 pm on May 19, 2013: contributor

@sipa, in Bitcoin policy change=network rules change if I’m not mistaken. I would support said “mechanism to detect what fees get confirmed” though.

gmaxwell commented at 4:23 pm on May 19, 2013: contributor

@paraipan You are mistaken. I thought you understood it after this discussion with you: https://bitcointalk.org/index.php?topic=197414.msg2054475#msg2054475

paraipan commented at 4:36 pm on May 19, 2013: contributor

@gmaxwell I understood your position then and stopped pushing the patch based on your analysis. I didn’t agree with your point though as I see personal preference as more important than maintaining a predictable fee level in the protocol.

ABISprotocol commented at 6:10 pm on May 19, 2013: none

@sipa you just don’t get it. Re-read my original comment above. Read it again if necessary for effect.

This is reminiscent of the efforts I had (with many others) to get the International Telecommunication Union to come out into the open. (They didn’t.) It was a effort of over a year resulting eventually in #OpWCIT and later which spawned #OpWTF - a smaller and more focused effort of awareness about the problems associated with closed-minded organizations and groups.

I have the feeling that just such an effort is needed to shove this development group out in the open and ensure that not only this issue is dealt with but all future issues involving bitcoin developers are not pushed in this nontransparent and backchannel way that does not take into account the voices of the internet.

This is Bitcoin.

jgarzik commented at 7:29 pm on May 19, 2013: contributor

@idiotsabound The public website containing public source code changes cannot be considered a back channel. It is already very much out in the open. All discussions occur in public, and are publicly logged and google-able.

I agree that a continual effort is needed to educate users like yourself on how open source engineering works, and how open source engineering differs from other engineering efforts.

n074v41l4bl34u commented at 9:41 pm on May 19, 2013: none

@jgarzik First, thank you for your hard work on Bitcoin protocol. Secondly, you write “All discussions occur in public” then I ask you where was this change discussed? To me and most other people supporting Bitcoin, the problem with this change is not only about the code itself but mostly about unilateralism with which the decision was made. I am, as a Bitcoin user and as a Bitcoin trader, wholeheartedly against such quick-fix changes. It seems Bitcoin is becoming just a replacement for Western Union type of transfers instead of being a full-fledged currency of the Internet with some unique features - where are contracts? The decision making process regarding Bitcoin development is becoming a problem. It is too centralized and not democratic/market driven enough. Fees should be determined by market so developers should focus on features relating to fee management rather than hardcoding another magic number. As Bitcoin’s value is ultimately set by the market, I am personally taking some money out of Bitcoin until some long-term market solution for fees management is proposed.

jgarzik commented at 11:04 pm on May 19, 2013: contributor

This change moves towards making fees more market driven. They were hardcoded constants before. Now users may much more easily select their desired fee level for relaying and mining with a simple configuration file change.

cjdelisle commented at 2:14 pm on May 20, 2013: none

What a mess! Let me first state that my opinion is my own, I am not a bitcoin developer and I have essentially no influence within the community, my opinion is worth just as much as yours; nothing. Furthermore, I have no interest whatsoever in getting involved in the dev community until people start getting serious about user-terrorists holding the development process hostage by throwing temper tantrums. “This is Bitcoin.” Wrong, this is one bitcoin client maintained by The Bitcoin Foundation, unless you are a member of that foundation you are not a stakeholder and your opinion is worth just as much as mine; nothing. BIP-16 was a change of network rule which required consent of the miners, this is just a change in client behavior. If you want your bitcoin client to behave differently you can use a different client, create a fork of The Bitcoin Foundation’s client or bother someone else.

Developers, your patience and your desire for community process is like that of a saint, you are all wonderful people. Right now though, your good will is becoming part of the problem. Any time there is public disagreement between developers over any technical detail, someone is going to use that issue as a wedge to divide the dev community and tie up the process. In regards to developer back-channels, this is something we need more of, not less. It doesn’t have to be a dark room with cigar smoke and plush curtains, a real-names-only mailing list should be more than adequate to maintain civility. Every time you so patiently try to explain the reality of the issue to the same person one more time around, you miss the point. This is not a misunderstanding, it is a negotiation and you are letting these people run roughshod over you!

What does the development process need? We needs a charismatic leader. We need someone who can source ideas and opinions from users, developers, and stakeholders alike, merge them into policy and then defend that policy with religious zealotry. We need someone with the programming skill to command respect from all developers for it is the master who leads from the front. We need someone with the credibility to arbitrate disagreements between developers without allowing them to bubble up into public view where idlers will no doubt incite them further. We need a Linus.

Thanks, Caleb

BlueMeanie commented at 2:26 pm on May 20, 2013: none

I don’t see the developers arguing over anything. The people with a bone to pick appear to be largely uninformed, uninvested end users who are upset that their particular usage scenario might be at risk. As many have already suggested, if you don’t like the changes, FORK and do what you will. If you get enough people to adopt your interpretation of the rules, then it will become block chain policy. I think what the core devs understand is that without these rules, there will be no Bitcoin.

btw- a paper I recently wrote in response to some of the color coin issues.

gavinandresen commented at 3:53 am on October 9, 2013: contributor

@idiotsabound: this pull request is an inappropriate place to discuss the NSA/etc. I’m deleting your comment, please stay on-topic, there are plenty of places to speculate about bitcoin in general (e.g. bitcointalk forums, reddit /r/bitcoin, bitcoin.stackexchange.com, #bitcoin channel in IRC).

jgarzik commented at 9:32 am on October 13, 2013: contributor

Deleted off-topic comment, and blocked user (though that may just be a jgarzik-block and not a project-wide block).

laudney referenced this in commit 99a1b3d973 on Mar 19, 2014

ynvtlmr commented at 4:24 am on September 26, 2014: none

Potentially stupid question to the thread regarding this patch:

Was fooling around with no-fee dust-transactions, and had created one that was too insignificant by the standards discussed in the thread. As a result, a bunch of coins are now stuck unconfirmed in limbo.

Question is: Assuming someone pushes a no-fee dust-transaction, does it ever get verified? If so, how long would it take? What is the proper solution to this edge case?

Transaction: https://blockchain.info/tx/2bba1468f81540a83d31ef55ae1e080947f78b22c173d61907b563fa76ef6fc5

laanwj commented at 7:43 am on September 26, 2014: member

@ynvtimr You can just forget sending it, and regard the coins as not stuck. Most nodes will not even have let that transaction into the mempool, so will not regard another use of them as a double spend.

ynvtlmr commented at 5:22 pm on September 29, 2014: none

Makes sense. I figured that was likely the case as the transaction maintained 0% network propagation 4 days after the transaction date.

ABISprotocol commented at 7:45 am on September 30, 2014: none

‘Uneconomic dust’ was indicated in this pull as “5430 satoshis, about $0.007..” at the time this was opened in April 2013 (note however that per @sipa ~ the meaning of ‘uneconomic dust’ is actually “3 times the cost (according to your own node’s relay rules, which are configurable) of the number of bytes that are added to the blockchain by the relevant output plus how many are needed to spend it,” and that this is anticipated to change in future versions). Since then a lot has changed, floating fees were announced in July of 2014 ~ though they are not yet realized. @ynvtlmr you mentioned originally, no-fee dust transactions, which reminded me of a collaboration between Coinbase and Bitmonet which was in January of 2014. That was off-chain no-fee, so very small transactions could technically be handled. This also allowed for micro-transactions on mobile (initially, Android) and other things (off blockchain micro-transactions between Coinbase users would appear to be free to the user). The question seems to be how would this be done on the network and the answer is, I think, tiny transactions cannot exist alone.

Many ’tiny transactions’ (we could call it a micro-donation, too) could be bundled in a wallet ~ some concepts and ideas for that are shown here. Apart from that, more specific to the question floated above,

“Assuming someone pushes a no-fee dust-transaction, does it ever get verified?”

The answer would seem to be no, if it is truly no-fee and is in the network, but I say “seem to be,” because I imagine the idea of a “wallet dusting feature” ~ as expressed by @gmaxwell ~ or a “specialized collector” to process small change and tiny txouts, which potentially could be used (in part) to gather dust together to provide for the fee in the floating or smart fee framework within the context of 0.10. (Thus transactions could be given priority which is variable depending upon conditions.)

Examining many small transactions together with a fee, and assuming a sort of bundling of many tiny transactions, one can imagine all kinds of possibilities in Core especially with the floating or smart fee framework.

sipa commented at 4:17 pm on September 30, 2014: member

Uneconomic dust is not defined as a specific number of satoshis.

It is 3 times the cost (according to your own node’s relay rules, which are configurable) of the number of bytes that are added to the blockchain by the relevant output plus how many are needed to spend it.

In future versions the relay rules may be estimated from transactions in the network, rather than being an (overridable) default.

ABISprotocol commented at 1:27 am on October 2, 2014: none

@sipa Making correction to my prior comment, thanks for your clarification.

MeTheAK commented at 4:19 pm on January 29, 2019: none

Is this protocol still in use? like no one can send less than 5430

DrahtBot locked this on Sep 8, 2021

Treat dust outputs as non-standard, un-hardcode TX_FEE constants #2577