Bitcoin Forum
June 18, 2019, 04:26:26 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: RFC: Updating dust output definition, and default fees  (Read 3269 times)
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1554
Merit: 1005


View Profile
December 12, 2012, 09:39:10 PM
 #1

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) 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
1560875186
Hero Member
*
Offline Offline

Posts: 1560875186

View Profile Personal Message (Offline)

Ignore
1560875186
Reply with quote  #2

1560875186
Report to moderator
NEW GAME FORMAT
JACKPOT UP TO $50000+
Guess The Symbols Of a Real Ethereum Hash
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560875186
Hero Member
*
Offline Offline

Posts: 1560875186

View Profile Personal Message (Offline)

Ignore
1560875186
Reply with quote  #2

1560875186
Report to moderator
1560875186
Hero Member
*
Offline Offline

Posts: 1560875186

View Profile Personal Message (Offline)

Ignore
1560875186
Reply with quote  #2

1560875186
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218
Merit: 1005


Gerald Davis


View Profile
December 12, 2012, 09:41:53 PM
 #2

Not sure the dust constant needs to be changed BUT I do like replacing hard coded literal values with constants.
BoardGameCoin
Sr. Member
****
Offline Offline

Activity: 283
Merit: 250



View Profile
December 12, 2012, 09:45:34 PM
 #3

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

Quote
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 Offline

Activity: 1792
Merit: 1010


View Profile
December 31, 2012, 08:06:43 PM
 #4

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) 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
*
qt
Offline Offline

Activity: 2758
Merit: 2308



View Profile
December 31, 2012, 08:45:59 PM
 #5

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 Offline

Activity: 1512
Merit: 1000



View Profile WWW
December 31, 2012, 11:08:44 PM
 #6

URL: https://github.com/bitcoin/bitcoin/pull/2100

1) 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
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
January 01, 2013, 09:39:04 AM
Last edit: January 01, 2013, 09:49:24 AM by grau
 #7

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
*
qt
Offline Offline

Activity: 2758
Merit: 2308



View Profile
January 02, 2013, 06:12:19 AM
 #8

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 🏕
VIP
Legendary
*
Offline Offline

Activity: 1176
Merit: 1023


View Profile
January 02, 2013, 06:16:43 AM
 #9

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
*
qt
Offline Offline

Activity: 2758
Merit: 2308



View Profile
January 02, 2013, 06:19:09 AM
 #10

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   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
*
qt
Offline Offline

Activity: 2758
Merit: 2308



View Profile
January 02, 2013, 06:30:32 AM
 #11

As more discussion fodder— here is in image that shows the role that very tiny txouts are having in bloating the txout set:

grau
Hero Member
*****
Offline Offline

Activity: 836
Merit: 1000


bits of proof


View Profile WWW
January 02, 2013, 10:05:35 AM
Last edit: January 02, 2013, 10:36:30 AM by grau
 #12

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
*
qt
Offline Offline

Activity: 2758
Merit: 2308



View Profile
January 02, 2013, 12:05:12 PM
 #13

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
Hero Member
*****
Offline Offline

Activity: 564
Merit: 500


View Profile
January 02, 2013, 01:50:15 PM
 #14

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
*
expert
Offline Offline

Activity: 1526
Merit: 1008


View Profile
January 02, 2013, 05:00:39 PM
 #15

(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 Offline

Activity: 2912
Merit: 1148



View Profile
January 22, 2013, 08:59:57 PM
 #16

Good discussion, some good ideas and solution approachs being raised here to the unresolved hard-coded "fees" issue.

ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470
Merit: 1000


Bringing Legendary Har® to you since 1952


View Profile
January 23, 2013, 01:03:04 PM
 #17

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

Quote
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

Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!