jgarzik (OP)
Legendary
Offline
Activity: 1596
Merit: 1099
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 12, 2012, 09:39:10 PM |
|
URL: https://github.com/bitcoin/bitcoin/pull/21001) Create COIN_DUST constant, to represent the dust spam limit used. 2) Update COIN_DUST from 0.01 BTC to 0.001 BTC Rationale: With the increase in bitcoin value (US$13.67 as of this writing), it seems reasonable to reduce the value level of which we consider "dust spam." 3) Update TX miner and relay fee defaults to 0.001 / 0.0005 BTC respectively Rationale: Reflects growth of dust spam in unspent transaction output dataset. Review of impact: a) Definition of COIN_DUST reduced from 0.01 to 0.001. b) Miners who mine with this code will require a fee >= 0.001 to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005 to relay TX's with outputs <= COIN_DUST
|
Jeff Garzik, Bloq CEO, former bitcoin core dev team; opinions are my own. Visit bloq.com / metronome.io Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
|
|
|
DeathAndTaxes
Donator
Legendary
Offline
Activity: 1218
Merit: 1079
Gerald Davis
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 12, 2012, 09:41:53 PM |
|
Not sure the dust constant needs to be changed BUT I do like replacing hard coded literal values with constants.
|
|
|
|
BoardGameCoin
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 12, 2012, 09:45:34 PM |
|
b) Miners who mine with this code will require a fee >= 0.001 to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005 to relay TX's with outputs <= COIN_DUST
Why not make these be b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005COIN_DUST/2 to relay TX's with outputs <= COIN_DUST
?
|
I'm selling great Minion Games like The Manhattan Project, Kingdom of Solomon and Venture Forth at 4% off retail starting June 2012. PM me or go to my thread in the Marketplace if you're interested. For Settlers/Dominion/Carcassone etc., I do email gift cards on Amazon for a 5% fee. PM if you're interested.
|
|
|
jl2012
Legendary
Offline
Activity: 1792
Merit: 1111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 08:06:43 PM |
|
URL: https://github.com/bitcoin/bitcoin/pull/21001) Create COIN_DUST constant, to represent the dust spam limit used. 2) Update COIN_DUST from 0.01 BTC to 0.001 BTC Rationale: With the increase in bitcoin value (US$13.67 as of this writing), it seems reasonable to reduce the value level of which we consider "dust spam." 3) Update TX miner and relay fee defaults to 0.001 / 0.0005 BTC respectively Rationale: Reflects growth of dust spam in unspent transaction output dataset. Review of impact: a) Definition of COIN_DUST reduced from 0.01 to 0.001. b) Miners who mine with this code will require a fee >= 0.001 to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005 to relay TX's with outputs <= COIN_DUST Another post ( https://bitcointalk.org/index.php?topic=128900.0) mentioned that currently 11% unspent output is 0.00000001BTC, 32% is less than 0.0001BTC and 60% is less than 0.001BTC. At the current price of US$13.5, 0.0001BTC worths only $0.00135. These are basically zero-value but take up 1/3 of resources of the network. To discourage these kinds of transaction, an even higher fee (e.g. 0.005BTC) should be charged with outputs < 0.0001BTC
|
Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY) LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC) PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 08:45:59 PM |
|
Another post ( https://bitcointalk.org/index.php?topic=128900.0) mentioned that currently 11% unspent output is 0.00000001BTC, 32% is less than 0.0001BTC and 60% is less than 0.001BTC. At the current price of US$13.5, 0.0001BTC worths only $0.00135. These are basically zero-value but take up 1/3 of resources of the network. To discourage these kinds of transaction, an even higher fee (e.g. 0.005BTC) should be charged with outputs < 0.0001BTC Perhaps a dust threshold could be made dynamic based on the chain. For example, compute the fee/KB for the last 2016 blocks and take its median value = MedianFee. Then assuming that every transaction must pay MedianFee/kb and each additional input to a transaction adds X bytes you arrive at a figure of MedianFee*X = the smallest output value which isn't worthless. Unfortunately thin clients can't measure this value on their own, but its data they could reasonably just trust if their server provides it (lying results in a DOS attack, but a thinclients server can dos attack in many ways). The proper thing to do with these transactions is not to relay or mine them at all— since it appears that there is be no economic incentive to spend them. But this is a bit blunt— as there are no doubt interesting ways to use small outputs which are not harmful, never redeemed bloat sources. I'm not sure how to best penalize these without completely denying them.
|
|
|
|
deepceleron
Legendary
Offline
Activity: 1512
Merit: 1036
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
December 31, 2012, 11:08:44 PM |
|
URL: https://github.com/bitcoin/bitcoin/pull/21001) Create COIN_DUST constant, to represent the dust spam limit used. 2) Update COIN_DUST from 0.01 BTC to 0.001 BTC Rationale: With the increase in bitcoin value (US$13.67 as of this writing), it seems reasonable to reduce the value level of which we consider "dust spam." When the minimum fee (if a fee is even required) was reduced 20-fold from .01 to .0005 (and the exchange value was doubling every month) in May-June 2011, the value of Bitcoin was the same as today. This greatly impacted the economics of Bitcoin as set up by Satoshi - upon examination of any facet of the currency, everything about Bitcoin seems extremely thought out as though it was delivered through divine intervention. Using a similar "value" argument to also allow more small transactions for free doesn't quite hold up. If you really want to send 0.005 today, you can for a 10% fee (Paypal would charge about a 700% fee for someone to receive $0.05 from you). A fee of less than $0.01 to instantly send any amount of money anywhere in the world is pretty reasonable.
|
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 01, 2013, 09:39:04 AM Last edit: January 01, 2013, 09:49:24 AM by grau |
|
Let us recognize that it is not dust as defined by an arbitrary threshold, but coin fragmentation in general that drives cost of the network.
A simple transaction has number of outputs to inputs ratio of 2, if addresses are infrequently re-used (as required to maintain high level of privacy) this leads to an exponential hence problematic expansion of the open transactions set. There are legitimate use cases for privacy but they should be weighted against their cost to the network just like dust.
I suggest to deal with dust and fragmentation in a combined approach to also incentivize dust collection and aggregation.
Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined.
Transactions collecting dust would become cheap compared to those fragmenting.
Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 06:12:19 AM |
|
Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined. Transactions collecting dust would become cheap compared to those fragmenting. Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)
You can't just do that. Block size is finite. Ultimately miners will prefer transactions with more fee per kbyte of transaction data. Software could implement default rules which are against the miners best economic interests, but then many miners would just change it— and the inconsistency would be even worse. For free transactions, or as a tie breakers for transactions with very similar fee/kb transactions which reduce the txout set are in the miner's (and overall communities best interest), but I don't think those cases are common enough to be worth solving alone. (E.g. addressing it only for free transactions doesn't even solve SD's 1e-8 BTC messaging). (though I do also think we should also strongly bias the free transaction logic to favor transactions which reduce the txout set size) This is why I was suggesting a heuristic to determine the smallest output which is economically nonredeemable (because its value is less than the marginal fee that would be required to get the transaction mined in reasonable time). The idea here is to avoid creating outputs which will not ever be redeemed by anyone because they would lose funds by doing so (perhaps someday they'd be worth redeeming— except they'll have likely lost the keys long before then). This isn't quite the same as penalizing txout set bloating, but it should prevent there from being a disincentive to _de_bloat it. I'm a little irritated that I wrote you a nice explanation about why privacy preserving behavior does not need to increase fragmentation, and relative to current behavior privacy improvements could reduce fragmentation... and you've ignored it and gone on saying that privacy is a major risk factor here, but oh well.
|
|
|
|
🏰 TradeFortress 🏰
Bitcoin Veteran
VIP
Legendary
Offline
Activity: 1316
Merit: 1043
👻
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 06:16:43 AM |
|
The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 06:19:09 AM |
|
The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.
This has been done for a long time. How do you think the pools are doing this? ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) But the criteria is not _highest fees_, it's _highest fees per byte_— because thats the criteria that maximized income given the constraints.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 06:30:32 AM |
|
As more discussion fodder— here is in image that shows the role that very tiny txouts are having in bloating the txout set: ![](https://ip.bitcointalk.org/?u=http%3A%2F%2Fbitcoin.sipa.be%2Fpruning-size.png&t=665&c=kZTi80W9wbCZdg)
|
|
|
|
grau
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 10:05:35 AM Last edit: January 02, 2013, 10:36:30 AM by grau |
|
Let us assign a minimum fee (FEE) for the ratio of number of outputs to inputs, a transaction with ratio n should offer n*FEE fee to be relayed or mined. Transactions collecting dust would become cheap compared to those fragmenting. Zero fee transactions should not be relayed or mined (other than of their ratio is below 1/FEE so they become free for collection of dust)
You can't just do that. Block size is finite. You make a very valid point that miner seek to maximize fee/size and that nodes should make sure tx favorable on that measure get to them. Since tx size is also driven primarily by the number of inputs and outputs we have identified two goals (containing UTXO and high fee/size) driven by same parameters. Do we find arguments to determine the relative weight of the two goals, such as (w being a fraction in [0,1])? fee = (w(nr_of_outputs/nr_of_inputs) + (1-w)(nr_of_outputs + number_of_inputs)) * FEE. I think the principal privacy leak is if two or more addresses are used as input for the same transaction while they have not previously received funds from same source address. If that is correct then privacy enhancing algorithms will in effect avoid aggregation hence bloat the UTXO. I apologize if I missed a contrary argument. Please point me to it.
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 12:05:12 PM |
|
I apologize if I missed a contrary argument. Please point me to it. I thought it was in this thread for some reason, here you go.
|
|
|
|
Roy Badami
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 01:50:15 PM |
|
The default fee handling needs to prioritize transactions with higher fees. Most mining pools do this already, but the default client should too. If not all acceptable transactions could be included into a block, include the ones with the highest TX fee first.
This has been done for a long time. Surely only since 0.7? Or does that count as a long time in bitcoin time? :-)
|
|
|
|
Mike Hearn
Legendary
Offline
Activity: 1526
Merit: 1129
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 02, 2013, 05:00:39 PM |
|
(though I do also think we should also strongly bias the free transaction logic to favor transactions which reduce the txout set size)
If we do that it makes sense for wallets to automatically defragment users wallets using free transactions that can wait around until there's spare space in the block, eg, at night. Such a policy is quite easy to implement for wallets on phones and tablets.
|
|
|
|
marcus_of_augustus
Legendary
Offline
Activity: 3920
Merit: 2349
Eadem mutata resurgo
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 22, 2013, 08:59:57 PM |
|
Good discussion, some good ideas and solution approachs being raised here to the unresolved hard-coded "fees" issue.
|
|
|
|
ShadowOfHarbringer
Legendary
Offline
Activity: 1470
Merit: 1006
Bringing Legendary Har® to you since 1952
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
January 23, 2013, 01:03:04 PM |
|
b) Miners who mine with this code will require a fee >= 0.001 to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005 to relay TX's with outputs <= COIN_DUST
Why not make these be b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005COIN_DUST/2 to relay TX's with outputs <= COIN_DUST
? I have an even better proposition const COIN_DUST_FEE_MULTIPLIER = 0.5; b) Miners who mine with this code will require a fee >= 0.001COIN_DUST to include TX's with outputs <= COIN_DUST c) Normal clients will require a fee >= 0.0005COIN_DUST * COIN_DUST_FEE_MULTIPLIER to relay TX's with outputs <= COIN_DUST
|
|
|
|
|