12020-11-26T00:00:25 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
22020-11-26T00:08:35 *** openoms <openoms!~quassel@91.132.136.76> has quit IRC (Ping timeout: 256 seconds)
32020-11-26T00:12:19 *** Eagle[TM] <Eagle[TM]!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 260 seconds)
42020-11-26T00:18:10 *** openoms <openoms!~quassel@91.132.136.76> has joined #bitcoin-core-dev
52020-11-26T00:32:48 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Read error: Connection reset by peer)
62020-11-26T00:35:25 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:bc9a:f509:3193:e14d> has joined #bitcoin-core-dev
72020-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â¦)
82020-11-26T00:46:36 *** proofofkeags <proofofkeags!~proofofke@c-73-34-43-4.hsd1.co.comcast.net> has quit IRC (Ping timeout: 240 seconds)
92020-11-26T00:53:32 <luke-jr> is it intentional that the test framework's addmultisigaddress substitute for descriptor wallets doesn't accept addresses?
102020-11-26T00:53:40 <achow101> luke-jr: yes
112020-11-26T00:53:46 <luke-jr> k, makes sense
122020-11-26T00:54:34 *** nkuttler <nkuttler!~nkuttler@unaffiliated/nkuttler> has quit IRC (Remote host closed the connection)
132020-11-26T00:55:27 *** nkuttler <nkuttler!~nkuttler@unaffiliated/nkuttler> has joined #bitcoin-core-dev
142020-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â¦)
152020-11-26T01:09:30 <luke-jr> achow101: I can't get it to work at all :/
162020-11-26T01:09:32 <luke-jr> test_framework.authproxy.JSONRPCException: Cannot import descriptor without private keys to a wallet with private keys enabled (-4)
172020-11-26T01:12:05 *** andrewtoth <andrewtoth!~andrewtot@gateway/tor-sasl/andrewtoth> has joined #bitcoin-core-dev
182020-11-26T01:18:43 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
192020-11-26T01:20:54 *** larryruane_ <larryruane_!uid473749@gateway/web/irccloud.com/x-vuztyjlkacjmkbdi> has quit IRC (Quit: Connection closed for inactivity)
202020-11-26T01:22:24 <achow101> luke-jr: the error message is self explanatory. you need a wallet with private keys disabled
212020-11-26T01:24:56 <luke-jr> achow101: but it's not supposed to be watch-only
222020-11-26T01:25:24 <achow101> then it has to have at least one private key
232020-11-26T01:25:37 <luke-jr> it does, addmultisigaddress still requires the pubkey passed thoughâ¦
242020-11-26T01:25:52 <achow101> how to setup multisigs in descriptor wallets is still an unsolved problem
252020-11-26T01:25:58 <luke-jr> :/
262020-11-26T01:26:20 <achow101> what exactly are you trying to do?
272020-11-26T01:28:43 <luke-jr> achow101: https://dpaste.com/5K7JHWDS4
282020-11-26T01:30:01 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
292020-11-26T01:30:03 <achow101> but why tho
302020-11-26T01:30:26 <luke-jr> so it gets tested
312020-11-26T01:31:00 <achow101> import a sortedmulti descriptor instead of adding more stuff to addmultsigaddress?
322020-11-26T01:31:10 <luke-jr> this is from 2016
332020-11-26T01:31:20 <luke-jr> and works with normal wallets
342020-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
352020-11-26T01:32:30 <luke-jr> fair enough
362020-11-26T01:32:50 <achow101> the helper only exists for when we use addmultisigaddress to make a multisig to test other stuff
372020-11-26T01:33:59 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Quit: WeeChat 2.9)
382020-11-26T01:34:17 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
392020-11-26T01:35:18 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
402020-11-26T01:38:23 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
412020-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?
422020-11-26T01:40:27 <sipa> CubicEarth: if you -addnode them, it'll likely fetch most blocks from there
432020-11-26T01:40:42 <sipa> there is no functionality for automatically detecting other bitcoin node in the local network
442020-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.
452020-11-26T01:45:20 <CubicEarth> But is there a reason why such functionality would be bad?
462020-11-26T01:47:41 <sipa> define more user friendly?
472020-11-26T01:48:14 <sipa> i can see the use of detecting other nodes on a local network, but nobody has implemented that
482020-11-26T01:48:20 <sipa> bneyond that, i don't know what you're asking for
492020-11-26T01:48:27 <sipa> is it behaving badly currently?
502020-11-26T01:50:53 <CubicEarth> One assumption I am making: the IBD can be costly in terms of ISP data caps
512020-11-26T01:51:01 <sipa> ah
522020-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
532020-11-26T01:54:04 <CubicEarth> Yeah, it is easy enough for me avoid pulling the data twice through my WAN
542020-11-26T01:54:27 <CubicEarth> I was just thinking of making it happen with less user intervention
552020-11-26T01:55:27 <sipa> doing it without user configuration is hard through
562020-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
572020-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
582020-11-26T01:59:36 <CubicEarth> Isn't is trivial to know if a device is on the same ... subnet?
592020-11-26T02:00:21 <CubicEarth> not sure if subnet is the right term... argh
602020-11-26T02:00:43 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has quit IRC (Ping timeout: 240 seconds)
612020-11-26T02:02:17 <sipa> CubicEarth: that's not the problem!
622020-11-26T02:02:34 <sipa> the problem is making sure that not everyone on the same network is slowing down blocks from the outside
632020-11-26T02:02:42 <sipa> they're still supposed to come in quickly to one node from outside
642020-11-26T02:02:56 <sipa> so you need some kind of "leader election"...
652020-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
662020-11-26T02:03:54 *** yanmaani <yanmaani!~yanmaani@gateway/tor-sasl/yanmaani> has joined #bitcoin-core-dev
672020-11-26T02:04:13 <sipa> ah, yes
682020-11-26T02:04:18 <sipa> for IBD it should Just Work(tm)
692020-11-26T02:04:24 <sipa> as it autoselects for faster peers
702020-11-26T02:05:23 <sipa> though probably not aggressively enough to get ~all blocks from just local nodes
712020-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
722020-11-26T02:06:32 <CubicEarth> And I know i
732020-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?
742020-11-26T02:07:48 <sipa> 1024 blocks
752020-11-26T02:08:11 <CubicEarth> the "sliding window"? thanks
762020-11-26T02:08:17 <sipa> yes
772020-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)."
782020-11-26T02:12:22 <CubicEarth> Still the case?
792020-11-26T02:12:30 <sipa> yes
802020-11-26T02:12:46 <sipa> otherwise you can't effectively prune
812020-11-26T02:13:54 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
822020-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?
832020-11-26T02:15:47 <sipa> yep, they're just appended in the order they arrive
842020-11-26T02:16:05 <sipa> you wouldn't know where to put things if you want to keep them in order
852020-11-26T02:16:21 <sipa> as you don't know the size of the blocks you still miss
862020-11-26T02:16:23 <CubicEarth> couldn't you use the headers?
872020-11-26T02:16:35 <sipa> headers don't contain the block's sizes
882020-11-26T02:17:49 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
892020-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?
902020-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.
912020-11-26T02:24:47 <CubicEarth> *highest block in unbroken sequence
922020-11-26T02:26:05 <CubicEarth> (meaning an attack could feed bad blocks, and then the blk.dat files would be more out of order)
932020-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?
942020-11-26T02:34:05 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has joined #bitcoin-core-dev
952020-11-26T02:34:54 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
962020-11-26T02:36:15 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
972020-11-26T02:36:23 <sipa> CubicEarth: i mean... a block arrives, you don't have its parent(s) yet... where do you store it?
982020-11-26T02:36:34 *** proofofkeags <proofofkeags!~proofofke@174-16-212-53.hlrn.qwest.net> has quit IRC (Remote host closed the connection)
992020-11-26T02:36:40 <sipa> CubicEarth: i've been around for a while :)
1002020-11-26T02:37:56 <sipa> and in this... i wrote a significant part of the block fetching logic
1012020-11-26T02:38:02 <sipa> +case
1022020-11-26T02:38:21 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
1032020-11-26T02:38:44 <CubicEarth> so this about avoid disk thrashing?
1042020-11-26T02:39:20 <CubicEarth> is ... avoiding
1052020-11-26T02:39:30 <sipa> compared to which alternative? you haven't given any
1062020-11-26T02:40:50 <sipa> a possibility is just storing every block in a separate file
1072020-11-26T02:41:04 <sipa> that's great as it means you can delete whatever block at any time
1082020-11-26T02:41:19 <sipa> unfortunately most filesystems perform terribly with huge numbers of files
1092020-11-26T02:41:39 <sipa> another possibility is constantly rewriting block files
1102020-11-26T02:41:51 <sipa> to keep the blocks in order
1112020-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.
1122020-11-26T02:52:07 <sipa> it is
1132020-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
1142020-11-26T02:52:21 <sipa> it doesn't matter where blocks are stored for validation
1152020-11-26T02:52:21 <CubicEarth> and then let the cpu chew through it later
1162020-11-26T02:53:03 <CubicEarth> well that is good
1172020-11-26T02:53:09 <sipa> yeah, that sounds vaguely useful
1182020-11-26T02:56:27 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has quit IRC (Remote host closed the connection)
1192020-11-26T02:58:35 *** az0re <az0re!~az0re@gateway/tor-sasl/az0re> has joined #bitcoin-core-dev
1202020-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?
1212020-11-26T02:59:10 <sipa> ah yes
1222020-11-26T02:59:18 <sipa> but it doesn't matter where things are stored for validation
1232020-11-26T02:59:28 <sipa> it's just restricted to make sure pruning is possible
1242020-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.
1252020-11-26T03:04:39 <sipa> that's the only reason
1262020-11-26T03:05:04 <sipa> otherwise you could end up with 1000 block files, and each contains blocks from all over the chain
1272020-11-26T03:05:10 <sipa> so you can't delete any of them
1282020-11-26T03:05:22 <sipa> because they all also contain very recent blocks
1292020-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?
1302020-11-26T03:09:13 <CubicEarth> or does the expose an attack vector?
1312020-11-26T03:09:18 <CubicEarth> that
1322020-11-26T03:09:31 <sipa> it's not tied to validation, except implicitly
1332020-11-26T03:09:37 <sipa> it's tied to the moving window
1342020-11-26T03:10:01 <sipa> which moves along the chain as far as it can while it has all blocks
1352020-11-26T03:10:08 <sipa> that happens to be identical to what validation needs
1362020-11-26T03:12:03 <CubicEarth> too bad validation can't get ahead of the block download ;)
1372020-11-26T03:12:29 <sipa> you see what i'm saying?
1382020-11-26T03:12:43 <sipa> we validate blocks as soon as we have all its parents (and those parents are validated)
1392020-11-26T03:13:12 <CubicEarth> I get that, and that fits my long held understanding
1402020-11-26T03:13:14 <sipa> and that's also when the download window moves (because limiting out-of-orderness has the exact same requirement)
1412020-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
1422020-11-26T03:16:34 <sipa> oh i see
1432020-11-26T03:16:45 <sipa> you're talking about making validating independent of block download entirely
1442020-11-26T03:16:50 <sipa> that's a whole other can of worms
1452020-11-26T03:17:00 <CubicEarth> yeah
1462020-11-26T03:17:15 <sipa> right now we always make sure that the best chain we know about is the actively validated one
1472020-11-26T03:17:43 <sipa> if you drop that, the window could move ahead of validation
1482020-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
1492020-11-26T03:22:22 *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
1502020-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
1512020-11-26T03:27:02 <CubicEarth> And the risk would be that the wasn't the right chain in the end
1522020-11-26T03:28:26 <CubicEarth> And so downloading would need to happen again
1532020-11-26T03:29:50 <sipa> seems reasonable
1542020-11-26T03:54:50 *** reallll <reallll!~belcher@unaffiliated/belcher> has joined #bitcoin-core-dev
1552020-11-26T03:55:45 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
1562020-11-26T03:58:29 *** belcher <belcher!~belcher@unaffiliated/belcher> has quit IRC (Ping timeout: 260 seconds)
1572020-11-26T04:12:55 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
1582020-11-26T04:13:41 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
1592020-11-26T04:15:36 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 240 seconds)
1602020-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)
1612020-11-26T04:27:31 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
1622020-11-26T04:36:25 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
1632020-11-26T05:00:35 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Remote host closed the connection)
1642020-11-26T05:02:13 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
1652020-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â¦)
1662020-11-26T05:14:22 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
1672020-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â¦)
1682020-11-26T06:44:52 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
1692020-11-26T07:10:13 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
1702020-11-26T07:10:35 *** romanz <romanz!~romanz@bzq-84-109-216-152.cablep.bezeqint.net> has joined #bitcoin-core-dev
1712020-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â¦)
1722020-11-26T07:19:17 *** Kiminuo <Kiminuo!~mix@217.138.199.36> has joined #bitcoin-core-dev
1732020-11-26T07:24:16 *** romanz_ <romanz_!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
1742020-11-26T07:24:25 *** romanz <romanz!~romanz@bzq-84-109-216-152.cablep.bezeqint.net> has quit IRC (Quit: WeeChat 2.8)
1752020-11-26T07:24:32 *** romanz_ <romanz_!~romanz@93.123.196.104.bc.googleusercontent.com> has quit IRC (Client Quit)
1762020-11-26T07:24:50 *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
1772020-11-26T07:25:15 *** kabaum <kabaum!~kabaum@h-13-35.A163.priv.bahnhof.se> has joined #bitcoin-core-dev
1782020-11-26T07:35:07 *** miketwenty1 <miketwenty1!~miketwent@ip24-136-61-186.ga.at.cox.net> has joined #bitcoin-core-dev
1792020-11-26T07:39:49 *** miketwenty1 <miketwenty1!~miketwent@ip24-136-61-186.ga.at.cox.net> has quit IRC (Ping timeout: 264 seconds)
1802020-11-26T07:53:39 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has quit IRC (Remote host closed the connection)
1812020-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
1822020-11-26T08:22:13 <wumpus> it's in qtbase5-dev
1832020-11-26T08:22:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1842020-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
1852020-11-26T08:22:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1862020-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
1872020-11-26T08:36:27 *** andyrtr1 <andyrtr1!~andyrtr@178.239.168.171> has quit IRC (Remote host closed the connection)
1882020-11-26T08:44:54 *** Bullit <Bullit!~Bullit01@042-236-158-163.dynamic.caiway.nl> has joined #bitcoin-core-dev
1892020-11-26T08:45:13 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1902020-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
1912020-11-26T08:45:25 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1922020-11-26T08:53:56 <sipa> wumpus: bizarre, i installed and reinstalled all the packages
1932020-11-26T08:54:15 <sipa> i'll retry and symlink it myself
1942020-11-26T08:54:30 <sipa> thanks
1952020-11-26T08:54:32 <wumpus> so you have /usr/lib/x86_64-linux-gnu/libQt5Core.so but it can't find it during linking?
1962020-11-26T08:54:41 <sipa> only .so.5
1972020-11-26T08:55:05 <hebasto> sipa: waiting for my groovy installation complete to check your link issue
1982020-11-26T08:55:28 <wumpus> does "dpkg -S dpkg -L qtbase5-dev|grep libQt5Core.so" show it should be in there?
1992020-11-26T08:55:45 <wumpus> eh just "dpkg -L qtbase5-dev|grep libQt5Core.so"
2002020-11-26T08:56:05 <wumpus> you really shouldn't have to make the symlink yourself
2012020-11-26T08:58:30 <wumpus> maybe the file is somewhere else on ubuntu 20.10 I haven't used that yet
2022020-11-26T08:58:54 *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has joined #bitcoin-core-dev
2032020-11-26T08:59:13 <sipa> wumpus: ok false alarm, i reinstalled it and now the .so file is there
2042020-11-26T08:59:21 <sipa> i must have reinstalled another package before
2052020-11-26T09:00:05 *** snowkeld[m] <snowkeld[m]!snowkeldma@gateway/shell/matrix.org/x-nbitttfhstlbskqd> has quit IRC (Quit: Idle for 30+ days)
2062020-11-26T09:00:05 <wumpus> phew, still wonder how it came to be erased but good to know!
2072020-11-26T09:01:16 <sipa> yeah, no idea how this happened
2082020-11-26T09:01:29 <sipa> i haven't done many weird things in this install
2092020-11-26T09:01:49 <wumpus> could be a bug I mean that version of ubuntu is still very new
2102020-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?
2112020-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
2122020-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)
2132020-11-26T09:08:09 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
2142020-11-26T09:08:34 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2152020-11-26T09:13:08 *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has quit IRC (Remote host closed the connection)
2162020-11-26T09:15:09 <sipa> wumpus: hmm, maybe i conflated windows stuff earlier then
2172020-11-26T09:16:51 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
2182020-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
2192020-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
2202020-11-26T09:27:06 <fanquake> also tbd stubs heh
2212020-11-26T09:27:43 <wumpus> fanquake: those are the macos specific kind isn't it?
2222020-11-26T09:27:48 <fanquake> yea
2232020-11-26T09:30:43 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Ping timeout: 240 seconds)
2242020-11-26T09:30:52 <fanquake> https://github.com/fanquake/core-review/blob/master/tbd-stubs.md
2252020-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
2262020-11-26T09:32:09 <wumpus> fanquake: now for ELF :)
2272020-11-26T09:32:43 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has joined #bitcoin-core-dev
2282020-11-26T09:34:18 <vasild_> sipa: https://bpa.st/VU2Q makes sense?
2292020-11-26T09:34:24 *** vasild_ is now known as vasild
2302020-11-26T09:34:49 <wumpus> fanquake: but yes that's certainly the idea, it's nice that they have a text based format too
2312020-11-26T09:36:35 <wumpus> "-interface-stub-version=experimental-yaml-elf-v1" hmm let's see if my clang is new enough
2322020-11-26T09:38:02 <wumpus> "error: invalid value 'Invalid interface stub format: experimental-yaml-elf-v1 is deprecated.' " loool oh already deprecated
2332020-11-26T09:38:29 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has quit IRC (Remote host closed the connection)
2342020-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()
2352020-11-26T09:45:15 *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has quit IRC (Quit: Quit)
2362020-11-26T09:56:02 <wumpus> experimental-ifs-v2 works but doesn't look like there is a text format anymore
2372020-11-26T09:57:11 *** gribble <gribble!~gribble@unaffiliated/nanotube/bot/gribble> has joined #bitcoin-core-dev
2382020-11-26T10:04:55 *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has joined #bitcoin-core-dev
2392020-11-26T10:05:38 *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has quit IRC (Ping timeout: 272 seconds)
2402020-11-26T10:06:08 *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has quit IRC (Client Quit)
2412020-11-26T10:07:05 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has joined #bitcoin-core-dev
2422020-11-26T10:12:09 <wumpus> otoh we're only linking against a few system C libraries not C++ libraries this makes things way simpler
2432020-11-26T10:14:35 <wumpus> e.g. ELF library -> text file with symbols and metadata -> ELF library with only symbols and metadata for linking
2442020-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
2452020-11-26T10:34:39 *** willcl_ark <willcl_ark!~quassel@cpc123780-trow7-2-0-cust177.18-1.cable.virginm.net> has joined #bitcoin-core-dev
2462020-11-26T10:45:42 <hebasto> sipa: on fresh minimal ubuntu 20.10 `configure --with-incompatible-bdb && make` works flawlessly
2472020-11-26T10:56:01 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Remote host closed the connection)
2482020-11-26T10:57:06 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
2492020-11-26T11:02:12 <wumpus> https://llvm.org/devmtg/2019-10/slides/Lotfi-ClangInterfaceStubs.pdf
2502020-11-26T11:14:09 *** reallll is now known as belcher
2512020-11-26T11:18:30 *** Keira72Terry <Keira72Terry!~Keira72Te@static.57.1.216.95.clients.your-server.de> has joined #bitcoin-core-dev
2522020-11-26T11:20:16 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 240 seconds)
2532020-11-26T11:21:29 <wumpus> oh would have been more on-topic in #bitcoin-builds i guess sorry
2542020-11-26T11:22:56 *** Keira72Terry <Keira72Terry!~Keira72Te@static.57.1.216.95.clients.your-server.de> has quit IRC (Ping timeout: 240 seconds)
2552020-11-26T11:29:13 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
2562020-11-26T11:29:20 *** AaronvanW <AaronvanW!~AaronvanW@unaffiliated/aaronvanw> has joined #bitcoin-core-dev
2572020-11-26T11:34:44 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 256 seconds)
2582020-11-26T11:34:51 *** hizkifw <hizkifw!hizkifwmat@gateway/shell/matrix.org/x-bkabzcpoowfubriy> has quit IRC (Quit: Bridge terminating on SIGTERM)
2592020-11-26T11:34:52 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-iviqgumaaxfuxogk> has quit IRC (Quit: Bridge terminating on SIGTERM)
2602020-11-26T11:34:52 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-uzbkbocahofvpvuf> has quit IRC (Quit: Bridge terminating on SIGTERM)
2612020-11-26T11:34:54 *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-qevdkhinzrrefbnr> has quit IRC (Quit: Bridge terminating on SIGTERM)
2622020-11-26T11:34:54 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-usneaxcbtqzjekhe> has quit IRC (Quit: Bridge terminating on SIGTERM)
2632020-11-26T11:35:15 *** sirpesto <sirpesto!sirpestoma@gateway/shell/matrix.org/x-pkphqgkkgyfomhwu> has quit IRC (Quit: Bridge terminating on SIGTERM)
2642020-11-26T11:37:25 *** nckx <nckx!~nckx@tobias.gr> has quit IRC (Ping timeout: 264 seconds)
2652020-11-26T11:38:01 *** nckx <nckx!~nckx@tobias.gr> has joined #bitcoin-core-dev
2662020-11-26T11:40:32 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
2672020-11-26T11:42:32 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
2682020-11-26T11:45:03 *** sirpesto <sirpesto!sirpestoma@gateway/shell/matrix.org/x-pswhzwdostxtpaos> has joined #bitcoin-core-dev
2692020-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.
2702020-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
2712020-11-26T11:49:04 *** k3tan172 <k3tan172!~pi@gateway/tor-sasl/k3tan> has joined #bitcoin-core-dev
2722020-11-26T11:49:23 *** k3tan <k3tan!~pi@gateway/tor-sasl/k3tan> has quit IRC (Ping timeout: 240 seconds)
2732020-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.
2742020-11-26T11:50:52 <jonatack> As the 11413 entry now mentions RPC send.
2752020-11-26T11:53:09 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
2762020-11-26T11:58:57 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
2772020-11-26T12:00:11 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
2782020-11-26T12:01:33 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
2792020-11-26T12:04:41 <hebasto> wumpus: may I remind to post rc2 binaries to https://bitcoincore.org/bin/ ?
2802020-11-26T12:05:41 <wumpus> hebasto: already working on that
2812020-11-26T12:05:50 <hebasto> thanks!
2822020-11-26T12:09:57 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
2832020-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
2842020-11-26T12:09:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
2852020-11-26T12:11:15 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
2862020-11-26T12:12:09 *** awesome_doge <awesome_doge!awesome-do@gateway/shell/matrix.org/x-qsnxxgllrqyjdxvn> has joined #bitcoin-core-dev
2872020-11-26T12:12:09 *** rCapital-Surpris <rCapital-Surpris!crtn32002m@gateway/shell/matrix.org/x-zsrqemrmfzdyubjl> has joined #bitcoin-core-dev
2882020-11-26T12:12:09 *** hizkifw <hizkifw!hizkifwmat@gateway/shell/matrix.org/x-gpsrokdzadhwpocp> has joined #bitcoin-core-dev
2892020-11-26T12:12:09 *** icota[m] <icota[m]!icotamatri@gateway/shell/matrix.org/x-krvymnjpngwletgk> has joined #bitcoin-core-dev
2902020-11-26T12:12:09 *** robert_spigler <robert_spigler!robertspig@gateway/shell/matrix.org/x-vacanapkkzgpicki> has joined #bitcoin-core-dev
2912020-11-26T12:12:09 *** k3tan172 is now known as k3tan
2922020-11-26T12:14:09 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
2932020-11-26T12:18:13 *** dleffler1 <dleffler1!~dleffler@178.239.168.171> has joined #bitcoin-core-dev
2942020-11-26T12:23:51 *** jonatack <jonatack!~jon@134.19.179.163> has quit IRC (Quit: jonatack)
2952020-11-26T12:25:23 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
2962020-11-26T12:31:24 *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has joined #bitcoin-core-dev
2972020-11-26T12:34:21 <wumpus> 0.21.0rc2 binaries up: https://bitcoincore.org/bin/bitcoin-core-0.21.0/test.rc2/
2982020-11-26T12:40:33 *** filchef <filchef!~filchef@212.104.97.177> has joined #bitcoin-core-dev
2992020-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â¦)
3002020-11-26T12:42:33 <fanquake> ð
3012020-11-26T12:45:37 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3022020-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
3032020-11-26T12:45:41 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3042020-11-26T12:49:28 *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
3052020-11-26T12:53:21 *** Tennis <Tennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 272 seconds)
3062020-11-26T13:07:02 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
3072020-11-26T13:13:36 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
3082020-11-26T13:25:35 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
3092020-11-26T13:35:21 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
3102020-11-26T13:36:29 *** jonatack <jonatack!~jon@88.124.242.136> has joined #bitcoin-core-dev
3112020-11-26T13:38:23 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
3122020-11-26T13:40:43 *** jonatack <jonatack!~jon@88.124.242.136> has quit IRC (Ping timeout: 246 seconds)
3132020-11-26T13:41:08 *** jonatack <jonatack!~jon@82.102.27.171> has joined #bitcoin-core-dev
3142020-11-26T13:46:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3152020-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
3162020-11-26T13:46:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3172020-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â¦)
3182020-11-26T13:53:50 *** da39a3ee5e6b4b0d <da39a3ee5e6b4b0d!~da39a3ee5@2403:6200:8876:7ef3:25b7:f5b5:a852:f5c4> has joined #bitcoin-core-dev
3192020-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)
3202020-11-26T13:56:08 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
3212020-11-26T13:59:43 *** vasild_ <vasild_!~vd@gateway/tor-sasl/vasild> has quit IRC (Ping timeout: 240 seconds)
3222020-11-26T14:10:25 *** ossifrage <ossifrage!~ossifrage@unaffiliated/ossifrage> has quit IRC (Ping timeout: 240 seconds)
3232020-11-26T14:11:03 *** rebelution <rebelution!~sam@20.68.25.16> has joined #bitcoin-core-dev
3242020-11-26T14:11:06 <rebelution> luke-jr ------->> [[ You are as grotesque as a disgraceful savage shitload of ineffectual repugnant maggot slime ]] <<-------
3252020-11-26T14:33:05 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
3262020-11-26T14:33:39 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3272020-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
3282020-11-26T14:33:51 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3292020-11-26T14:40:49 *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
3302020-11-26T14:42:56 *** vasild <vasild!~vd@gateway/tor-sasl/vasild> has joined #bitcoin-core-dev
3312020-11-26T14:48:13 *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has joined #bitcoin-core-dev
3322020-11-26T14:54:31 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3332020-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
3342020-11-26T14:54:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3352020-11-26T14:54:40 <vasild> sipa: ^
3362020-11-26T14:56:19 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
3372020-11-26T14:57:05 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has quit IRC (Ping timeout: 240 seconds)
3382020-11-26T15:10:50 *** Klox04809318631 <Klox04809318631!~Klox@c-24-1-131-19.hsd1.il.comcast.net> has joined #bitcoin-core-dev
3392020-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â¦)
3402020-11-26T15:21:26 *** ChanServ sets mode: +o wumpus
3412020-11-26T15:21:28 *** wumpus sets mode: +b *!*@20.68.25.16
3422020-11-26T15:21:35 *** rebelution was kicked by wumpus (rebelution)
3432020-11-26T15:21:41 *** ChanServ sets mode: -o wumpus
3442020-11-26T15:23:19 *** mol <mol!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
3452020-11-26T15:27:10 <luke-jr> any idea why bitcoind crashes at startup in Valgrind? :/
3462020-11-26T15:28:01 <luke-jr> with UBSan*
3472020-11-26T15:30:46 *** ossifrage <ossifrage!~ossifrage@unaffiliated/ossifrage> has joined #bitcoin-core-dev
3482020-11-26T15:31:19 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
3492020-11-26T15:32:48 *** dleffler1 <dleffler1!~dleffler@178.239.168.171> has quit IRC ()
3502020-11-26T15:33:42 *** Kiminuo <Kiminuo!~mix@217.138.199.36> has quit IRC (Ping timeout: 272 seconds)
3512020-11-26T15:36:04 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Quit: pinheadmz)
3522020-11-26T15:41:50 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
3532020-11-26T15:43:25 *** jbarcelo <jbarcelo!43daf305@67.218.243.5> has quit IRC (Ping timeout: 245 seconds)
3542020-11-26T15:46:35 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has quit IRC (Client Quit)
3552020-11-26T15:59:26 *** jMCg <jMCg!~jMCg@195.140.213.38> has joined #bitcoin-core-dev
3562020-11-26T16:03:42 *** mol_ <mol_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
3572020-11-26T16:06:39 *** mol <mol!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 260 seconds)
3582020-11-26T16:07:53 *** molz_ <molz_!~mol@unaffiliated/molly> has joined #bitcoin-core-dev
3592020-11-26T16:11:55 *** mol_ <mol_!~mol@unaffiliated/molly> has quit IRC (Ping timeout: 246 seconds)
3602020-11-26T16:33:51 *** promag <promag!~promag@188.250.84.129> has quit IRC (Remote host closed the connection)
3612020-11-26T16:34:32 *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has quit IRC (Quit: WeeChat 2.3)
3622020-11-26T16:36:23 *** romanz <romanz!~romanz@93.123.196.104.bc.googleusercontent.com> has joined #bitcoin-core-dev
3632020-11-26T16:39:33 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
3642020-11-26T16:45:29 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3652020-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
3662020-11-26T16:45:30 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3672020-11-26T16:49:53 *** RickMortir22 <RickMortir22!~RickMorti@45.135.187.65> has joined #bitcoin-core-dev
3682020-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..."
3692020-11-26T16:52:48 *** pinheadmz <pinheadmz!~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net> has joined #bitcoin-core-dev
3702020-11-26T17:02:48 *** promag <promag!~promag@188.250.84.129> has joined #bitcoin-core-dev
3712020-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â¦)
3722020-11-26T17:10:30 *** RickMortir22 <RickMortir22!~RickMorti@45.135.187.65> has quit IRC ()
3732020-11-26T17:11:45 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3742020-11-26T17:16:18 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
3752020-11-26T17:19:30 <wumpus> luke-jr: no idea, I'm sure valgrind gives some kind of error?
3762020-11-26T17:21:03 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
3772020-11-26T17:21:12 <wumpus> there's sanitizer suppressions for ubsan in fuzz/test/sanitizer_suppressions/ubsan
3782020-11-26T17:25:46 <MarcoFalke> can valgrind run with sanitizers on top, even?
3792020-11-26T17:31:46 <wumpus> that's a good question
3802020-11-26T17:34:57 *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
3812020-11-26T17:40:39 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
3822020-11-26T17:58:28 <sipa> afaik no
3832020-11-26T17:58:42 *** Kiminuo <Kiminuo!~mix@217.138.199.36> has joined #bitcoin-core-dev
3842020-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)
3852020-11-26T18:06:43 *** sr_gi <sr_gi!~sr_gi@80.174.218.168.dyn.user.ono.com> has joined #bitcoin-core-dev
3862020-11-26T18:11:29 <sipa> vasild: yes, that works
3872020-11-26T18:11:47 <glozow> #proposedmeetingtopic package validation design question
3882020-11-26T18:11:50 <sipa> i was working on a fix as part of rebasing the serialization parameters
3892020-11-26T18:11:56 <glozow> is that how u do it
3902020-11-26T18:12:56 <jnewbery> that's exactly how you do it!
3912020-11-26T18:13:20 <glozow> whew, thanks jnewbery
3922020-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â¦)
3932020-11-26T18:16:20 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
3942020-11-26T18:17:36 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
3952020-11-26T18:24:34 <ajonas> #proposedmeetingtopic 2019-20 Coredev survey summary
3962020-11-26T18:30:43 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has quit IRC (Ping timeout: 240 seconds)
3972020-11-26T18:39:24 <sipa> ugh, anchors.dat stores CAddress objects on disk, without file versioning
3982020-11-26T18:39:49 <sipa> this means it doesn't support v2 addresses
3992020-11-26T18:40:43 <jonatack> good catch
4002020-11-26T18:41:15 <sipa> going to open an issue
4012020-11-26T18:50:19 <sipa> glozow: wth is peter wheel? ;)
4022020-11-26T18:53:37 <glozow> sipa: bitcoin gandalf, roams Middle Earth with the hobbitcoins
4032020-11-26T18:59:20 <hebasto> as anchors.dat is a new feature, could it use only v2 addresses?
4042020-11-26T19:00:49 <wumpus> #startmeeting
4052020-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.
4062020-11-26T19:00:50 <core-meetingbot> Available commands: action commands idea info link nick
4072020-11-26T19:00:53 <sipa> hebasto: yes, but what when we introduce v3?
4082020-11-26T19:01:00 <jonasschnelli> hi
4092020-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
4102020-11-26T19:01:06 <kanzure> hi
4112020-11-26T19:01:07 <hebasto> hi
4122020-11-26T19:01:07 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
4132020-11-26T19:01:09 <achow101> today's a us holiday so there may be fewer people
4142020-11-26T19:01:21 <jonatack> hola
4152020-11-26T19:01:34 <glozow> hi
4162020-11-26T19:01:41 <wumpus> congrats on rc2 everyone !
4172020-11-26T19:01:44 <fjahr> hi
4182020-11-26T19:01:45 <jb55> hi
4192020-11-26T19:01:54 <wumpus> achow101: yes, might be a short meeting
4202020-11-26T19:01:54 <sipa> hi
4212020-11-26T19:02:11 <michaelfolkson> Happy Thanksgiving US peeps
4222020-11-26T19:02:11 <ajonas> hi
4232020-11-26T19:02:14 *** satwo <satwo!~textual@209-30-116-174.lightspeed.nsvltn.sbcglobal.net> has joined #bitcoin-core-dev
4242020-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)
4252020-11-26T19:03:18 <wumpus> any any others if people have last minute proposals
4262020-11-26T19:03:46 <wumpus> #topic High priority for review
4272020-11-26T19:03:46 <core-meetingbot> topic: High priority for review
4282020-11-26T19:04:03 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 9 blockers, 2 chasing concept ACK
4292020-11-26T19:04:28 *** satwo <satwo!~textual@209-30-116-174.lightspeed.nsvltn.sbcglobal.net> has quit IRC (Client Quit)
4302020-11-26T19:04:32 <jnewbery> hi
4312020-11-26T19:04:43 <wumpus> anything to add/remote or that is ready for merge?
4322020-11-26T19:04:56 <fjahr> Can we add #19055 to blockers again?
4332020-11-26T19:05:00 <gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
4342020-11-26T19:05:34 <wumpus> fjahr:sure
4352020-11-26T19:05:41 <fjahr> thx
4362020-11-26T19:05:58 <sipa> #20207 should be ready... not really a blocker for me, but would be nice to get in
4372020-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
4382020-11-26T19:06:36 <wumpus> you have nothing else on the list so will add it
4392020-11-26T19:08:04 <wumpus> that concludes the topic I think
4402020-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
4412020-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
4422020-11-26T19:08:45 <wumpus> ok
4432020-11-26T19:08:45 <jonatack> if not, otherwise it can wait
4442020-11-26T19:09:22 *** shesek <shesek!~shesek@unaffiliated/shesek> has quit IRC (Remote host closed the connection)
4452020-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
4462020-11-26T19:09:40 <jonatack> (feeRate is in BTC/kB, fee_rate is in sat/vB)
4472020-11-26T19:10:04 <jonatack> wumpus: as you think best
4482020-11-26T19:10:09 <wumpus> in any case it's in the high prio list now
4492020-11-26T19:11:22 <jonatack> ð
4502020-11-26T19:11:43 <wumpus> oh it's 8 files changes, of which 7 tests and only small changes in a cpp
4512020-11-26T19:12:39 <wumpus> could still be in a rc i guess
4522020-11-26T19:13:09 <wumpus> #topic package validation design question (glozow)
4532020-11-26T19:13:09 <core-meetingbot> topic: package validation design question (glozow)
4542020-11-26T19:13:14 *** bitdex <bitdex!~bitdex@gateway/tor-sasl/bitdex> has joined #bitcoin-core-dev
4552020-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?â
4562020-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.
4572020-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.
4582020-11-26T19:14:26 <glozow> Wondering if people have thoughts/opinions?
4592020-11-26T19:14:48 <sipa> you're basically asking if the whole package would fail, should the behavior sort of automatically retry with subpackages?
4602020-11-26T19:15:03 <sipa> (or be equivalent to that)
4612020-11-26T19:15:14 <glozow> sipa: yeah
4622020-11-26T19:15:34 <sipa> is there a need for that?
4632020-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
4642020-11-26T19:16:06 <sipa> the idea is initially just having this as RPC?
4652020-11-26T19:16:14 <wumpus> yes, P2P clients don't get helpful information back anyway
4662020-11-26T19:16:16 <jnewbery> If there was a sendrawtransactionpackage we'd probably want that to be atomic I think
4672020-11-26T19:16:33 <glozow> yeah, i want to do 1 testmempoolaccept, 2 submit packages through rpc, 3 package relay
4682020-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
4692020-11-26T19:16:55 <sipa> (if ever)
4702020-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
4712020-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
4722020-11-26T19:17:56 <sipa> but i think those are longer term questions
4732020-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
4742020-11-26T19:18:42 <glozow> yes, i'm leaning towards running full checks for each tx until they pass/fail in a testaccept
4752020-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?
4762020-11-26T19:19:16 <wumpus> sipa: right, shouldn't cache all the transactions individually as rejected
4772020-11-26T19:19:51 <glozow> yah good point
4782020-11-26T19:20:32 <michaelfolkson> I guess it depends on whether if there are weird rejection policies out there
4792020-11-26T19:21:00 <glozow> michaelfolkson: what kinds of weird rejection policies?
4802020-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?
4812020-11-26T19:21:17 <glozow> jnewbery: i think we should sort it ourselves
4822020-11-26T19:21:18 <sipa> jnewbery: i'd expect to use dependency ordering
4832020-11-26T19:21:40 <sipa> (first sort by how many parents in the package it has, then by txid)
4842020-11-26T19:21:51 <sipa> on either the sender or the receiver side
4852020-11-26T19:22:00 <michaelfolkson> glozow: I'm trying to think of reasons for a package rejection that isn't clear to the sender
4862020-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)
4872020-11-26T19:22:42 <sipa> if that happens in a leaf of a package
4882020-11-26T19:22:48 <jnewbery> sipa: how many parents or how many ancestors?
4892020-11-26T19:23:02 <sipa> jnewbery: either works
4902020-11-26T19:23:17 <sipa> presumably the receiver still wants the package without that leaf
4912020-11-26T19:23:17 <glozow> would you know how many ancestors without doing a few checks? uh oh
4922020-11-26T19:23:32 <sipa> glozow: that's trivial, i think?
4932020-11-26T19:23:38 <sipa> we do that sorting everywhere
4942020-11-26T19:23:41 <sipa> inside tx messages e.g.
4952020-11-26T19:23:45 <jnewbery> huh? A tx's parent can have more parents in the package than the child, no?
4962020-11-26T19:23:46 <glozow> ah okay cool
4972020-11-26T19:24:19 <sipa> jnewbery: oh sorry i mean you can either use ancestors, or depth
4982020-11-26T19:24:23 <sipa> not # of parents
4992020-11-26T19:24:28 <jnewbery> right
5002020-11-26T19:24:40 <sipa> but i think these are all questions for later
5012020-11-26T19:24:47 <jonatack> glozow: is your concern about a trade-off between resource use/ddos and full atomic validation?
5022020-11-26T19:25:01 <sipa> for now i think, as an RPC it's fine to just try atomically accepting the whole package
5032020-11-26T19:25:08 <michaelfolkson> sipa: Is it possible that post Taproot activation that an unupgraded node would reject Taproot transactions in a package?
5042020-11-26T19:25:19 <sipa> michaelfolkson: they should
5052020-11-26T19:25:31 <sipa> (except there won't be pre-taproot post-package relay nodes :p)
5062020-11-26T19:26:16 <michaelfolkson> sipa hopes
5072020-11-26T19:26:18 <michaelfolkson> haha
5082020-11-26T19:26:35 <sipa> regardless of whether it activates or not
5092020-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.
5102020-11-26T19:27:01 <sipa> policy checks are cheap though
5112020-11-26T19:27:15 <glozow> PolicyScriptChecks?
5122020-11-26T19:27:17 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 272 seconds)
5132020-11-26T19:27:33 <jnewbery> sipa: PolicyScriptChecks are script/sig validation
5142020-11-26T19:27:39 <sipa> oh, ok
5152020-11-26T19:27:44 <sipa> not familiar with that function
5162020-11-26T19:28:05 <michaelfolkson> Why "they should"? What do they have to lose by accepting a anyonecanspend transaction as part of the package?
5172020-11-26T19:28:26 <sipa> michaelfolkson: soft fork safety relies on using transactions the unupgraded networks considers nonstandard
5182020-11-26T19:28:43 <jnewbery> sipa: it's a step in AcceptToMemoryPool
5192020-11-26T19:29:18 <jnewbery> added by sdaftuar when he split it possible to implment package acceptance I believe
5202020-11-26T19:29:30 <sipa> ah
5212020-11-26T19:29:51 <glozow> yeah added in #16400
5222020-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
5232020-11-26T19:30:35 <jnewbery> sipa: so you think the node should always dependency sort packages, both from p2p and rpc?
5242020-11-26T19:30:53 <jnewbery> seems to me that the sender/client should do that?
5252020-11-26T19:31:06 <sipa> jnewbery: yeah, no opening on whose responsibility it should be
5262020-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
5272020-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?
5282020-11-26T19:32:38 <jnewbery> I can see the argument for rpc to accept just a bag of txs and sort it
5292020-11-26T19:32:44 <sipa> glozow: yeah
5302020-11-26T19:32:46 <sipa> jnewbery: yeah
5312020-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?)
5322020-11-26T19:33:13 <sipa> glozow: i'd more think the other way around
5332020-11-26T19:33:22 <wumpus> there's one other, probably short, topic, so no you're not taking up too much time :)
5342020-11-26T19:33:29 <jnewbery> I think sipa is saying make both RPC and P2P atomic
5352020-11-26T19:33:42 <sipa> i'm saying, for now, only do RPC, and make it atomic
5362020-11-26T19:33:51 <sipa> because there is no need for anything else unless someone comes up with a use case
5372020-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
5382020-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
5392020-11-26T19:34:35 <sipa> extra information and being atomic aren't in conflict with each other
5402020-11-26T19:34:50 <sipa> you can report "the package failed... and this is the first problem i encountered, in tx A"
5412020-11-26T19:34:59 <wumpus> right
5422020-11-26T19:35:23 <jnewbery> ah, maybe we haven't described the problem well
5432020-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"
5442020-11-26T19:35:51 <jnewbery> there are many steps in AcceptToMemoryPool: Prechecks, policy checks, consensus checks
5452020-11-26T19:35:56 <sipa> at least that's how i interpreted it
5462020-11-26T19:36:01 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has quit IRC (Ping timeout: 260 seconds)
5472020-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â¦)
5482020-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
5492020-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
5502020-11-26T19:36:35 <sipa> jnewbery: agree
5512020-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?
5522020-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"
5532020-11-26T19:37:34 <sipa> i'd say no - for now - because the package in its entirety isn't acceptable
5542020-11-26T19:38:02 *** EagleTM <EagleTM!~EagleTM@unaffiliated/eagletm> has joined #bitcoin-core-dev
5552020-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
5562020-11-26T19:38:43 <sipa> michaelfolkson: in RPC there is no "sender"
5572020-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?
5582020-11-26T19:39:01 <sipa> and if the user wants that kind of functionality, we should add it
5592020-11-26T19:39:36 <sipa> glozow: is that a big design question that needs to be known up front?
5602020-11-26T19:39:46 <sipa> otherwise i'd just say do the simplest thing first, and iterate
5612020-11-26T19:40:03 *** skyikot <skyikot!~skyikot@gateway/tor-sasl/skyikot> has joined #bitcoin-core-dev
5622020-11-26T19:41:59 <glozow> it does affect the testmempoolaccept API, i'd like as helpful a response as possible if the package fails
5632020-11-26T19:42:27 <sipa> i feel that adding more detailed error reporting later can probably be done in a backward compatible manner
5642020-11-26T19:42:30 *** eugene-ff <eugene-ff!~eugene_ff@2604:2000:1383:472b:243e:c1cc:8b:e45f> has joined #bitcoin-core-dev
5652020-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
5662020-11-26T19:42:53 <glozow> ok, so atomic for now
5672020-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: []"
5682020-11-26T19:43:10 <MarcoFalke> Also, we can't keep policy error messages identical between releases anyway
5692020-11-26T19:43:17 <sipa> MarcoFalke: right
5702020-11-26T19:44:07 <glozow> got it, thanks everyone
5712020-11-26T19:44:37 <wumpus> #topic 2019-20 Coredev survey summary (ajonas)
5722020-11-26T19:44:37 <core-meetingbot> topic: 2019-20 Coredev survey summary (ajonas)
5732020-11-26T19:44:48 <MarcoFalke> glozow: Thanks for working on this!
5742020-11-26T19:44:56 <sipa> absolutely
5752020-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/.
5762020-11-26T19:45:14 <ajonas> No action items. Just want to call it to people's attention.
5772020-11-26T19:45:22 <wumpus> ajonas: awesome!
5782020-11-26T19:45:46 <jnewbery> ajonas: thank you for picking this up
5792020-11-26T19:45:55 <michaelfolkson> For the summary watch the video I guess?
5802020-11-26T19:46:12 <ajonas> the post and the video are about the same
5812020-11-26T19:46:15 <sipa> short note: i just opened #20511, which i think is something to address for 0.21
5822020-11-26T19:46:16 <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
5832020-11-26T19:46:20 <jonatack> ajonas: wow! thanks!
5842020-11-26T19:46:26 <glozow> ajonas: wow cool!!!
5852020-11-26T19:46:34 <sipa> ajonas: thanks for that, will read (and maybe watch)
5862020-11-26T19:46:43 <jonasschnelli> nice!
5872020-11-26T19:46:44 <ajonas> thanks to jnewbery for sending it out and I hope we can do another round in early 2021.
5882020-11-26T19:47:46 <fjahr> ajonas: cool!
5892020-11-26T19:49:41 <wumpus> unless anyone wants to discuss a specific thing from that overview, I think this concludes the meeting
5902020-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
5912020-11-26T19:50:51 <wumpus> yes it's interesting I agree with most of the comments
5922020-11-26T19:51:25 <wumpus> #endmeeting
5932020-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
5942020-11-26T19:51:26 <core-meetingbot> Meeting ended Thu Nov 26 19:51:25 2020 UTC.
5952020-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
5962020-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
5972020-11-26T19:53:34 <MarcoFalke> michaelfolkson: IRC works better than video
5982020-11-26T19:53:54 <sipa> i'm personally not particularly interested in non-in-person coredev
5992020-11-26T19:54:03 <michaelfolkson> Fair enough
6002020-11-26T19:55:29 <michaelfolkson> I think it is IRC < Video < In person for engagement. But IRC definitely most convenient
6012020-11-26T19:58:49 *** luke <luke!~luke@bitnomial/staff/luke> has joined #bitcoin-core-dev
6022020-11-26T20:00:21 <jonatack> same for me as MarcoFalke and sipa ^
6032020-11-26T20:01:53 *** joelklabo <joelklabo!~textual@157-131-101-185.fiber.dynamic.sonic.net> has joined #bitcoin-core-dev
6042020-11-26T20:03:45 <hebasto> ^ same
6052020-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
6062020-11-26T20:18:24 <michaelfolkson> Great video ajonas. Interested in how next year's will compare
6072020-11-26T20:19:33 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
6082020-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
6092020-11-26T20:25:00 <michaelfolkson> And process separation and fuzzing PRs struggle for review
6102020-11-26T20:25:36 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
6112020-11-26T20:36:13 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6122020-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
6132020-11-26T20:36:14 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6142020-11-26T20:40:31 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6152020-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
6162020-11-26T20:40:33 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6172020-11-26T20:46:05 *** Kiminuo <Kiminuo!~mix@217.138.199.36> has quit IRC (Ping timeout: 240 seconds)
6182020-11-26T20:55:01 *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
6192020-11-26T20:58:09 *** luke <luke!~luke@bitnomial/staff/luke> has quit IRC (Quit: sleep)
6202020-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â¦)
6212020-11-26T21:02:48 *** kristapsk_ <kristapsk_!~KK@gateway/tor-sasl/kristapsk> has joined #bitcoin-core-dev
6222020-11-26T21:03:28 *** schmeckin <schmeckin!~schmecks@198.181.163.31> has joined #bitcoin-core-dev
6232020-11-26T21:03:57 *** kristapsk <kristapsk!~KK@gateway/tor-sasl/kristapsk> has quit IRC (Remote host closed the connection)
6242020-11-26T21:06:17 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
6252020-11-26T21:07:05 *** luke-jr <luke-jr!~luke-jr@unaffiliated/luke-jr> has joined #bitcoin-core-dev
6262020-11-26T21:12:10 *** schmeckin <schmeckin!~schmecks@198.181.163.31> has left #bitcoin-core-dev
6272020-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?
6282020-11-26T21:12:48 *** schmeckin <schmeckin!~schmecks@198.181.163.31> has joined #bitcoin-core-dev
6292020-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?
6302020-11-26T21:13:26 <schmeckin> midnight ------->> [[ You are as rotten as a clumsy decaying myriad of smelly bat pus ]] <<-------
6312020-11-26T21:13:30 <schmeckin> luke-jr ------->> [[ You are as noxious as a dirty clumsy accumulation of rotten despicable disgusting cockroach dung ]] <<-------
6322020-11-26T21:13:34 <schmeckin> gmaxwell ------->> [[ You are as hostile as a barren mass of ineffectual bat orifices ]] <<-------
6332020-11-26T21:18:38 *** schmeckin <schmeckin!~schmecks@198.181.163.31> has quit IRC (Quit: Leaving)
6342020-11-26T21:30:34 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
6352020-11-26T21:30:38 *** satwo <satwo!~textual@2600:1700:2d30:5310:a1c8:226c:c134:e878> has joined #bitcoin-core-dev
6362020-11-26T21:34:11 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6372020-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
6382020-11-26T21:34:12 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6392020-11-26T21:36:52 *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Quit: Ping timeout (120 seconds))
6402020-11-26T21:37:11 *** kexkey <kexkey!~kexkey@static-198-54-132-150.cust.tzulo.com> has quit IRC (Ping timeout: 256 seconds)
6412020-11-26T21:37:18 *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
6422020-11-26T21:56:14 *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has quit IRC (Ping timeout: 272 seconds)
6432020-11-26T21:57:23 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has quit IRC (Ping timeout: 272 seconds)
6442020-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â¦)
6452020-11-26T22:01:45 *** lightlike <lightlike!~lightlike@p200300c7ef1bcf00887629e01a1f3407.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
6462020-11-26T22:02:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6472020-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
6482020-11-26T22:02:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6492020-11-26T22:06:21 <luke-jr> wumpus: not a sensible one https://dpaste.com/8KGS42GH5
6502020-11-26T22:08:13 <luke-jr> I mean, if this were correct, it wouldn't matter if it was Valgrind run or not XD
6512020-11-26T22:11:05 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Quit: Pavlenex)
6522020-11-26T22:14:18 <luke-jr> oh lovely, it goes away if I LogPrintf the pointer -.-
6532020-11-26T22:16:58 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
6542020-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
6552020-11-26T22:16:59 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
6562020-11-26T22:17:51 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has joined #bitcoin-core-dev
6572020-11-26T22:21:10 *** Pavlenex <Pavlenex!~Thunderbi@178.220.103.52> has quit IRC (Client Quit)
6582020-11-26T22:24:40 <michaelfolkson> Don't know why the trolls are targeting you today luke-jr. On behalf of humanity I apologize
6592020-11-26T22:26:37 <luke-jr> michaelfolkson: me either :/
6602020-11-26T22:28:52 <sipa> wumpus: qt compiles now, "apt install --reinstall qtbase5-dev" was enough to fix it
6612020-11-26T22:33:48 <luke-jr> O.o
6622020-11-26T22:34:32 <sipa> luke-jr: somehow i was missing libQt5Core.so (i only had .so.5)
6632020-11-26T22:34:58 <luke-jr> weird
6642020-11-26T22:45:04 *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 260 seconds)
6652020-11-26T22:46:52 <luke-jr> hrm, -O0 doesn't crash in Valgrind
6662020-11-26T22:47:12 <luke-jr> not sure this tells me anything
6672020-11-26T22:51:58 <sipa> luke-jr: are you mixing sanitizers and valgrind?
6682020-11-26T22:54:55 <luke-jr> sipa: just ubsan
6692020-11-26T22:55:14 <sipa> that's certainly the least invasive
6702020-11-26T22:58:22 <luke-jr> I suppose I could rebuild without just to see
6712020-11-26T22:58:37 <luke-jr> but if it fails to reproduce, I'm not sure UBSan is at fault even then
6722020-11-26T22:59:54 <luke-jr> LogPrintfs down to FastRandomContext::rand64 leave the crash intact and show non-null ptr
6732020-11-26T23:00:15 <luke-jr> LogPrintfs in FastRandomContext::FillByteBuffer or ChaCha20::Keystream show the same non-null ptr and fix the crash
6742020-11-26T23:00:52 *** Guyver2 <Guyver2!Guyver@guyver2.xs4all.nl> has quit IRC (Quit: Going offline, see ya! (www.adiirc.com))
6752020-11-26T23:01:08 <sipa> luke-jr: i mean... if it were actually trying to write 4 bytes to nullptr, your process would segfault
6762020-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
6772020-11-26T23:02:57 *** gleb <gleb!~gleb@178.150.137.228> has joined #bitcoin-core-dev
6782020-11-26T23:05:45 <luke-jr> sipa: it does segfault :P
6792020-11-26T23:05:56 <luke-jr> inside valgrind*
6802020-11-26T23:06:08 <luke-jr> but not without UBSan
6812020-11-26T23:06:24 <luke-jr> strange
6822020-11-26T23:07:42 <sipa> luke-jr: but does it segfault *with* ubsan, but outside valgrind?
6832020-11-26T23:11:35 <luke-jr> sipa: no
6842020-11-26T23:11:43 <luke-jr> but that could just indicate a timing issuse
6852020-11-26T23:14:07 *** filchef <filchef!~filchef@212.104.97.177> has quit IRC (Read error: Connection reset by peer)
6862020-11-26T23:17:53 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
6872020-11-26T23:18:17 *** gleb3 <gleb3!~gleb@178.150.137.228> has joined #bitcoin-core-dev
6882020-11-26T23:19:33 *** gleb <gleb!~gleb@178.150.137.228> has quit IRC (Ping timeout: 260 seconds)
6892020-11-26T23:19:48 <sipa> luke-jr: could be, indeed
6902020-11-26T23:19:50 *** gleb3 is now known as gleb
6912020-11-26T23:19:51 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has quit IRC (Client Quit)
6922020-11-26T23:20:12 *** jesseposner <jesseposner!~jp@2601:643:8980:bfd2:29df:a2cb:6f55:8d6d> has joined #bitcoin-core-dev
6932020-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â¦)
6942020-11-26T23:35:35 *** justanotheruser <justanotheruser!~justanoth@unaffiliated/justanotheruser> has joined #bitcoin-core-dev
6952020-11-26T23:42:30 <luke-jr> in the meantime, the actual issue I was *trying* to debug, doesn't occur in Valgrind x.x
6962020-11-26T23:44:17 *** MTennis <MTennis!~Tennis@unaffiliated/tennis> has joined #bitcoin-core-dev
6972020-11-26T23:54:39 *** lightlike <lightlike!~lightlike@p200300c7ef1bcf00887629e01a1f3407.dip0.t-ipconnect.de> has quit IRC (Quit: Leaving)
6982020-11-26T23:58:56 *** mrostecki <mrostecki!~mrostecki@gateway/tor-sasl/mrostecki> has quit IRC (Quit: Leaving)
6992020-11-26T23:59:15 *** mrostecki <mrostecki!mrostecki@nat/suse/x-kwnqnqspcazesbuo> has joined #bitcoin-core-dev