Bitcoin Core considers a transaction output to be dust when its value is lower than the cost of creating and spending it.
Ephemeral dust is a new concept that allows a single dust output in a transaction, provided the transaction is zero fee. In order to spend any unconfirmed outputs from this transaction, the spender must also spend this dust in addition to any other outputs.
Ephemeral dust enables additional options for creating and using dust outputs. This can be useful with types of presigned transactions, chains of transactions, keyed and keyless anchors: allowing zero usage of input funds while still enabling CPFP.
Where in code is it determined if an amount is dust?
Is dust restricted by consensus? Policy? Both?
How can dust be problematic?
Why is the term ephemeral significant? What are the proposed rules specific to ephemeral dust?
Why is it important to impose a fee restriction? Which specific vulnerabilities can you imagine without the fee restriction? Can you think of (in your view) positive use cases that are not possible because of the fee restriction?
How are 1P1C relay and TRUC transactions relevant to ephemeral dust?
What could happen if restrictions on the the child transaction were not in place?
Can a node operator change the amounts considered to be dust? If so, how? How are ephemeral dust rules enforced in this case? What would happen if the node tries to broadcast a transaction after adjusting dust amounts?
Could a miner choose to mine transactions containing dust? Is this a concern? What could be done to address the concerns, if any?
Which types of tests were created for the PR? What is the purpose of each type of test? Did you run the tests locally? If so, which ones? Which tests did you not run, and why?
Do the tests introduced exercise all of the code changes? How might you find out? Can you think of test scenarios and types of tests that could enhance testing?
Bonus questions
Why would a modified fee be relevant to ephemeral dust?
<stickies-v> i'm still going through the code but it looks like a pretty strong concept ack from me! my review approach is going through the code commit-by-commit
<chinggg> I mean the comment for the function was from commit `Consensus: Minimal way to move dust out of consensus`, so the function is probably not restricted by consensus anymore
<hodlinator> ("move dust out of Consensus" in 330bb5a456a5f9c26703fa742e4c80691e1455ab might be referring to the deprecated libconsensus rather than an actual change to the bitcoin protocol?)
<stickies-v> it's more an implementation optimization concern than a protocol risk - dust transactions are unlikely to be ever spent, so they may end up bloating the UTXO set forever
<hodlinator> since dust costs more to spend than the amount it provides by definition, the risk is that the UTXO set will grow for all nodes (pruned and non-pruned, blocks-only and regular).
<instagibbs> tiny utxos may have incentives to sweep them outside of the satoshi value themselves, but putting sats in outputs is another incentive to eventually spend it
<chinggg> I am not so familiar with the miner's economics. I guess dust could be problematic because the transaction output will not be usable anymore in the future, leading to fragments.
<hodlinator> The PR proposes to allow for relaying dust, but forces the fee of the tx to 0, meaning it is unlikely to make it into a block without a child, which now *has to* spend the dust (else it won't be relayed).
<stickies-v> i think it's significant because it indicates that the dust output is not meant to last, i.e. it gets cleaned up "by definition" (even if it's not guaranteed)
<stickies-v> I think hodlinator already covered that in his previous response about making it less attractive for a minor to include the dusty tx into a block without a spending child?
<instagibbs> You could imagine a first child spending dust(yay), then a 2nd child, higher fee, not spending dust. Parent and second child get mined first, then first child evicted
<tdb3> yeah, I think you're right, we sort of talked about two different things, but they seem fairly related in the sense that we want to avoid non-ephemeral dust as much as possible.
<hodlinator> Should probably be the highest paying child in that case... to encourage it to be within the same block as the parent. Code gets complicated/slower by allowing multiple children..?
<stickies-v> i just thought the question was about why force the dust to be spent in the first place, which is why i mentioned dos - because otherwise we'd be relaying 0-fee transactions without limit, i think?
<hodlinator> If the witness data makes the tx big enough that segwit nodes calculate the outputs as below the dust limit, but a non-segwit node only sees the transaction without the witness data bytes?
<tdb3> and to touch on the first question, the first commit of the PR creates a great test that ensures that ephemeral dust rules don't conflict with adjusting dust limits
<stickies-v> thanks a lot for hosting this meeting tdb3, that was such a helpful way to go through the PR. and of course thank you instagibbs for your work on this code, and to join today as well!