1 2018-03-01 05:35:30 0|bitcoin-git|[13bitcoin] 15kostaz opened pull request #12570: Add test cases for HexStr (std::reverse_iterator and corner cases) (06master...06master) 02 https://github.com/bitcoin/bitcoin/pull/12570
2 2018-03-01 07:56:47 0|bitcoin-git|[13bitcoin] 15AkioNak opened pull request #12572: [script] lint-whitespace: improve print linenumber (06master...06morelinenumber) 02 https://github.com/bitcoin/bitcoin/pull/12572
3 2018-03-01 09:23:55 0|bitcoin-git|[13bitcoin] 15532479301 opened pull request #12573: Consensus: Fix bug when compiler do not support __builtin_clz* (06master...06vs2017) 02 https://github.com/bitcoin/bitcoin/pull/12573
4 2018-03-01 09:46:03 0|pierre_rochard|Is there an equivalent to ScriptToAsmStr for an CTxInââ¬â¢s scriptWitness?
5 2018-03-01 09:46:47 0|pierre_rochard|the current implementation of TxToUniv in core_write.cpp just uses HexStr
6 2018-03-01 10:03:25 0|wumpus|pierre_rochard: I don't think so
7 2018-03-01 10:06:21 0|pierre_rochard|Ok, Iââ¬â¢ll settle for HexStr until I really need it, then Iââ¬â¢ll try my hand at a PR :)
8 2018-03-01 10:06:56 0|pierre_rochard|Thank you for the quick response wumpus!
9 2018-03-01 10:07:10 0|wumpus|I'm not sure it's possible to unambigiously distinguish between data encodings there, so it's shown as just hex. But maybe something better could be done, not sure...
10 2018-03-01 11:13:36 0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/9e2ed253f505...32987d5aebc4
11 2018-03-01 11:13:37 0|bitcoin-git|13bitcoin/06master 14e46be25 15Akio Nakamura: Reduce redundant code of prevector and speed it up...
12 2018-03-01 11:13:37 0|bitcoin-git|13bitcoin/06master 14f0e7aa7 15Evan Klitzke: Add new prevector benchmarks....
13 2018-03-01 11:13:38 0|bitcoin-git|13bitcoin/06master 145aad635 15Evan Klitzke: Use memset() to optimize prevector::resize()...
14 2018-03-01 11:14:37 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12549: Make prevector::resize() and other prevector operations much faster (06master...06prevector) 02 https://github.com/bitcoin/bitcoin/pull/12549
15 2018-03-01 11:37:24 0|bitcoin-git|13bitcoin/06master 14e7d9fc5 15Sjors Provoost: [qt] navigate to transaction history page after send...
16 2018-03-01 11:37:24 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/32987d5aebc4...be263faf871f
17 2018-03-01 11:37:25 0|bitcoin-git|13bitcoin/06master 14be263fa 15Wladimir J. van der Laan: Merge #12421: [qt] navigate to transaction history page after send...
18 2018-03-01 11:38:10 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12421: [qt] navigate to transaction history page after send (06master...062018/02/qt-goto-transactions-after-send) 02 https://github.com/bitcoin/bitcoin/pull/12421
19 2018-03-01 13:11:29 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/be263faf871f...39dcac27a1be
20 2018-03-01 13:11:30 0|bitcoin-git|13bitcoin/06master 1490eac8c 15Kosta Zertsekel: Add tests for HexStr corner cases...
21 2018-03-01 13:11:30 0|bitcoin-git|13bitcoin/06master 14ac48861 15Kosta Zertsekel: Add tests for HexStr std::reverse_iterator cases...
22 2018-03-01 13:11:31 0|bitcoin-git|13bitcoin/06master 1439dcac2 15Wladimir J. van der Laan: Merge #12570: Add test cases for HexStr (std::reverse_iterator and corner cases)...
23 2018-03-01 13:12:26 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12570: Add test cases for HexStr (std::reverse_iterator and corner cases) (06master...06master) 02 https://github.com/bitcoin/bitcoin/pull/12570
24 2018-03-01 14:14:21 0|promag|review request #12559
25 2018-03-01 14:14:23 0|gribble|https://github.com/bitcoin/bitcoin/issues/12559 | Avoid locking cs_main in some wallet RPC by promag ÷ Pull Request #12559 ÷ bitcoin/bitcoin ÷ GitHub
26 2018-03-01 14:31:56 0|bitcoin-git|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/39dcac27a1be...5c2aff8d95a9
27 2018-03-01 14:31:57 0|bitcoin-git|13bitcoin/06master 1431c45a9 15Jonas Schnelli: Accept addresses with NODE_NETWORK_LIMITED flag
28 2018-03-01 14:31:57 0|bitcoin-git|13bitcoin/06master 146fe57bd 15Jonas Schnelli: Connect to peers signaling NODE_NETWORK_LIMITED when out-of-IBD
29 2018-03-01 14:31:57 0|provoostenator|Is bitcoind --daemon supposed to keep a macOS machine awake?
30 2018-03-01 14:31:58 0|bitcoin-git|13bitcoin/06master 14fa999af 15Jonas Schnelli: [QA] Allow addrman loopback tests (add debug option -addrmantest)
31 2018-03-01 14:32:09 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10387: Eventually connect to NODE_NETWORK_LIMITED peers (06master...062017/05/node_network_limited) 02 https://github.com/bitcoin/bitcoin/pull/10387
32 2018-03-01 14:46:50 0|Randolf|provoostenator: Normally, when running any sort of a server daemon, sleep mode isn't typically wanted. After all, if the machine is in sleep mode, the daemon can't respond to any inbound queries.
33 2018-03-01 14:48:08 0|provoostenator|Right, that's what I would expect too...
34 2018-03-01 14:48:11 0|Randolf|provoostenator: There are some hardware configurations which can "wake up" the machine when network traffic is received, but since Bitcoin has a constant flow of data even this would in effect be pointless.
35 2018-03-01 14:48:32 0|Randolf|...because the machine would constantly be waking up if ever it could get into sleep mode in the first place.
36 2018-03-01 14:48:57 0|provoostenator|Maybe we can add --caffeinate as a flag (for OSX, maybe Linux has a similar thing)?
37 2018-03-01 14:50:05 0|provoostenator|https://discussions.apple.com/thread/7858428
38 2018-03-01 14:50:45 0|Randolf|provoostenator: I think it's better to leave the power management to the OS. I also think it's reasonable to assume that someone running a server daemon should also have enough knowledge to manage their power settings according to their needs.
39 2018-03-01 14:51:31 0|provoostenator|Yeah, that's what I thought to. But apparently I'm not not knowledgeable enough. :-)
40 2018-03-01 14:52:28 0|Randolf|If Bitcoin were to add options to manage power settings, then that would also be adding complexity to the project which I think would generally be beyond the scope of what Bitcoin is.
41 2018-03-01 14:52:52 0|Randolf|And then whenever a vendor changes their power management API, precious development time gets taken away from more important things.
42 2018-03-01 14:53:43 0|provoostenator|I probably made the mistake of logging out all users from the UI. It probably turned itself off once I closed the last SSH connection into the machine, despite bitcoind and a detached virtual box sessions.
43 2018-03-01 14:54:29 0|provoostenator|I tend to agree bitcoind shouldn't do that for the OS. Though we could add some installation instructions / hints.
44 2018-03-01 14:55:02 0|Randolf|provoostenator: I think that knowing how to change your system's power management configuration is something you'll have to master.
45 2018-03-01 14:55:26 0|Randolf|Again, power management is, in my view, beyond the scope of what Bitcoin does.
46 2018-03-01 14:55:37 0|Randolf|It could be good for a Wiki page.
47 2018-03-01 14:58:25 0|Randolf|provoostenator: Consider this: Windows 10 regulatly reboots to install updates without asking the user first. Should Bitcoin's instructions tell users how to change the settings in Windows 10 to stop this from happening? And then update those instructions every time Microsoft changes the way
48 2018-03-01 14:59:48 0|Randolf|And again, I think it's reasonable to assume that anyone who wants to run bitcoind is knowledgeable enough to manage their own OS accordingly.
49 2018-03-01 14:59:48 0|Randolf|those settings are configured? I think this would also be beyond the scope of what Bitcoin does.
50 2018-03-01 15:13:43 0|promag|wumpus: does this make sense https://github.com/bitcoin/bitcoin/blame/5c2aff8d95a932f82a9472975b1d183da6c99e5f/src/qt/transactionrecord.cpp#L140 ?
51 2018-03-01 15:15:57 0|promag|why is the fee added? fwiw rpc gettransaction separates amount and fee (in details field)
52 2018-03-01 15:16:25 0|promag|I wonder if we could remove that
53 2018-03-01 18:02:30 0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/5c2aff8d95a9...987a80995a69
54 2018-03-01 18:02:31 0|bitcoin-git|13bitcoin/06master 143f592b8 15Jonas Schnelli: [QA] add wallet-rbf test
55 2018-03-01 18:02:31 0|bitcoin-git|13bitcoin/06master 148222e05 15Jonas Schnelli: Disable wallet fallbackfee by default on mainnet
56 2018-03-01 18:02:32 0|bitcoin-git|13bitcoin/06master 14987a809 15Wladimir J. van der Laan: Merge #11882: Disable default fallbackfee on mainnet...
57 2018-03-01 18:03:02 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11882: Disable default fallbackfee on mainnet (06master...062017/12/feeest_readyness) 02 https://github.com/bitcoin/bitcoin/pull/11882
58 2018-03-01 18:03:13 0|zks_|Guys, I'm new to Bitcoin Core source code... and I have a question - why base_blob::GetHex() reverses the base_blob::data[WIDTH] array?
59 2018-03-01 18:03:30 0|zks_|Hope it is an appropriate place to ask questions...
60 2018-03-01 18:06:30 0|wumpus|zks_: that's an old tradition, to represent hashes in reversed order
61 2018-03-01 18:06:59 0|zks_|wumpus: Thanks for the answer! But why?
62 2018-03-01 18:07:05 0|wumpus|zks_: we inherited it from satoshi and it's not realistic to change the entire interface
63 2018-03-01 18:07:14 0|zks_|wumpus: Is it related to network byte order?
64 2018-03-01 18:07:23 0|wumpus|no, definitely not
65 2018-03-01 18:07:35 0|mmgen|zks_: possibly because it shows leading zeroes of the block header as *leading* zeroes
66 2018-03-01 18:07:41 0|zks_|wumpus: Ok. Got it. Historic reasons...
67 2018-03-01 18:07:47 0|mmgen|zks_: block header hash
68 2018-03-01 18:07:48 0|wumpus|hashes are just blobs of data, their 'network byte order' is simply their memory representation
69 2018-03-01 18:07:52 0|wumpus|there is no logic to it
70 2018-03-01 18:09:16 0|mmgen|zks_: that's my reasoning on why Satoshi did it that way
71 2018-03-01 18:09:18 0|zks_|mmgen: wumpus: If I get it right - there is no difference how to store the hashes (regular or reversed order). It just has to be this way or the other...
72 2018-03-01 18:09:49 0|wumpus|I'm not sure GetHex on blob is the best place to do that swap, as it precludes using it in a neutral fashion, should probably ave been an external function GetWackyExternalRepresentation() but meh...
73 2018-03-01 18:09:53 0|mmgen|zks_: this is how they're represented, not how they're stored
74 2018-03-01 18:10:33 0|wumpus|indeed, internally the data is in normal order, just for external representation it's swapped
75 2018-03-01 18:11:02 0|wumpus|makes sense to use the same conventions in your own software, swap it only for communication with bitcoind
76 2018-03-01 18:11:32 0|zks_|so, in the blockchain "database" the hashes are always in the natural order and only printed in reverse?
77 2018-03-01 18:11:39 0|wumpus|yep
78 2018-03-01 18:12:08 0|zks_|ok, ... moving on guys... thx!
79 2018-03-01 18:12:47 0|wumpus|satoshi's orignal vision: print hashes in reversed order :-)
80 2018-03-01 18:13:31 0|Chris_Stewart_5|*vein pulses in forehead*
81 2018-03-01 18:14:17 0|luke-jr|XD
82 2018-03-01 18:31:29 0|bitcoin-git|[13bitcoin] 15promag opened pull request #12578: Add transaction record type Fee (06master...062018-03-fee-transaction-record) 02 https://github.com/bitcoin/bitcoin/pull/12578
83 2018-03-01 18:31:57 0|promag|wumpus: not sure if this makes sense ^ but please comment since you wrote the origin code
84 2018-03-01 18:32:01 0|promag|*original
85 2018-03-01 18:32:30 0|promag|I'll update the PR description and add a before image later
86 2018-03-01 18:32:30 0|wumpus|promag: no, I did not write that code, that came literally from the satoshi wxwindows code
87 2018-03-01 18:32:40 0|promag|oh :P
88 2018-03-01 18:32:42 0|wumpus|I think it's correct, though a bit weird
89 2018-03-01 18:33:02 0|promag|it's weird to see the fee as debit in the first output
90 2018-03-01 18:33:21 0|wumpus|the idea is that the total works out
91 2018-03-01 18:33:25 0|promag|we could "hide" fee records by default with a checkbox
92 2018-03-01 18:33:35 0|promag|right
93 2018-03-01 18:34:06 0|wumpus|so satoshi's reasoning there is that it doesn't matter which of the outputs the fee is added to, but it must be added to one, otherwise the total doesn't match
94 2018-03-01 18:34:39 0|wumpus|probably there's something similar in the RPC wallet
95 2018-03-01 18:43:14 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12518: [0.16] Bump leveldb subtree (060.16...06Mf1802-leveldbSubtreeBump) 02 https://github.com/bitcoin/bitcoin/pull/12518
96 2018-03-01 18:46:40 0|promag|wumpus: maybe in listtransactions, I'll check later
97 2018-03-01 18:47:02 0|promag|btw, pr description updated
98 2018-03-01 19:01:22 0|Randolf|wumpus: Perhaps the "hashes in reverse" routine could be analogous to AMBULANCE written backward on ambulances?
99 2018-03-01 19:02:53 0|jcorgan|meeting?
100 2018-03-01 19:03:03 0|Randolf|jcorgan++
101 2018-03-01 19:03:38 0|sipa|meetung
102 2018-03-01 19:03:45 0|jcorgan|not sure the world could handle two of me
103 2018-03-01 19:03:49 0|achow101|meeting.
104 2018-03-01 19:04:02 0|lightningbot|Meeting started Thu Mar 1 19:04:02 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
105 2018-03-01 19:04:02 0|lightningbot|Useful Commands: #action #agreed #help #info #idea #link #topic.
106 2018-03-01 19:04:02 0|wumpus|#startmeeting
107 2018-03-01 19:04:19 0|wumpus|#bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
108 2018-03-01 19:04:40 0|wumpus|Randolf: yes, like that, hash mirroring (TM)
109 2018-03-01 19:04:53 0|wumpus|#topic high priority for review
110 2018-03-01 19:05:15 0|wumpus|https://github.com/bitcoin/bitcoin/projects/8
111 2018-03-01 19:05:29 0|wumpus|a few of the PRs really need rebase
112 2018-03-01 19:06:41 0|sipa|many people at FC18 right now, btw
113 2018-03-01 19:06:41 0|wumpus|but we managed to merge a few this week, so if you have nothing on that list yet, proposals are welcome
114 2018-03-01 19:06:43 0|Randolf|I have purposely NOT rebased PR #12501 fully yet because it turned into some discussion about the "virtual size" of transactions.
115 2018-03-01 19:06:45 0|gribble|https://github.com/bitcoin/bitcoin/issues/12501 | [qt] Improved "custom fee" explanation in tooltip by randolf ÷ Pull Request #12501 ÷ bitcoin/bitcoin ÷ GitHub
116 2018-03-01 19:07:01 0|Randolf|I hoped that last week it would be an easy one to complete, but turns out this wasn't so straight-forward.
117 2018-03-01 19:07:28 0|wumpus|there are certainly valid reasons to not rebase something
118 2018-03-01 19:07:35 0|Randolf|I think that PR #12567 can probably be closed, but a few more people might want to take a quick look at it first.
119 2018-03-01 19:07:37 0|gribble|https://github.com/bitcoin/bitcoin/issues/12567 | util: Print timestamp strings in logs using ISO 8601 formatting by practicalswift ÷ Pull Request #12567 ÷ bitcoin/bitcoin ÷ GitHub
120 2018-03-01 19:07:56 0|Randolf|I think that PR #12546 should be merged.
121 2018-03-01 19:07:57 0|gribble|https://github.com/bitcoin/bitcoin/issues/12546 | [docs] Minor improvements to Compatibility Notes by randolf ÷ Pull Request #12546 ÷ bitcoin/bitcoin ÷ GitHub
122 2018-03-01 19:07:57 0|wumpus|on the other hand, if something runs out of sync with current master, then reviewing it in the current state makes less sense
123 2018-03-01 19:07:58 0|luke-jr|#11383 is probably ready for merge, just only one recent utACK
124 2018-03-01 19:08:02 0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr ÷ Pull Request #11383 ÷ bitcoin/bitcoin ÷ GitHub
125 2018-03-01 19:08:04 0|Randolf|(Sorry, I meant "merged" earlier rather than "closed.")
126 2018-03-01 19:08:45 0|wumpus|12501 isn't on that list, should it be?
127 2018-03-01 19:08:53 0|Randolf|I suspect that PR 12501 probably needs more peer-review and discussion.
128 2018-03-01 19:09:01 0|wumpus|luke-jr: great!
129 2018-03-01 19:09:25 0|wumpus|luke-jr: looks like jonasschnelli has some, unreplied to comments there
130 2018-03-01 19:10:04 0|wumpus|it's fine to say that you're leaving them for a later PR, but please do reply to ereview comments
131 2018-03-01 19:10:14 0|Randolf|Okay.
132 2018-03-01 19:10:41 0|kanzure|hi.
133 2018-03-01 19:11:15 0|promag|hi
134 2018-03-01 19:11:54 0|kanzure|btw i am still seeking topic suggestions (either stuff you want to talk about, or you want other people to talk about) for next week's event.
135 2018-03-01 19:12:27 0|kanzure|speaking of which, we should decide about next weekly meeting timing since i imagine some folks will be traveling
136 2018-03-01 19:12:31 0|wumpus|#action send kanzure further topic suggestions
137 2018-03-01 19:12:47 0|wumpus|right, I'll definitely not be there next week
138 2018-03-01 19:13:10 0|wumpus|will be travellingback at that time
139 2018-03-01 19:13:15 0|kanzure|wasn't aware we'd lose a bunch of people to fc18 but makes sense.
140 2018-03-01 19:13:27 0|promag|regarding multiwallet, there are other details that can be left for other pulls
141 2018-03-01 19:13:28 0|wumpus|indeed, apparently same problem this week
142 2018-03-01 19:13:33 0|sipa|sorry!
143 2018-03-01 19:13:51 0|luke-jr|sipa: next time, schedule FC so it doesn't conflict.
144 2018-03-01 19:13:57 0|luke-jr|:p
145 2018-03-01 19:13:57 0|sipa|haha!
146 2018-03-01 19:14:02 0|wumpus|so I think we should skip next week's IRC meeting
147 2018-03-01 19:14:11 0|achow101|ack
148 2018-03-01 19:14:13 0|Randolf|Ack.
149 2018-03-01 19:14:24 0|kanzure|we can move it forward if we want.. since a lot of folks in same room. but it's sort of redundant.
150 2018-03-01 19:14:41 0|wumpus|right
151 2018-03-01 19:15:05 0|sipa|sgtm
152 2018-03-01 19:15:18 0|luke-jr|I suggest we have kanzure transcribe RL stuff to #bitcoin-core-dev in real time
153 2018-03-01 19:15:31 0|kanzure|that's okay with me since roasbeef wont be there
154 2018-03-01 19:15:35 0|luke-jr|lol
155 2018-03-01 19:15:39 0|kanzure|(i love him tho)
156 2018-03-01 19:15:44 0|wumpus|hehe
157 2018-03-01 19:15:57 0|btcdrak|oh what did I miss?
158 2018-03-01 19:16:04 0|luke-jr|1/4th of the meeting
159 2018-03-01 19:16:14 0|wumpus|<kanzure> that's okay with me since roasbeef wont be there
160 2018-03-01 19:16:14 0|wumpus|<luke-jr> I suggest we have kanzure transcribe RL stuff to #bitcoin-core-dev in real time
161 2018-03-01 19:16:30 0|wumpus|not much is going on, everyone is at FC apparently
162 2018-03-01 19:16:51 0|luke-jr|end early and spend 45 minutes on #11383 ? :D
163 2018-03-01 19:16:54 0|gribble|https://github.com/bitcoin/bitcoin/issues/11383 | Basic Multiwallet GUI support by luke-jr ÷ Pull Request #11383 ÷ bitcoin/bitcoin ÷ GitHub
164 2018-03-01 19:16:59 0|wumpus|but if anyone has a topic they like to discuss with the three of us, please mention
165 2018-03-01 19:17:04 0|Randolf|btcdrak: I suggested merging PRs 12567 and 12546 and luke-jr suggested merging PR 11383.
166 2018-03-01 19:17:32 0|luke-jr|wumpus, luke-jr, sipa, btcdrak, kanzure, achow101, Randolf, promag = 8
167 2018-03-01 19:17:35 0|sdaftuar|hi
168 2018-03-01 19:17:36 0|wumpus|12546 is obvious / documentation only
169 2018-03-01 19:17:49 0|Randolf|Yes.
170 2018-03-01 19:18:13 0|luke-jr|Randolf: well, it'd be nice to get a few more utACKs first (although I've shipped 11383 in Knots so long that I doubt there's any problems to find left)
171 2018-03-01 19:19:25 0|achow101|I'll take a look at 11383
172 2018-03-01 19:20:28 0|promag|luke-jr: I'll review again
173 2018-03-01 19:21:28 0|Randolf|wumpus: In PR 12501 an issue arose about the "virtual size" of the transaction. I'm thinking that it would probably be best to not mention this so as not to confuse end-users, but there's one person who's in favour of specifying this. If there's a link to documentation that can get into the
174 2018-03-01 19:22:36 0|Randolf|details of the virtual size of the transaction, then I'm also thinking that including the link in the tooltip as a "see all" item should keep everyone happy?
175 2018-03-01 19:22:36 0|Randolf|"See also," not see all. :)
176 2018-03-01 19:23:17 0|luke-jr|Randolf: the value being configured is fundamentally tied to virtual size. I don't think it's avoidable.
177 2018-03-01 19:23:37 0|wumpus|it's most important to be correct / complete
178 2018-03-01 19:23:54 0|luke-jr|"adjusted size" might be more understandable in plain English
179 2018-03-01 19:24:06 0|luke-jr|but there's no precedent for calling it that yet
180 2018-03-01 19:24:24 0|wumpus|in general, even if certain terms might confuse users, it's better to mention something than leave it out and say the wrong thing
181 2018-03-01 19:24:29 0|wumpus|but yeah, virtual size is confusing
182 2018-03-01 19:24:30 0|Randolf|Okay. I want the tooltip to be correct without adding confusion.
183 2018-03-01 19:24:54 0|luke-jr|weight-adjusted size?
184 2018-03-01 19:25:09 0|wumpus|but calling it differently might be even worse
185 2018-03-01 19:25:11 0|wumpus|I don't know
186 2018-03-01 19:25:25 0|wumpus|(as you can't google it then!)
187 2018-03-01 19:26:22 0|luke-jr|it's really a different way of speaking of the weight, not the size
188 2018-03-01 19:26:28 0|luke-jr|I can't think up a nice way to call it
189 2018-03-01 19:26:28 0|Randolf|From a plain-English perspective, "weight-adjusted size" is much nicer, but that point about it being a new term is an important one because then it needs to be in the full documentation too.
190 2018-03-01 19:26:57 0|Randolf|Originally, I didn't have the word "virtual" in there.
191 2018-03-01 19:27:04 0|luke-jr|I suggest we just stick to "virtual size" until some English genius thinks up a better name
192 2018-03-01 19:27:08 0|wumpus|if there are new terms there's a good rationale to only use a single term for it, not make up multiple terms just because they sound nicer
193 2018-03-01 19:27:18 0|Randolf|I agree.
194 2018-03-01 19:27:55 0|wumpus|so if it is virtual size, I think we need to bite the bullet and simply use that
195 2018-03-01 19:28:35 0|wumpus|any other topics?
196 2018-03-01 19:28:37 0|Randolf|Alright. So, if the current wording in most recent commit - https://github.com/bitcoin/bitcoin/pull/12501/commits/a6a800cc4b3c1cbc4e5199563e2de1b5228ff9e2 - looks fine, then I'll go ahead and rebase.
197 2018-03-01 19:29:29 0|luke-jr|lgtn
198 2018-03-01 19:29:31 0|luke-jr|lgtm*
199 2018-03-01 19:29:48 0|wumpus|yes
200 2018-03-01 19:29:54 0|lightningbot|Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-01-19.04.log.html
201 2018-03-01 19:29:54 0|lightningbot|Meeting ended Thu Mar 1 19:29:53 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
202 2018-03-01 19:29:54 0|lightningbot|Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-01-19.04.html
203 2018-03-01 19:29:54 0|lightningbot|Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-03-01-19.04.txt
204 2018-03-01 19:29:54 0|wumpus|#endmeeting
205 2018-03-01 19:29:57 0|Randolf|Thanks.
206 2018-03-01 19:31:00 0|bitcoin-git|13bitcoin/06master 14b22c289 15Randolf Richardson: [docs] Minor improvements to Compatibility Notes...
207 2018-03-01 19:31:00 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/987a80995a69...a4a5fc7c17cd
208 2018-03-01 19:31:01 0|bitcoin-git|13bitcoin/06master 14a4a5fc7 15Wladimir J. van der Laan: Merge #12546: [docs] Minor improvements to Compatibility Notes...
209 2018-03-01 19:31:52 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12546: [docs] Minor improvements to Compatibility Notes (06master...06patch-3) 02 https://github.com/bitcoin/bitcoin/pull/12546
210 2018-03-01 19:33:10 0|bitcoin-git|[13bitcoin] 15achow101 closed pull request #12180: scripted-diff: change kB to kvB, kilobyte to kilovbyte for transaction fee rate things (06master...06use-vbytes) 02 https://github.com/bitcoin/bitcoin/pull/12180
211 2018-03-01 19:43:35 0|jtimon|I guess "weight / 4" is more confusing than "virtual size"
212 2018-03-01 19:48:15 0|wumpus|yes
213 2018-03-01 19:48:48 0|wumpus|and even if you explain how it is computed, you'd still need to mention the term
214 2018-03-01 19:48:51 0|sipa|i wish we just everyone changed 'size' to mean vsize
215 2018-03-01 19:48:55 0|sipa|*everywhere
216 2018-03-01 19:49:08 0|sipa|but it's probably too late for that
217 2018-03-01 19:51:43 0|bitcoin-git|13bitcoin/06master 1419ac86e 15Alin Rus: Remove useless string initialization.
218 2018-03-01 19:51:43 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02 https://github.com/bitcoin/bitcoin/compare/a4a5fc7c17cd...90a0aed51194
219 2018-03-01 19:51:44 0|bitcoin-git|13bitcoin/06master 1490a0aed 15Wladimir J. van der Laan: Merge #12182: Remove useless string initializations...
220 2018-03-01 19:52:28 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #12182: Remove useless string initializations (06master...06remove_useless_string_init) 02 https://github.com/bitcoin/bitcoin/pull/12182
221 2018-03-01 19:54:07 0|wumpus|sipa: that would be the neatest solution, just have 'size' interpreted as 'vsize' everywhere
222 2018-03-01 19:54:35 0|Randolf|wumpus and jtimon: PR #12501 has been rebased, and I wrote a comment to @dooglus explaining where we're at.
223 2018-03-01 19:54:38 0|gribble|https://github.com/bitcoin/bitcoin/issues/12501 | [qt] Improved "custom fee" explanation in tooltip by randolf ÷ Pull Request #12501 ÷ bitcoin/bitcoin ÷ GitHub
224 2018-03-01 19:55:40 0|Randolf|sipa: I wonder if it might be helpful to have a glossary of terms included in a separate file.
225 2018-03-01 19:59:04 0|wumpus|it would be something to put in the UI user documentation, if we had any :)
226 2018-03-01 20:03:14 0|Randolf|I suppose bits and pieces could be put together at first, and then later formed into a proper document.
227 2018-03-01 20:03:55 0|Randolf|I guess there would be two documentation files -- one for bitcoind, and the other for the GUI.
228 2018-03-01 20:04:21 0|Randolf|Or perhaps they should just be separate chapters to avoid overlap.
229 2018-03-01 20:06:49 0|rex_4539|Are you interested in a PR about fixing all the potential typos in the source code? I could go through all the source code, fix all typos, and squash to a single commit. If you are interested, let me know if you want me to fix all typos (comments and readable messages) or just a particular type. I have already fixed them in Zcash and Monero projects.
230 2018-03-01 20:12:23 0|Randolf|rex_4539: How does one fix "potential typos?"
231 2018-03-01 20:12:40 0|Randolf|Fixing existing typos is always welcome.
232 2018-03-01 20:13:47 0|rex_4539|Very tedious work, I can assure you :) Not a developer but willing to help in any capacity I can.
233 2018-03-01 20:13:55 0|Randolf|That's fantastic.
234 2018-03-01 20:13:57 0|Randolf|My suggestion is this...
235 2018-03-01 20:14:22 0|Randolf|Do all the corrections in documentation in one PR, and do all the corrections in source code in another PR.
236 2018-03-01 20:14:35 0|Randolf|That is, if you want to keep the number of PRs down to a minimum.
237 2018-03-01 20:14:48 0|Randolf|You're also welcome to break them apart into smaller PRs if you like.
238 2018-03-01 20:15:29 0|Randolf|One of the advantages of smaller PRs is that it's easier to get them reviewed and merged.
239 2018-03-01 20:20:16 0|rex_4539|The good thing with typos is that they are extremely trivial to review. Shouldn't take more than 5 minutes for the whole Bitcoin project.
240 2018-03-01 20:21:00 0|Randolf|Your contributions are most certainly welcome. :)
241 2018-03-01 20:21:34 0|Randolf|Please feel free to connect with me on GitHub as well: https://www.github.com/randolf
242 2018-03-01 20:22:50 0|rex_4539|Do you want me to fix also comments or just readable messages?
243 2018-03-01 20:24:12 0|Randolf|rex_4539: That's entirely up to you as this is a volunteer effort after all.
244 2018-03-01 20:24:33 0|jcorgan|PRs with changes that are scattered through the code, like typo fixes, can sometimes make other PRs need rebasing (if merged)
245 2018-03-01 20:25:36 0|rex_4539|I'm asking because each team works differently. Zcash team was happy to have all fixed, Monero wanted just readable comments.
246 2018-03-01 20:25:52 0|rex_4539|*messages
247 2018-03-01 20:26:00 0|Randolf|rex_4539: Oh, I see. All fixes are welcome.
248 2018-03-01 20:26:38 0|rex_4539|Don't worry, I will not touch typos in the actual code, just comments and readable messages.
249 2018-03-01 20:27:12 0|Randolf|jcorgan: Does it make a difference if the changes are in a very small number of very large PRs, or if the changes are in a lot of smaller PRs?
250 2018-03-01 20:28:17 0|rex_4539|In my experience in the 2 previous projects, they wanted one big BR because each separate PR was using the CI machines all the time :P
251 2018-03-01 20:28:52 0|jcorgan|i think there's a way to comment your PR so it gets ignored by CI, don't remember
252 2018-03-01 20:29:45 0|jcorgan|appropriate for doc only changes, but not for code comments, as you might accidentally break syntax
253 2018-03-01 20:31:27 0|Randolf|Oh, I'd like to know how to comment my PR to prevent the CI checks. That would reduce system resource load then.
254 2018-03-01 20:31:47 0|jcorgan|but i wouldn't worry so much about it now, i'd focus on getting the work done and submit a single PR for it, then if it needs breaking into multiple ones it will come out in the review
255 2018-03-01 20:32:05 0|rex_4539|I think there is a rollup command for the bot.
256 2018-03-01 20:32:11 0|Chris_Stewart_5|isn't travis 'free' for open source projects?
257 2018-03-01 20:32:24 0|Randolf|I still think it would be good to separate documentation updates from code/comment updates into two PRs though, at least.
258 2018-03-01 20:32:29 0|jcorgan|free, but capacity limited and might only run one job at a time
259 2018-03-01 20:32:50 0|jcorgan|agree on code/comment and doc separation
260 2018-03-01 20:33:10 0|Randolf|Chris_Stewart_5: For doc-only PRs that I've been submitting, if I knew I could do something to prevent unnecessary resource usage, I would have been happy to do it.
261 2018-03-01 20:33:22 0|rex_4539|Sure, 2 separate PRs it is then. Will get to it in a couple of days.
262 2018-03-01 20:33:28 0|Randolf|rex_4539: Wow, thank you!
263 2018-03-01 20:35:24 0|jcorgan|another general purpose consideration for pull requests is that independent things don't get combined into one request, as the maintainer can't selectively merge one or the other
264 2018-03-01 20:36:17 0|jcorgan|anyway, just some thoughts from experience as a maintainer elsewhere, carry on :-)
265 2018-03-01 20:36:26 0|rex_4539|Yes, but maintainer can comment on the ones he disagrees and I can revert those commits.
266 2018-03-01 20:37:03 0|jcorgan|in general, the less work the maintainer and reviewers need to do, the more likely it is to get merged
267 2018-03-01 20:37:27 0|Randolf|That's why I suggested smaller PRs.
268 2018-03-01 20:41:40 0|eklitzke|I found a bug in GCC 8.0 (not yet stable) as a result of that prevector optimization, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84656
269 2018-03-01 20:43:49 0|wumpus|I agree with jcorgan
270 2018-03-01 20:43:57 0|wumpus|eklitzke: congrats on finding a gcc bug
271 2018-03-01 20:46:10 0|Randolf|Chris_Stewart_5: Apparently the [ci-skip]"
272 2018-03-01 20:46:47 0|Randolf|Chris_Stewart_5: Apparently, including the text "[ci-skip]" (without the quotation marks) in a PR's message will prevent Travis-CI from attempting a build.
273 2018-03-01 20:47:36 0|Randolf|rex_4539: You may want to include this text in your doc-only PRs to prevent the build process: [ci-skip]
274 2018-03-01 20:47:49 0|Randolf|rex_4539: When changing comments, you should still let the build occur.
275 2018-03-01 20:50:30 0|wumpus|I found a clang bug once: https://github.com/bitcoin-core/secp256k1/issues/445
276 2018-03-01 20:51:34 0|eklitzke|your bug is a lot more interesting than mine
277 2018-03-01 20:56:11 0|rex_4539|Randolf, is it [ci-skip] [ci skip] or [skip ci]? Found all cases in GitHub :P
278 2018-03-01 20:56:24 0|rex_4539|https://github.com/bitcoin/bitcoin/commit/e3a820751f11b3b30ac19d8118df3e755132e470
279 2018-03-01 20:56:31 0|rex_4539|https://github.com/bitcoin/bitcoin/pull/7658
280 2018-03-01 20:56:51 0|Randolf|Someone in the #travis channel just indicated to me that it's this: [ci-skip]
281 2018-03-01 20:57:05 0|Randolf|If they all work (which would be good), then it doesn't matter.
282 2018-03-01 20:59:09 0|Randolf|I suggest using the in-comment style that in PR #7658 instead of including it in the PR's title -- keeping those titles simple is generally encouraged, and they're also limited in size anyway as far as I know.
283 2018-03-01 20:59:11 0|gribble|https://github.com/bitcoin/bitcoin/issues/7658 | Add curl to Gitian setup instructions by btcdrak ÷ Pull Request #7658 ÷ bitcoin/bitcoin ÷ GitHub
284 2018-03-01 22:06:32 0|bitcoin-git|[13bitcoin] 15dooglus opened pull request #12580: Show a transaction's virtual size in its details dialog (06master...06show_vsize) 02 https://github.com/bitcoin/bitcoin/pull/12580
285 2018-03-01 23:00:34 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10040: wallet: use headers chain for anti fee sniping (06master...06patch) 02 https://github.com/bitcoin/bitcoin/pull/10040