< suryab>
Hi, i'm trying to calculate the fee rate of a transaction that is not in the mempool. I saw the way fees are traditionally calculated and can't do the mempool.info() route. Any suggestions?
< suryab>
There also doesn't seem to be any functionality already there for getting the feerate out of a transaction.
< sipa>
you can't get the feerate from a transaction
< sipa>
you need the UTXOs it spends
< jtimon>
suryab: I believe you are correct. Not only at the rpc level but not even at a lower level. https://github.com/bitcoin/bitcoin/pull/8498 would solve this or you can just CAmount nFees = view.GetValueIn(tx)- tx.GetValueOut();
< bitcoin-git>
bitcoin/master d609fd8 Wladimir J. van der Laan: Merge #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts()...
< bitcoin-git>
[bitcoin] laanwj closed pull request #10282: Expire bitcoind & bitcoin-qt 7-8 years after its last change (master...timebomb) https://github.com/bitcoin/bitcoin/pull/10282
< instagibbs>
git log -p -M can help you track across renamings at least
< earlz>
Is there some way to force a node to rebroadcast it's mempool?
< sipa>
no
< sipa>
(peers can ask for a node's mempool using the bip35 'mempool' command, but it's never broadcast unadvertized)
< earlz>
is there any way to easily make that request from a Bitcoin Core node?
< earlz>
ie, an RPC command for it?
< sipa>
getrawmempool
< sipa>
oh, no
< sipa>
you meam make your node request it from another, no
< earlz>
ah lame, so you'd have to write code to get Bitcoin Core to do that
< sipa>
why do you need it?
< earlz>
Testing something and was see some difference between 2 node's mempool count
< sipa>
how would that help?
< sipa>
afaik the only reason you'd use that command on a full node is to get your mempool to converge faster to that of your peers
< sipa>
something that's much less needed now with mempool being saved to disk
< earlz>
If node A mempool is 200, and node B only has 100, and B is only connected to A, will the missing txs be broadcast to B through the mempool, or does rebroadcasting never happen naturally?
< sipa>
no, only new transactions are relayed
< sipa>
and wallets rebroadcast their own transactions occasionally
< earlz>
What about when a wallet does a rebroadcast because it doesn't see it's tx in the network mempool? Would that cause it to spread to the greater network? (ie, if A has tx X, and B does a rebroadcast of X, does that cause A to also rebroadcast X to it's peers)
< sipa>
yes
< sipa>
wait, no
< sipa>
the rebroascast only happens to peers that don't already have the tx
< sipa>
they will of course relay it further
< sipa>
but if a node has a tx already, and sees it inved again, it is ignored
< earlz>
ok thanks, I think this behavior makes sense to me now
< ProfMac>
This may interest this group: I am trying to set up my own flavor of a deterministic build environment. This uses the desktop Trusty (14.04.5) amd64 iso and a preseed file. I am having trouble with preseeding. I have set up a git with the scripts and the syslog, and hope to get help in #ubuntu-installer
< jtimon>
sipa: continuing here instead of the PR, I'm just curious about your thoughts
< jtimon>
I see what you are saying, you mean moving part of primitives/transaction.h to consensus/tx_verify or similar, I don't care much about it either way
< jtimon>
the libconsensus package (which is the encapsulation I care about the most) will have it either way
< jtimon>
although data structures don't need to depend on consensus validation, consensus validation does depend on consensus data structures. Both primitives/transaction.h and primitives/block.h are already in LIBBITCOIN_CONSENSUS unlike consensus/tx_verify
< jtimon>
well, actually I didn't had any question left...
< jtimon>
I guess I'm just curious of what BlueMatt plans to put on LIBBITCOIN_CONSENSUS, I hope not validation.o and all its dependencies
< sipa>
jtimon: my thoughts are that serialization code shouldn't need to depend on consensus logic (which includes resource limits and weight calculation)... for example spv wallet code does not need a dependendy on anything consensus related, but it does need to be able to serialize/deserialize transactions
< sipa>
so i see primitives/* as a basic dependency for everything, while consensus/* is only needed for validation-related things
< jtimon>
ok, but you will still depend on the LIBBITCOIN_CONSENSUS package if you need anything from primitives
< sipa>
no, you shouldn't
< jtimon>
I guess we could do a primitives package on the makefile
< sipa>
right
< jtimon>
well, it's the way it is now
< sipa>
i don't really care about how the package layout is now
< sipa>
more about what inherent dependencies exist within the code
< jtimon>
I personally don't have a problem with anything wallet depending on the consensus package tough, pretty much the contrary, I wish more wallets depended on it
< sipa>
sure, but a hardware wallet glue utility shouldn't need more than just primitives
< sipa>
it seems unnecessary to have serialization code depend on consensus
< jtimon>
right, what I've thought more about iw what I would like LIBBITCOIN_CONSENSUS to have in total in the future, but separating some smaller packages shouldn't conflict with that
< jtimon>
primitiveslib ?
< jtimon>
oh, sorry, you mean internally
< jtimon>
yeah, sure, more encapsulation than what I thought I needed can't hurt
< sipa>
or the primitives/* code can be compiled into multiple packages even, including consensus - i don't really care