< shesek> I'm afraid that I'm probably not the the right person for the job, but I will happily help with testing. :) but yes, sorry, I know that making these requests without offering any help implementing them is not very useful. bitcoin core has plenty of features that could be added if someone with the expertise and time prioritized them
< shesek> and to make yet another not very useful request: it is somewhat annoying that `listtransactions` doesn't list the block height directly, but only the block hash and number of confirmations. it would typically mean that you'll need an extra rpc request per transaction to figure the height out (that's what electrum-personal-server does for example)
< shesek> I hacked around it in a different way - I first check the tip, then fetch `listtransactions`, then make sure the tip hasn't moved in the meanwhile (and retry if it did), then calculate the block height is tip_height-confirmations+1. which isn't very ideal either :)
< luke-jr> sipa: it might make sense to show the sum of fees pushing for unconfirmed transactions
< luke-jr> ie, including descendants in it
< kanzure> shesek: document in a ticket
< bitcoin-git> [bitcoin] shesek opened pull request #19002: docs: Document that 'fee' is unavailable when there are non-wallet inputs (master...202005-docs-fee) https://github.com/bitcoin/bitcoin/pull/19002
< shesek> kanzure, ^
< * luke-jr> prods people to review #17946 <.<
< gribble> https://github.com/bitcoin/bitcoin/issues/17946 | Fix GBT: Restore "!segwit" and "csv" to "rules" key by luke-jr · Pull Request #17946 · bitcoin/bitcoin · GitHub
< luke-jr> (apparently this bug is causing segwit transactions to not get mined)
< shesek> luke-jr, you helped convince me to avoid reporting a fee for incoming payments altogether, this is indeed pretty useless without taking parent and child fees into account as well. saved me a bunch work, thanks :p
< hebasto> wumpus: kindly reminder -- is it time to upload rc2 to https://bitcoincore.org/bin/bitcoin-core-0.20.0/ ?
< shesek> sipa, getmempoolentry is useful indeed, not sure why I haven't considered it (I do ideally need this for confirmed transactions too, but its not as important). thanks.
< shesek> but now I'm no longer sure that I should be providing raw feerate info for incoming transactions. what would be a sensible way to display fee information that takes ancestors/descendants into account to a user? ideally I'm thinking of a metric that says "if the miner clears transactions paying X sat/vB, this transaction should get included"
< shesek> taking ancestors into account seems easy enough - total fees divided by total vsize. but descendants are more tricky because you only need to take the ones that increase the combined feerate into account, right?
< shesek> I guess that means recursively iterating over `spentby` and figuring it out?
< sipa> shesek: if you want to make a guess for inclusion... run getblocktemplate
< sipa> perhaps we could expose a way that uses the same algorithm, but without the block weight/sigops restrictions, to have an idea how far down every transaction gets included
< shesek> I'm not trying to determine the feerate needed to get included in the next block, I'm trying to tell how low the feerate has to be in order for the transaction package to get included
< sipa> yeah, i know
< shesek> oh, sorry. I misunderstood you. how can I use getblocktemplate for that?
< sipa> the current algorithm that GBT uses (but this is an implementation detail and subject to change) basically includes transactions in feerate order
< sipa> (package feerate)
< sipa> so you can see how far down in the GBT result you are, to see how many kB worth of block spaces goes to other transactions before it
< sipa> of course, that is restricted to 1 block
< sipa> but it's not too hard to modify things to have a (non-GBT) way to computing the same thing for more than just 1 block
< shesek> so basically make larger and larger blocks until I see the transaction is able to get in? clever, but terribly inefficient :)
< shesek> I guess there's no --bitcoin-unlimited parameter that would easily let me make blocks that are larger than the weight limit, right? :p
< shesek> but it wouldn't be relevant for my purposes anyway, its aimed for personal use on a low-resource environment
< sipa> not larger and larger; just once for a huge size, and keep track of the order
< shesek> assuming a very large mempool and a transaction that's paying a high fee rate relative to others, it could be quite wasteful. like, maybe it would've been enough to create a 10kb block, but you're creating a 50mb one instead anyway
< shesek> so hmm, how about I simply use `ancestorfees/ancestorsize`? this would at least take low feerate ancestors into account, making the feerate less misleading. it still won't take cpfp into account, but still better than just the raw feerate
< shesek> thanks for all the help and your time btw, its very appreciated
< bitcoin-git> [bitcoin] kcalvinalvin opened pull request #19004: script: Replace const char* to std::string (master...replace-char-with-string) https://github.com/bitcoin/bitcoin/pull/19004
< harding> I'm not sure knowing how deep a transaction is in the package-feerate sorted mempool is useful to normal users. E.g., knowing that a transaction is 3 block candidates deep in the mempool doesn't mean it's likely to be mined three blocks from now---during active periods, it's likely to be mined much later than that as additional relayed transactions arrive paying next-block and second-to-next-block feerates. If you want to give
< harding> useful information to the use, I think you want to (1) use getmempoolentry recursively to enumerate all of its descendents (this is limited to 25 by default), (2) find whichever one of those descendents has the highest package feerate (ancestorfees / ancestorsize), (3) loop over the estimatesmartfee estimates for the closest feerate match and report to the user something like "estimated to confirm within 30 blocks".
< aj> harding: i think getblocktemplate is useful for the case where you have P at 1kB + 1000sat, A spending P:0 at 200B, 6000sat, and B spending P:1 at 200B, 800 sat -- gbt will include P+A at 5sat/byte, then B at 4sat/byte, even though B's ancestor fee rate is only 1.5sat/byte
< harding> aj: which of those transactions is the one affecting the user's wallet?
< harding> The one the user wants to know whether it needs to be fee bumped?
< aj> harding: B
< harding> Hmm. That's a good point, but I think it means that both methods might suck for anything that's not in the next-block top of the mempool. If P+A gets mined without B, then B drops much further down in the mempool.
< aj> harding: no, 4sat/byte is B's fee rate on its own, it won't move lower
< harding> Yeah, sorry.
< aj> harding: otherwise, yeah
< wumpus> hebasto: yes, thanks for the reminder, didn't get around to it in the weekend
< hebasto> \o/
< hebasto> downloaded rc2 source archive looks nice :)
< bitcoin-git> [bitcoin] kcalvinalvin opened pull request #19005: doc: Add documentation for 'checklevel' argument in 'verifychain' RPC… (master...add-documentation-for-verifychain) https://github.com/bitcoin/bitcoin/pull/19005
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #19006: http: Avoid crash when g_thread_http was never started (master...2005-httpNoCrash) https://github.com/bitcoin/bitcoin/pull/19006
< jonasschnelli> ugh. #12783 introduced a nasty mac only GUI blocking issue
< gribble> https://github.com/bitcoin/bitcoin/issues/12783 | macOS: disable AppNap during sync by krab · Pull Request #12783 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #19007: relax GUI locks: avoid unnecesarry calls to ::ChainstateActive().IsInitialBlockDownload (master...2020/05/fix_macguilock) https://github.com/bitcoin/bitcoin/pull/19007
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #19008: ci: tsan on focal (master...2005-ciTsanFocal) https://github.com/bitcoin/bitcoin/pull/19008
< bitcoin-git> [bitcoin] h2o10 opened pull request #19009: Print "verifychain" progress every 1 step if user verifies whole blockchain. (master...patch-3) https://github.com/bitcoin/bitcoin/pull/19009
< bitcoin-git> [bitcoin] jnewbery opened pull request #19010: net processing: Add support for getcfheaders (master...2020-05-cfheaders) https://github.com/bitcoin/bitcoin/pull/19010
< pierre_rochard> For those interested, https://bitcoinacks.com is back up, feel free to send pull requests / feature ideas
< michaelfolkson> Awesome. I'm assuming from the above you have the time to maintain it pierre_rochard going forward?
< pierre_rochard> Yes for the foreseeable future, if that changes I'll notify here and hand it over if there are users.
< michaelfolkson> Cool, that's great. Thanks
< harding> pierre_rochard: thanks!
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #19011: Reduce cs_main lock accumulation during GUI startup (master...2020/05/guilocks) https://github.com/bitcoin/bitcoin/pull/19011
< tryphe> is there any way to resolve these review comments? i guess i've selected the wrong review type but it looks ugly to see all of my comments expanded: https://github.com/bitcoin/bitcoin/pull/19004#pullrequestreview-413807305
< tryphe> or maybe i can't and will have to select the right one in the future
< jonasschnelli> tryphe: don't you have a "Resolve conversation" button?
< sipa> tryphe: i marked them resolved for you
< jonasschnelli> (or is that an admin thing?)
< tryphe> sipa, thanks
< tryphe> jonasschnelli, i had selected the first type of review, something like "general comments"
< sipa> tryphe: not sure what you mean by review type
< tryphe> i guess the resolve button is only available for the other 2 choices
< tryphe> sipa, when you press "start a review" there's multiple choices, and i wasn't able to unexpand my comments from showing up in the default thread without you doing it
< tryphe> will use the other ones in the future
< tryphe> i guess maybe only the author and admins can resolve the conversation?
< tryphe> author/PR author
< sipa> huh, never seen that
< tryphe> yeah i had figured i could resolve it, but honestly i don't do much review and didn't know which review type to select