lnd: lnwallet: incorrect dust limit applied for p2wkh outputs

Background

Cannot use sendcoins to send 294 sats to a p2wkh address.

Your environment

  • lnd v0.9.0-beta-rc3
  • linux
  • btcd 0.20.0-beta

Steps to reproduce

  • lncli newaddress p2wkh
  • lncli sendcoins <address_from_above> 294

Expected behaviour

Coins sent

Actual behaviour

[lncli] rpc error: code = Unknown desc = transaction output is dust

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 21 (7 by maintainers)

Most upvoted comments

I will have to check bitcoin core’s relay dust in a functional/unit test, but I suspect it’s the same as btcd’s (which pulled the relevant code from Core) and counts 294 as lowest non-dust for p2wpkh. Your calculations are correct, just the code is wrong. Also, do you happen to know why the output being spent’s serialized size is included in the calculation for dust? I ask because the output serialized size isn’t included in the spending transaction, so I’m not sure why it’s counted?

Args. 🤕

Well, the actual size of a P2WPKH input is 67.75 vB or 68 vB, depending on whether you get a low-r or high-r signature. But apparently, when the dust limit was implemented for p2wpkh, the author didn’t round up as is policy for the conversion of weight to vsize. I would expect that Bitcoin Core will continue to use this value for the dust limit as changing it would affect network policy interactions. I would suspect, though, that this error only applies to the dust calculation, and the correct weight is relevant in other places e.g. for the minRelayTxFeeRate.

@MrManPew: I was just looking at this notification and another project that was also investigating an input size related issue, so I wrote https://bitcoin.stackexchange.com/q/100159/5406

@Xekyo maybe you can double check this one? Thanks

@MrManPew: A p2wpkh input should have up to 68 vbytes and a p2wpkh output has 31 bytes, so by using the same dust definition as Bitcoin Core, the dust limit for p2wpkh would be (68+31)×3 = 297. That may be why 294 is failing?

Fix for 0.11?