New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support controlling txconfirmtarget over RPC #5796
Comments
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. |
If we're going down this route, I think it should be a (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 |
@promag What about the |
@MarcoFalke What about? |
It should be possible to use the |
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/ |
Bitcoin 0.10 introduces
txconfirmtarget
to 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 thatsendmany
andsentoaddress
could be augmented with an optional argument to override the defaulttxconfirmtarget
.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:but I feel that bitcoin should support it a bit more elegantly and safer with:
The text was updated successfully, but these errors were encountered: