Skip to content
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

Feature request: provide tx fee in direct-send api request #1360

Closed
theborakompanioni opened this issue Sep 26, 2022 · 11 comments · Fixed by #1597
Closed

Feature request: provide tx fee in direct-send api request #1360

theborakompanioni opened this issue Sep 26, 2022 · 11 comments · Fixed by #1597
Labels

Comments

@theborakompanioni
Copy link
Contributor

Would it be possible to provide the tx fee in sats/vbyte to the SendDirectRequest? Is this rather difficult to implement? I guess it can be done in a backward compatible way: If tx_fee prevent, use this a the miner fee, if no tx_fee is given is given, keep the current behaviour.

What do you think? Is this a feature worth implementing?

@kristapsk
Copy link
Member

This sounds good idea, should not be hard, --txfee argument can already be specified when using sendpayment.py. Note that it's only sat/vB for numbers above 1000, below that it is confirmation target in blocks.

@theborakompanioni
Copy link
Contributor Author

theborakompanioni commented Sep 26, 2022

This sounds good idea, should not be hard, --txfee argument can already be specified when using sendpayment.py. Note that it's only sat/vB for numbers above 1000, below that it is confirmation target in blocks.

Good to know. Thanks for the heads-up. Pardon the question, how would one actually send a transaction with 1sats/vbyte? Setting the block target to a high value such as 999?

Edit: Okay, looking at the docs, it's sats/kilo-vbyte - now I understand. Thank you!

@kristapsk
Copy link
Member

Okay, looking at the docs, it's sats/kilo-vbyte - now I understand. Thank you!

Ah, yes, not sat/vB.

@AdamISZ
Copy link
Member

AdamISZ commented Sep 27, 2022

Pardon the question, how would one actually send a transaction with 1sats/vbyte?

Just a side note: we have a comment in the config about this, but don't set txfee to less than 1200 sats/kvb, because we randomize it 20% (and that is hardcoded currently, we don't let users change it). I'd keep a safety buffer a bit higher than that if it was me, I'm never comfortable being too close to the limit (but ymmv there!).

@kristapsk
Copy link
Member

we randomize it 20% (and that is hardcoded currently, we don't let users change it).

Actually we do, for almost a year, since #1033 (v0.9.3).

# Transaction fee rate variance factor, 0.2 means 20% variation around
# any manually chosen values, so if you set tx_fees=10000 and
# tx_fees_factor=0.2, it might use any value between 8 thousand and 12 thousand
# for your transactions.
tx_fees_factor = 0.2

@theborakompanioni
Copy link
Contributor Author

Just a side note: we have a comment in the config about this, but don't set txfee to less than 1200 sats/kvb, because we randomize it 20% (and that is hardcoded currently, we don't let users change it). I'd keep a safety buffer a bit higher than that if it was me, I'm never comfortable being too close to the limit (but ymmv there!).

I know what you mean. Currently implementing adapting fee related configs in Jam and actively preventing setting it lower than 1000 sats/kilo-vbyte minus the lower max. randomization factor.
However,... technically, a 900 sats/kilo-vbyte transaction would be possible, right?

@kristapsk
Copy link
Member

technically, a 900 sats/kilo-vbyte transaction would be possible, right?

Yes, even 0 sat fee transactions are valid, but with default settings Bitcoin Core will not relay anything below 1 sat/vB (1000 sat/kvB).

@theborakompanioni
Copy link
Contributor Author

theborakompanioni commented Sep 29, 2022

Pardon the question, how would one actually send a transaction with 1sats/vbyte?

Just a side note: we have a comment in the config about this, but don't set txfee to less than 1200 sats/kvb, because we randomize it 20% (and that is hardcoded currently, we don't let users change it). I'd keep a safety buffer a bit higher than that if it was me, I'm never comfortable being too close to the limit (but ymmv there!).

Wouldn't it still be okay to set it to 1001 sats/kvb given that the value cannot go below mempoolminfee?
Asking because this is also being discussed in joinmarket-webui/jam#522 (comment)

@theborakompanioni
Copy link
Contributor Author

theborakompanioni commented Sep 29, 2022

Hmm.. just got this after a "direct-send" (4 inputs [one of them an expired fb], 1 output) with tx_fees := 1001 and tx_fees_factor := 0:

2022-09-29 03:54:34,238 [DEBUG]  rpc: getmempoolinfo None
2022-09-29 03:54:34,239 [INFO]  Using this manually set tx feerate: 1001 sat/vkB (1.0 sat/vB).
2022-09-29 03:54:34,240 [INFO]  Using a fee of: 0.00000315 BTC (315 sat).
2022-09-29 03:54:34,264 [INFO]  Got signed transaction:

2022-09-29 03:54:34,267 [INFO]  {
    "hex": "02000000000104d0189d23c6f5d253bc1baf415b04e4e4a78cf8dca755218233686a9d2f9c6c260100000000feffffffb9b4e4d9322f0d068eebae7f7b9d216103f650b41aa883aa3f66d91d47d5da7f0000000000feffffff8f16de5ec1685055e1fb74f652bd67a0fcdc70e27e970587c1b6e5e1c5f0c4700000000000feffffff8b9c9dc70083bb15eaf12553210a040d6d2253737af88a3a0ff99642162281760000000000feffffff019d04b67603000000160014cdbe0755b88d9e2b1fa54ae6968f92225dda9c810247304402207a825ce1ba720fe9d7c5e3fb402607988e5b3bcdd498f71d988a61ee8cc2a4af0220105e04bcc7203d17f57095c430e486f3fd4cdc51137d138ad48a1a15e281f424012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d902483045022100bac146aeb39ef1c17006d57f21321abedffc415b51a214fe28706b3855d9bceb022063167144dde451f8c5708aa892ce26d4f0ffa4d4506fc157a4b04321fa0d9b67012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd600247304402200520757d2e2be1d6b47764debe3375d956b3ee24bbf1fc5c6ad3ded40aa01afd022052e2abcba55855aec0c519938d1c5cb1840821bbdc694e178ad77a97b454848b012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd6002483045022100f16d03edf52a5365cb6c149697225b0b206fd68df0f43e186ae4a36403f2415102202ee826a8330903aec2febd318b3d6aa6adc78965d57a4f7241fc6477dedd3a0a012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac814f5661",
    "inputs": [
        {
            "outpoint": "266c9c2f9d6a6833822155a7dcf88ca7e4e4045b41af1bbc53d2f5c6239d18d0:1",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "0247304402207a825ce1ba720fe9d7c5e3fb402607988e5b3bcdd498f71d988a61ee8cc2a4af0220105e04bcc7203d17f57095c430e486f3fd4cdc51137d138ad48a1a15e281f424012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d9"
        },
        {
            "outpoint": "7fdad5471dd9663faa83a81ab450f60361219d7b7faeeb8e060d2f32d9e4b4b9:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "02483045022100bac146aeb39ef1c17006d57f21321abedffc415b51a214fe28706b3855d9bceb022063167144dde451f8c5708aa892ce26d4f0ffa4d4506fc157a4b04321fa0d9b67012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60"
        },
        {
            "outpoint": "70c4f0c5e1e5b6c18705977ee270dcfca067bd52f674fbe1555068c15ede168f:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "0247304402200520757d2e2be1d6b47764debe3375d956b3ee24bbf1fc5c6ad3ded40aa01afd022052e2abcba55855aec0c519938d1c5cb1840821bbdc694e178ad77a97b454848b012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60"
        },
        {
            "outpoint": "768122164296f90f3a8af87a7353226d0d040a215325f1ea15bb8300c79d9c8b:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "02483045022100f16d03edf52a5365cb6c149697225b0b206fd68df0f43e186ae4a36403f2415102202ee826a8330903aec2febd318b3d6aa6adc78965d57a4f7241fc6477dedd3a0a012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac"
        }
    ],
    "outputs": [
        {
            "value_sats": 14876542109,
            "scriptPubKey": "0014cdbe0755b88d9e2b1fa54ae6968f92225dda9c81",
            "address": "bcrt1qeklqw4dc3k0zk8a9ftnfdrujyfwa48ypknjcc9"
        }
    ],
    "txid": "917c66e7e96bdf0d8dfdc9c979dac41562a892555709d933e5e9fbbbbd2b181e",
    "nLockTime": 1633046401,
    "nVersion": 2
}
2022-09-29 03:54:34,267 [INFO]  Sends: 148.76542109 BTC (14876542109 sat) to destination: bcrt1qeklqw4dc3k0zk8a9ftnfdrujyfwa48ypknjcc9
2022-09-29 03:54:34,267 [DEBUG]  rpc: sendrawtransaction ['02000000000104d0189d23c6f5d253bc1baf415b04e4e4a78cf8dca755218233686a9d2f9c6c260100000000feffffffb9b4e4d9322f0d068eebae7f7b9d216103f650b41aa883aa3f66d91d47d5da7f0000000000feffffff8f16de5ec1685055e1fb74f652bd67a0fcdc70e27e970587c1b6e5e1c5f0c4700000000000feffffff8b9c9dc70083bb15eaf12553210a040d6d2253737af88a3a0ff99642162281760000000000feffffff019d04b67603000000160014cdbe0755b88d9e2b1fa54ae6968f92225dda9c810247304402207a825ce1ba720fe9d7c5e3fb402607988e5b3bcdd498f71d988a61ee8cc2a4af0220105e04bcc7203d17f57095c430e486f3fd4cdc51137d138ad48a1a15e281f424012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d902483045022100bac146aeb39ef1c17006d57f21321abedffc415b51a214fe28706b3855d9bceb022063167144dde451f8c5708aa892ce26d4f0ffa4d4506fc157a4b04321fa0d9b67012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd600247304402200520757d2e2be1d6b47764debe3375d956b3ee24bbf1fc5c6ad3ded40aa01afd022052e2abcba55855aec0c519938d1c5cb1840821bbdc694e178ad77a97b454848b012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd6002483045022100f16d03edf52a5365cb6c149697225b0b206fd68df0f43e186ae4a36403f2415102202ee826a8330903aec2febd318b3d6aa6adc78965d57a4f7241fc6477dedd3a0a012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac814f5661']
2022-09-29 03:54:34,272 [WARNING]  error pushing = -26 min relay fee not met, 315 < 316
2022-09-29 03:54:34,272 [ERROR]  Transaction broadcast failed!

But shortly afterwards - without changing anything:

2022-09-29 03:57:02,103 [DEBUG]  rpc: getmempoolinfo None
2022-09-29 03:57:02,104 [INFO]  Using this manually set tx feerate: 1001 sat/vkB (1.0 sat/vB).
2022-09-29 03:57:02,105 [INFO]  Using a fee of: 0.00000315 BTC (315 sat).
2022-09-29 03:57:02,126 [INFO]  Got signed transaction:

2022-09-29 03:57:02,129 [INFO]  {
    "hex": "02000000000104d0189d23c6f5d253bc1baf415b04e4e4a78cf8dca755218233686a9d2f9c6c260100000000feffffff8b9c9dc70083bb15eaf12553210a040d6d2253737af88a3a0ff99642162281760000000000feffffffb9b4e4d9322f0d068eebae7f7b9d216103f650b41aa883aa3f66d91d47d5da7f0000000000feffffff8f16de5ec1685055e1fb74f652bd67a0fcdc70e27e970587c1b6e5e1c5f0c4700000000000feffffff019d04b67603000000160014cdbe0755b88d9e2b1fa54ae6968f92225dda9c8102483045022100b46c66121dfed65b966649b2c5524395005f7b40c1145cd1ffc51f59df35faa502205814b84cbfff79ff46f339db51a01171ecb269d0f6daf456c3541dac57b23bc9012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d9024730440220499d46be30f9cbb27884b85bece69c63a5b9eb863203e65f597f7bf5760a73200220450f4a270557b2de8a34020b6b74c9db12ea79bf7d0b6b33daebcf9915982a6b012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac0247304402202878c559e9ae5ebfe1332291cff481759ee9e21b92c5a9cbb2a59c1fb91302a702202a1c8d78d9b5f5241ff734d5c46a2aa387bb968ea5a5d7dd3e4aaa14472034e9012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd600247304402200e5bb3cb21868e5b27733ecb0d0241febe6e5620ee37bcc93bd70c637287ab37022057942c10f81282b01b705c4ccf34b272c4227fbfa2c9f09abcb78784eef80696012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60814f5661",
    "inputs": [
        {
            "outpoint": "266c9c2f9d6a6833822155a7dcf88ca7e4e4045b41af1bbc53d2f5c6239d18d0:1",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "02483045022100b46c66121dfed65b966649b2c5524395005f7b40c1145cd1ffc51f59df35faa502205814b84cbfff79ff46f339db51a01171ecb269d0f6daf456c3541dac57b23bc9012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d9"
        },
        {
            "outpoint": "768122164296f90f3a8af87a7353226d0d040a215325f1ea15bb8300c79d9c8b:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "024730440220499d46be30f9cbb27884b85bece69c63a5b9eb863203e65f597f7bf5760a73200220450f4a270557b2de8a34020b6b74c9db12ea79bf7d0b6b33daebcf9915982a6b012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac"
        },
        {
            "outpoint": "7fdad5471dd9663faa83a81ab450f60361219d7b7faeeb8e060d2f32d9e4b4b9:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "0247304402202878c559e9ae5ebfe1332291cff481759ee9e21b92c5a9cbb2a59c1fb91302a702202a1c8d78d9b5f5241ff734d5c46a2aa387bb968ea5a5d7dd3e4aaa14472034e9012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60"
        },
        {
            "outpoint": "70c4f0c5e1e5b6c18705977ee270dcfca067bd52f674fbe1555068c15ede168f:0",
            "scriptSig": "",
            "nSequence": 4294967294,
            "witness": "0247304402200e5bb3cb21868e5b27733ecb0d0241febe6e5620ee37bcc93bd70c637287ab37022057942c10f81282b01b705c4ccf34b272c4227fbfa2c9f09abcb78784eef80696012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60"
        }
    ],
    "outputs": [
        {
            "value_sats": 14876542109,
            "scriptPubKey": "0014cdbe0755b88d9e2b1fa54ae6968f92225dda9c81",
            "address": "bcrt1qeklqw4dc3k0zk8a9ftnfdrujyfwa48ypknjcc9"
        }
    ],
    "txid": "41f153e92a4cfdc77abe6d2edf3725338babd97f149eef7eceb21e52a4775a2d",
    "nLockTime": 1633046401,
    "nVersion": 2
}
2022-09-29 03:57:02,130 [INFO]  Sends: 148.76542109 BTC (14876542109 sat) to destination: bcrt1qeklqw4dc3k0zk8a9ftnfdrujyfwa48ypknjcc9
2022-09-29 03:57:02,130 [DEBUG]  rpc: sendrawtransaction ['02000000000104d0189d23c6f5d253bc1baf415b04e4e4a78cf8dca755218233686a9d2f9c6c260100000000feffffff8b9c9dc70083bb15eaf12553210a040d6d2253737af88a3a0ff99642162281760000000000feffffffb9b4e4d9322f0d068eebae7f7b9d216103f650b41aa883aa3f66d91d47d5da7f0000000000feffffff8f16de5ec1685055e1fb74f652bd67a0fcdc70e27e970587c1b6e5e1c5f0c4700000000000feffffff019d04b67603000000160014cdbe0755b88d9e2b1fa54ae6968f92225dda9c8102483045022100b46c66121dfed65b966649b2c5524395005f7b40c1145cd1ffc51f59df35faa502205814b84cbfff79ff46f339db51a01171ecb269d0f6daf456c3541dac57b23bc9012102081ae230b8117d251ed3a86915c148e8d32f229a2266ba10dce6e0bd44ccb5d9024730440220499d46be30f9cbb27884b85bece69c63a5b9eb863203e65f597f7bf5760a73200220450f4a270557b2de8a34020b6b74c9db12ea79bf7d0b6b33daebcf9915982a6b012a04804f5661b1752102e0d7ac6e6f6bcc74f224916bcc09c9a58b3c4ff93f72844fa8d5b1d5cd3863dfac0247304402202878c559e9ae5ebfe1332291cff481759ee9e21b92c5a9cbb2a59c1fb91302a702202a1c8d78d9b5f5241ff734d5c46a2aa387bb968ea5a5d7dd3e4aaa14472034e9012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd600247304402200e5bb3cb21868e5b27733ecb0d0241febe6e5620ee37bcc93bd70c637287ab37022057942c10f81282b01b705c4ccf34b272c4227fbfa2c9f09abcb78784eef80696012103b6a31e7978e687dc5cdd828e4077c6ef1ffb17b99f88f83bd35129a57bc2bd60814f5661']
2022-09-29 03:57:02,135 [INFO]  Transaction sent: 41f153e92a4cfdc77abe6d2edf3725338babd97f149eef7eceb21e52a4775a2d

First transaction (failed) is 646 bytes.
Second transaction (success) is 645 bytes.

🤔
I am just shooting in the dark, but maybe round up here: https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/v0.9.8/jmclient/jmclient/wallet.py#L83 ?

bitcoin-cli getmempoolinfo
{
  "loaded": true,
  "size": 3,
  "bytes": 330,
  "usage": 3648,
  "total_fee": 0.00000333,
  "maxmempool": 500000000,
  "mempoolminfee": 0.00001000,
  "minrelaytxfee": 0.00001000,
  "unbroadcastcount": 3
}

@kristapsk
Copy link
Member

Ahh, yes, there are multiple situations where JM sometimes incorrectly calculates tx vsize.

@theborakompanioni
Copy link
Contributor Author

This sounds good idea, should not be hard, --txfee argument can already be specified [...]

Any updates/estimates on this @kristapsk? Would greatly enhance the UX in Jam. Also nice to have for joinmarket-webui/jam#678 since no change output is created and it cannot be CPFPd.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants