Create a generalized rpc command for creating a transaction

[RHavar]

There's some pretty severe limitations with all the current rpc APIs to send a transaction, so I think it might make sense to create a more generalized API that subsumes them (createrawtransaction, fundrawtransaction, sendmany)

Arguments it should have:

• transactions (from createcrawtransaction) with the difference that if you leave sequence undefined it uses normal core sequence number picking, instead of 0

• amounts from sendmany but not an object, but an array of outputs (the current object makes it very annoying to implement batched withdrawal logic when multiple payments are to the same address), along with the addition of subtractfeefromamount as an option in the object

• The options from fundrawtransaction, along with the additional ability to pick to broadcast the transaction or not.

---

And the return should contain the full transaction, txid, fees paid, and location of the change.

[BlackFoxController]

I don't see a limitation here. Are you asking for the 4 commands (create, fund, sign, send) to be done in one command? (to save, say bandwidth space?)

I also don't understand what sendmany has to do with the raw transaction? I think sendmany and sendrawtransation both request the same input which is [ {"address":amount}, ... ]

[RHavar]

I don't see a limitation here. Are you asking for the 4 commands (create, fund, sign, send) to be done in one command? (to save, say bandwidth space?)

No, it's not about using fewer rpc calls, but about creating it's about a better and more general purpose sending API. The current one has significant enough limitations for advanced use cases that I've actually found it easier as a client to use a bitcoin library to create the transaction and then pass it to bitcoin core to sign.

A simple example is that when you're batching sends, you might not want to send to the same address multiple times. Or maybe you want to use a particular input (e.g. when issuing someone a refund/withdrawal, you want to make sure if their initial payment failed to confirm their refund would also do so)

[BlackFoxController]

But wouldn't you check for address duplicates (in your batch payment) before you send it to the bitcoin client? It seems perhaps not the purpose of the bitcoin software to deal with that?

And if you want to use a particular input, would this one not do the trick:
createrawtransaction [{ "txid":"input_txhash","vout":input_n }] {"refund_address": refund_amount}

(e.g. you can keep fundrawtransaction out of the equation completely for that?)

[RHavar]

It seems perhaps not the purpose of the bitcoin software to deal with that?

I think this is getting a bit off-topic, but there's no particular reason that the RPC API should restrict you from sending funds to the same address multiple times. There's a few legitimate use cases for it, and it can also drastically simplify the clients logic (i.e. can assume a unique txid:vout for each queued send).

And if you want to use a particular input, would this one not do the trick:
createrawtransaction [{ "txid":"input_txhash","vout":input_n }] {"refund_address": refund_amount}

Not really, that has a few problems. For one, all those inputs would have a sequence of 0, which would make your transactions more recognizable. Then you still need to deal with cases like adding change address and sourcing additional inputs if needed (i.e. all the stuff fundrawtransaction does). And then you need to figure out how much fees to apply (which changes based on the size of the transaction.

And then by the time you've solved all those problems, you'd probably just wish there was a generalized api call for it... ;D

[maflcko]

Pull request welcome, but I don't think it makes sense to keep the feature request open.

Also note it is possible to specify sequence numbers: #7957

[adamjonas]

Closing for lack of activity/progress.

As Marco mentioned, pull requests welcome if there is further interest.

[maflcko]

I think this was fixed by send (experimental)?

[jonatack]

And the return should contain the full transaction, txid, fees paid, and location of the change.

I've often thought the same, at least if verbose is true.