--- Log opened Thu Sep 03 00:00:07 2020
00:00 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
00:01 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
00:01 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
00:02 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has joined #bitcoin-core-dev
00:06 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
00:13 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
00:14 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-dev
00:14 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
00:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
00:14 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
00:15 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:1d6c:8e6f:6253:29c7] has quit [Remote host closed the connection]
00:15 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:1d6c:8e6f:6253:29c7] has joined #bitcoin-core-dev
00:20 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:1d6c:8e6f:6253:29c7] has quit [Ping timeout: 244 seconds]
00:27 -!- jeremyrubin [~jr@2601:645:c200:f539:48f9:a6f1:b50:ed18] has quit [Ping timeout: 240 seconds]
00:38 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
00:38 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
00:52 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has joined #bitcoin-core-dev
00:56 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
00:59 < vasild> sipa: gleb: wrt https://github.com/bitcoin/bips/pull/907#issuecomment-686053435 
00:59 < vasild> why "but relay to some extent to the level (2) ones in addition to that" ?
00:59 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #bitcoin-core-dev
01:00 < vasild> why care to relay to (2)?
01:00 < vasild> if (2) guys care/want/need addr messages, they can always ask for it themselves via getaddr, no?
01:06 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Quit: Leaving]
01:08 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds]
01:10 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
01:10 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
01:10 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
01:18 < sipa> vasild: well that's the point, i argue we shouldn't have (2)
01:18 < vasild> I agree
01:19 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection]
01:19 < vasild> I think it should be just two options: "I want" and "I don't want" unasked addr messages
01:19 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
01:20 < vasild> because if it is known that implementations prefer to relay to (3) over (2), or relay more to (3), then a (2) relay has incentive to pretend to be (3)
01:24 < sipa> vasild: my worry is the opposite- an attacker who wants to learn your connectivity could connect many times, as (2)
01:25 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has quit [Read error: Connection reset by peer]
01:25 < sipa> because we'd uniformly relay to all  (3)s, but then in _addition_ still relay to (2) giving them a better than proportional view of our activity
01:25 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
01:26 < sipa> (i'm hypothesizing about how (2) would work here, of course, as it doesn't exist and imho shouldn't exist... but i can't imagine any other useful rhing to do with it)
01:26 < vasild> so, two distinct reasons to have just two options - (1) and (3) ;)
01:26 < sipa> right
01:35 < vasild> From Gleb's email: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-October/017428.html "I want to suggest making explicit whether a node promises to participate in address relay by a) forwarding unsolicited messages (I work on a somewhat related issue in this PR [2]) , and, b) responding to GETADDR."
01:35 < vasild> I have been wondering if those two deserve a separate BIP or should be sneaked into BIP155
01:36 < vasild> that a) should be "I want / I don't want unsolicited addr messages"
01:37 < vasild> and maybe b) deserves a service bit so that nodes that plan to ask GETADDR from their peers can chose to connect only to such peers (rather than discover that the peer they already connected to cannot reply to GETADDR)
01:38 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has quit [Remote host closed the connection]
01:38 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
01:40 < vasild> it would be undesirable to have some SPV client connect-disconnect in a loop until they find a node that can reply to getaddr
01:42 < vasild> Maybe a) can be sneaked into BIP155 as a boolean flag to sendaddrv2 and b) done outside of BIP155 via a service bit?
01:43 -!- andreacab [~andreacab@137.200.107.92.dynamic.wline.res.cust.swisscom.ch] has quit [Ping timeout: 265 seconds]
01:54 -!- jonatack_ [~jon@192.113.14.109.rev.sfr.net] has joined #bitcoin-core-dev
01:59 -!- jonatack_ [~jon@192.113.14.109.rev.sfr.net] has quit [Ping timeout: 264 seconds]
01:59 -!- jonatack_ [~jon@213.152.162.10] has joined #bitcoin-core-dev
02:00 -!- zorun1 [~zorun@195.181.170.239] has quit []
02:03 < sipa> vasild: well is there any software right now that one may xonnect to that can't respond to getaddr?
02:04 < vasild> I am not 100% sure, but I gather that SPV nodes don't keep an addr database, so maybe they are such ones?
02:07 < sipa> you also can't connect to them
02:07 < sipa> they only make outbound connections afaik
02:14 < vasild> hmm, then maybe "b) responding to GETADDR." is not needed? I am not familiar enough to judge, Gleb?
02:19 < gleb> vasild: I think I wanted to emphasize while b) is always true (I guess?), a) is something that may wary. You are right that my sentence has redundancy. It may be reduced to "whether a node promises to participate in forwarding unsolicited messages".
02:21 < vasild> I se
02:21 < vasild> e
02:21 < sipa> f
02:22 < fanquake> g
02:22 -!- furkanmustafa [~furkanmus@77.243.177.38] has joined #bitcoin-core-dev
02:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:32 -!- emzy [~quassel@unaffiliated/emzy] has quit [Remote host closed the connection]
02:34 -!- emzy [~quassel@raspberry.emzy.de] has joined #bitcoin-core-dev
02:51 -!- emzy [~quassel@raspberry.emzy.de] has quit [Changing host]
02:51 -!- emzy [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
02:57 -!- vincenzopalazzo [~vincent@host-79-23-116-18.retail.telecomitalia.it] has quit [Quit: Leaving]
03:11 -!- spinza [~spin@102.132.245.16] has quit [Ping timeout: 240 seconds]
03:22 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:25 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
03:35 < gleb> Does anyone know why we have "Add small amount of random noise before connection to avoid synchronization" when connecting to feelers? There is already a randomized (poisson) interval between creating feelers, so this seems unnecessary?
03:35 < gleb> I privately messaged ethan on irc, but he didn't respond
03:42 < wumpus> #19478 seems close to being mergable
03:42 < gribble> https://github.com/bitcoin/bitcoin/issues/19478 | Remove CTxMempool::mapLinks data structure member by JeremyRubin · Pull Request #19478 · bitcoin/bitcoin · GitHub
03:42 < wumpus> gleb: no, no idea, sorry
03:52 -!- tasaoirse [31258557@49.37.133.87] has joined #bitcoin-core-dev
03:56 -!- tasaoirse [31258557@49.37.133.87] has left #bitcoin-core-dev []
03:58 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
04:01 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
04:27 -!- jonatack_ [~jon@213.152.162.10] has quit [Ping timeout: 260 seconds]
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:29 < bitcoin-git> [bitcoin] laanwj pushed 11 commits to master: https://github.com/bitcoin/bitcoin/compare/68f0ab26bca8...620ac8c47539
04:29 < bitcoin-git> bitcoin/master 8d6ff46 Amiti Uttarwar: scripted-diff: Rename `OUTBOUND` ConnectionType to `OUTBOUND_FULL_RELAY`
04:29 < bitcoin-git> bitcoin/master a6ab1e8 Amiti Uttarwar: [net] Remove unnecessary default args on OpenNetworkConnection
04:29 < bitcoin-git> bitcoin/master dff16b1 Amiti Uttarwar: [refactor] Restructure logic to check for addr relay.
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:29 < bitcoin-git> [bitcoin] laanwj merged pull request #19724: [net] Cleanup connection types- followups  (master...2020-08-conn-refactor-followups) https://github.com/bitcoin/bitcoin/pull/19724
04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:39 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/620ac8c47539...4053de04e239
04:39 < bitcoin-git> bitcoin/master 6de9429 nthumann: qa: Changes v0.17.1 to v0.17.2
04:39 < bitcoin-git> bitcoin/master 4053de0 Wladimir J. van der Laan: Merge #19859: qa: Fixes failing functional test by changing version
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
04:39 < bitcoin-git> [bitcoin] laanwj merged pull request #19859: qa: Fixes failing functional test by changing version (master...qa-fix-wrong-version) https://github.com/bitcoin/bitcoin/pull/19859
04:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:00 -!- furkanmustafa [~furkanmus@77.243.177.38] has quit []
05:10 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
05:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 258 seconds]
05:16 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
05:22 -!- ccallahan1 [~ccallahan@s91904426.blix.com] has joined #bitcoin-core-dev
05:31 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev
05:43 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
05:43 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
05:49 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
06:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
06:07 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:07 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:08 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:08 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:09 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:09 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:11 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:11 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:12 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:12 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:17 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
06:17 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
06:19 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has quit [Remote host closed the connection]
06:19 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has joined #bitcoin-core-dev
06:20 -!- vincenzopalazzo [~vincent@host-79-23-116-18.retail.telecomitalia.it] has joined #bitcoin-core-dev
06:53 -!- ccallahan1 [~ccallahan@s91904426.blix.com] has quit [Remote host closed the connection]
06:53 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
06:54 -!- tralfaz [~tralfaz@94.198.42.233] has joined #bitcoin-core-dev
06:55 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
07:03 -!- aclark1 [~aclark@45.133.193.50] has joined #bitcoin-core-dev
07:15 -!- jonatack_ [~jon@37.170.79.18] has joined #bitcoin-core-dev
07:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
07:25 -!- jeremyrubin [~jr@2601:645:c200:f539:bd11:45e8:9cd8:a7e6] has joined #bitcoin-core-dev
07:29 < sdaftuar> gleb: i had that same question myself recently!  i agree with you that it seems unnecessary
07:30 < sdaftuar> wumpus: i think #19670 is close to mergable as well?  i'm not sure if anyone else is planning to review, but it has a few ACKs and user reports it fixes a bug
07:30 < gribble> https://github.com/bitcoin/bitcoin/issues/19670 | Protect localhost and block-relay-only peers from eviction by sdaftuar · Pull Request #19670 · bitcoin/bitcoin · GitHub
07:43 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
07:43 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
08:00 -!- aclark1 [~aclark@45.133.193.50] has quit []
08:12 -!- Talkless [~Talkless@hst-227-49.splius.lt] has joined #bitcoin-core-dev
08:15 < jonatack_> I was planning to review 19670 once it has test coverage.
08:16 < jonatack_> Or perhaps more data. ATM we only have one user report.
08:17 < jonatack_> The concept does make sense and is interesting.
08:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:21 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/4053de04e239...69a13eb2467a
08:21 < bitcoin-git> bitcoin/master 752e6ad Suhas Daftuar: Protect localhost and block-relay-only peers from eviction
08:21 < bitcoin-git> bitcoin/master 69a13eb Wladimir J. van der Laan: Merge #19670: Protect localhost and block-relay-only peers from eviction
08:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:21 < bitcoin-git> [bitcoin] laanwj merged pull request #19670: Protect localhost and block-relay-only peers from eviction (master...2020-08-improved-eviction) https://github.com/bitcoin/bitcoin/pull/19670
08:21 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:22 -!- carldani1 [~carldani@89.47.234.28] has joined #bitcoin-core-dev
08:24 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:3c87:dabd:ead8:7704] has joined #bitcoin-core-dev
08:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:24 < bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/69a13eb2467a...bd60a9a8edd4
08:24 < bitcoin-git> bitcoin/master 407175e Jon Atack: p2p: change CInv::type from int to uint32_t
08:24 < bitcoin-git> bitcoin/master 7984c39 Jon Atack: test framework: serialize/deserialize inv type as unsigned int
08:24 < bitcoin-git> bitcoin/master bd60a9a Wladimir J. van der Laan: Merge #19818: p2p: change `CInv::type` from `int` to `uint32_t`, fix UBSan...
08:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:24 < bitcoin-git> [bitcoin] laanwj merged pull request #19818: p2p: change `CInv::type` from `int` to `uint32_t`, fix UBSan warning (master...CInv-type-refactoring) https://github.com/bitcoin/bitcoin/pull/19818
08:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:45 -!- jonatack_ [~jon@37.170.79.18] has quit [Ping timeout: 260 seconds]
08:52 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has quit [Ping timeout: 240 seconds]
08:57 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:3c87:dabd:ead8:7704] has quit [Remote host closed the connection]
08:58 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:3c87:dabd:ead8:7704] has joined #bitcoin-core-dev
09:02 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has joined #bitcoin-core-dev
09:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
09:03 -!- andreacab [~andreacab@2a02:120b:2c22:e0c0:3c87:dabd:ead8:7704] has quit [Ping timeout: 260 seconds]
09:03 < achow101> is #19754 RTM?
09:03 < gribble> https://github.com/bitcoin/bitcoin/issues/19754 | wallet, gui: Reload previously loaded wallets on startup by achow101 · Pull Request #19754 · bitcoin/bitcoin · GitHub
09:10 -!- jonatack_ [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
09:12 < jonasschnelli> looks like
09:13 < jonasschnelli> achow101: why is there no functional RPC test?
09:13 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
09:14 < achow101> jonasschnelli: because it's gui?
09:14 < achow101> there's already tests for the RPC side of things
09:14 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
09:14 < jonasschnelli> I see! All clear then.
09:16 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
09:23 -!- tralfaz [~tralfaz@94.198.42.233] has quit [Read error: Connection reset by peer]
09:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:25 < bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bd60a9a8edd4...a0a422c34cfd
09:25 < bitcoin-git> bitcoin/master f1ee373 Andrew Chow: wallet: Reload previously loaded wallets on GUI startup
09:25 < bitcoin-git> bitcoin/master a0a422c Jonas Schnelli: Merge #19754: wallet, gui: Reload previously loaded wallets on startup
09:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:25 < bitcoin-git> [bitcoin] jonasschnelli merged pull request #19754: wallet, gui: Reload previously loaded wallets on startup (master...load-on-start-gui) https://github.com/bitcoin/bitcoin/pull/19754
09:25 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:28 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
09:28 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
09:28 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
09:28 -!- tralfaz [~dulyNoded@94.198.42.233] has joined #bitcoin-core-dev
09:28 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
09:31 < sdaftuar> jonatack_: post-merge review would be welcome as well
09:31 < sdaftuar> thanks!
09:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
09:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 246 seconds]
09:51 -!- jonatack_ [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack_]
09:52 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #bitcoin-core-dev
09:56 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
09:56 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has quit [Quit: pinheadmz]
09:56 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
10:11 -!- lightlike [~lightlike@p200300c7ef1c200028db9d94710dbbbf.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
10:20 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
10:20 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
10:28 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has quit [Ping timeout: 260 seconds]
10:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
10:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
10:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
10:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
10:46 -!- TheRec [~toto@drupal.org/user/146860/view] has quit []
10:47 < moneyball> #proposedmeetingtopic Bitcoin Design Community and efforts around the Bitcoin Core project
10:53 -!- Victor_sueca is now known as Victorsueca
10:58 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 256 seconds]
10:59 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-rxqdoythyokaqdyt] has joined #bitcoin-core-dev
11:00 -!- carldani1 [~carldani@89.47.234.28] has quit []
11:06 -!- EagleTM [~EagleTM@unaffiliated/eagletm] has quit [Ping timeout: 260 seconds]
11:11 -!- Talkless [~Talkless@hst-227-49.splius.lt] has quit [Quit: Konversation terminated!]
11:20 -!- simonbusborg [~simonbusb@84.39.116.180] has joined #bitcoin-core-dev
11:30 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has quit [Remote host closed the connection]
11:31 -!- braydonf [~braydon@gateway/tor-sasl/braydonf] has joined #bitcoin-core-dev
11:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
11:35 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has joined #bitcoin-core-dev
11:36 -!- alko89 [~alko89@unaffiliated/alko89] has quit [Quit: ZNC 1.7.5 - https://znc.in]
11:38 -!- alko89 [~alko89@unaffiliated/alko89] has joined #bitcoin-core-dev
11:39 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
11:40 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Sep  3 19:00:01 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < achow101> hi
12:00 < hebasto> hi
12:00 < sipa> hi
12:00 < jonasschnelli> hi
12:00 < ariard_> hi
12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
12:00 < wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
12:00 < gleb> hi
12:01 < wumpus> two proposed topics for this week: conducting a large scale usage survey (achow101), Bitcoin Design Community and efforts around the Bitcoin Core project (moneyball)
12:01 < amiti> hi 
12:01 < wumpus> any last minute things anyone wants to discuss?
12:01 < aj> hi
12:01 < jonatack> hi
12:01 < moneyball> hi
12:02 < jeremyrubin> hi
12:02 < jb55> hi
12:02 < lightlike> hi
12:02 < ajonas> hi
12:03 < wumpus> #topic High priority for review
12:03 < wumpus> let's start with the usual then
12:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8 10 blockers open, 1 bugfix, 2 chasing concept ACK
12:04 < hebasto> could I nominate #18710 for high-prio
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/18710 | Add local thread pool to CCheckQueue by hebasto · Pull Request #18710 · bitcoin/bitcoin · GitHub
12:04 < wumpus> #19476 seems to be getting close to mergable
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/19476 | rpc: Add mempoolchanges by promag · Pull Request #19476 · bitcoin/bitcoin · GitHub
12:04 < wumpus> sorry #19478
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/19478 | Remove CTxMempool::mapLinks data structure member by JeremyRubin · Pull Request #19478 · bitcoin/bitcoin · GitHub
12:04 < jeremyrubin> I pushed the fixes required :)
12:05 < sipsorcery> hi
12:05 < gleb> Can we add #19697 for now? It not that difficult, but already has 2 acks. Hopefully it enters & leaves high prio quickly :)
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/19697 | Improvements on ADDR caching by naumenkogs · Pull Request #19697 · bitcoin/bitcoin · GitHub
12:05 < wumpus> hebasto: added
12:06 < hebasto> thanks
12:06 < meshcollider> hi
12:07 < wumpus> gleb: added
12:07 < gleb> thank you!
12:08 < wumpus> #19606 also seems close to be able to be merged, but as it is a pretty big backport it would be nice to get a third ack 
12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
12:08 < luke-jr> I didn't review the code, but it is in Knots v0.20.1
12:08 < wumpus> good, at least it already gets some testing then
12:09 < ajonas> is #14895 actually chasing concept ACK?
12:09 < gribble> https://github.com/bitcoin/bitcoin/issues/14895 | Package relay design questions · Issue #14895 · bitcoin/bitcoin · GitHub
12:09 < luke-jr> (well, obviously I did *look at* the code, but not enough to ACK it)
12:09 < ajonas> I'm unclear what that means in this case
12:09 < luke-jr> maybe close enough I should just finish the review tho
12:11 < wumpus> ajonas: I think it's in there mostly to give the discussion there visibility (which is what that colum is for, even if it's not strictly about a concept ACK)
12:11 < ariard_> ajonas: actually we could swap it by #19820 first, as any package relay discussions should fall under this one first IMO
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
12:11 < aj> wumpus: it's been there a long time now, and don't think there's current progress on it (and maybe better served by the p2p meetings for now anyway?)
12:12 < wumpus> I don't mind swapping it with #19820
12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
12:12 < wumpus> if people agree on that
12:13 < aj> sgtm
12:13 < wumpus> ok
12:14 < wumpus> I think we can go on to the other topics
12:14 < wumpus> #topic conducting a large scale usage survey (achow101)
12:14 < achow101> I wanted to get some opinions on the feasibility and usefulness of conducting a usage survey
12:15 < jonasschnelli> smells after a drama maker. :)
12:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:15 < bitcoin-git> [bitcoin] ariard closed pull request #19147: Document discouragement logic with regards to malicious exploitation (master...2020-06-doc-banman-infra) https://github.com/bitcoin/bitcoin/pull/19147
12:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:15 < achow101> the idea for the survey is to get data on how people use Core. particularly, for the wallet, we want to know things like if anyone uses things like zapwallettxes
12:15 < jeremyrubin> I think it's a great idea!
12:15 < jeremyrubin> I've appreciated your twitter questions
12:16 < jeremyrubin> and I've done some similarly; would be cool for it to be a bit more buttoned up with ability to follow up with users
12:16 < moneyball> Square Crypto just announced a user research grant to Jamaal who is an experienced research from OMI and IDEO, to exclusively focus on Bitcoin Core, so it seems like that would be a great person to engage on this
12:16 < jonasschnelli> I think it's a great idea. Unsure how to execute practically
12:16 < wumpus> I was okay with remiving zapwallettxes but I dislike how it seems we're removing all recorvery functionality
12:16 < moneyball> His proposal can be found here https://docs.google.com/document/d/1d8QND6mGHayOAynt1ywZ1mgca1Ghlt1Rkn7l02Jj2IA/edit
12:16 < moneyball> but he is eager to work with Core developers on improving it and making it as impactful as possible
12:16 < wumpus> it's clear such things are useful sometimes even if people don't use them a lot day to day
12:16 < sipa> moneyball: please wait for topic?
12:17 < moneyball> sipa: I am responding to achow's call for a usage survey
12:17 < luke-jr> sipa: this is the topic
12:17 < sipa> oh, oops!
12:17 < moneyball> We now literally have an expert at this :)
12:17 < achow101> wumpus: i'm not necessarily trying to remove recovery functionality
12:17 < ariard_> moneyball: you should ping folks from blockchain commons, IIRC they have thoughts on how to improve core wallet
12:17 < wumpus> in any case, more generally, I don't think doing a survey can hurt
12:18 < achow101> but also I think a survey could also get us some useful data for other things
12:18 < jeremyrubin> I'm not positive that lack of expertise is the issue. E.g., I'm a published HCI author and I know other people have similar expertise. I think the broader issue is coming up with agreement that the results of such a survey would be actionable.
12:19 < nehan> DCI has also been talking to a user research team. I think it can be tricky to design these surveys well, for example so you don't just hear what you want to hear
12:19 < moneyball> Ok let me re-state: we have someone who will be dedicated full-time to this for 6 months, so I encourage anyone interested in shaping and influencing his research to connect with him
12:20 < moneyball> His email is jamaalmonty [at] gmail.com
12:20 < luke-jr> sounds like lots of different people trying to do a survey
12:20 < luke-jr> I suggest they all work together :p
12:20 < jonasschnelli> Just a little warning: some users don't know what they want (especially when it hits the privacy layer).
12:20 < nehan> we have not started anything yet, just offering up information. will ask them to reach out to jamaal!
12:21 < jeremyrubin> achow101: I think maybe what might make sense is to come up with some key issues we want to fix but don't know how to fix.
12:21 < moneyball> nehan: great!!
12:21 < jonasschnelli> Probably also hard to find samples that are representative for "the usergroupe" of Bitcoin Core
12:21 < jeremyrubin> it sounds like wallet recovery is a real issue
12:21 < luke-jr> I don't know we have a reliable way to contact all or even a good sample of users
12:21 < achow101> jeremyrubin: right
12:21 < achow101> the kind of data I'm looking for is more of what things are being used
12:21 < luke-jr> I expect people who read bitcoincore.org, or the announcements list, etc are the same niches
12:22 < achow101> I spoke with Jamaal and he's doing more on user experience stuff which is more subjective
12:22 < jeremyrubin> achow101: you know the whole bullet holes on plane wing issue right?
12:22 < achow101> jeremyrubin: yes
12:22 < jeremyrubin> :)
12:22 < jonasschnelli> Yes. UX and feature uses are two different things
12:22 < luke-jr> a lot of users haven't upgraded since <0.18 still
12:22 < jeremyrubin> I think what might be nice would be to start with a project-wise survey
12:22 < luke-jr> (40%)
12:22 < achow101> But if we're debating whether to remove e.g. zapwallettxes, it would be nice to know whether people use this
12:23 < jeremyrubin> Rather than talking to end-users, start by talking to mid?-users
12:23 < jeremyrubin> e.g., LND, BTCPayServer, Coinbase, etc
12:23 < luke-jr> jeremyrubin: very different kind of users
12:23 < jonasschnelli> achow101: how would you get representative samples to acctually use this as a decision base (to remove zap)?
12:23 < achow101> other data I'm looking for though is number of UTXOs (within orders of magnitudes, not actual numbers), and wallet versions
12:24 < nehan> achow101: is there a list i could share of your questions and thoughts?
12:24 < achow101> jonasschnelli: I think the best we would be able to do is to promote the survey in as many places as possible. like put it on reddit, bitcointalk, twitter, etc.
12:24 < jeremyrubin> luke-jr: that cluster of users is probably just more useful in early on work at having users who can clearly express what they want v.s. end users where the question becomes more of a UX endeavor IMO 
12:24 < achow101> nehan: not yet
12:24 < jonasschnelli> The survey will probably be anonymous. So its super hard to tell wether one person did fill up 10k forms or 10k users filled out one form.
12:24 < luke-jr> jeremyrubin: but they'd also already be opening PRs for what they want
12:24 < jeremyrubin> That's not true
12:24 < sipa> achow101: one issue especially with recovery options is that they're extremely rarely used features to begin with
12:25 < sipa> achow101: and even if 99.99% of users never touch them, they are worthwhile
12:25 < jonasschnelli> There will always be large questionmarks wether the gathered data is useful due to the nature that we don't do CRM
12:25 < achow101> jonasschnelli: yes, that's certainly a problem. I think the best we could do there is to put a captcha and ask people not to be assholes
12:25 < sipa> which means you need an extremely large and representative sample
12:25 < luke-jr> back when I did the KYC poll thing, it matched Twitter polls pretty closely
12:25 < wumpus> sipa: that was also my point, i think a survey is good for some things, but probably not for recovery options
12:25 < luke-jr> so I don't think there's a whole lot of effort into skewing polls
12:26 < sipa> wumpus: agree
12:26 < achow101> wumpus, sipa: I agree that for recovery options, it's not as useful. But asking whether people have heard of the option might be.
12:27 < sipa> achow101: agree
12:27 < jeremyrubin> You can also make a survey only show a follow up if they check a box that they used  it or lost a wallet
12:27 < jeremyrubin> which if you just don't collect enough data on, you ignore it
12:27 < wumpus> if it is about a single option, it's likely better to ask it separately on twitter than do a survey, will reach more people
12:27 < sipa> "How many BTC have you lost due to unrecoverable wallet.dat files?"
12:27 < jeremyrubin> heh
12:28 < achow101> I think there would end up being a lot of questions like "have you heard of X?" followed by "If yes, have you ever used X?"
12:28 < jeremyrubin> achow101: I think we can probably between some set of people also pay to promote the tweet?
12:28 < jeremyrubin> if you want more respondents 
12:28 < luke-jr> inb4 a bunch of lost bitcoins get recovered as a result of said survey
12:28 < nehan> there is also depth vs. breadth: it might be useful to interview 2-3 people who have lost btc to find out what went wrong
12:28 < jeremyrubin> but in my experience polls get very high engagement
12:28 < jeremyrubin> like usually at least 200 ppl
12:29 < jeremyrubin> hey!
12:29 < jonasschnelli> If a survey happens,.. i think the form how it's done (google forms, etc.) and what branding, originator/sender is used, privacy in general, etc. is used if very important to prevent people freaking out
12:29 < jeremyrubin> Lots of people from the MIT Bitcoin Project lost their wallet.dats
12:29 < jeremyrubin> can shoot the participants an email nehan
12:30 < achow101> jonasschnelli: that's definitely a concern. I don't think any existing survey sites don't have tracking
12:30 < achow101> we'd likely have to run something ourselves
12:30 < jonasschnelli> Those details are the reason why I said at the beginning it is probably a "drama maker"
12:30 < jeremyrubin> the issue is that then you bias onto people who will visit mysketchypoll.info vs. google forms :)
12:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
12:31 < achow101> put it on bitcoincore.org
12:31 < jonasschnelli> And I bet some BCH morons will script 10k survey submissions just to show off
12:31 < gwillen> achow101: it's hard to guarantee anything doesn't have tracking, I have suggested to people that they just fill out google forms over Tor if they care a lot
12:31 < achow101> mysketchpoll.bitcoincore.org :)
12:31 < sipa> jeremyrubin: lol, i could have predicted that :)
12:31 < gleb> blinded proof of ownership to participate? :)
12:31 < gwillen> (I guess perhaps some non-google provider might be less likely to give Tor users lots of annoying captchas)
12:32 < wumpus> agree w/ regard to drama maker, especially if you ask about people losing money you have to do with some care
12:32 < gleb> poodle-style construction may help?  not sure, should re-read it
12:32 < jonasschnelli> And maybe you can argue that the most Core powerusers (which we actually want to sample) are generally not filling out surveys.
12:32 < jeremyrubin> I think I'll re-make my suggestion that rather than doing an initial broad scope survey, we should build some experience on a couple smaller scale ones
12:32 < ariard_> gleb: it's 2020, just ask them to pay a LN invoice :p
12:32 < wumpus> at least for a public survery, if you're just going to interview a few people it's less of an issue
12:32 < jeremyrubin> And then leverage that learning for future work
12:32 < achow101> gleb: that would severely bias our sample to people willing to jump through the hoops
12:33 < wumpus> heh, getting reliable statistics in 2020
12:33 < instagibbs> what's the budget for this? :)
12:33 < jonasschnelli> maybe it's best done outside of the core "official" channels (bitcoincore.org) and best put under your own umbrella (achow, twitter, your website)?
12:33 < sipa> put it on the blockchain
12:33 < jonasschnelli> instagibbs: budget is always 0
12:33  * jeremyrubin I lost my wallet.dat because the blocks were too small to upload it.
12:33 < achow101> I could setup a google doc where we discuss what and how to ask questions.
12:33 < instagibbs> jonasschnelli, I am personal friends with survey researchers/professionals :P 
12:34 < nehan> achow101: +1
12:34 < achow101> instagibbs: My budget is like $20
12:34 < jonasschnelli> should be enough for 1m of a VM
12:34 < instagibbs> s/friends/wife/
12:34 < instagibbs> I'll sak her
12:34 < instagibbs> ask
12:35 < jonasschnelli> don't sak her!
12:35 < luke-jr> …
12:35 < luke-jr> instagibbs: you are a survey researcher's wife?
12:35 < jeremyrubin> Those responsible for the survey have been sacked.
12:35 < instagibbs> luke-jr, i no english sorry
12:35 < luke-jr> XD
12:35 < jeremyrubin> Anyways -- I think there's broad conceptually agreement on a survey achow101?
12:35 < achow101> jeremyrubin: welp
12:36 < achow101> yeah, i'll come up with a slightly more concerte proposal
12:36 < jonatack> data point of one: i don't fill out surveys ever
12:36 < jonasschnelli> achow101: thanks!
12:36 < sdaftuar> by induction...
12:36 < jonatack> due to google forms, tracking, etc.
12:36 < jeremyrubin> jonatack: you just answered a survey on taking surveys
12:36 < luke-jr> Sometimes I do if they're quick
12:36 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev
12:36 < jeremyrubin> So I think maybe a good next step would be to make a google doc and just let people add questions they want asked?
12:36 < luke-jr> if they say 15 minutes, I just close it
12:37 < jeremyrubin> Then trim it down into something more concrete
12:37 < achow101> yeah
12:37 < jeremyrubin> if it helps: https://docs.google.com/document/d/1gGP9CmOiM80JmNPiDrTL6dgP6fVVusDuEqYQ9cBJz5E/edit
12:37 < sipa> "This survey will end when block $(($HEIGHT+1)) is found. Good luck!"
12:37 < jeremyrubin> anyone can suggest edit dump questions here
12:37 < instagibbs> luke-jr, 15 minutes is a prety long survey 
12:37 < luke-jr> sipa: lol
12:38 < instagibbs> in paper terms, roughly 15 pages of checkboxes and stuff
12:38 < luke-jr> instagibbs: I wouldn't know, since I don't go through them :P
12:39 < achow101> end of topic I guess
12:40 < wumpus> #topic Bitcoin Design Community and efforts around the Bitcoin Core project (moneyball)
12:40 < moneyball> For context, back in June Square Crypto announced the formation of the Bitcoin Design community https://medium.com/@squarecrypto/bringing-together-the-bitcoin-design-community-b89e5fbe080f
12:40 < moneyball> We had an amazing response with over 500 designers and creatives from around the world joining the community. Some of them have an interest in contributing to the Bitcoin Core project.
12:40 < moneyball> I already mentioned Jamaal's project above which is one touchpoint with the Core project.
12:40 < moneyball> There is also a group of people interested in helping with the GUI design. They've formed a Slack channel #bitcoin-core-gui in the Design Community Slack (http://www.bitcoindesigners.org/). They're also holding biweekly video calls to discuss issues (eg https://github.com/BitcoinDesign/Meta/issues/13).
12:41 < moneyball> An example of improving the GUI is https://github.com/bitcoin-core/gui/issues/81
12:41 < moneyball> If interested, feel free to join these and engage. Note that there is not an expectation Core contributors must join these discussions, and as I state here (https://github.com/bitcoin-core/gui/pull/79#issuecomment-686613427), any formal proposed changes and discussion should occur on GitHub per the existing process.
12:41 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
12:41 < moneyball> I think this is great news to have designers and researchers interested in helping the Core project! I am sure there will be a few areas to improve as we add new types of contributors, so don't be afraid to provide feedback or offer suggestions.
12:41 < moneyball> Comments?
12:41 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
12:41 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
12:42 < luke-jr> moneyball: why can't they use IRC, or at least the existing Core slack?
12:43 < wumpus> moneyball: great to hear
12:43 < jonasschnelli> Yes. Great to hear.
12:43 < moneyball> They could, but most designers are not on IRC, but we are working to get them more comfortable with GitHub, which I think is going well.
12:44 < wumpus> getting people to use IRC is kind of out of scope I think
12:44 < sdaftuar> personally i'm glad we're getting thoughtful newcomers to contribute, sounds great!
12:44 < wumpus> it's got to be more about what is being discussed than where, anyway
12:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
12:45 < jeremyrubin> I think one question I have is the extent to which it makes sense to, assuming we have this massive influx of design talent, to work on the existing GUI or to gut-rennovate it. Not sure what's in scope
12:45 < instagibbs> provided larger scale coordination is done at github level I don't think it should cause many issues
12:45 < jonasschnelli> One first think that pops into my head when I hear designers working on Core: how hard will it be to adapt a flexible design with our native platform Qt approach
12:45 < luke-jr> moneyball: they can join IRC just as easily as joining some new Slack
12:45 < jeremyrubin> jonasschnelli: +1 similar q
12:45 < wumpus> that's why QML was brought up, it's much more flexible in that regard
12:45 < hebasto> jonasschnelli: by moving to QML?
12:46 < jonasschnelli> So whatever comes out of the design process,... implementing it will be a challenge.
12:46 < jonasschnelli> I agree with QML.
12:46 < wumpus> there's only so much you can do with widgets
12:46 < jonasschnelli> Which _is_ hard to switch towards
12:46 < jonasschnelli> Also,... should the GUI still respect color patterns of the OS (dark mode, etc.)?
12:46 < wumpus> someone already did some stuff with QML and bitcoin core in a PR for android
12:47 < hebasto> is it acceptable to have hybrid (widgets + QML) binaries at somepoint?
12:47 < wumpus> #16883
12:47 < gribble> https://github.com/bitcoin/bitcoin/issues/16883 | WIP: Qt: add QML based mobile GUI by icota · Pull Request #16883 · bitcoin/bitcoin · GitHub
12:47 < luke-jr> the GUI low-level design (colours, widgets, etc) should be entirely determined by the OS
12:47 < jonasschnelli> I think QML could be the right direction. Just,... that not an easy step by step transition probably
12:47 < jeremyrubin> How far along is the splitting of wallet process stuff?
12:47 < wumpus> I'm not sure they can be combined in one UI (or whether that makes sense)
12:48 < jonasschnelli> Maybe the design process leads to a new UI...
12:48 < jeremyrubin> Is it feasible that e.g. different GUIs can link to the same intefaces?
12:48 < wumpus> in any case we'd need someone that knows how to use QML
12:48 < sipa> luke-jr: you must hate websites :)
12:48 < wumpus> jonasschnelli: yes, maybe eventually
12:49 < luke-jr> sipa: I used Konqueror as long as it was viable ;)
12:49 < wumpus> I think starting with a "mobile GUI" for core would be good
12:49 < wumpus> just leave the current one for desktop for now
12:49 < jonasschnelli> luke-jr: that would be impossible for designers to work with "(colours, widgets, etc) should be entirely determined by the OS".
12:49 < jeremyrubin> that makes sense to me too; and is something familiar to designers these days (mobile first!)
12:49 < yanmaani> as a user, I really hate QML
12:49 < wumpus> which is also the PR I linked
12:49 < luke-jr> jonasschnelli: then they're bad designers… :/
12:50 < yanmaani> I really like it when it has a native look, like Core or, arguably better, Electrum
12:50 < jonasschnelli> yanmaani: on what platform? Desktop?
12:50 < wumpus> qt widgets is more or less unusable on mobile platforms so it's the first application anyway
12:50 < yanmaani> Monero has a QML gui, and that looks horrible
12:50 < yanmaani> jonasschnelli: yeah
12:50 < yanmaani> mobile is different, but nobody (I hope) runs a full node on their phone
12:50 < luke-jr> yanmaani: does QML mean non-native? :/
12:50 < wumpus> people definitely run full nodes on their phones and tablets these days
12:50 < jonasschnelli> QML means non native widgets
12:50 < yanmaani> luke-jr: Think of QML like knock-off HTML for GUI development
12:50 < yanmaani> Try using the Monero GUI, it looks like a website or something
12:51 < luke-jr> NACK QML then :<
12:51 < wumpus> this is not going to lead anywhere
12:51 < jonasschnelli> QT provides some QML basic widgets. But they don't feel like your OSes widgets. Similar to using web-based applications like slack, etc.
12:51 < yanmaani> I don't have much clout here but I think you should definitely stay native 
12:51 < luke-jr> wumpus: if the direction is bad, best to not follow that lead?
12:52 < jonasschnelli> I guess there are good and bad native desktop apps as they are good and bad QML desktop apps. It probably depends on how it's made
12:52 < luke-jr> jonasschnelli: by definition, if it doesn't use native widgets, it is bad. So if you're saying QML means non-native widgets, they are necessarily all bad?
12:52 -!- SkuMHB [bd21c47b@189.33.196.123] has joined #bitcoin-core-dev
12:52 < sipa> luke-jr: that's your opinion....
12:52 < wumpus> this is not going to lead anywhere? start with a mobile GUI
12:52 < jonasschnelli> luke-jr: that's only your opinion
12:52 < jonasschnelli> agree.
12:52 < moneyball> these are the types of discussions that i'd love to have designers engage with existing Core contributors. discussion on GitHub is one common ground. if there is interest from Core devs to join the biweekly video calls, already hebasto and a few others do, and you're very welcome to that.
12:52 < wumpus> leave the current one for desktop for now
12:53 < jonasschnelli> I just repeat my first answer to this topic: [21:46:00]  <jonasschnelli> So whatever comes out of the design process,... implementing it will be a challenge.
12:53 < sipa> luke-jr: i'd say leave the UI decisions up to those working on it
12:53 < yanmaani> well it is a bit rude to have the designers have their meetings in Slack and Zoom and whatnot
12:53 < wumpus> when it has existed for a while we can at some point maybe look at QML for desktop, but I don't want to make that decision now, at all
12:53 < yanmaani> and then present it, take it or leave it, with some amount of pressure, to the devs
12:53 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
12:53 < wumpus> also, just build whatever you want to build and think is useful, I'm kind of tired of this discussion
12:53 < jeremyrubin> When someone is doing work you aren't paying for you really can't demand it be on your terms
12:53 < instagibbs> yanmaani, I didn't get this at all from the comments
12:53 < yanmaani> it seems like it would make an atmosphere with a bit of bad communication 
12:53 < luke-jr> sipa: I work on UI
12:53 < yanmaani> it seems like it would be better if everyone used the same platform
12:53 < luke-jr> sipa: I also use UI
12:54 < jonasschnelli> we don't have the data points for a decition. Someone need to come up with a live running example
12:54 < sipa> luke-jr: yes, i don't mean to say that excludes you!
12:54 < luke-jr> i c
12:54 < achow101> https://doc.qt.io/qt-5/topics-ui.html#comparison seems to indicate that QML can do the native styling
12:54 < sipa> luke-jr: but i don't think it's something to work out here
12:54 < moneyball> yanmaani: I think you misinterpret. I explicitly said above and in my GitHub comment that I agree with luke-jr, we shouldn't require Core developers to go elsewhere for formal discussion.
12:54 < wumpus> native styling means nothing on mobile platforms anywy, it's fine to start without that
12:55 < yanmaani> native styling, maybe. It's still notorious for being very sluggish, but that might just be a stereotype
12:55 < luke-jr> wumpus: Android doesn't have native widgets? Pretty sure it does
12:55 < jonasschnelli> as for moneyball: I think it is important to tell the designers that the _implementation_ of it will raise tons of questions. Just that they are aware that this project is different to the corporate world.
12:55 < yanmaani> wumpus: Do app GUIs have much in common with desktop GUIs?
12:55 < moneyball> However, there is nothing preventing people from using other mediums to communicate with each other. We shouldn't prevent designers from using, say Figma.
12:55 < wumpus> luke-jr: yes but no one uses them
12:55 < yanmaani> They're all profoundly different platforms
12:55 < luke-jr> wumpus: most apps do in my experience
12:55 -!- SkuMHB [bd21c47b@189.33.196.123] has quit [Remote host closed the connection]
12:55 < yanmaani> moneyball: Right, but then the designers will be discussing without talking to the core devs
12:55 < luke-jr> wumpus: I think the only exception I know of is Pokemon GO
12:55 < wumpus> in any case, qt widgets doesn't really work on android ...
12:56 < luke-jr> ⁇
12:56 < wumpus> qml does
12:56 < yanmaani> I mean, my worry is that you might end up with a website that looks "designed by designers" (see: angular/react monstrosities) but is horribly slow
12:56 < yanmaani> rather than a nice HTML site with a small amount of CSS
12:56 < jonasschnelli> yanmaani: we all share that worry
12:56 < moneyball> yanmaani: There has been effort put forth to have Core devs and designers talking to each other. It is already happening. That said, I'm sure we can improve even more so.
12:56 < yanmaani> uh I mean app
12:56 < yanmaani> not website
12:56 < yanmaani> uh I mean program, not app
12:57 < luke-jr> maybe designers should make image files and coders do the implementation?
12:57 < wumpus> QML is definitely not 'horribly slow'
12:57 < jonasschnelli> the opposite 
12:57 < wumpus> it's very well optimized for animations and such
12:57 < luke-jr> The following list summarizes what you can do with Qt for Android:
12:57 < instagibbs> It's a lost cause to get everyone on IRC, ship sailed a long time ago. Provided typical Github workflow is followed, there's no issue
12:57 < luke-jr> Run Widget-based and QML applications on a device or an emulator.
12:57 < luke-jr> wumpus: ^
12:57 < yanmaani> That seems like a reasonable idea. It would probably make more sense for designers to try and do higher-level stuff
12:57 < yanmaani> things like "is this workflow broken", "does it make sense to order the tabs in this way"
12:57 < wumpus> it's mainly used in kiosks and inflight entertainment and industrial devices etc
12:58 < wumpus> usually some ARM core
12:58 < yanmaani> wumpus: Yeah but compare Monero's GUI to Electrum or whatever
12:58 < hebasto> QML supports hardware acceleration
12:58  * luke-jr would like to see what Bitcoin Core looks like on Android today
12:58 < luke-jr> GUI*
12:58 < yanmaani> It's still extremely big and bloated
12:58 < jeremyrubin> if you get the designers on IRC, they will leave core, and then work on a more pretty IRC client
12:58 < sipa> jeremyrubin: hahaha
12:58 < wumpus> native UI is also 'big and bloated'
12:58 < luke-jr> hebasto: so does widgets…
12:58 < jeremyrubin> so let's keep them focused on the task at hand
12:58 < instagibbs> wait... that sounds great jeremyrubin 
12:58 < luke-jr> jeremyrubin: lol
12:58 < wumpus> did you look at windowing toolkits recently
12:58 < sipa> irc is supposed to be ugly! *plays with beard*
12:58 < instagibbs> everyone should tmux into their IRC machine or log off
12:59 < sipa> instagibbs: screen, ffs
12:59 < hebasto> luke-jr: sure?
12:59 < sdaftuar> instagibbs: i think we call it slack?
12:59 < moneyball> yanmaani: it is unrealistic to have everyone use the same platform. designers use tools like figma. can you imagine if designers demanded developers to use figma instead of git and whatever your favorite editor is?
13:00 < luke-jr> hebasto: yes, it's annoying tbh
13:00 < wumpus> in any case, if the designers don't come up with something better then we can always say no, but I think rejecting any kind of improvement in advance is bad
13:00 < sipa> wumpus: +1
13:00 < jeremyrubin> moneyball: designers should use DCC whiteboard only
13:00 < moneyball> at minimum GitHub will be the common communication platform
13:00 < luke-jr> hebasto: simple GUIs shouldn't need hw acceleration
13:00 < jonasschnelli> wumpus: +1
13:00 < wumpus> this is how you get stuck 
13:00 < yanmaani> moneyball: Sure, but then you end up in a situation where there's almost no communication
13:00 < sdaftuar> it seems presumptuous to tell other volunteers on this project how to work and collaborate with others
13:00 < hebasto> luke-jr: agree
13:00 < jeremyrubin> sdaftuar: +1
13:00 < yanmaani> they just lock themselves in a room and present a design
13:00 < yanmaani> Compare bitcoin.org anno 2011 and today
13:01 < wumpus> yanmaani: please...
13:01 < luke-jr> hebasto: by default, Qt Widgets uses OpenGL
13:01 < moneyball> yanmaani: this is not the intention. i am genuinely reaching out here to find ways to avoid your concern
13:01 < wumpus> meeting time is over
13:01 < jeremyrubin> (btw for anyone connecting over Tor, please do not accept DCC chats -- easy way to dox yourself)
13:01 < sdaftuar> moneyball: thanks for sharing this!
13:01 < wumpus> moneyball: yes, thanks for working on this
13:01 < jonatack> +1
13:01 < jonasschnelli> moneyball: thanks!
13:01 < yanmaani> moneyball: Well, you would want some sort of neutral ground. Like a phpBB forum, or maybe github is good enough.
13:01 < jeremyrubin> excited to see what comes out!
13:02 < yanmaani> And slack or keybase or whatever bridged to IRC
13:02 < instagibbs> achow101, sorry, wife's company only does contracts north of $20k. Can you 1000x your offer?
13:02 < sipa> yanmaani: "neutral ground"? is this a war?
13:02 < sipa> yes, IRC bridging may be useful
13:02 < wumpus> #endmeeting
13:02 < lightningbot> Meeting ended Thu Sep  3 20:02:41 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:02 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-03-19.00.html
13:02 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-03-19.00.txt
13:02 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-03-19.00.log.html
13:02 < jeremyrubin> \o/
13:04 -!- pinheadmz [~pinheadmz@pool-100-33-69-78.nycmny.fios.verizon.net] has joined #bitcoin-core-dev
13:04 < jonasschnelli> |0/
13:05 < instagibbs> yanmaani, as I noted, I think the usual github review flows should be followed. There are a number of IRC channels now for various sub-topics(build systems f.e.) but that doesn't allow sidestep of PR lifecycle
13:05 < instagibbs> so where someone congregates to brainstorm, iterate isn't quite as important
13:05 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
13:05 < yanmaani> I think it's basically a matter of how 'young' the ideas are before being brought up publically to discussion.
13:06 < yanmaani> Too young and you'll be laughed at because it was just idle suggestions. Too old and they'll be solidified and hard to nudge right.
13:06 < instagibbs> that's up to the subgroups to navigate imo
13:07 < sipa> yanmaani: yep
13:08 < achow101> I setup ##bitcoin-core-survey for us to argue about how to do this survey
13:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
13:09 < jeremyrubin> To be fair, this conversation would be *VERY* different if we had a world-class GUI. I think the reality is that while we're good in terms of stability (I think core gui doesn't crash often?) core gui isn't fantastic. Some people are graciously offering to help, and we should encourage them to experiment rather than shackling them to "change it but make it identical to what it is now".
13:10 < jeremyrubin> (I accept some people might feel differently about GUI quality)
13:11 < yanmaani> I think that there's non-contentious stuff that could be done
13:11 < yanmaani> things like "does the big log thing to the right on the main screen really need to be there"
13:11 < jeremyrubin> non-contentious == incremental
13:11 < yanmaani> where a qualified expert designer can offer lots of insightful advice and is sorely needed
13:11 < yanmaani> and contentious stuff, like "let's switch to QML"
13:12 < yanmaani> No, you can have complete overhauls where you completely change the tab structure
13:12 < instagibbs> I'd be surprised if it ended up wholly replacing the GUI any time soon
13:12 < instagibbs> whatever it was
13:12 < yanmaani> Like imagine if they just straight up copied Electrum's layout
13:12 < yanmaani> but kept the Qt, implementation, etc
13:12 < yanmaani> I think it would be more productive to ask questions like "what is the best layout" than "what is the best GUI framework"
13:12 < hebasto> luke-jr: https://forum.qt.io/topic/87509/using-hardware-acceleration-gpu-for-qwidget-paintevent "QWidget doesn't use hardware acceleration"
13:13 < jonatack> Getting designers to use github/gitlab/etc is already asking them to use tools they don't normally use from what I saw on teams at corporates and startups. IRC, fuggetaboutit. Will check out the design channel to meet them halfway.
13:13 < jeremyrubin> yanmaani: I think it's ignorant of existing developers struggling with aspects of qt widgets
13:13 < jeremyrubin> so it's not a problem that's made up just to make new designers happy to use trendy new framework
13:13 < jonatack> *design slack channel
13:13 < wumpus> QML is not a 'trendy new framework' anyway
13:14 < yanmaani> I mean, the basic problem is that you can see Monero using QML
13:14 < wumpus> it has existed virtually as long as bitcoin has
13:14 < yanmaani> and it's not very good
13:14 < jeremyrubin> That's not a problem
13:14 < jeremyrubin> that's like saying
13:14 < wumpus> then we should not copy monery, easy as that
13:14 < jeremyrubin> the problem is craigslist.com uses HTML
13:14 < jeremyrubin> so it's not good for websites 
13:14 < wumpus> just one example of a bad GUI using QML doesn't invalidate the framework 
13:14 < jeremyrubin> (I like craigslist fwiw)
13:14 < yanmaani> If there's a persistent pattern of projects using `X` tending to end up like dumpster fires, that's not a good pattern.
13:15 < hebasto> jonatack: it would be nice if you find opportunity to join calls
13:15 < yanmaani> React/Angular/jQuery have bad reputations
13:15 < wumpus> QML is not those
13:15 < jonatack> hebasto: are they audio or video?
13:15 < hebasto> video
13:15 < wumpus> also even those are used for some well-designed GUIs
13:15 < instagibbs> there are many people who don't give a fig if something is "native" looking fwiw. That's a tiny part of UX
13:16 < wumpus> e.g. jquery is simply a javascript utiltiy framework, it doesnt impose any specific design
13:16 < wumpus> instagibbs: only old people care about that :)
13:16 < yanmaani> it's also very big and bloated, and sites using it tend to have atrocious performance
13:16 < jeremyrubin> +1; there's also an argument for cross platform consistency being good 
13:16 < hebasto> jonatack: https://github.com/BitcoinDesign/Meta/issues/12
13:16 < yanmaani> It's not bad per se for them to be non-native, but it usually correlates strongly to a whole host of pathologies
13:17 < wumpus> yes, they are big and bloated, qml is not though
13:17 < jeremyrubin> yanmaani: you're just to vague and hand wavey here
13:17 < wumpus> yes
13:17 < jeremyrubin> if there's a concrete issue with QML, bring it up
13:17 < wumpus> this isn't going anywhere, you're just complaining for the sake of complaining here
13:17 < yanmaani> Fair point. It usually correlates strongly to GUIs that are sluggish and overly animated.
13:17 < jeremyrubin> but "I don't like how other people use it" isn't the kind of reason that will get you traction here
13:17 < jonatack> hebasto: thanks. at least it's jitsi, not zoom. might try joining in (with my camera off ;)
13:18 < wumpus> if people want to do a QML GUI for bitcoin core, let them
13:18 < yanmaani> With bad latency, and so on. I think that switching the UI framework and redesigning the design are two orthogonal issues
13:18 < hebasto> jonatack: this morning my camera was off too
13:19 < yanmaani> The designers are presumably going to have good layout suggestions like "change the receive tab", not just "bitcoin-qt with a different theme". So I think that it is still going to be useful.
13:19 < wumpus> UI designers tend to not know how to work with qt widgets, so that is off the table
13:19 < instagibbs> hebasto, remind me in a month or so, I'll probably start listening in on calls too
13:19 < wumpus> the idea is to get new people involved here\
13:19 < hebasto> yup
13:20 < jeremyrubin> I think also w.r.t. layout there's going to be other things that come up that are not layout.
13:20 < yanmaani> wumpus: The design work doesn't need any such. You can just draw mockups or whatever and have someone else implement it. You could (presumably) do your mockups in QML just fine, that's true
13:20 < wumpus> no one really knows how to work with qt widgets
13:20 < wumpus> so who is going to do the work then ?
13:21 < yanmaani> Aren't there ordinary developers working on the GUI?
13:21 < sipa> for historic context: the current qt widget ui was originally written by wumpus 
13:21 < wumpus> 'having someone else implement it' doesn't help if no one has the expertise, we're trying to get new people involved
13:21 < wumpus> yes
13:21 < instagibbs> did I mention how much I love the QT 
13:22 < yanmaani> GUI implementation expertise =/= design expertise
13:22 < wumpus> I'm no longer doing that, though
13:22 < instagibbs> I can fudge with stuff in QT, but anything serious I offload to someone else
13:22 < sipa> instagibbs: i think that's how most people feel
13:23 < wumpus> I started very enthousiastically back in the day and just burned out on it, my idea back then was also to get new people involved, but I had overestimated the amount of people in open source that really know how to use (and are good with) qt widgets GUIs
13:23 < hebasto> It seems Qt is focused on QML -- https://www.qt.io/blog/2019/08/07/technical-vision-qt-6
13:23 -!- Guyver2 [Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:23 < jonatack> hebasto: thanks. so iiuc, next call is 2020-09-17 at 0600 UTC https://github.com/BitcoinDesign/Meta/issues/13
13:24 < yanmaani> if you wanted to get really grandiose, you'd try and coordinate with Electrum folks
13:24 < sipa> wumpus: i'd say it was a serious improvement over a pre-release version of wxwidgets :p
13:24 < yanmaani> on how to design (but not build) the best GUI
13:24 < hebasto> jonatack: correct
13:24 < wumpus> sipa: it was! it just got more or less stuck in time
13:25 < jonatack> hebasto: ok, noting in calendar
13:25 < luke-jr> wumpus: Qt Widgets isn't hard..
13:25 < wumpus> fwiw I think the GUI is mostly OK, I do use it myself
13:25 < yanmaani> agreed
13:25 < wumpus> luke-jr: still, there are very few people who want to use it, saying "it is not hard" is easy to say
13:26 < luke-jr> I'm mostly just happy with the current GUI :P
13:26 < yanmaani> it has some warts though, like the receive tab and the payment request system
13:26 < luke-jr> yanmaani: ?
13:26 < jeremyrubin> It's hard to self-evaluate software you've used for a long time. I don't agree with a lot of current design methodology, but there are scientifically rigorous design methodologies e.g. used in the DoD
13:26 < yanmaani> I've never seen anyone in the wild use the URI stuff, just "send bitcoin to address X"
13:26 < wumpus> WELL improve it then
13:26 < wumpus> it's open source
13:26 < wumpus> scratch your own itch
13:26 < wumpus> instead of complaining complaining complaining
13:27 < yanmaani> so it would make more sense to do it like in Electrum - you have a list of addresses, and you can copy them, and see if they're clean.
13:27 < wumpus> I'm tired of this, just figure it out
13:27 < luke-jr> yanmaani: that's what we had before. why would you want that⁇
13:27 < yanmaani> wumpus: the reason I am asking is because I would like to know if others have the same issue
13:27 < jeremyrubin> current design methodology ==> general designers, not specific to core
13:27 < yanmaani> and, clearly they don't
13:28 < luke-jr> the receive tab works great IMO
13:28 < yanmaani> Well, there's one click to get an address. It would be nice if you got one just by opening the tab.
13:29 < wumpus> I'm looking forward to what people come up with QML in any case
13:29 < yanmaani> But if there are good reasons things are as they are, that's obviously a good reason to keep them like they are
13:29 < luke-jr> yanmaani: how will it guess the label you want?
13:30 < yanmaani> It won't
13:30 -!- lightlike [~lightlike@p200300c7ef1c200028db9d94710dbbbf.dip0.t-ipconnect.de] has quit [Quit: Leaving]
13:36 < jeremyrubin> achow101: hey look at this travis log https://api.travis-ci.org/v3/job/723885222/log.txt
13:36 < jeremyrubin> err https://travis-ci.org/github/bitcoin/bitcoin/jobs/723885222
13:36 < jeremyrubin> failure in wallet test, unrelated to PR
13:37 < achow101> possibly related to #19853 ?
13:37 < gribble> https://github.com/bitcoin/bitcoin/issues/19853 | random wallet_basic failure · Issue #19853 · bitcoin/bitcoin · GitHub
13:51 -!- shdx [59cc8785@x59cc8785.dyn.telefonica.de] has joined #bitcoin-core-dev
14:00 -!- simonbusborg [~simonbusb@84.39.116.180] has quit []
14:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
14:11 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
14:12 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
14:21 < phantomcircuit> jeremyrubin, transaction has too long of a mempool chain in a pr changing something about the mempool seems likely related
14:21 < jeremyrubin> I'm fairly certain it's unrelated
14:22 -!- bear1 [~bear@185.163.110.125] has joined #bitcoin-core-dev
14:22 < jeremyrubin> the evidence being that all other tests pass & the change does not impact any "logic", just data structures.
14:23 < jeremyrubin> This type of error can come up in a test if we're not careful with how we generate a txn/children and if we get everything mined at the correct time
14:23 < achow101> it's the 19853 problem. the failures listed there are the same
14:23 < jeremyrubin> even better evidence :)
14:28 < jonatack> yep, saw the same travis ci failure in a couple of PRs reviewed today
14:48 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has quit [Ping timeout: 264 seconds]
14:50 -!- instagibbs [~instagibb@pool-71-178-191-230.washdc.fios.verizon.net] has joined #bitcoin-core-dev
15:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection]
15:26  * luke-jr wonders if it would be bad to alias make='make -j32'
15:29 < sipa> luke-jr: i don't know what the optimal number of build threads is, but for test_runner it's huge (a large multiple of core count for me)
15:29 < luke-jr> sipa: well, I mean the alias itself - will I regret not having -j1 as a default?
15:29 < aj> depends how much memory you have, c++ takes up a fair chunk
15:29 < luke-jr> aj: yeah, -j64 wasn't pretty lol
15:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
15:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
15:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
15:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
15:34 < phantomcircuit> sipa, i've always done -j for the test_runner, on systems with swap it's faster than any limit
15:37 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
15:38 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]
15:44 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
15:44 -!- shdx [59cc8785@x59cc8785.dyn.telefonica.de] has quit [Remote host closed the connection]
15:44 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-rxqdoythyokaqdyt] has quit [Quit: Connection closed for inactivity]
15:52 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
15:53 < yanmaani> If you want it to go faster why not use meson or something?
15:55 < sipa> how does a different build system help with that?
15:56 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
15:59 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
16:00 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #bitcoin-core-dev
16:02 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
16:03 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
16:03 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
16:04 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
16:04 < yanmaani> I've always heard meson was faster
16:04 < yanmaani> But it might just be folklore
16:04 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
16:05 < phantomcircuit> yanmaani, the autotools stuff is slow, but that's because it's single threaded, make itself though is quite fast
16:05 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has quit [Ping timeout: 272 seconds]
16:05 < yanmaani> I guess you're bottlenecked by the compiler here. The real big-brained move would be to have some way to track the memory size, and spawn new gcc/clang instances when the memory util goes below some level
16:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]
16:06 -!- sipsorcery [~sipsorcer@2a02:8084:6981:7880::1e7] has joined #bitcoin-core-dev
16:07 < sipa> yanmaani: every build system has advantages and disadvantages, but replacing one (and all infrastructure we have on top of it) with another would be an enormous effort
16:07 < sipa> (and just adding a new one in addition is unlikely to be acceptable, as it means more maintenance work for all contributors)
16:08 < sipa> also make is super fast, really - the autotools configuring is pretty slow, but that's not the issue here
16:09 < yanmaani> Right, but if you'd have make with some -jAUTO switch, that would be much faster
16:09 < yanmaani> if you're constrained by RAM, then sometimes you can run 20 instances at a time and sometimes barely one
16:10 -!- marcoagner [~user@2001:8a0:6a45:1900:2fd7:e0f0:d356:dd70] has quit [Ping timeout: 244 seconds]
16:10 < sipa> one -j per GB or RAM is my rule of thumb, and not more than your number of cores
16:10 < sipa> works well
16:12 < yanmaani> humans are greedy, they always want more
16:12 < yanmaani> money, fame, power, build performance, it's all the same really
16:21 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
16:21 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
16:23 < luke-jr> sipa: I have 64 GB RAM, so doesn't work well for me :P
16:25 < luke-jr> yanmaani: something like -l I guess
16:25 < phantomcircuit> luke-jr, just get more ram and run everything with -j
16:25 < luke-jr> phantomcircuit: -.-
16:25 < sipa> luke-jr: your ram is inadequate and you should feel inadequate
16:25 < aj> i use -j12 with 16GB and 8 cores, seems to be okay
16:26 < sipa> (i have 32 GiB)
16:26 < yanmaani> luke-jr: like -l but with RAM yes
16:26 < aj> oh, i guess i'm not running a web browser on the computer i compile on, so that probably saves 5000 GB or so of ram
16:27 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
16:27 < yanmaani> and with mechanisms to kill runaway processes and restart them
16:27 < achow101> I use -j32 and I have 64 GB
16:27 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
16:28 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
16:28 < sipa> yanmaani: that sounds very useful
16:28 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
16:28  * sipa volunteers yanmaani to write it
16:29 -!- gzhao408 [uid453516@gateway/web/irccloud.com/x-upikznymqymtlwmr] has joined #bitcoin-core-dev
16:29 < aj> yanmaani: systemd as a build system?
16:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
16:31 < yanmaani> an ounce of googling is worth a pound of dev time
16:32 < dongcarl> aj: Don't give Lennart any new ideas
16:33 -!- opsec_x12 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
16:34 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
16:36 < luke-jr> sipa: and you run -j32?
16:36 < luke-jr> yanmaani: actually, SIGSTOP is useful when you hit swap
16:36 < luke-jr> yanmaani: when/if I do catch myself losing control of RAM, I killall -STOP cc1 and slowly resume them
16:39 < yanmaani> yep, a script to do that and you're all set
16:40 < gzhao408> O commanders of CI, please grant me these restarts... for time, the greatest thief, has marked my PR with the ugly red ❌ https://github.com/bitcoin/bitcoin/pull/19339/checks?check_run_id=1067833523 https://travis-ci.org/github/bitcoin/bitcoin/jobs/723849508 
16:46 < sipa> luke-jr: yes
16:46 < achow101> gzhao408: restarted the travis one. dunno how to restart the cirrus one
16:47 < gzhao408> thank you achow101!  🙏
16:49 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]
16:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:49 < bitcoin-git> [bitcoin] ryanofsky opened pull request #19865: scripted-diff: Restore AssertLockHeld after #19668, remove LockAssertion (master...pr/locka) https://github.com/bitcoin/bitcoin/pull/19865
16:49 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:53 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Remote host closed the connection]
16:53 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
16:56 < fanquake> practicalswift requested #19065 as their high-prio, so I've added that
16:56 < gribble> https://github.com/bitcoin/bitcoin/issues/19065 | tests: Add fuzzing harness for CAddrMan. Fill some fuzzing coverage gaps. by practicalswift · Pull Request #19065 · bitcoin/bitcoin · GitHub
17:00 -!- bear1 [~bear@185.163.110.125] has quit []
17:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
17:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
17:20 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
17:20 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
17:22 -!- ldoguin [~ldoguin@195.181.170.239] has joined #bitcoin-core-dev
17:42 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
18:34 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
18:34 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Ping timeout: 260 seconds]
18:35 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Remote host closed the connection]
18:35 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
18:36 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 260 seconds]
18:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
18:47 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
18:57 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
19:02 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 265 seconds]
19:10 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has joined #bitcoin-core-dev
19:14 -!- Highway61 [~Thunderbi@unaffiliated/highway61] has quit [Client Quit]
19:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 256 seconds]
19:34 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
19:34 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
19:37 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
19:45 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
19:56 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has quit [Ping timeout: 240 seconds]
20:00 -!- ldoguin [~ldoguin@195.181.170.239] has quit []
20:14 -!- IGHOR [~quassel@176.121.4.135] has quit [Quit: No Ping reply in 180 seconds.]
20:18 -!- IGHOR [~quassel@176.121.4.135] has joined #bitcoin-core-dev
20:21 -!- [LE] [~LE]@s91904426.blix.com] has joined #bitcoin-core-dev
20:23 -!- davterra [~davterra@gateway/tor-sasl/tralfaz] has joined #bitcoin-core-dev
20:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:40 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 240 seconds]
20:42 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has quit [Read error: Connection reset by peer]
20:43 -!- Mercury_Vapor [~Mercury_V@174-082-166-092.res.spectrum.com] has joined #bitcoin-core-dev
20:44 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has joined #bitcoin-core-dev
20:44 -!- go121212 [~go1111111@104.156.98.86] has joined #bitcoin-core-dev
20:44 -!- thaumavorio [~thaumavor@thaumavor.io] has quit [Quit: ZNC 1.7.1 - https://znc.in]
20:46 -!- thaumavorio [~thaumavor@thaumavor.io] has joined #bitcoin-core-dev
20:46 -!- go11111111111 [~go1111111@104.156.98.86] has quit [Ping timeout: 240 seconds]
20:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
20:54 < bitcoin-git> [bitcoin] jb55 opened pull request #19866: RFC: eBPF Linux tracepoints (master...usdt-probes) https://github.com/bitcoin/bitcoin/pull/19866
20:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
21:01 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
21:01 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
21:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
21:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
21:14 -!- skyikot [~skyikot@gateway/tor-sasl/skyikot] has quit [Ping timeout: 240 seconds]
21:23 -!- flag [~ppisati@net-188-153-155-31.cust.vodafonedsl.it] has quit [Quit: leaving]
21:26 -!- tralfaz [~dulyNoded@94.198.42.233] has quit [Read error: Connection reset by peer]
21:29 -!- flag [~flag@net-5-94-134-71.cust.vodafonedsl.it] has joined #bitcoin-core-dev
21:49 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 240 seconds]
21:49 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
21:54 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
21:54 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
22:04 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
22:04 -!- shesek [~shesek@164.90.217.137] has joined #bitcoin-core-dev
22:04 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
22:04 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev
22:04 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
22:24 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
22:25 -!- jb551 [~jb55@gateway/tor-sasl/jb55] has joined #bitcoin-core-dev
22:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
23:00 -!- [LE] [~LE]@s91904426.blix.com] has quit []
23:07 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev
23:11 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 240 seconds]
23:20 -!- qrf [~qrf@178.239.168.171] has joined #bitcoin-core-dev
23:31 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has quit [Read error: Connection reset by peer]
23:31 -!- asoltys [~root@s207-81-214-2.bc.hsia.telus.net] has joined #bitcoin-core-dev
23:32 -!- opsec_x122 [~opsec_x12@44-25-143-49.ip.hamwan.net] has joined #bitcoin-core-dev
23:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
23:35 -!- shdx [59cc87da@x59cc87da.dyn.telefonica.de] has joined #bitcoin-core-dev
23:48 -!- marcoagner [~user@bl11-17-219.dsl.telepac.pt] has joined #bitcoin-core-dev
23:57 -!- arowser [~arowser1@204.124.180.72] has quit [Remote host closed the connection]
23:58 -!- arowser [~arowser1@204.124.180.72] has joined #bitcoin-core-dev
23:59 -!- andreacab [~andreacab@12.46.194.178.dynamic.wline.res.cust.swisscom.ch] has joined #bitcoin-core-dev
--- Log closed Fri Sep 04 00:00:08 2020