1 2017-06-25 00:04:02	0|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?
 2 2017-06-25 00:05:28	0|suryab|There also doesn't seem to be any functionality already there for getting the feerate out of a transaction.
 3 2017-06-25 00:11:11	0|sipa|you can't get the feerate from a transaction
 4 2017-06-25 00:11:17	0|sipa|you need the UTXOs it spends
 5 2017-06-25 00:11:18	0|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();
 6 2017-06-25 00:11:34	0|jtimon|right, there the utxos are in view
 7 2017-06-25 05:06:56	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #9717: Pow: Remove fCheckPOW from CheckBlockHeader (06master...06pre-0.14-dont-call-me) 02https://github.com/bitcoin/bitcoin/pull/9717
 8 2017-06-25 05:16:11	0|bitcoin-git|[13bitcoin] 15jtimon reopened pull request #9717: Pow: Remove fCheckPOW from CheckBlockHeader (06master...06pre-0.14-dont-call-me) 02https://github.com/bitcoin/bitcoin/pull/9717
 9 2017-06-25 06:09:51	0|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
10 2017-06-25 08:10:01	0|jtimon|what's the simplest way to find out whoch commit deleted a given variable, say, pwalletMain
11 2017-06-25 08:10:03	0|jtimon|?
12 2017-06-25 08:11:45	0|jcorgan|some unholy combination of git bisect and grep i'd suppose
13 2017-06-25 08:13:29	0|jtimon|I guess I can always ask how to do it from xmonad on #haskell
14 2017-06-25 08:13:42	0|wumpus|git log -p is usually my friend in those cases
15 2017-06-25 08:14:15	0|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
16 2017-06-25 08:15:25	0|wumpus|though bisect and grep seems more elegant
17 2017-06-25 08:26:34	0|bitcoin-git|13bitcoin/06master 14b324b28 15Jorge Timón: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts()
18 2017-06-25 08:26:34	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bef02fb6ac9f...d609fd85ca41
19 2017-06-25 08:26:35	0|bitcoin-git|13bitcoin/06master 14d609fd8 15Wladimir J. van der Laan: Merge #9176: Globals: Pass Consensus::Params through CBlockTreeDB::LoadBlockIndexGuts()...
20 2017-06-25 08:48:55	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10668: Pow: Introduce MaybeGenerateProof (06master...06b15-blocksign) 02https://github.com/bitcoin/bitcoin/pull/10668
21 2017-06-25 08:50:20	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #10668: Pow: Introduce MaybeGenerateProof (06master...06b15-blocksign) 02https://github.com/bitcoin/bitcoin/pull/10668
22 2017-06-25 08:56:14	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #10669: Pow: Introduce MaybeGenerateProof (06master...06b14-pow-maybe-prove) 02https://github.com/bitcoin/bitcoin/pull/10669
23 2017-06-25 09:01:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10282: Expire bitcoind & bitcoin-qt 7-8 years after its last change (06master...06timebomb) 02https://github.com/bitcoin/bitcoin/pull/10282
24 2017-06-25 11:43:33	0|instagibbs|git log -p -M can help you track across renamings at least
25 2017-06-25 15:59:07	0|earlz|Is there some way to force a node to rebroadcast it's mempool?
26 2017-06-25 16:09:05	0|sipa|no
27 2017-06-25 16:09:53	0|sipa|(peers can ask for a node's mempool using the bip35 'mempool' command, but it's never broadcast unadvertized)
28 2017-06-25 16:23:05	0|earlz|is there any way to easily make that request from a Bitcoin Core node?
29 2017-06-25 16:23:11	0|earlz|ie, an RPC command for it?
30 2017-06-25 16:24:12	0|sipa|getrawmempool
31 2017-06-25 16:24:22	0|sipa|oh, no
32 2017-06-25 16:24:33	0|sipa|you meam make your node request it from another, no
33 2017-06-25 16:25:10	0|earlz|ah lame, so you'd have to write code to get Bitcoin Core to do that
34 2017-06-25 16:27:45	0|sipa|why do you need it?
35 2017-06-25 16:34:52	0|earlz|Testing something and was see some difference between 2 node's mempool count
36 2017-06-25 16:37:55	0|sipa|how would that help?
37 2017-06-25 16:39:07	0|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
38 2017-06-25 16:39:29	0|sipa|something that's much less needed now with mempool being saved to disk
39 2017-06-25 16:42:24	0|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?
40 2017-06-25 16:49:42	0|sipa|no, only new transactions are relayed
41 2017-06-25 16:50:07	0|sipa|and wallets rebroadcast their own transactions occasionally
42 2017-06-25 16:51:16	0|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)
43 2017-06-25 16:55:56	0|sipa|yes
44 2017-06-25 16:56:03	0|sipa|wait, no
45 2017-06-25 16:56:17	0|sipa|the rebroascast only happens to peers that don't already have the tx
46 2017-06-25 16:56:37	0|sipa|they will of course relay it further
47 2017-06-25 16:57:15	0|sipa|but if a node has a tx already, and sees it inved again, it is ignored
48 2017-06-25 17:17:22	0|earlz|ok thanks, I think this behavior makes sense to me now
49 2017-06-25 17:46:16	0|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
50 2017-06-25 17:47:17	0|ProfMac|An entry to my git is at https://github.com/a-mcintosh/Trusty-preseed/blob/master/syslog
51 2017-06-25 18:19:17	0|jamesob|heyyyyy everybodyboydyboydy
52 2017-06-25 18:24:26	0|jamesob|(wrong window :)
53 2017-06-25 21:11:16	0|jtimon|sipa: continuing here instead of the PR, I'm just curious about your thoughts
54 2017-06-25 21:11:59	0|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
55 2017-06-25 21:12:28	0|jtimon|the libconsensus package (which is the encapsulation I care about the most) will have it either way
56 2017-06-25 21:16:35	0|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
57 2017-06-25 21:18:14	0|jtimon|well, actually I didn't had any question left...
58 2017-06-25 21:19:18	0|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
59 2017-06-25 21:20:37	0|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
60 2017-06-25 21:21:06	0|sipa|so i see primitives/* as a basic dependency for everything, while consensus/* is only needed for validation-related things
61 2017-06-25 21:21:36	0|jtimon|ok, but you will still depend on the LIBBITCOIN_CONSENSUS package if you need anything from primitives
62 2017-06-25 21:21:52	0|sipa|no, you shouldn't
63 2017-06-25 21:22:01	0|jtimon|I guess we could do a primitives package on the makefile
64 2017-06-25 21:22:09	0|sipa|right
65 2017-06-25 21:22:12	0|jtimon|well, it's the way it is now
66 2017-06-25 21:22:24	0|sipa|i don't really care about how the package layout is now
67 2017-06-25 21:22:34	0|sipa|more about what inherent dependencies exist within the code
68 2017-06-25 21:23:59	0|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
69 2017-06-25 21:25:08	0|sipa|sure, but a hardware wallet glue utility shouldn't need more than just primitives
70 2017-06-25 21:25:23	0|sipa|it seems unnecessary to have serialization code depend on consensus
71 2017-06-25 21:26:31	0|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
72 2017-06-25 21:26:51	0|jtimon|primitiveslib ?
73 2017-06-25 21:27:09	0|jtimon|oh, sorry, you mean internally
74 2017-06-25 21:28:07	0|jtimon|yeah, sure, more encapsulation than what I thought I needed can't hurt
75 2017-06-25 21:30:46	0|sipa|or the primitives/* code can be compiled into multiple packages even, including consensus - i don't really care