Open yanmaani opened 3 years ago
I'm not sure about this. While it certainly makes the flow a bit easier, fundrawtransaction
's main function is to choose coins using wallet logic, which is not trivial to do explicitly. Adding a name input on the other hand is something that is trivial to do for a caller by themselves. As the RPC interface is meant to be used by software (mostly), I think the better solution here is to just let that software call name_show
first and add the input by itself.
Also, I'm not a big fan of using higher-than-0.01 NMC values in names. While that is certainly possible of course, it feels like a hack to me and I think we should avoid it as much as possible.
I'm not sure about this. While it certainly makes the flow a bit easier,
fundrawtransaction
's main function is to choose coins using wallet logic, which is not trivial to do explicitly. Adding a name input on the other hand is something that is trivial to do for a caller by themselves. As the RPC interface is meant to be used by software (mostly), I think the better solution here is to just let that software callname_show
first and add the input by itself.
@domob1812 Quoting https://github.com/namecoin/namecoin-core/blob/master/doc/psbt.md#rpcs :
walletcreatefundedpsbt
(Creator, Updater) is a wallet RPC that creates a PSBT with the specified inputs and outputs, adds additional inputs and change to it to balance it out, and adds relevant metadata. In particular, for inputs that the wallet knows about (counting towards its normal or watch-only balance), UTXO information will be added. For outputs and inputs with UTXO information present, key and script information will be added which the wallet knows about. It is equivalent to runningcreaterawtransaction
, followed byfundrawtransaction
, andconverttopsbt
.
IMO, adding a name input or a name output to balance a transaction that has a name input but no name output (or vice versa) is very much within the stated scope of "add[ing] additional inputs and change to it to balance it out".
Also, I'm not convinced that doing this as 2 separate RPC's is always easy. If we add a name output first and then run fundrawtransaction
, then that means we need to figure out the name output address ourselves, and also means that we can't consolidate the name output and the change output into a pure name output. If we run fundrawtransaction
first and then add a name output, then fundrawtransaction
's calculated fee will no longer be correct because of the extra bytes taken by the name script prefix.
Generally I would rather have this kind of functionality in the RPC interface, where it can properly be subject to integration tests, rather than figuring "the application will handle this", especially something like this where I don't have any confidence that application devs (including me) will find this to be trivial. Keeping the RPC interface too low-level has bitten us before (mainly in cases where the GUI ended up adding logic that would have been better to have in the RPC interface).
Also, I'm not a big fan of using higher-than-0.01 NMC values in names. While that is certainly possible of course, it feels like a hack to me and I think we should avoid it as much as possible.
If you dislike pure name transactions, it would be good if you could explain why in https://github.com/namecoin/meta/issues/43 (I think they're generally a good idea for multiple reasons, as elaborated in that issue).
@JeremyRand Thanks for your feedback! I thought the point was to add the name input, not the name output? Because you need to add the name output anyway already when you specify the name operation - just like you add the desired outputs before you call fundrawtransaction
for currency transactions? Adding the name input manually is trivial IMHO. (But sure, if you prefer to do this in fundrawtransaction
, I have no really strong objection. Just trying to keep daemon complexity to the minimum where possible.)
Also one thing to note: fundrawtransaction
only works if all inputs are solvable (independent of which ones you add manually and which ones are present already). In particular, it will not work for processing atomic trades unfortunately.
@domob1812
Also one thing to note:
fundrawtransaction
only works if all inputs are solvable (independent of which ones you add manually and which ones are present already). In particular, it will not work for processing atomic trades unfortunately.
Any reason for this? Could we change it so it does work with atomic name trades?
If you're dealing with fungible currency, then it makes sense not to add random people's coins to it, but if you're just dealing with names, why not? There's only one possible input, right?
@yanmaani The reason is fee computation and upstream https://github.com/bitcoin/bitcoin/issues/7879. If we can get upstream to solve this, I would be very happy myself, but I doubt it.
What one can do instead is use fundrawtransaction
as the "buyer" of a name, and then just manually add the name input and output to it. This increases the size of the transaction by less than 50%, so you just need to be "a little" generous in the feerate when calling fundrawtransaction
. At least, that's the best solution I was able to come up with so far (and that's what we plan to use for trading in Xaya).
@yanmaani The reason is fee computation and upstream bitcoin/bitcoin#7879. If we can get upstream to solve this, I would be very happy myself, but I doubt it.
@domob1812 If I'm understanding correctly Andrew's explanation at https://github.com/bitcoin/bitcoin/issues/7879#issuecomment-511847862 , it sounds like the high-level issue is that Bitcoin Core expects some metadata to be present for the inputs, which is not available in the network-serialized format that fundrawtransaction
accepts. Is this metadata covered by the PSBT specification, or is it not even present there? If it's covered by PSBT, then that seems like a strong hint that we should be using PSBT for this use case rather than the network serialization that Andrew recommended to us. If PSBT doesn't cover it, then that seems like a bug in the PSBT spec.
What one can do instead is use
fundrawtransaction
as the "buyer" of a name, and then just manually add the name input and output to it. This increases the size of the transaction by less than 50%, so you just need to be "a little" generous in the feerate when callingfundrawtransaction
. At least, that's the best solution I was able to come up with so far (and that's what we plan to use for trading in Xaya).
This is an incredibly messy solution since it means that the feerate passed by the user is unpredictably different from the feerate that actually gets used. I would really rather get this resolved properly, even if it takes more effort.
According to https://github.com/bitcoin/bitcoin/blob/master/doc/psbt.md#overall-workflow , PSBT metadata includes:
information about the scripts and public keys involved in each of the inputs (and possibly outputs) of the PSBT
Which sounds like it covers the metadata that's missing according to Andrew's explanation about fundrawtransaction
. So it sounds like we should be using PSBT for this. @domob1812 Is my analysis accurate?
@JeremyRand Yes indeed, I think the data should be present in PSBTs. I do not know if fundpsbt
works with imported addresses in Bitcoin Core - if you got some time, maybe try it out? If it does, then we should just go with PSBTs and all should work well (and I'd be happy also for Xaya usecases). If it doesn't, then indeed that would be a good reason to bring it back up with upstream Bitcoin, and see if we can get that support added.
@JeremyRand Yes indeed, I think the data should be present in PSBTs. I do not know if
fundpsbt
works with imported addresses in Bitcoin Core - if you got some time, maybe try it out? If it does, then we should just go with PSBTs and all should work well (and I'd be happy also for Xaya usecases). If it doesn't, then indeed that would be a good reason to bring it back up with upstream Bitcoin, and see if we can get that support added.
@domob1812 Unless the Bitcoin Core docs are outdated, there is no direct PSBT equivalent of fundrawtransaction
; there is only walletcreatefundedpsbt
, which does not accept a PSBT as input. Should we ask Bitcoin Core to add a fundpsbt
RPC method that accepts a PSBT as input, and utilizes PSBT metadata to correctly handle inputs that are not solvable by the wallet?
@JeremyRand I'm not aware of any other approach either, so yes, let's see what they think about that.
@domob1812
What one can do instead is use
fundrawtransaction
as the "buyer" of a name, and then just manually add the name input and output to it. This increases the size of the transaction by less than 50%, so you just need to be "a little" generous in the feerate when callingfundrawtransaction
. At least, that's the best solution I was able to come up with so far (and that's what we plan to use for trading in Xaya).
If you want to do that then it'd make more sense to add a parameter to fundrawtransaction 'bytes', so that the fee is calculated for size+bytes (default value = 0).
If you want to do that then it'd make more sense to add a parameter to fundrawtransaction 'bytes', so that the fee is calculated for size+bytes (default value = 0).
Yes, we can do that. I don't think it is the best approach in general - getting upstream Bitcoin to "fix" funding would be ideal. The suggested approach (maybe with your change) is just something we can do instead if they don't agree. Also I think from a practical point of view, very precise fee estimation is at least for now not very important in Namecoin anyway.
If you have a transaction with more output than input value,
fundrawtransaction
will add inputs to match and to pay the fee.It would be nice, especially for atomic name trades, if
fundrawtransaction
would add missing name inputs too. e.g. turn this:into this:
Then you could accept non-interactive offers by feeding them into fundrawtransaction. Here is some (edited) discussion from IRC about this: (emphasis added)
Also, the change should go into the name, because anything above NMC 0.01 is spendable: