Open darosior opened 3 years ago
Instead, why not sending it back to the 1ofM descriptor? I don't see why wasting money sending to an OP_RETURN. This way we might end up with some small inputs that we would never spend (not economical), but better than burning whatever amount every time.
You don't waste money sending to an OP_RETURN, it's 0-value.
Of course, if you don't need the entire spent txo value add a change output.. But you probably don't want to keep around a sub-1000sat utxo so you'll burn it at some point one way or another.
-------- Original Message -------- On Oct 23, 2021, 12:44, Daniela Brozzoni wrote:
Instead, why not sending it back to the 1ofM descriptor? I don't see why wasting money sending to an OP_RETURN. This way we might end up with some small inputs that we would never spend (not economical), but better than burning whatever amount every time.
— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android.
Ah yeah, now it makes sense :)
Concept ACK on lowering it - right now it's 30,000 sats (~16 eur), and "spending" 32 euros (unvault and spend) in "fees" for every spend seems a bit too much :)
This was discussed during the meeting and generally agreed it should be... Guess what? Configurable!
Still need to pick something for the default. Also, for the Spend it's not that simple. I guess we could reduce the feerate by the same factor as the Unvault magical number.
Let's say a factor of 2/3
? That makes the Unvault CPFP output 20_000
sats (allowing to create a ~180sats/vb child tx). That's also 7.5€ at today's market rate. For the Spend this makes the magical factor which today is 64
, 42
. I think that's a sign we shall not ignore.
Currently
30_000
sats, the CPFP output would allow to create a ~275sats/vbyte child transaction (consuming it entirely and paying to an emptyOP_RETURN
). That's probably way too much :)