Maybe we could give Spend outputs larger than Bitcoin dust but lower than Revault dust to managers

[darosior]

trafficstars

Currently we would give away up to 199_999 sats in fees to the miners. Miners getting paid is good, but hey it's 100$ at current BTC/USD price!

https://github.com/revault/revaultd/blob/ebd9cbf0c48ecf3200a3c12e40051761f66a3d29/src/daemon/jsonrpc/api.rs#L1075-L1097

Also we are not interested in outputs just above network dust, so maybe if it's higher than the CPFP output value?

[danielabrozzoni]

What do you mean "to managers"? To a multisig between all the managers? IMHO this makes the UX way more complicated. I would use just the network dust here and create the change if the value is above dust. In future we could be smarter and start saying "we create the change only if it's worth it" (I mean, if the fees for spending it aren't more expensive than the utxo itself)...

[darosior]

The change would be unspendable if below "our" dust.

EDIT: sorry, expanding a bit.

It is not worth creating an expensive transaction chain for small UTxOs. Actually i believe that it's not worth doing so before at least a million sats. We should not create a change paying to the N-of-N of the stakeholders in this case. However, if above the network dust it could be sent to the M-of-M of the managers and used to feebump the Unvaults and Spends (note this would allow to RBF the Spend without CPFP'ing too by reducing the "M-of-M change" if no cosigning servers).

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le mercredi 8 septembre 2021 à 11:35 AM, Daniela Brozzoni @.***> a écrit :

What do you mean "to managers"? To a multisig between all the managers? IMHO this makes the UX way more complicated. I would use just the network dust here and create the change if the value is above dust. In future we could be smarter and start saying "we create the change only if it's worth it" (I mean, if the fees for spending it aren't more expensive than the utxo itself)...

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[danielabrozzoni]

We should not create a change paying to the N-of-N of the stakeholders in this case.

Ah right, agreed

However, if above the network dust it could be sent to the M-of-M of the managers and used to feebump the Unvaults and Spends

Ok I get your point, but this could be confusing. Is it too much of a problem to send it to the cpfp wallet instead (1-of-M)?

[darosior]

Sorry, yes, 1ofM is what i meant. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Le mercredi 8 septembre 2021 à 3:39 PM, Daniela Brozzoni @.***> a écrit :

We should not create a change paying to the N-of-N of the stakeholders in this case.

Ah right, agreed

However, if above the network dust it could be sent to the M-of-M of the managers and used to feebump the Unvaults and Spends

Ok I get your point, but this could be confusing. Is it too much of a problem to send it to the cpfp wallet instead (1-of-M)?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.

[danielabrozzoni]

Concept ACK then :)

[darosior]

The "deposit split project" would help here as we would batch small inputs to create a vault of a given threshold.