Support controlling txconfirmtarget over RPC #5796

Bitcoin 0.10 introduces txconfirmtargetto control how quickly transactions should confirm, however unfortunately this is unexposed over RPC. It would be extremely useful to be able to configure this on a per-transaction level. I am thinking that sendmany and sentoaddress could be augmented with an optional argument to override the default txconfirmtarget.

The use-case for this is pretty simple, certain transactions I don't really care if they take a while (e.g. sweeping to cold), while other transactions I need to confirm ASAP. A system wide configuration is too course grain for this.

Right now I've hacked my bitcoin client with a quick an dirty settxconfirmtarget and can send transactions like:

bitcoin-cli settxconfirmtarget 6
bitcoin-cli sendtoaddress $COLD_WALLET $AMOUNT
bitcoin-cli settxconfirmtarget 1

but I feel that bitcoin should support it a bit more elegantly and safer with:

bitcoin-cli sendtoaddress $COLD_WALLET $AMOUNT "" "" 6

I'd prefer the stateless method too, works better in case of concurrency. Ideally all the send* methods would go away, and be replaced with one send method that takes a structure that specifies the whole configuration (including addresses and amounts, fee/kb, maximum fee, confirm targets, minconfirms and such), instead of playing positional parameter bingo or changing defaults on the fly.

Ideally all the send* methods would go away, and be replaced with one send method

If we're going down this route, I think it should be a create method, where send is merely one of the options. Being able to create transactions (using bitcoin-cores coin and fee selection) without pushing them on the network has a lot of use-cases: multi-sig, offline, and in my personal case I would much prefer to push transactions over tor than push them to peers.

(I do not wish to run the entire node behind tor, and as I process hundreds of user-requested transfers per day, if I connect to arbitrary nodes on the network it is trivial for an attacker to learn my node's ip address for either DoS'ing it, or listening to my node to see what other transactions I (probably) created).

If I had a way of creating the transaction, and not sending it, I could easily listen to the general network and merely push my transactions over tor.

(And yes, I'm aware of createrawtransaction, but the interface is far too low-level to work with. Writing coin selection and fee calculations is something I'd rather not concern myself with)

After this fundrawtransaction, bumpfee and others were implemented. There's also PSBT. I think this can be closed?

@promag What about the send* rpcs?

@MarcoFalke What about?

It should be possible to use the send* rpcs, specifying a confirm target. We shouldn't force users to deal with raw transactions.

Ideally all the send* methods would go away, and be replaced with one send method that takes a structure that specifies the whole configuration

You mean in this new RPC or in the existing?

Also, I thought that, with the current set RPC interface, @RHavar would be just fine with raw transactions, considering his use cases.

Oh, I see they both have a conf_target: https://bitcoincore.org/en/doc/0.18.0/rpc/wallet/sendtoaddress/