1 2020-11-26T00:00:25  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
  2 2020-11-26T00:08:35  *** openoms <openoms!~quassel@91.132.136.76> has quit IRC (Ping timeout: 256 seconds)
  3 2020-11-26T00:12:19  *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 260 seconds)
  4 2020-11-26T00:18:10  *** openoms <openoms!~quassel@91.132.136.76> has joined #bitcoin-core-dev
  5 2020-11-26T00:32:48  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Read error: Connection reset by peer)
  6 2020-11-26T00:35:25  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:bc9a:f509:3193:e14d> has joined #bitcoin-core-dev
  7 2020-11-26T00:46:03  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
  8 2020-11-26T00:46:36  *** proofofkeags <proofofkeags!~proofofke@c-73-34-43-4.hsd1.co.comcast.net> has quit IRC (Ping timeout: 240 seconds)
  9 2020-11-26T00:53:32  <luke-jr> is it intentional that the test framework's addmultisigaddress substitute for descriptor wallets doesn't accept addresses?
 10 2020-11-26T00:53:40  <achow101> luke-jr: yes
 11 2020-11-26T00:53:46  <luke-jr> k, makes sense
 12 2020-11-26T00:54:34  *** nkuttler <nkuttler!~nkuttler@unaffiliated/nkuttler> has quit IRC (Remote host closed the connection)
 13 2020-11-26T00:55:27  *** nkuttler <nkuttler!~nkuttler@unaffiliated/nkuttler> has joined #bitcoin-core-dev
 14 2020-11-26T00:58:01  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:bc9a:f509:3193:e14d> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
 15 2020-11-26T01:09:30  <luke-jr> achow101: I can't get it to work at all :/
 16 2020-11-26T01:09:32  <luke-jr> test_framework.authproxy.JSONRPCException: Cannot import descriptor without private keys to a wallet with private keys enabled (-4)
 17 2020-11-26T01:12:05  *** andrewtoth <andrewtoth!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
 18 2020-11-26T01:18:43  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
 19 2020-11-26T01:20:54  *** larryruane_ <larryruane_!uid473749@gateway/web/irccloud.com/x-vuztyjlkacjmkbdi> has quit IRC (Quit: Connection closed for inactivity)
 20 2020-11-26T01:22:24  <achow101> luke-jr: the error message is self explanatory. you need a wallet with private keys disabled
 21 2020-11-26T01:24:56  <luke-jr> achow101: but it's not supposed to be watch-only
 22 2020-11-26T01:25:24  <achow101> then it has to have at least one private key
 23 2020-11-26T01:25:37  <luke-jr> it does, addmultisigaddress still requires the pubkey passed though…
 24 2020-11-26T01:25:52  <achow101> how to setup multisigs in descriptor wallets is still an unsolved problem
 25 2020-11-26T01:25:58  <luke-jr> :/
 26 2020-11-26T01:26:20  <achow101> what exactly are you trying to do?
 27 2020-11-26T01:28:43  <luke-jr> achow101: https://dpaste.com/5K7JHWDS4
 28 2020-11-26T01:30:01  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
 29 2020-11-26T01:30:03  <achow101> but why tho
 30 2020-11-26T01:30:26  <luke-jr> so it gets tested
 31 2020-11-26T01:31:00  <achow101> import a sortedmulti descriptor instead of adding more stuff to addmultsigaddress?
 32 2020-11-26T01:31:10  <luke-jr> this is from 2016
 33 2020-11-26T01:31:20  <luke-jr> and works with normal wallets
 34 2020-11-26T01:32:19  <achow101> since addmultisigaddress doesn't exist for descriptorwallets, I don't think it makes sense to try to test it for them
 35 2020-11-26T01:32:30  <luke-jr> fair enough
 36 2020-11-26T01:32:50  <achow101> the helper only exists for when we use addmultisigaddress to make a multisig to test other stuff
 37 2020-11-26T01:33:59  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Quit: WeeChat 2.9)
 38 2020-11-26T01:34:17  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
 39 2020-11-26T01:35:18  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
 40 2020-11-26T01:38:23  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
 41 2020-11-26T01:39:40  <CubicEarth> on the P2P side fo things, is there a reason for the client to not look for and prioritize downloading block data from sources on the LAN?
 42 2020-11-26T01:40:27  <sipa> CubicEarth: if you -addnode them, it'll likely fetch most blocks from there
 43 2020-11-26T01:40:42  <sipa> there is no functionality for automatically detecting other bitcoin node in the local network
 44 2020-11-26T01:45:03  <CubicEarth> I use addnode or connect :)  It seemed like such functionality could be of benefit helping to make dissemination of the block data more user friendly. Totally understood that it would be a low priority in any case.
 45 2020-11-26T01:45:20  <CubicEarth> But is there a reason why such functionality would be bad?
 46 2020-11-26T01:47:41  <sipa> define more user friendly?
 47 2020-11-26T01:48:14  <sipa> i can see the use of detecting other nodes on a local network, but nobody has implemented that
 48 2020-11-26T01:48:20  <sipa> bneyond that, i don't know what you're asking for
 49 2020-11-26T01:48:27  <sipa> is it behaving badly currently?
 50 2020-11-26T01:50:53  <CubicEarth> One assumption I am making: the IBD can be costly in terms of ISP data caps
 51 2020-11-26T01:51:01  <sipa> ah
 52 2020-11-26T01:51:25  <sipa> i'd suggest to have one gateway node in your network, and have the other nodes not make outgoing connections, if you're concerned about that
 53 2020-11-26T01:54:04  <CubicEarth> Yeah, it is easy enough for me avoid pulling the data twice through my WAN
 54 2020-11-26T01:54:27  <CubicEarth> I was just thinking of making it happen with less user intervention
 55 2020-11-26T01:55:27  <sipa> doing it without user configuration is hard through
 56 2020-11-26T01:56:02  <sipa> you could have a rule say that causes a delay before fetching from external IPs to give a chance for a local node to announce it first to you
 57 2020-11-26T01:56:37  <sipa> but now you need to make sure there is one node in your network that doesn't have this delay, or you're just going to lag behind on all nodes
 58 2020-11-26T01:59:36  <CubicEarth> Isn't is trivial to know if a device is on the same ... subnet?
 59 2020-11-26T02:00:21  <CubicEarth> not sure if subnet is the right term... argh
 60 2020-11-26T02:00:43  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
 61 2020-11-26T02:02:17  <sipa> CubicEarth: that's not the problem!
 62 2020-11-26T02:02:34  <sipa> the problem is making sure that not everyone on the same network is slowing down blocks from the outside
 63 2020-11-26T02:02:42  <sipa> they're still supposed to come in quickly to one node from outside
 64 2020-11-26T02:02:56  <sipa> so you need some kind of "leader election"...
 65 2020-11-26T02:03:50  <CubicEarth> Are you talking about just keeping up with new blocks as they are issued? I am thinking about when one node is far behind in block height
 66 2020-11-26T02:03:54  *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
 67 2020-11-26T02:04:13  <sipa> ah, yes
 68 2020-11-26T02:04:18  <sipa> for IBD it should Just Work(tm)
 69 2020-11-26T02:04:24  <sipa> as it autoselects for faster peers
 70 2020-11-26T02:05:23  <sipa> though probably not aggressively enough to get ~all blocks from just local nodes
 71 2020-11-26T02:06:06  <CubicEarth> Interesting. I haven't noticed this to be the case, but I can test it going forward and see how it behaves
 72 2020-11-26T02:06:32  <CubicEarth> And I know i
 73 2020-11-26T02:07:10  <CubicEarth> I've asked this before, but I forget the answer... how far ahead of the validation will it download blocks?
 74 2020-11-26T02:07:48  <sipa> 1024 blocks
 75 2020-11-26T02:08:11  <CubicEarth> the "sliding window"? thanks
 76 2020-11-26T02:08:17  <sipa> yes
 77 2020-11-26T02:12:15  <CubicEarth> "The main purpose of this is so that blocks that are near one another on the blockchain are most likely contained in the same .dat file (where the raw block data is stored on disk)."
 78 2020-11-26T02:12:22  <CubicEarth> Still the case?
 79 2020-11-26T02:12:30  <sipa> yes
 80 2020-11-26T02:12:46  <sipa> otherwise you can't effectively prune
 81 2020-11-26T02:13:54  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
 82 2020-11-26T02:14:30  <CubicEarth> I've never looked at, or asked about how the .dat files were structured, but I had assumed the blocks were more or less kept in order. But actually each .dat file is just filled with whatever the next blocks to come in are?
 83 2020-11-26T02:15:47  <sipa> yep, they're just appended in the order they arrive
 84 2020-11-26T02:16:05  <sipa> you wouldn't know where to put things if you want to keep them in order
 85 2020-11-26T02:16:21  <sipa> as you don't know the size of the blocks you still miss
 86 2020-11-26T02:16:23  <CubicEarth> couldn't you use the headers?
 87 2020-11-26T02:16:35  <sipa> headers don't contain the block's sizes
 88 2020-11-26T02:17:49  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
 89 2020-11-26T02:24:19  <CubicEarth> Got it. And the reason to tie the sliding window to the validation is make sure that the sliding window never gets more than 1024 blocks ahead of blocks known to be good?
 90 2020-11-26T02:24:20  <CubicEarth> Because otherwise it would seem the sliding window could just be in relation to highest unbroken block in sequence, and could therefore advance far faster than validation.
 91 2020-11-26T02:24:47  <CubicEarth> *highest block in unbroken sequence
 92 2020-11-26T02:26:05  <CubicEarth> (meaning an attack could feed bad blocks, and then the blk.dat files would be more out of order)
 93 2020-11-26T02:29:03  <CubicEarth> sipa: You are always the person to answer my questions about the P2P stuff... and gmaxwell sometimes. Are you like the only person who knows all of the 'why' the p2p stuff is the way it is, or are you just the person willing to entertain my questions?
 94 2020-11-26T02:34:05  *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
 95 2020-11-26T02:34:54  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
 96 2020-11-26T02:36:15  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
 97 2020-11-26T02:36:23  <sipa> CubicEarth: i mean... a block arrives, you don't have its parent(s) yet... where do you store it?
 98 2020-11-26T02:36:34  *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has quit IRC (Remote host closed the connection)
 99 2020-11-26T02:36:40  <sipa> CubicEarth: i've been around for a while :)
100 2020-11-26T02:37:56  <sipa> and in this... i wrote a significant part of the block fetching logic
101 2020-11-26T02:38:02  <sipa> +case
102 2020-11-26T02:38:21  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
103 2020-11-26T02:38:44  <CubicEarth> so this about avoid disk thrashing?
104 2020-11-26T02:39:20  <CubicEarth> is ... avoiding
105 2020-11-26T02:39:30  <sipa> compared to which alternative? you haven't given any
106 2020-11-26T02:40:50  <sipa> a possibility is just storing every block in a separate file
107 2020-11-26T02:41:04  <sipa> that's great as it means you can delete whatever block at any time
108 2020-11-26T02:41:19  <sipa> unfortunately most filesystems perform terribly with huge numbers of files
109 2020-11-26T02:41:39  <sipa> another possibility is constantly rewriting block files
110 2020-11-26T02:41:51  <sipa> to keep the blocks in order
111 2020-11-26T02:50:31  <CubicEarth> I guess the question becomes how bad is it if that some blocks are way out of order. On the surface, it seems desirable for the block download to be independent of the cpu intensive validation.
112 2020-11-26T02:52:07  <sipa> it is
113 2020-11-26T02:52:09  <CubicEarth> Coupled with the LAN prioritization I was musing about, imagine that for some short period of time, you have a high bandwidth connection. It would be advantageous to be able to download all of the blocks right then
114 2020-11-26T02:52:21  <sipa> it doesn't matter where blocks are stored for validation
115 2020-11-26T02:52:21  <CubicEarth> and then let the cpu chew through it later
116 2020-11-26T02:53:03  <CubicEarth> well that is good
117 2020-11-26T02:53:09  <sipa> yeah, that sounds vaguely useful
118 2020-11-26T02:56:27  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Remote host closed the connection)
119 2020-11-26T02:58:35  *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
120 2020-11-26T02:58:43  <CubicEarth> You are saying those processes are independent, but at the moment, they are tied together with the 1024 block window?
121 2020-11-26T02:59:10  <sipa> ah yes
122 2020-11-26T02:59:18  <sipa> but it doesn't matter where things are stored for validation
123 2020-11-26T02:59:28  <sipa> it's just restricted to make sure pruning is possible
124 2020-11-26T03:04:17  <CubicEarth> interesting. Yeah, with pruning, especially if pruning is on because there just ins't *that much* disk space available, it all makes perfect sense. There is basically no advantage to what I am thinking.
125 2020-11-26T03:04:39  <sipa> that's the only reason
126 2020-11-26T03:05:04  <sipa> otherwise you could end up with 1000 block files, and each contains blocks from all over the chain
127 2020-11-26T03:05:10  <sipa> so you can't delete any of them
128 2020-11-26T03:05:22  <sipa> because they all also contain very recent blocks
129 2020-11-26T03:08:18  <CubicEarth> I hear that, but I aren't we mixing two concepts here? because couldn't you still have the sliding window, but just have it be decoupled from validation?
130 2020-11-26T03:09:13  <CubicEarth> or does the expose an attack vector?
131 2020-11-26T03:09:18  <CubicEarth> that
132 2020-11-26T03:09:31  <sipa> it's not tied to validation, except implicitly
133 2020-11-26T03:09:37  <sipa> it's tied to the moving window
134 2020-11-26T03:10:01  <sipa> which moves along the chain as far as it can while it has all blocks
135 2020-11-26T03:10:08  <sipa> that happens to be identical to what validation needs
136 2020-11-26T03:12:03  <CubicEarth> too bad validation can't get ahead of the block download ;)
137 2020-11-26T03:12:29  <sipa> you see what i'm saying?
138 2020-11-26T03:12:43  <sipa> we validate blocks as soon as we have all its parents (and those parents are validated)
139 2020-11-26T03:13:12  <CubicEarth> I get that, and that fits my long held understanding
140 2020-11-26T03:13:14  <sipa> and that's also when the download window moves (because limiting out-of-orderness has the exact same requirement)
141 2020-11-26T03:15:45  <CubicEarth> that's why I was asking about the attack consideration, because otherwise you wouldn't need to validate the blocks to limit out-of-orderness, right? You would just need to make sure you didn't download to crazily
142 2020-11-26T03:16:34  <sipa> oh i see
143 2020-11-26T03:16:45  <sipa> you're talking about making validating independent of block download entirely
144 2020-11-26T03:16:50  <sipa> that's a whole other can of worms
145 2020-11-26T03:17:00  <CubicEarth> yeah
146 2020-11-26T03:17:15  <sipa> right now we always make sure that the best chain we know about is the actively validated one
147 2020-11-26T03:17:43  <sipa> if you drop that, the window could move ahead of validation
148 2020-11-26T03:21:12  <CubicEarth> It seems like a feature that could add convenience, along with some inherent vulnerabilities. But it seems the consequences of those vulnerabilities being exploited would more or less be reduced to the loss of the convenience, along with perhaps some additional nuisance
149 2020-11-26T03:22:22  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
150 2020-11-26T03:26:07  <CubicEarth> Meaning, if there was an option to allow the node to let the window move ahead, independent of the state of validation, the benefit would be the possibility that validation could continue on in absence of good network connectivity
151 2020-11-26T03:27:02  <CubicEarth> And the risk would be that the wasn't the right chain in the end
152 2020-11-26T03:28:26  <CubicEarth> And so downloading would need to happen again
153 2020-11-26T03:29:50  <sipa> seems reasonable
154 2020-11-26T03:54:50  *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
155 2020-11-26T03:55:45  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
156 2020-11-26T03:58:29  *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 260 seconds)
157 2020-11-26T04:12:55  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
158 2020-11-26T04:13:41  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
159 2020-11-26T04:15:36  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
160 2020-11-26T04:26:12  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Quit: The Lounge - https://thelounge.github.io)
161 2020-11-26T04:27:31  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
162 2020-11-26T04:36:25  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
163 2020-11-26T05:00:35  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Remote host closed the connection)
164 2020-11-26T05:02:13  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
165 2020-11-26T05:02:30  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
166 2020-11-26T05:14:22  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
167 2020-11-26T05:23:20  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
168 2020-11-26T06:44:52  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
169 2020-11-26T07:10:13  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
170 2020-11-26T07:10:35  *** romanz <romanz!~romanz@bzq-84-109-216-152.cablep.bezeqint.net> has joined #bitcoin-core-dev
171 2020-11-26T07:12:38  *** jesseposner <jesseposner!~jesseposn@2601:643:8980:bfd2:f8c7:7086:b02c:8117> has quit IRC (Quit: My Mac Mini has gone to sleep. ZZZzzz…)
172 2020-11-26T07:19:17  *** Kiminuo <Kiminuo!~mix@217.138.199.36> has joined #bitcoin-core-dev
173 2020-11-26T07:24:16  *** romanz_ <romanz_!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
174 2020-11-26T07:24:25  *** romanz <romanz!~romanz@bzq-84-109-216-152.cablep.bezeqint.net> has quit IRC (Quit: WeeChat 2.8)
175 2020-11-26T07:24:32  *** romanz_ <romanz_!~romanz@93.123.196.104.bc.googleusercontent.com> has quit IRC (Client Quit)
176 2020-11-26T07:24:50  *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
177 2020-11-26T07:25:15  *** kabaum <kabaum!~kabaum@h-13-35.A163.priv.bahnhof.se> has joined #bitcoin-core-dev
178 2020-11-26T07:35:07  *** miketwenty1 <miketwenty1!~miketwent@ip24-136-61-186.ga.at.cox.net> has joined #bitcoin-core-dev
179 2020-11-26T07:39:49  *** miketwenty1 <miketwenty1!~miketwent@ip24-136-61-186.ga.at.cox.net> has quit IRC (Ping timeout: 264 seconds)
180 2020-11-26T07:53:39  *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has quit IRC (Remote host closed the connection)
181 2020-11-26T08:20:42  <wumpus> sipa: to link dynamically against qt you need libQt5Core.so, only libQt5Core.so.5 won't do, it should be created as a symlink though... sounds more like a weird linker path issue
182 2020-11-26T08:22:13  <wumpus> it's in qtbase5-dev
183 2020-11-26T08:22:17  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
184 2020-11-26T08:22:17  <bitcoin-git> [bitcoin] fanquake opened pull request #20504: build: use more legible (q)make commands in qt package (master...legible_qt_config_cmds) https://github.com/bitcoin/bitcoin/pull/20504
185 2020-11-26T08:22:18  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
186 2020-11-26T08:24:54  <wumpus> ubuntu does not install statically linkable qt libraries, only dynamic linker ones, but that's fine if you're only building locally and not for distribution
187 2020-11-26T08:36:27  *** andyrtr1 <andyrtr1!~andyrtr@178.239.168.171> has quit IRC (Remote host closed the connection)
188 2020-11-26T08:44:54  *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
189 2020-11-26T08:45:13  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
190 2020-11-26T08:45:13  <bitcoin-git> [bitcoin] dergoegge opened pull request #20505: [backport] build: Avoid secp256k1.h include from system (0.21...21_backport) https://github.com/bitcoin/bitcoin/pull/20505
191 2020-11-26T08:45:25  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
192 2020-11-26T08:53:56  <sipa> wumpus: bizarre, i installed and reinstalled all the packages
193 2020-11-26T08:54:15  <sipa> i'll retry and symlink it myself
194 2020-11-26T08:54:30  <sipa> thanks
195 2020-11-26T08:54:32  <wumpus> so you have /usr/lib/x86_64-linux-gnu/libQt5Core.so but it can't find it during linking?
196 2020-11-26T08:54:41  <sipa> only .so.5
197 2020-11-26T08:55:05  <hebasto> sipa: waiting for my groovy installation complete to check your link issue
198 2020-11-26T08:55:28  <wumpus> does "dpkg -S dpkg -L qtbase5-dev|grep libQt5Core.so" show it should be in there?
199 2020-11-26T08:55:45  <wumpus> eh just "dpkg -L qtbase5-dev|grep libQt5Core.so"
200 2020-11-26T08:56:05  <wumpus> you really shouldn't have to make the symlink yourself
201 2020-11-26T08:58:30  <wumpus> maybe the file is somewhere else on ubuntu 20.10 I haven't used that yet
202 2020-11-26T08:58:54  *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has joined #bitcoin-core-dev
203 2020-11-26T08:59:13  <sipa> wumpus: ok false alarm, i reinstalled it and now the .so file is there
204 2020-11-26T08:59:21  <sipa> i must have reinstalled another package before
205 2020-11-26T09:00:05  *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-nbitttfhstlbskqd> has quit IRC (Quit: Idle for 30+ days)
206 2020-11-26T09:00:05  <wumpus> phew, still wonder how it came to be erased but good to know!
207 2020-11-26T09:01:16  <sipa> yeah, no idea how this happened
208 2020-11-26T09:01:29  <sipa> i haven't done many weird things in this install
209 2020-11-26T09:01:49  <wumpus> could be a bug I mean that version of ubuntu is still very new
210 2020-11-26T09:02:12  <sipa> wumpus: i remember yeard ago that a -l argument always needed a .a, was a wrong, or is that since outdated?
211 2020-11-26T09:04:07  <wumpus> that's true on windows, it has these import libraries (.lib IIRC) to tell what is in a dll, but not (and never was) on linux, the linker links directly to the .so, linking to an .a is static linking
212 2020-11-26T09:06:57  <wumpus> (there's also .la files with library metadata that are used by libtool, but these are not required for anything, and doesn't look like qt uses that system)
213 2020-11-26T09:08:09  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
214 2020-11-26T09:08:34  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
215 2020-11-26T09:13:08  *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has quit IRC (Remote host closed the connection)
216 2020-11-26T09:15:09  <sipa> wumpus: hmm, maybe i conflated windows stuff earlier then
217 2020-11-26T09:16:51  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
218 2020-11-26T09:22:48  <wumpus> i think windows' .lib system is pretty nice, it allows for linking against a library without having the compiled library (the .lib is just a list of symbols), right now in the depends system we need to build some libraries (such as freetype) just to link against the system copy of it... that could be avoided in that case
219 2020-11-26T09:26:39  <wumpus> though there is work on this under the name of 'interface stubs', but only in clang afaik, https://phoronix.com/scan.php?page=news_item&px=Clang-Interface-Stubs
220 2020-11-26T09:27:06  <fanquake> also tbd stubs heh
221 2020-11-26T09:27:43  <wumpus> fanquake: those are the macos specific kind isn't it?
222 2020-11-26T09:27:48  <fanquake> yea
223 2020-11-26T09:30:43  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Ping timeout: 240 seconds)
224 2020-11-26T09:30:52  <fanquake> https://github.com/fanquake/core-review/blob/master/tbd-stubs.md
225 2020-11-26T09:30:55  <wumpus> would be so nice to just have (deterministically generated) stubs and headers for OS dependencies, this could even replace the symbol check because too new symbols would just not be in the stubs
226 2020-11-26T09:32:09  <wumpus> fanquake: now for ELF :)
227 2020-11-26T09:32:43  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
228 2020-11-26T09:34:18  <vasild_> sipa: https://bpa.st/VU2Q makes sense?
229 2020-11-26T09:34:24  *** vasild_ is now known as vasild
230 2020-11-26T09:34:49  <wumpus> fanquake: but yes that's certainly the idea, it's nice that they have a text based format too
231 2020-11-26T09:36:35  <wumpus> "-interface-stub-version=experimental-yaml-elf-v1" hmm  let's see if my clang is new enough
232 2020-11-26T09:38:02  <wumpus> "error: invalid value 'Invalid interface stub format: experimental-yaml-elf-v1 is deprecated.' " loool oh already deprecated
233 2020-11-26T09:38:29  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
234 2020-11-26T09:38:41  <vasild> serialization is ok, but deserialize could produce strange results indeed - the value stored in nVersion here `int nVersion = s.GetVersion();` will be overwritten 2 lines below by `READWRITE(nVersion);` by what comes in from disk. That overwritten nVersion will be used to make decision about compactsize services, but will not be used by READWRITEAS(CService, obj);, which will use s.GetVersion()
235 2020-11-26T09:45:15  *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has quit IRC (Quit: Quit)
236 2020-11-26T09:56:02  <wumpus> experimental-ifs-v2 works but doesn't look like there is a text format anymore
237 2020-11-26T09:57:11  *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
238 2020-11-26T10:04:55  *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has joined #bitcoin-core-dev
239 2020-11-26T10:05:38  *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has quit IRC (Ping timeout: 272 seconds)
240 2020-11-26T10:06:08  *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has quit IRC (Client Quit)
241 2020-11-26T10:07:05  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
242 2020-11-26T10:12:09  <wumpus> otoh we're only linking against a few system C libraries not C++ libraries this makes things way simpler
243 2020-11-26T10:14:35  <wumpus> e.g. ELF library -> text file with symbols and metadata -> ELF library with only symbols and metadata for linking
244 2020-11-26T10:31:13  <wumpus> the only thing is that you'd end up with a file per architecture, as there might be symbol differences, but as we have only a limited number of architectures that's not too bad
245 2020-11-26T10:34:39  *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has joined #bitcoin-core-dev
246 2020-11-26T10:45:42  <hebasto> sipa: on fresh minimal ubuntu 20.10 `configure --with-incompatible-bdb && make` works flawlessly
247 2020-11-26T10:56:01  *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Remote host closed the connection)
248 2020-11-26T10:57:06  *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
249 2020-11-26T11:02:12  <wumpus> https://llvm.org/devmtg/2019-10/slides/Lotfi-ClangInterfaceStubs.pdf
250 2020-11-26T11:14:09  *** reallll is now known as belcher
251 2020-11-26T11:18:30  *** Keira72Terry <Keira72Terry!~Keira72Te@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
252 2020-11-26T11:20:16  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 240 seconds)
253 2020-11-26T11:21:29  <wumpus> oh would have been more on-topic in #bitcoin-builds i guess sorry
254 2020-11-26T11:22:56  *** Keira72Terry <Keira72Terry!~Keira72Te@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 240 seconds)
255 2020-11-26T11:29:13  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
256 2020-11-26T11:29:20  *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
257 2020-11-26T11:34:44  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 256 seconds)
258 2020-11-26T11:34:51  *** hizkifw <hizkifw!hizkifwmat@gateway/shell/matrix.org/x-bkabzcpoowfubriy> has quit IRC (Quit: Bridge terminating on SIGTERM)
259 2020-11-26T11:34:52  *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-iviqgumaaxfuxogk> has quit IRC (Quit: Bridge terminating on SIGTERM)
260 2020-11-26T11:34:52  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-uzbkbocahofvpvuf> has quit IRC (Quit: Bridge terminating on SIGTERM)
261 2020-11-26T11:34:54  *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-qevdkhinzrrefbnr> has quit IRC (Quit: Bridge terminating on SIGTERM)
262 2020-11-26T11:34:54  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-usneaxcbtqzjekhe> has quit IRC (Quit: Bridge terminating on SIGTERM)
263 2020-11-26T11:35:15  *** sirpesto <sirpesto!sirpestoma@gateway/shell/matrix.org/x-pkphqgkkgyfomhwu> has quit IRC (Quit: Bridge terminating on SIGTERM)
264 2020-11-26T11:37:25  *** nckx <nckx!~nckx@tobias.gr> has quit IRC (Ping timeout: 264 seconds)
265 2020-11-26T11:38:01  *** nckx <nckx!~nckx@tobias.gr> has joined #bitcoin-core-dev
266 2020-11-26T11:40:32  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
267 2020-11-26T11:42:32  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
268 2020-11-26T11:45:03  *** sirpesto <sirpesto!sirpestoma@gateway/shell/matrix.org/x-pswhzwdostxtpaos> has joined #bitcoin-core-dev
269 2020-11-26T11:46:34  <jonatack> MarcoFalke: thanks for fixing that stray line I added in the release note wiki. Just updated it to add the new fee_rate sat/vB changes and adjust the PR 11413 fee rate info.
270 2020-11-26T11:47:48  <jonatack> The wallet RPC changes are a bit spread out ATM and should probably be regrouped in one place under the Wallet section, Updated RPCs
271 2020-11-26T11:49:04  *** k3tan172 <k3tan172!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
272 2020-11-26T11:49:23  *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Ping timeout: 240 seconds)
273 2020-11-26T11:50:01  <jonatack> I didn't do that, other than moving the PR 11413 entries down to just after the new RPC send entry so it makes more sense.
274 2020-11-26T11:50:52  <jonatack> As the 11413 entry now mentions RPC send.
275 2020-11-26T11:53:09  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
276 2020-11-26T11:58:57  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
277 2020-11-26T12:00:11  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
278 2020-11-26T12:01:33  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
279 2020-11-26T12:04:41  <hebasto> wumpus: may I remind to post rc2 binaries to https://bitcoincore.org/bin/ ?
280 2020-11-26T12:05:41  <wumpus> hebasto: already working on that
281 2020-11-26T12:05:50  <hebasto> thanks!
282 2020-11-26T12:09:57  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
283 2020-11-26T12:09:57  <bitcoin-git> [bitcoin] hebasto closed pull request #19832: p2p: Put disconnecting logs into BCLog::NET category (master...200829-log) https://github.com/bitcoin/bitcoin/pull/19832
284 2020-11-26T12:09:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
285 2020-11-26T12:11:15  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
286 2020-11-26T12:12:09  *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-qsnxxgllrqyjdxvn> has joined #bitcoin-core-dev
287 2020-11-26T12:12:09  *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-zsrqemrmfzdyubjl> has joined #bitcoin-core-dev
288 2020-11-26T12:12:09  *** hizkifw <hizkifw!hizkifwmat@gateway/shell/matrix.org/x-gpsrokdzadhwpocp> has joined #bitcoin-core-dev
289 2020-11-26T12:12:09  *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-krvymnjpngwletgk> has joined #bitcoin-core-dev
290 2020-11-26T12:12:09  *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-vacanapkkzgpicki> has joined #bitcoin-core-dev
291 2020-11-26T12:12:09  *** k3tan172 is now known as k3tan
292 2020-11-26T12:14:09  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
293 2020-11-26T12:18:13  *** dleffler1 <dleffler1!~dleffler@178.239.168.171> has joined #bitcoin-core-dev
294 2020-11-26T12:23:51  *** jonatack <jonatack!~jon@134.19.179.163> has quit IRC (Quit: jonatack)
295 2020-11-26T12:25:23  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
296 2020-11-26T12:31:24  *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has joined #bitcoin-core-dev
297 2020-11-26T12:34:21  <wumpus> 0.21.0rc2 binaries up: https://bitcoincore.org/bin/bitcoin-core-0.21.0/test.rc2/
298 2020-11-26T12:40:33  *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
299 2020-11-26T12:42:24  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
300 2020-11-26T12:42:33  <fanquake> 🚀
301 2020-11-26T12:45:37  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
302 2020-11-26T12:45:37  <bitcoin-git> [bitcoin] sipsorcery opened pull request #20506: WIP: AppVeyor CI fixes in preparation for next image bump (master...msvc-no-optimise) https://github.com/bitcoin/bitcoin/pull/20506
303 2020-11-26T12:45:41  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
304 2020-11-26T12:49:28  *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
305 2020-11-26T12:53:21  *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 272 seconds)
306 2020-11-26T13:07:02  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
307 2020-11-26T13:13:36  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
308 2020-11-26T13:25:35  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
309 2020-11-26T13:35:21  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
310 2020-11-26T13:36:29  *** jonatack <jonatack!~jon@88.124.242.136> has joined #bitcoin-core-dev
311 2020-11-26T13:38:23  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
312 2020-11-26T13:40:43  *** jonatack <jonatack!~jon@88.124.242.136> has quit IRC (Ping timeout: 246 seconds)
313 2020-11-26T13:41:08  *** jonatack <jonatack!~jon@82.102.27.171> has joined #bitcoin-core-dev
314 2020-11-26T13:46:05  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
315 2020-11-26T13:46:05  <bitcoin-git> [bitcoin] vasild opened pull request #20507: sync: print proper lock order location when double lock is detected (master...double_lock_print_location) https://github.com/bitcoin/bitcoin/pull/20507
316 2020-11-26T13:46:06  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
317 2020-11-26T13:49:59  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
318 2020-11-26T13:53:50  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
319 2020-11-26T13:55:41  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has quit IRC (Read error: Connection reset by peer)
320 2020-11-26T13:56:08  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
321 2020-11-26T13:59:43  *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
322 2020-11-26T14:10:25  *** ossifrage <ossifrage!~ossifrage@unaffiliated/ossifrage> has quit IRC (Ping timeout: 240 seconds)
323 2020-11-26T14:11:03  *** rebelution <rebelution!~sam@20.68.25.16> has joined #bitcoin-core-dev
324 2020-11-26T14:11:06  <rebelution> luke-jr ------->> [[ You are as grotesque as a disgraceful savage shitload of ineffectual repugnant maggot slime ]] <<-------
325 2020-11-26T14:33:05  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
326 2020-11-26T14:33:39  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
327 2020-11-26T14:33:39  <bitcoin-git> [bitcoin] sipsorcery opened pull request #20508: IGNORE: Testing appveyor CI build with pre-built dependencies (master...msvc-vcpkg-prebuilt) https://github.com/bitcoin/bitcoin/pull/20508
328 2020-11-26T14:33:51  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
329 2020-11-26T14:40:49  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
330 2020-11-26T14:42:56  *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
331 2020-11-26T14:48:13  *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has joined #bitcoin-core-dev
332 2020-11-26T14:54:31  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
333 2020-11-26T14:54:31  <bitcoin-git> [bitcoin] vasild opened pull request #20509: net: CAddress deser: use stream's version, not what's coming from disk (master...caddress_deser_version) https://github.com/bitcoin/bitcoin/pull/20509
334 2020-11-26T14:54:34  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
335 2020-11-26T14:54:40  <vasild> sipa: ^
336 2020-11-26T14:56:19  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
337 2020-11-26T14:57:05  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
338 2020-11-26T15:10:50  *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
339 2020-11-26T15:15:35  *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
340 2020-11-26T15:21:26  *** ChanServ sets mode: +o wumpus
341 2020-11-26T15:21:28  *** wumpus sets mode: +b *!*@20.68.25.16
342 2020-11-26T15:21:35  *** rebelution was kicked by wumpus (rebelution)
343 2020-11-26T15:21:41  *** ChanServ sets mode: -o wumpus
344 2020-11-26T15:23:19  *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
345 2020-11-26T15:27:10  <luke-jr> any idea why bitcoind crashes at startup in Valgrind? :/
346 2020-11-26T15:28:01  <luke-jr> with UBSan*
347 2020-11-26T15:30:46  *** ossifrage <ossifrage!~ossifrage@unaffiliated/ossifrage> has joined #bitcoin-core-dev
348 2020-11-26T15:31:19  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
349 2020-11-26T15:32:48  *** dleffler1 <dleffler1!~dleffler@178.239.168.171> has quit IRC ()
350 2020-11-26T15:33:42  *** Kiminuo <Kiminuo!~mix@217.138.199.36> has quit IRC (Ping timeout: 272 seconds)
351 2020-11-26T15:36:04  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
352 2020-11-26T15:41:50  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
353 2020-11-26T15:43:25  *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has quit IRC (Ping timeout: 245 seconds)
354 2020-11-26T15:46:35  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Client Quit)
355 2020-11-26T15:59:26  *** jMCg <jMCg!~jMCg@195.140.213.38> has joined #bitcoin-core-dev
356 2020-11-26T16:03:42  *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
357 2020-11-26T16:06:39  *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
358 2020-11-26T16:07:53  *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
359 2020-11-26T16:11:55  *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
360 2020-11-26T16:33:51  *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
361 2020-11-26T16:34:32  *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has quit IRC (Quit: WeeChat 2.3)
362 2020-11-26T16:36:23  *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
363 2020-11-26T16:39:33  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
364 2020-11-26T16:45:29  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
365 2020-11-26T16:45:29  <bitcoin-git> [bitcoin] jonatack opened pull request #20510: [backport] wallet: allow zero-fee fundrawtransaction/walletcreatefundedpsbt and other fixes (0.21...backport-fee_rate-follow-ups) https://github.com/bitcoin/bitcoin/pull/20510
366 2020-11-26T16:45:30  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
367 2020-11-26T16:49:53  *** RickMortir22 <RickMortir22!~RickMorti@45.135.187.65> has joined #bitcoin-core-dev
368 2020-11-26T16:49:55  <RickMortir22> Anyone Can Help? - My Bitcoin Core dont Work Anymore, it stoped syng 19 hours ago and dont sync anymore, its shows "19 hours ago" forever, and status bar show "connecting..."
369 2020-11-26T16:52:48  *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
370 2020-11-26T17:02:48  *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
371 2020-11-26T17:08:57  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
372 2020-11-26T17:10:30  *** RickMortir22 <RickMortir22!~RickMorti@45.135.187.65> has quit IRC ()
373 2020-11-26T17:11:45  *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
374 2020-11-26T17:16:18  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
375 2020-11-26T17:19:30  <wumpus> luke-jr: no idea, I'm sure valgrind gives some kind of error?
376 2020-11-26T17:21:03  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
377 2020-11-26T17:21:12  <wumpus> there's sanitizer suppressions for ubsan in fuzz/test/sanitizer_suppressions/ubsan
378 2020-11-26T17:25:46  <MarcoFalke> can valgrind run with sanitizers on top, even?
379 2020-11-26T17:31:46  <wumpus> that's a good question
380 2020-11-26T17:34:57  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
381 2020-11-26T17:40:39  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
382 2020-11-26T17:58:28  <sipa> afaik no
383 2020-11-26T17:58:42  *** Kiminuo <Kiminuo!~mix@217.138.199.36> has joined #bitcoin-core-dev
384 2020-11-26T18:06:18  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has quit IRC (Read error: Connection reset by peer)
385 2020-11-26T18:06:43  *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
386 2020-11-26T18:11:29  <sipa> vasild: yes, that works
387 2020-11-26T18:11:47  <glozow> #proposedmeetingtopic package validation design question
388 2020-11-26T18:11:50  <sipa> i was working on a fix as part of rebasing the serialization parameters
389 2020-11-26T18:11:56  <glozow> is that how u do it
390 2020-11-26T18:12:56  <jnewbery> that's exactly how you do it!
391 2020-11-26T18:13:20  <glozow> whew, thanks jnewbery
392 2020-11-26T18:14:21  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has quit IRC (Quit: My Mac Mini has gone to sleep. ZZZzzz…)
393 2020-11-26T18:16:20  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
394 2020-11-26T18:17:36  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
395 2020-11-26T18:24:34  <ajonas> #proposedmeetingtopic 2019-20 Coredev survey summary
396 2020-11-26T18:30:43  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Ping timeout: 240 seconds)
397 2020-11-26T18:39:24  <sipa> ugh, anchors.dat stores CAddress objects on disk, without file versioning
398 2020-11-26T18:39:49  <sipa> this means it doesn't support v2 addresses
399 2020-11-26T18:40:43  <jonatack> good catch
400 2020-11-26T18:41:15  <sipa> going to open an issue
401 2020-11-26T18:50:19  <sipa> glozow: wth is peter wheel? ;)
402 2020-11-26T18:53:37  <glozow> sipa: bitcoin gandalf, roams Middle Earth with the hobbitcoins
403 2020-11-26T18:59:20  <hebasto> as anchors.dat is a new feature, could it use only v2 addresses?
404 2020-11-26T19:00:49  <wumpus> #startmeeting
405 2020-11-26T19:00:50  <core-meetingbot> Meeting started Thu Nov 26 19:00:49 2020 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
406 2020-11-26T19:00:50  <core-meetingbot> Available commands: action commands idea info link nick
407 2020-11-26T19:00:53  <sipa> hebasto: yes, but what when we introduce v3?
408 2020-11-26T19:01:00  <jonasschnelli> hi
409 2020-11-26T19:01:06  <wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
410 2020-11-26T19:01:06  <kanzure> hi
411 2020-11-26T19:01:07  <hebasto> hi
412 2020-11-26T19:01:07  <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
413 2020-11-26T19:01:09  <achow101> today's a us holiday so there may be fewer people
414 2020-11-26T19:01:21  <jonatack> hola
415 2020-11-26T19:01:34  <glozow> hi
416 2020-11-26T19:01:41  <wumpus> congrats on rc2 everyone !
417 2020-11-26T19:01:44  <fjahr> hi
418 2020-11-26T19:01:45  <jb55> hi
419 2020-11-26T19:01:54  <wumpus> achow101: yes, might be a short meeting
420 2020-11-26T19:01:54  <sipa> hi
421 2020-11-26T19:02:11  <michaelfolkson> Happy Thanksgiving US peeps
422 2020-11-26T19:02:11  <ajonas> hi
423 2020-11-26T19:02:14  *** satwo <satwo!~textual@209-30-116-174.lightspeed.nsvltn.sbcglobal.net> has joined #bitcoin-core-dev
424 2020-11-26T19:02:50  <wumpus> we do have two proposed meeting topics for today: package validation design question (glozow), 2019-20 Coredev survey summary (ajonas)
425 2020-11-26T19:03:18  <wumpus> any any others if people have last minute proposals
426 2020-11-26T19:03:46  <wumpus> #topic High priority for review
427 2020-11-26T19:03:46  <core-meetingbot> topic: High priority for review
428 2020-11-26T19:04:03  <wumpus> https://github.com/bitcoin/bitcoin/projects/8  9 blockers, 2 chasing concept ACK
429 2020-11-26T19:04:28  *** satwo <satwo!~textual@209-30-116-174.lightspeed.nsvltn.sbcglobal.net> has quit IRC (Client Quit)
430 2020-11-26T19:04:32  <jnewbery> hi
431 2020-11-26T19:04:43  <wumpus> anything to add/remote or that is ready for merge?
432 2020-11-26T19:04:56  <fjahr> Can we add #19055 to blockers again?
433 2020-11-26T19:05:00  <gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
434 2020-11-26T19:05:34  <wumpus> fjahr:sure
435 2020-11-26T19:05:41  <fjahr> thx
436 2020-11-26T19:05:58  <sipa> #20207 should be ready... not really a blocker for me, but would be nice to get in
437 2020-11-26T19:06:00  <gribble> https://github.com/bitcoin/bitcoin/issues/20207 | Follow-up extra comments on taproot code and tests by sipa · Pull Request #20207 · bitcoin/bitcoin · GitHub
438 2020-11-26T19:06:36  <wumpus> you have nothing else on the list so will add it
439 2020-11-26T19:08:04  <wumpus> that concludes the topic I think
440 2020-11-26T19:08:25  <jonatack> not as a blocker, but maybe #20483 for backport to 0.21 to avoid the feeRate / fee_rate options being a potential source of confusion/footgun
441 2020-11-26T19:08:27  <gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
442 2020-11-26T19:08:45  <wumpus> ok
443 2020-11-26T19:08:45  <jonatack> if not, otherwise it can wait
444 2020-11-26T19:09:22  *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
445 2020-11-26T19:09:33  <wumpus> for 0.21.1 I guess? if it's not a bugfix I don't think we should merge it between rcs
446 2020-11-26T19:09:40  <jonatack> (feeRate is in BTC/kB, fee_rate is in sat/vB)
447 2020-11-26T19:10:04  <jonatack> wumpus: as you think best
448 2020-11-26T19:10:09  <wumpus> in any case it's in the high prio list now
449 2020-11-26T19:11:22  <jonatack> 👌
450 2020-11-26T19:11:43  <wumpus> oh it's 8 files changes, of which 7 tests and only small changes in a cpp
451 2020-11-26T19:12:39  <wumpus> could still be in a rc i guess
452 2020-11-26T19:13:09  <wumpus> #topic package validation design question (glozow)
453 2020-11-26T19:13:09  <core-meetingbot> topic: package validation design question (glozow)
454 2020-11-26T19:13:14  *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
455 2020-11-26T19:13:26  <glozow> So I’m in the process of doing package mempool acceptance logic. I have a design question that boils down to “if a transaction in a package fails, should we reject the whole package immediately?”
456 2020-11-26T19:13:37  <glozow> If it’s a package from p2p (i.e. through package relay) then it seems most logical to fail as early as possible. my draft implementation does all PreChecks first for this reason, and then we don’t do script checks.
457 2020-11-26T19:13:42  <glozow> If we’re doing a testmempoolaccept for a package, however, it seems appropriate to fully validate each one so clients have more helpful information.
458 2020-11-26T19:14:26  <glozow> Wondering if people have thoughts/opinions?
459 2020-11-26T19:14:48  <sipa> you're basically asking if the whole package would fail, should the behavior sort of automatically retry with subpackages?
460 2020-11-26T19:15:03  <sipa> (or be equivalent to that)
461 2020-11-26T19:15:14  <glozow> sipa: yeah
462 2020-11-26T19:15:34  <sipa> is there a need for that?
463 2020-11-26T19:15:46  <jnewbery> That sounds reasonable to me. package acceptance over p2p should be atomic. If you're doing a testmempoolaccept it's helpful to return more granular acceptance information
464 2020-11-26T19:16:06  <sipa> the idea is initially just having this as RPC?
465 2020-11-26T19:16:14  <wumpus> yes, P2P clients don't get helpful information back anyway
466 2020-11-26T19:16:16  <jnewbery> If there was a sendrawtransactionpackage we'd probably want that to be atomic I think
467 2020-11-26T19:16:33  <glozow> yeah, i want to do 1 testmempoolaccept, 2 submit packages through rpc, 3 package relay
468 2020-11-26T19:16:51  <sipa> no reason why the RPC can't be initially just only entire-package, and if there is a use for more granular acceptance, add RPC support for that later
469 2020-11-26T19:16:55  <sipa> (if ever)
470 2020-11-26T19:17:09  <wumpus> for RPC it's useful to at least get detailed information on which transaction failed, but it still makes sense for it to be atomic
471 2020-11-26T19:17:50  <sipa> i could imagine that on P2P maybe there are reasons why you'd want to be able to accept subpackages, e.g. to avoid one bad transactions added to a package by an attacker can't prevent the entire package from being relayed
472 2020-11-26T19:17:56  <sipa> but i think those are longer term questions
473 2020-11-26T19:17:58  <jnewbery> I think if you submit a package (tx A -> tx B -> tx C) to testmempoolaccept it's helpful to the user to know whether A or B or C failed
474 2020-11-26T19:18:42  <glozow> yes, i'm leaning towards running full checks for each tx until they pass/fail in a testaccept
475 2020-11-26T19:19:16  <michaelfolkson> But surely something has gone badly wrong if you can't figure out which transaction in your package was the reason for the rejection?
476 2020-11-26T19:19:16  <wumpus> sipa: right, shouldn't cache all the transactions individually as rejected
477 2020-11-26T19:19:51  <glozow> yah good point
478 2020-11-26T19:20:32  <michaelfolkson> I guess it depends on whether if there are weird rejection policies out there
479 2020-11-26T19:21:00  <glozow> michaelfolkson: what kinds of weird rejection policies?
480 2020-11-26T19:21:03  <jnewbery> Do we ever need to sort the txs in a package (from user or over P2P), or do we expect them always to be sorted?
481 2020-11-26T19:21:17  <glozow> jnewbery: i think we should sort it ourselves
482 2020-11-26T19:21:18  <sipa> jnewbery: i'd expect to use dependency ordering
483 2020-11-26T19:21:40  <sipa> (first sort by how many parents in the package it has, then by txid)
484 2020-11-26T19:21:51  <sipa> on either the sender or the receiver side
485 2020-11-26T19:22:00  <michaelfolkson> glozow: I'm trying to think of reasons for a package rejection that isn't clear to the sender
486 2020-11-26T19:22:35  <sipa> michaelfolkson: the obvious one is a new standardness rule on the network (e.g. softfork that enables new scripts, which the sender knows about but the receiver doesn't)
487 2020-11-26T19:22:42  <sipa> if that happens in a leaf of a package
488 2020-11-26T19:22:48  <jnewbery> sipa: how many parents or how many ancestors?
489 2020-11-26T19:23:02  <sipa> jnewbery: either works
490 2020-11-26T19:23:17  <sipa> presumably the receiver still wants the package without that leaf
491 2020-11-26T19:23:17  <glozow> would you know how many ancestors without doing a few checks? uh oh
492 2020-11-26T19:23:32  <sipa> glozow: that's trivial, i think?
493 2020-11-26T19:23:38  <sipa> we do that sorting everywhere
494 2020-11-26T19:23:41  <sipa> inside tx messages e.g.
495 2020-11-26T19:23:45  <jnewbery> huh? A tx's parent can have more parents in the package than the child, no?
496 2020-11-26T19:23:46  <glozow> ah okay cool
497 2020-11-26T19:24:19  <sipa> jnewbery: oh sorry i mean you can either use ancestors, or depth
498 2020-11-26T19:24:23  <sipa> not # of parents
499 2020-11-26T19:24:28  <jnewbery> right
500 2020-11-26T19:24:40  <sipa> but i think these are all questions for later
501 2020-11-26T19:24:47  <jonatack> glozow: is your concern about a trade-off between resource use/ddos and full atomic validation?
502 2020-11-26T19:25:01  <sipa> for now i think, as an RPC it's fine to just try atomically accepting the whole package
503 2020-11-26T19:25:08  <michaelfolkson> sipa: Is it possible that post Taproot activation that an unupgraded node would reject Taproot transactions in a package?
504 2020-11-26T19:25:19  <sipa> michaelfolkson: they should
505 2020-11-26T19:25:31  <sipa> (except there won't be pre-taproot post-package relay nodes :p)
506 2020-11-26T19:26:16  <michaelfolkson> sipa hopes
507 2020-11-26T19:26:18  <michaelfolkson> haha
508 2020-11-26T19:26:35  <sipa> regardless of whether it activates or not
509 2020-11-26T19:26:46  <glozow> jonatack: yeah, even if not a dos concern, it at least seems unproductive to run PolicyScriptChecks for any tx if we're going to reject the whole package, since those aren't even cached.
510 2020-11-26T19:27:01  <sipa> policy checks are cheap though
511 2020-11-26T19:27:15  <glozow> PolicyScriptChecks?
512 2020-11-26T19:27:17  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 272 seconds)
513 2020-11-26T19:27:33  <jnewbery> sipa: PolicyScriptChecks are script/sig validation
514 2020-11-26T19:27:39  <sipa> oh, ok
515 2020-11-26T19:27:44  <sipa> not familiar with that function
516 2020-11-26T19:28:05  <michaelfolkson> Why "they should"? What do they have to lose by accepting a anyonecanspend transaction as part of the package?
517 2020-11-26T19:28:26  <sipa> michaelfolkson: soft fork safety relies on using transactions the unupgraded networks considers nonstandard
518 2020-11-26T19:28:43  <jnewbery> sipa: it's a step in AcceptToMemoryPool
519 2020-11-26T19:29:18  <jnewbery> added by sdaftuar when he split it possible to implment package acceptance I believe
520 2020-11-26T19:29:30  <sipa> ah
521 2020-11-26T19:29:51  <glozow> yeah added in #16400
522 2020-11-26T19:29:57  <gribble> https://github.com/bitcoin/bitcoin/issues/16400 | refactor: Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar · Pull Request #16400 · bitcoin/bitcoin · GitHub
523 2020-11-26T19:30:35  <jnewbery> sipa: so you think the node should always dependency sort packages, both from p2p and rpc?
524 2020-11-26T19:30:53  <jnewbery> seems to me that the sender/client should do that?
525 2020-11-26T19:31:06  <sipa> jnewbery: yeah, no opening on whose responsibility it should be
526 2020-11-26T19:31:23  <sipa> in P2P, i think it may make sense to force the burden on the sender, because they already know this information anyway
527 2020-11-26T19:32:15  <glozow> sipa: so if you receive a package you don't check to see if it's sorted properly, you just reject if it doesn't work?
528 2020-11-26T19:32:38  <jnewbery> I can see the argument for rpc to accept just a bag of txs and sort it
529 2020-11-26T19:32:44  <sipa> glozow: yeah
530 2020-11-26T19:32:46  <sipa> jnewbery: yeah
531 2020-11-26T19:32:49  <glozow> (also so i don't take up too much time, just making sure, for RPC, it's ok if i do full validation checks for each tx in a testmempoolaccept package, and atomic for real package submissions?)
532 2020-11-26T19:33:13  <sipa> glozow: i'd more think the other way around
533 2020-11-26T19:33:22  <wumpus> there's one other, probably short, topic, so no you're not taking up too much time :)
534 2020-11-26T19:33:29  <jnewbery> I think sipa is saying make both RPC and P2P atomic
535 2020-11-26T19:33:42  <sipa> i'm saying, for now, only do RPC, and make it atomic
536 2020-11-26T19:33:51  <sipa> because there is no need for anything else unless someone comes up with a use case
537 2020-11-26T19:34:11  <sipa> for P2P package relay... i feel there may be a need for accepting subpackages, but that's a question we can discuss later
538 2020-11-26T19:34:18  <jnewbery> I still think there's value to make RPC granular if it doesn't add too much complication, because providing the extra information to the user can be helpful
539 2020-11-26T19:34:35  <sipa> extra information and being atomic aren't in conflict with each other
540 2020-11-26T19:34:50  <sipa> you can report "the package failed... and this is the first problem i encountered, in tx A"
541 2020-11-26T19:34:59  <wumpus> right
542 2020-11-26T19:35:23  <jnewbery> ah, maybe we haven't described the problem well
543 2020-11-26T19:35:36  <sipa> being non-atomic would be a result of the form "the subset of packages {A,B,C,...} is acceptable from your bag, but D failed because Y"
544 2020-11-26T19:35:51  <jnewbery> there are many steps in AcceptToMemoryPool: Prechecks, policy checks, consensus checks
545 2020-11-26T19:35:56  <sipa> at least that's how i interpreted it
546 2020-11-26T19:36:01  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 260 seconds)
547 2020-11-26T19:36:03  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
548 2020-11-26T19:36:18  <michaelfolkson> Non-atomic would be accepting a subset of the package right? Rather than rejecting it outright and providing info why
549 2020-11-26T19:36:22  <jnewbery> we should first do prechecks for all txs, then policy checks for all txs, then consensus checks for all txs
550 2020-11-26T19:36:35  <sipa> jnewbery: agree
551 2020-11-26T19:36:59  <glozow> so the question is, if A and B passed prechecks but C didn't, should we still run script checks for A and B?
552 2020-11-26T19:37:11  <jnewbery> but if tx C fails prechecks, it might still be helpful to do policy checks for tx A and tx B and consensus checks for tx A and tx B so we can say to the user "tx A and tx B are good, but tx C fails in prechecks"
553 2020-11-26T19:37:34  <sipa> i'd say no - for now - because the package in its entirety isn't acceptable
554 2020-11-26T19:38:02  *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
555 2020-11-26T19:38:23  <michaelfolkson> I guess the concern that there is inefficiency. The sender keeps coming back with a smaller package that still gets rejected
556 2020-11-26T19:38:43  <sipa> michaelfolkson: in RPC there is no "sender"
557 2020-11-26T19:38:59  <glozow> what if there's a script error in A, and a prechecks error in C (and C depends on B which depends on A), it'd be more helpful to the RPC client to know how to fix the error in A first?
558 2020-11-26T19:39:01  <sipa> and if the user wants that kind of functionality, we should add it
559 2020-11-26T19:39:36  <sipa> glozow: is that a big design question that needs to be known up front?
560 2020-11-26T19:39:46  <sipa> otherwise i'd just say do the simplest thing first, and iterate
561 2020-11-26T19:40:03  *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
562 2020-11-26T19:41:59  <glozow> it does affect the testmempoolaccept API, i'd like as helpful a response as possible if the package fails
563 2020-11-26T19:42:27  <sipa> i feel that adding more detailed error reporting later can probably be done in a backward compatible manner
564 2020-11-26T19:42:30  *** eugene-ff <eugene-ff!~eugene_ff@2604:2000:1383:472b:243e:c1cc:8b:e45f> has joined #bitcoin-core-dev
565 2020-11-26T19:42:41  <MarcoFalke> I'd also say to do the simpler thing first. Literally any progress on teaching TATMP packages is a nice feature
566 2020-11-26T19:42:53  <glozow> ok, so atomic for now
567 2020-11-26T19:42:56  <sipa> if the RPC is "your package is acceptable in its entirety: yes/no. here is a list of problems i found: []"
568 2020-11-26T19:43:10  <MarcoFalke> Also, we can't keep policy error messages identical between releases anyway
569 2020-11-26T19:43:17  <sipa> MarcoFalke: right
570 2020-11-26T19:44:07  <glozow> got it, thanks everyone
571 2020-11-26T19:44:37  <wumpus> #topic 2019-20 Coredev survey summary (ajonas)
572 2020-11-26T19:44:37  <core-meetingbot> topic: 2019-20 Coredev survey summary (ajonas)
573 2020-11-26T19:44:48  <MarcoFalke> glozow: Thanks for working on this!
574 2020-11-26T19:44:56  <sipa> absolutely
575 2020-11-26T19:45:02  <ajonas> In January, jnewbery sent out a survey that he planned to present the results of at the Coredev in March. Given that the meeting never happened, I put together a presentation/post summarizing the responses. Both can be found at https://adamjonas.com/bitcoin/coredev/retro/coredev-2019-retro/.
576 2020-11-26T19:45:14  <ajonas> No action items. Just want to call it to people's attention.
577 2020-11-26T19:45:22  <wumpus> ajonas: awesome!
578 2020-11-26T19:45:46  <jnewbery> ajonas: thank you for picking this up
579 2020-11-26T19:45:55  <michaelfolkson> For the summary watch the video I guess?
580 2020-11-26T19:46:12  <ajonas> the post and the video are about the same
581 2020-11-26T19:46:15  <sipa> short note: i just opened #20511, which i think is something to address for 0.21
582 2020-11-26T19:46:16  <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
583 2020-11-26T19:46:20  <jonatack> ajonas: wow! thanks!
584 2020-11-26T19:46:26  <glozow> ajonas: wow cool!!!
585 2020-11-26T19:46:34  <sipa> ajonas: thanks for that, will read (and maybe watch)
586 2020-11-26T19:46:43  <jonasschnelli> nice!
587 2020-11-26T19:46:44  <ajonas> thanks to jnewbery for sending it out and I hope we can do another round in early 2021.
588 2020-11-26T19:47:46  <fjahr> ajonas: cool!
589 2020-11-26T19:49:41  <wumpus> unless anyone wants to discuss a specific thing from that overview, I think this concludes the meeting
590 2020-11-26T19:49:42  <jnewbery> I agree that there's much more value in these things if we repeat them periodically. Everyone who answered talked about their hopes for the project and their contributions in 2020, so looking back at those should be interesting for people
591 2020-11-26T19:50:51  <wumpus> yes it's interesting I agree with most of the comments
592 2020-11-26T19:51:25  <wumpus> #endmeeting
593 2020-11-26T19:51:25  <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
594 2020-11-26T19:51:26  <core-meetingbot> Meeting ended Thu Nov 26 19:51:25 2020 UTC.
595 2020-11-26T19:51:26  <core-meetingbot> Minutes:        https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2020/bitcoin-core-dev.2020-11-26-19.00.moin.txt
596 2020-11-26T19:52:12  <michaelfolkson> I'm guessing there will be no Core dev meeting until it can be done in person? People aren't keen on video conference like things
597 2020-11-26T19:53:34  <MarcoFalke> michaelfolkson: IRC works better than video
598 2020-11-26T19:53:54  <sipa> i'm personally not particularly interested in non-in-person coredev
599 2020-11-26T19:54:03  <michaelfolkson> Fair enough
600 2020-11-26T19:55:29  <michaelfolkson> I think it is IRC < Video < In person for engagement. But IRC definitely most convenient
601 2020-11-26T19:58:49  *** luke <luke!~luke@bitnomial/staff/luke> has joined #bitcoin-core-dev
602 2020-11-26T20:00:21  <jonatack> same for me as MarcoFalke and sipa ^
603 2020-11-26T20:01:53  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
604 2020-11-26T20:03:45  <hebasto> ^ same
605 2020-11-26T20:04:58  <michaelfolkson> To be clear I wasn't proposing video instead of IRC for the weekly meetings lol. Only as a possible substitute to the in person Core dev meeting until Covid is over
606 2020-11-26T20:18:24  <michaelfolkson> Great video ajonas. Interested in how next year's will compare
607 2020-11-26T20:19:33  *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
608 2020-11-26T20:23:01  <michaelfolkson> I'm guessing at least some of this has improved. Signet and BIP 157 have made progress. Coin selection less so presumably
609 2020-11-26T20:25:00  <michaelfolkson> And process separation and fuzzing PRs struggle for review
610 2020-11-26T20:25:36  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
611 2020-11-26T20:36:13  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
612 2020-11-26T20:36:13  <bitcoin-git> [bitcoin] emilengler opened pull request #20512: doc: Add bash as an OpenBSD dependency (master...2020-11-doc-build-openbsd-bash-dependency) https://github.com/bitcoin/bitcoin/pull/20512
613 2020-11-26T20:36:14  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
614 2020-11-26T20:40:31  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
615 2020-11-26T20:40:31  <bitcoin-git> [bitcoin] bitcoinhodler opened pull request #20513: Release notes: remove mention of default wallet creation (master...no-default-wallet) https://github.com/bitcoin/bitcoin/pull/20513
616 2020-11-26T20:40:33  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
617 2020-11-26T20:46:05  *** Kiminuo <Kiminuo!~mix@217.138.199.36> has quit IRC (Ping timeout: 240 seconds)
618 2020-11-26T20:55:01  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
619 2020-11-26T20:58:09  *** luke <luke!~luke@bitnomial/staff/luke> has quit IRC (Quit: sleep)
620 2020-11-26T21:00:42  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
621 2020-11-26T21:02:48  *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
622 2020-11-26T21:03:28  *** schmeckin <schmeckin!~schmecks@198.181.163.31> has joined #bitcoin-core-dev
623 2020-11-26T21:03:57  *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
624 2020-11-26T21:06:17  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
625 2020-11-26T21:07:05  *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
626 2020-11-26T21:12:10  *** schmeckin <schmeckin!~schmecks@198.181.163.31> has left #bitcoin-core-dev
627 2020-11-26T21:12:28  <aj> wumpus: any thoughts on "bitcoin-util grind" ? another option might be to add "bitcoin-cli -grind=HEADER" with the idea being to move it into bitcoin-util in a later PR that also includes other useful stuff, like psbt commands?
628 2020-11-26T21:12:48  *** schmeckin <schmeckin!~schmecks@198.181.163.31> has joined #bitcoin-core-dev
629 2020-11-26T21:13:07  <schmeckin> It's amazing what a bunch of assholes yall are.  You wonder why you're being insulted after spending 8 years being corrupt pathological lieing fucktards instead of rectifying the issue?
630 2020-11-26T21:13:26  <schmeckin> midnight ------->> [[ You are as rotten as a clumsy decaying myriad of smelly bat pus ]] <<-------
631 2020-11-26T21:13:30  <schmeckin> luke-jr ------->> [[ You are as noxious as a dirty clumsy accumulation of rotten despicable disgusting cockroach dung ]] <<-------
632 2020-11-26T21:13:34  <schmeckin> gmaxwell ------->> [[ You are as hostile as a barren mass of ineffectual bat orifices ]] <<-------
633 2020-11-26T21:18:38  *** schmeckin <schmeckin!~schmecks@198.181.163.31> has quit IRC (Quit: Leaving)
634 2020-11-26T21:30:34  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
635 2020-11-26T21:30:38  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
636 2020-11-26T21:34:11  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
637 2020-11-26T21:34:11  <bitcoin-git> [bitcoin] bitcoinhodler closed pull request #20513: Release notes: remove mention of default wallet creation (0.21...no-default-wallet) https://github.com/bitcoin/bitcoin/pull/20513
638 2020-11-26T21:34:12  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
639 2020-11-26T21:36:52  *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Quit: Ping timeout (120 seconds))
640 2020-11-26T21:37:11  *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has quit IRC (Ping timeout: 256 seconds)
641 2020-11-26T21:37:18  *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
642 2020-11-26T21:56:14  *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 272 seconds)
643 2020-11-26T21:57:23  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 272 seconds)
644 2020-11-26T22:00:28  *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzz…)
645 2020-11-26T22:01:45  *** lightlike <lightlike!~lightlike@p200300c7ef1bcf00887629e01a1f3407.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
646 2020-11-26T22:02:42  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
647 2020-11-26T22:02:42  <bitcoin-git> [bitcoin] sipa opened pull request #20514: Use addrv2 serialization in anchors.dat (master...202011_v2_anchors) https://github.com/bitcoin/bitcoin/pull/20514
648 2020-11-26T22:02:43  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
649 2020-11-26T22:06:21  <luke-jr> wumpus: not a sensible one https://dpaste.com/8KGS42GH5
650 2020-11-26T22:08:13  <luke-jr> I mean, if this were correct, it wouldn't matter if it was Valgrind run or not XD
651 2020-11-26T22:11:05  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
652 2020-11-26T22:14:18  <luke-jr> oh lovely, it goes away if I LogPrintf the pointer -.-
653 2020-11-26T22:16:58  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
654 2020-11-26T22:16:58  <bitcoin-git> [bitcoin] sipsorcery closed pull request #20508: IGNORE: Testing appveyor CI build with pre-built dependencies (master...msvc-vcpkg-prebuilt) https://github.com/bitcoin/bitcoin/pull/20508
655 2020-11-26T22:16:59  *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
656 2020-11-26T22:17:51  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
657 2020-11-26T22:21:10  *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
658 2020-11-26T22:24:40  <michaelfolkson> Don't know why the trolls are targeting you today luke-jr. On behalf of humanity I apologize
659 2020-11-26T22:26:37  <luke-jr> michaelfolkson: me either :/
660 2020-11-26T22:28:52  <sipa> wumpus: qt compiles now, "apt install --reinstall qtbase5-dev" was enough to fix it
661 2020-11-26T22:33:48  <luke-jr> O.o
662 2020-11-26T22:34:32  <sipa> luke-jr: somehow i was missing libQt5Core.so (i only had .so.5)
663 2020-11-26T22:34:58  <luke-jr> weird
664 2020-11-26T22:45:04  *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 260 seconds)
665 2020-11-26T22:46:52  <luke-jr> hrm, -O0 doesn't crash in Valgrind
666 2020-11-26T22:47:12  <luke-jr> not sure this tells me anything
667 2020-11-26T22:51:58  <sipa> luke-jr: are you mixing sanitizers and valgrind?
668 2020-11-26T22:54:55  <luke-jr> sipa: just ubsan
669 2020-11-26T22:55:14  <sipa> that's certainly the least invasive
670 2020-11-26T22:58:22  <luke-jr> I suppose I could rebuild without just to see
671 2020-11-26T22:58:37  <luke-jr> but if it fails to reproduce, I'm not sure UBSan is at fault even then
672 2020-11-26T22:59:54  <luke-jr> LogPrintfs down to FastRandomContext::rand64 leave the crash intact and show non-null ptr
673 2020-11-26T23:00:15  <luke-jr> LogPrintfs in FastRandomContext::FillByteBuffer or ChaCha20::Keystream show the same non-null ptr and fix the crash
674 2020-11-26T23:00:52  *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
675 2020-11-26T23:01:08  <sipa> luke-jr: i mean... if it were actually trying to write 4 bytes to nullptr, your process would segfault
676 2020-11-26T23:01:46  <sipa> so if it works by just running, and not inside valgrind (both with ubsan enabled), it's a problem with the combination of the two
677 2020-11-26T23:02:57  *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
678 2020-11-26T23:05:45  <luke-jr> sipa: it does segfault :P
679 2020-11-26T23:05:56  <luke-jr> inside valgrind*
680 2020-11-26T23:06:08  <luke-jr> but not without UBSan
681 2020-11-26T23:06:24  <luke-jr> strange
682 2020-11-26T23:07:42  <sipa> luke-jr: but does it segfault *with* ubsan, but outside valgrind?
683 2020-11-26T23:11:35  <luke-jr> sipa: no
684 2020-11-26T23:11:43  <luke-jr> but that could just indicate a timing issuse
685 2020-11-26T23:14:07  *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Read error: Connection reset by peer)
686 2020-11-26T23:17:53  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
687 2020-11-26T23:18:17  *** gleb3 <gleb3!~gleb@178.150.137.228> has joined #bitcoin-core-dev
688 2020-11-26T23:19:33  *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 260 seconds)
689 2020-11-26T23:19:48  <sipa> luke-jr: could be, indeed
690 2020-11-26T23:19:50  *** gleb3 is now known as gleb
691 2020-11-26T23:19:51  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has quit IRC (Client Quit)
692 2020-11-26T23:20:12  *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
693 2020-11-26T23:28:16  *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzz…)
694 2020-11-26T23:35:35  *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
695 2020-11-26T23:42:30  <luke-jr> in the meantime, the actual issue I was *trying* to debug, doesn't occur in Valgrind x.x
696 2020-11-26T23:44:17  *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
697 2020-11-26T23:54:39  *** lightlike <lightlike!~lightlike@p200300c7ef1bcf00887629e01a1f3407.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
698 2020-11-26T23:58:56  *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Quit: Leaving)
699 2020-11-26T23:59:15  *** mrostecki <mrostecki!mrostecki@nat/suse/x-kwnqnqspcazesbuo> has joined #bitcoin-core-dev