Never produce dust outputs about lightning

[NicolasDorier]

the problem is that dust definition is not fixed it depends on mintxrelayfee which is itself floating bitcoin/bitcoin#6722 (depends on mempool state) which is why I proposed to make dust depends on fee instead of magic rule bitcoin/bitcoin#6824 the problem when I tried to implement that is that I stumbled on a circular dependency.

You may be tempted to take a fixed value to simplify the problem, but this is forgetting that the latest bump bitcoin/bitcoin#6793 was order of magnitude higher.

I fear there is no solution without doing something to decouple mintxrelayfee from dust.

[Roasbeef]

@NicolasDorier with bitcoin/bitcoin#6722, minTxRelayFee remains static. Therefore the definition of dust remains fixed (well, the default is fixed, but it's a matter of node policy).

[NicolasDorier]

I got confused by the title "Limit mempool by throwing away the cheapest txn and setting min relay fee to it" which I interpreted as : Set the mintxrelayfee with the cheapest tx in the mempool.

Anyway, I think it is fragile to rely on a fixed number for defining dust. I got burned by the bump to 0.00005, and I think it will happen again one day.

[rustyrussell]

Nicolas Dorier [email protected] writes:

I got confused by the title "Limit mempool by throwing away the cheapest txn and setting min relay fee to it" which I interpreted as : Set the mintxrelayfee with the cheapest tx in the mempool.

Anyway, I think it is fragile to rely on a fixed number for defining dust. I got burned by the bump to 0.00005, and I think it will happen again one day.

Indeed. I would like a "would you accept this tx if it were signed?"
operation for bitcoin core, which we could use as a sanity check.

Meanwhile, we'll leave a fairly large margin for avoiding dust, I think.

Cheers,
Rusty.

[ABISprotocol]

NACK!

See bitcoin/bitcoin#6824 (comment)

and http://subsatoshi.org/ - originating from a discussion at ABISprotocol/ABIS#1

[rustyrussell]

ABIS [email protected] writes:

NACK!

See bitcoin/bitcoin#6824 (comment)

This is irrelevant to the issue here. Dust outputs mean that
transactions will have difficulty traversing the bitcoin network, and
thus should not be produced.

Please also note that opening with "NACK" is uncivil and disrespectful;
which makes us less open to your ideas.

Cheers,
Rusty.

[ABISprotocol]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hola Rusty, replying from my mail (see below) ~

Rusty Russell:

ABIS [email protected] writes:

NACK!

See
bitcoin/bitcoin#6824 (comment)

This is irrelevant to the issue here.

I don't agree that the above comment cited is irrelevant to the issue,
"Never produce dust outputs." As part of that comment, I noted that
@petertodd had developed a proposed system, dust-b-gone, in which
"Every dust txout is collected into a single transaction sending all
the funds to mining fees, and that transaction is signed with the
NONE|ANYONECANPAY flag." I also mentioned in my comment (via a link
to a comment in bitcoin/bitcoin issue 4079) that @gmaxwell at one time
suggested "a wallet dusting feature where you can tell the wallet to
send dust (e.g. small change and tiny txouts) to a list of user
specified donation targets with a monthly quota on how much will be
sent, and then it just automatically sends and reports on the results.
Then you get a three way benefit: the user gets a less fragmented
wallet, the network gets a less fragmented utxo set, and the recipient
of the funds gets the funds." Finally, and notably, I suggested in my
comment cited (which you claimed to be irrelevant) "that
http://abis.io should be looked at for ideas regarding how you can do
things with dust (in particular, use it as a gift rather than as a
problem)." Whether or not you agree with my perspective, it is not
irrelevant.

Dust outputs mean that transactions will have difficulty traversing
the bitcoin network, and thus should not be produced.

A simple way of assessing this would be to say that if you had no way
of properly managing dust then it would be problematic for
transactions, but if a proposal was developed (with an acceptable BIP)
to manage dust, it could be helpful. Again, dust need not be seen
simply as harmful ~ it depends on how it is managed and used.

Please also note that opening with "NACK" is uncivil and
disrespectful; which makes us less open to your ideas.

Presumably there are no speech rules for this repository. Rows of
ACKs or +1s could be seen as glaringly offensive. I suggest being
open to the form and character of how people speak or write and not
being offended by something that hits you the wrong way or that you
disagree with. Censorship (even when it doesn't exist) usually begins
with people claiming they are offended by something that they feel is
harmful.

Cheers, Rusty.

Cheerio,

Odinn

--- Reply to this email directly or view it on GitHub:
#14 (comment)
8550575

---

http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJWjcTcAAoJEGxwq/inSG8CSLYH/RhNhSpw5m4MUK7qWi/hwW8N
JmDO3SrIk1jmB99RphLvzpVleuKy3dwO8Y9LQAjM6/OnpoCp16AZEtCywvWE6Q8W
+pbYbATMO7I06weCEY2sVeniaAAXQKvgLFwWCg5XBGw0p7vF+OLljZ/K+i0y4+hC
rAGbFQ2/a0Hsy8GQLbz4kwHQNqGWMKiX5Cr7Yv3uAMVbrEH0BJKWB5yupKqwJFN5
moyhS04FG0ztuOOvGrZhIXjXg/xt4JHwP4dgpA4M2qTl6U7ugss4laBtdFZxQcUZ
hc8G6OmpdUiT0B6mm33SDcqErloDRReIp/rPcs6dr+DGVf/cJliMlp70foLbMcM=
=L1at
-----END PGP SIGNATURE-----

[rustyrussell]

Presumably there are no speech rules for this repository.

Yes, there are: be friendly! I have indicated that your terse "NACK" was not friendly.

Your suggestions about bitcoin are irrelevant here in the lightning repository. I will not hesitate to delete your comments from now on.

[NicolasDorier]

@ABISprotocol the reason why what you are linking as nothing to do with what we are talking is because you are speaking dust in the context of a wallet while we speak about dust in the context of lightning.

In the context of lightning, if one of the output happens to be dust during a pending commitment, it means that one of the two party can steal the money from the other. There is nothing to NACK, it is a problem to solve. A dangerous security issue provoked by dust.

@rustyrussell by thinking about it I think the solution is simple. If someone wants to open a channel of 10 BTC, ask him to send 10BTC + Additional BTC in the anchor transaction.

Then reject any commitment N+1 with the following condition:

Commitment N+1 have a party with a balance superior to 10 BTC AND Commitment N have a party with a balance inferior to 10 BTC.

When the channel get open, the channel opener will have 10BTC + Additional BTC.
But as soon as the threshold of Additional BTC of payment is crossed, then a "come back" will not be possible. As long as Additional BTC is significantly higher than probable dust, it should be safe.

I think this is the simplest way to deal with the problem.

[jtimon]

Although minTxRelayFee remains static, it is configurable by users at run time and is a relay policy check, so it shouldn't be assumed that all nodes will consider the same outputs dust.
But I guess a sanity check with Bitcoin Core's default is the best you can do.

Indeed. I would like a "would you accept this tx if it were signed?" operation for bitcoin core, which we could use as a sanity check.

I've been considering a RPC call "verifyTx" only with the consensus checks. I also considered a verifyAndApproveTx RPC that would do both consensus and relay policy checks.
If there's demand for something like that I may code it for bitcoin-jt-0.12 (which will have the consensus code fully encapsulated, the relay policy code partially encapsulated and more relay/mining policy options than Bitcoin Core, among other things).

[ABISprotocol]

@NicolasDorier Hello, as I understood it, based on a brief discussion from about six months ago, subsatoshi ( see current project status at http://subsatoshi.org/ - developed by @ktorn et. al. ) was anticipated to probably use the Lightning network when payments accumulate to above-satoshi amounts, as they eventually make their way onto the actual blockchain.

@NicolasDorier I am curious on your thinking regarding dust (https://github.com/bitcoin/bitcoin/blob/v0.10.0rc3/src/primitives/transaction.h#L137), for in this issue in another repository, bitcoin/bitcoin#6824 you seemed to want to define it differently. You say here (in this repository) that there is a "dangerous security issue provoked by dust," but I suspect that the answer to this problem does not lie in never producing it... thus this discussion.. I understand what the issue is for lightning because I read the thread that @rustyrussell posted that kicked off this discussion. The payment channel doesn't close and there's an issue. So.... is there a way to calculate the amounts you'd need for the channel to successfully close before you initiate or update the commitment in lightning? That's my question.

There may of course be additional details or information that relate to this discussion in the context of subsatoshi which is why I've copied @ktorn on this.

[ktorn]

@ABISprotocol I appreciate and sympathize with your philosophical concerns around what constitutes a dust transaction, but this is clearly not the appropriate thread for discussing those, for two reasons:

1. it is a technical thread, not a political one;
2. it deals with existing constraints of the underlying stack (i.e. bitcoin-core).

In short, this is not the dust you're looking for.

BTW, I like @NicolasDorier's idea and ideally long term we can have a bitcoin-core RPC call return the dust threshold at that point in time.

[ABISprotocol]

Hope this leads to a long term collaboration @NicolasDorier @ktorn

[NicolasDorier]

@jtimon verifyTx bitcoin/bitcoin#7552