< 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();
< jtimon> right, there the utxos are in view
< bitcoin-git> [bitcoin] jtimon closed pull request #9717: Pow: Remove fCheckPOW from CheckBlockHeader (master...pre-0.14-dont-call-me) https://github.com/bitcoin/bitcoin/pull/9717
< bitcoin-git> [bitcoin] jtimon reopened pull request #9717: Pow: Remove fCheckPOW from CheckBlockHeader (master...pre-0.14-dont-call-me) https://github.com/bitcoin/bitcoin/pull/9717
< jtimon> mhmm, it doesn't seem like https://travis-ci.org/bitcoin/bitcoin/jobs/246709867 and https://travis-ci.org/bitcoin/bitcoin/jobs/246709865 should have failed, but I'm on the laptop and I can't say for sure yet
< jtimon> what's the simplest way to find out whoch commit deleted a given variable, say, pwalletMain
< jtimon> ?
< jcorgan> some unholy combination of git bisect and grep i'd suppose
< jtimon> I guess I can always ask how to do it from xmonad on #haskell
< wumpus> git log -p is usually my friend in those cases
< wumpus> find out what what commit it was last mentioned in, especially works if you can limit the scope to not the entire source code
< wumpus> though bisect and grep seems more elegant
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/bef02fb6ac9f...d609fd85ca41
< bitcoin-git> bitcoin/master b324b28 Jorge Timón: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts()
< bitcoin-git> bitcoin/master d609fd8 Wladimir J. van der Laan: Merge #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts()...
< bitcoin-git> [bitcoin] jtimon opened pull request #10668: Pow: Introduce MaybeGenerateProof (master...b15-blocksign) https://github.com/bitcoin/bitcoin/pull/10668
< bitcoin-git> [bitcoin] jtimon closed pull request #10668: Pow: Introduce MaybeGenerateProof (master...b15-blocksign) https://github.com/bitcoin/bitcoin/pull/10668
< bitcoin-git> [bitcoin] jtimon opened pull request #10669: Pow: Introduce MaybeGenerateProof (master...b14-pow-maybe-prove) https://github.com/bitcoin/bitcoin/pull/10669
< 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
< jamesob> heyyyyy everybodyboydyboydy
< jamesob> (wrong window :)
< 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