--- Log opened Thu Sep 05 00:00:01 2019 00:10 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 245 seconds] 00:19 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has quit [Ping timeout: 264 seconds] 00:44 -!- michaelfolkson [~textual@2a02:ed0:530f:9500:12:e248:f61d:de31] has joined #bitcoin-core-dev 00:49 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 00:53 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-dev 00:58 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 01:09 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:13 -!- michaelfolkson [~textual@2a02:ed0:530f:9500:12:e248:f61d:de31] has quit [Ping timeout: 264 seconds] 01:15 -!- coinmonks [6a334ae1@106.51.74.225] has joined #bitcoin-core-dev 01:15 < coinmonks> Hey Michael, My name is gaurav,. I run Coinmonks (https://medium.com/coinmonks) publication.. 01:16 < coinmonks> I also run Coincodecap.com where we track crypto based on their Github activity 01:16 < coinmonks> We started a series "Developers in crypto" .. we want to mention you in our blog.. and we have few question 01:17 < coinmonks> Can you please help us with them? 01:17 < coinmonks> Your background? 01:17 < coinmonks> When and how you get involved in Bitcoin? 01:17 < coinmonks> What are your main contributions on Bitcoin ecosystem? 01:17 < coinmonks> What are new tech innovations you introduced on Bitcoin? 01:17 < coinmonks> Any interesting story you might want to share about contributing on Bitcoin? 01:26 < jouke> What are your private keys? 01:26 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 01:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:34 -!- shesek [~shesek@188.64.207.219] has joined #bitcoin-core-dev 01:34 -!- shesek [~shesek@188.64.207.219] has quit [Changing host] 01:34 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 01:35 < coinmonks> Shit ..I didn't realise I was typing this on general chat :) 01:36 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 01:36 < wumpus> heh 01:42 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 01:43 -!- kcalvina_ [~calvin@222.110.133.193] has joined #bitcoin-core-dev 01:43 -!- kcalvinalvin [~calvin@222.110.133.193] has quit [Read error: Connection reset by peer] 02:00 -!- tomatopotato [~tomatopot@192.145.126.115] has quit [] 02:16 -!- kcalvina_ [~calvin@222.110.133.193] has quit [] 02:16 -!- kcalvinalvin [~calvin@222.110.133.193] has joined #bitcoin-core-dev 02:16 -!- michaelfolkson [~textual@188.64.206.231] has joined #bitcoin-core-dev 02:17 -!- ranman1 [~ranman@89.238.178.75] has joined #bitcoin-core-dev 02:27 -!- michaelfolkson [~textual@188.64.206.231] has quit [Quit: Sleep mode] 02:29 -!- michaelfolkson [~textual@188.64.206.231] has joined #bitcoin-core-dev 02:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host] 02:37 -!- michaelfolkson [~textual@188.64.206.231] has quit [Quit: Sleep mode] 02:42 -!- lightlike [~lightlike@2001:16b8:571d:4f00:c084:9795:3807:6a25] has joined #bitcoin-core-dev 02:42 -!- michaelfolkson [~textual@188.64.206.231] has joined #bitcoin-core-dev 02:44 -!- kcalvinalvin [~calvin@222.110.133.193] has quit [Ping timeout: 268 seconds] 02:51 -!- michaelfolkson [~textual@188.64.206.231] has quit [Quit: Sleep mode] 02:51 -!- michaelfolkson [~textual@188.64.206.231] has joined #bitcoin-core-dev 02:57 -!- michaelfolkson [~textual@188.64.206.231] has quit [Quit: Sleep mode] 02:58 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 03:07 -!- michaelfolkson [~textual@188.64.206.231] has joined #bitcoin-core-dev 03:15 -!- michaelfolkson [~textual@188.64.206.231] has quit [Quit: Textual IRC Client: www.textualapp.com] 03:31 -!- ccdle12 [~ccdle12@static-84-9-17-116.vodafonexdsl.co.uk] has joined #bitcoin-core-dev 03:47 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 03:47 -!- davec [~davec@cpe-24-243-230-10.hot.res.rr.com] has quit [Ping timeout: 245 seconds] 03:48 < coinmonks> anyone from India here? 03:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 03:50 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16806: doc: Add issue templates for bug and feature request (master...master) https://github.com/bitcoin/bitcoin/pull/16806 03:50 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 03:55 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 03:56 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host] 04:14 -!- ccdle12 [~ccdle12@static-84-9-17-116.vodafonexdsl.co.uk] has quit [Remote host closed the connection] 04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:29 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/45be44cce4fa...cbde2bc80674 04:29 < bitcoin-git> bitcoin/master fae91a0 MarcoFalke: test: Remove incorrect and unused try-block in assert_debug_log 04:29 < bitcoin-git> bitcoin/master cbde2bc Wladimir J. van der Laan: Merge #16804: test: Remove unused try-block in assert_debug_log 04:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:30 < bitcoin-git> [bitcoin] laanwj merged pull request #16804: test: Remove unused try-block in assert_debug_log (master...1909-testFix) https://github.com/bitcoin/bitcoin/pull/16804 04:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:31 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cbde2bc80674...5667b0d758f1 04:31 < bitcoin-git> bitcoin/master 2457aea Samuel Dobson: Assert that the HRP is lowercase in Bech32::Encode 04:31 < bitcoin-git> bitcoin/master 5667b0d Wladimir J. van der Laan: Merge #16792: Assert that the HRP is lowercase in Bech32::Encode 04:31 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 04:32 < bitcoin-git> [bitcoin] laanwj merged pull request #16792: Assert that the HRP is lowercase in Bech32::Encode (master...201909_bech32_hrp_check) https://github.com/bitcoin/bitcoin/pull/16792 04:32 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 04:32 -!- Highway61 [~Thunderbi@ip184-186-21-239.no.no.cox.net] has joined #bitcoin-core-dev 04:38 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 04:40 -!- coinmonks [6a334ae1@106.51.74.225] has quit [Remote host closed the connection] 04:57 -!- davec [~davec@cpe-24-243-230-10.hot.res.rr.com] has joined #bitcoin-core-dev 05:00 -!- ranman1 [~ranman@89.238.178.75] has quit [] 05:11 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Remote host closed the connection] 05:12 -!- davec [~davec@cpe-24-243-230-10.hot.res.rr.com] has quit [Ping timeout: 245 seconds] 05:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:13 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev 05:17 -!- andrea5 [~andrea@89.238.178.75] has joined #bitcoin-core-dev 05:20 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: harrigan] 05:23 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #bitcoin-core-dev 05:32 -!- promag [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 05:46 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Quit: harrigan] 06:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:15 < bitcoin-git> [bitcoin] meshcollider opened pull request #16807: Let validateaddress locate error in Bech32 address (master...201909_bech32_error_detection) https://github.com/bitcoin/bitcoin/pull/16807 06:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:19 -!- emilengler_ [~emilengle@unaffiliated/emilengler] has quit [Quit: ZNC 1.7.2+deb3 - https://znc.in] 06:22 -!- davec [~davec@cpe-24-243-230-10.hot.res.rr.com] has joined #bitcoin-core-dev 06:28 -!- pbase [~pbase@unaffiliated/pbase] has joined #bitcoin-core-dev 06:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:29 < bitcoin-git> [bitcoin] meshcollider pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/5667b0d758f1...5e202382a987 06:29 < bitcoin-git> bitcoin/master a31be09 Antoine Riard: Encapsulate tx status in a Confirmation struct 06:29 < bitcoin-git> bitcoin/master 7e89994 Antoine Riard: Remove SyncTransaction for conflicted txn in CWallet::BlockConnected 06:29 < bitcoin-git> bitcoin/master 40ede99 Antoine Riard: Modify wallet tx status if has been reorged out 06:29 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 06:30 < bitcoin-git> [bitcoin] meshcollider merged pull request #16624: wallet: encapsulate transactions state (master...2019-08-encapsulate-tx-state) https://github.com/bitcoin/bitcoin/pull/16624 06:30 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 06:35 < meshcollider> review beg for #15450 06:35 < gribble> https://github.com/bitcoin/bitcoin/issues/15450 | gui: Create wallet menu option by achow101 · Pull Request #15450 · bitcoin/bitcoin · GitHub 06:36 < meshcollider> its already on high priority list 06:37 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-dev 06:40 < meshcollider> I'd like to merge it tomorrow but it'd be great to have at least one more review or tester 06:53 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 06:56 < jnewbery> #proposedmeetingtopic: review/merge #16704 or #16713 to remove worrying "unknown new rules activated (versionbit 1)" warning 06:56 < gribble> https://github.com/bitcoin/bitcoin/issues/16704 | Dont warn about activated buried BIP 9 deployments by achow101 · Pull Request #16704 · bitcoin/bitcoin · GitHub 06:56 < gribble> https://github.com/bitcoin/bitcoin/issues/16713 | logging: Redefine CSV and segwit deployments to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 06:58 -!- Highway61 [~Thunderbi@ip184-186-21-239.no.no.cox.net] has quit [Remote host closed the connection] 06:59 -!- Highway61 [~Thunderbi@ip184-186-21-239.no.no.cox.net] has joined #bitcoin-core-dev 07:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 244 seconds] 07:04 -!- nullptr| [~nullptr|@ip-94-112-129-192.net.upcbroadband.cz] has quit [Ping timeout: 244 seconds] 07:05 -!- nullptr| [~nullptr|@ip-94-112-129-192.net.upcbroadband.cz] has joined #bitcoin-core-dev 07:09 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 07:11 < fanquake> meshcollider: just make sure you check/close/merge the base PR as well. I assume it’s still the same in create wallet. Has 1 ACK I think. 07:13 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 07:15 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 07:16 -!- astro [~astro@gateway/tor-sasl/astro] has quit [Remote host closed the connection] 07:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has quit [Remote host closed the connection] 07:16 < meshcollider> fanquake: I see yeah, why is the base PR not on the high priority list as well/instead? 07:16 -!- astro [~astro@gateway/tor-sasl/astro] has joined #bitcoin-core-dev 07:16 -!- mryandao [~mryandao@gateway/tor-sasl/mryandao] has joined #bitcoin-core-dev 07:17 < fanquake> meshcollider: it is 07:17 < fanquake> #16261 07:17 < gribble> https://github.com/bitcoin/bitcoin/issues/16261 | gui: Refactor OpenWalletActivity by promag · Pull Request #16261 · bitcoin/bitcoin · GitHub 07:18 < meshcollider> Oh I totally missed that, sorry 07:18 < meshcollider> Yeah I saw the PR just didn't see it on the list for some reason 07:23 -!- pinheadmz [~matthewzi@209.58.139.210] has joined #bitcoin-core-dev 07:43 < aj> jnewbery: https://github.com/ajtowns/bitcoin/commits/201909-unknown-softforks -- i would've thought something like that would make more sense than reinstating csv/segwit into vDeployments? 07:43 < aj> jnewbery: (also, shorter :) 07:45 < jnewbery> aj: looks good to me! 07:46 < aj> jnewbery: if you like it, put a PR on it? :) 07:47 < aj> jnewbery: i mean, feel free to merge it into your PR :) 08:00 -!- andrea5 [~andrea@89.238.178.75] has quit [] 08:01 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 08:02 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 08:10 -!- behradkhodayar [~behrad@62.74.217.215] has joined #bitcoin-core-dev 08:12 -!- pbase [~pbase@unaffiliated/pbase] has quit [Quit: Leaving] 08:13 < jnewbery> aj: testing now 08:17 -!- Velociraptor1 [~Velocirap@185.169.255.76] has joined #bitcoin-core-dev 08:21 < aj> jnewbery: thinking about it, could just set it to 0 for regtest (since no historical versionbit stuff for segwit etc needed there); which means it could be set straight after the buried heights not after -segwitheight is worked out 08:41 -!- alko [~alko@BSN-77-147-172.static.siol.net] has quit [Quit: Konversation terminated!] 08:43 -!- alko [~alko@BSN-77-147-172.static.siol.net] has joined #bitcoin-core-dev 08:43 -!- alko [~alko@BSN-77-147-172.static.siol.net] has quit [Client Quit] 08:44 < jonatack> meshcollider: re-reviewing #15450 now 08:44 < gribble> https://github.com/bitcoin/bitcoin/issues/15450 | gui: Create wallet menu option by achow101 · Pull Request #15450 · bitcoin/bitcoin · GitHub 08:44 -!- alko [~alko@BSN-77-147-172.static.siol.net] has joined #bitcoin-core-dev 08:53 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 08:57 -!- behradkhodayar [~behrad@62.74.217.215] has quit [Ping timeout: 246 seconds] 08:58 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 09:00 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 09:03 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 09:07 < stevenroose> Is there already a C++ implementation of the taproot tagged hashes? I'm looking for some example values to test an implementation against. 09:12 < sipa> stevenroose: sure, https://github.com/sipa/bitcoin/blob/taproot/src/script/interpreter.cpp#L1324L1331 09:12 < sipa> note that nothing about taproot is final 09:12 < sipa> (or even guaranteed to make it in) 09:18 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 09:19 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 09:20 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 244 seconds] 09:21 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has joined #bitcoin-core-dev 09:26 < stevenroose> sipa: I realize, but it doesn't hurt to start experimenting with some implementation already :) 09:26 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has quit [Ping timeout: 258 seconds] 09:28 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 09:30 < sipa> of course 09:34 -!- DougieBot5000 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev 09:35 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 09:36 -!- Highway61 [~Thunderbi@ip184-186-21-239.no.no.cox.net] has quit [Remote host closed the connection] 09:37 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 09:46 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 09:49 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 09:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:52 -!- Highway61 [~Thunderbi@ip184-186-21-239.no.no.cox.net] has joined #bitcoin-core-dev 09:53 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Ping timeout: 245 seconds] 09:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 10:00 -!- promag [~promag@2.80.22.20] has joined #bitcoin-core-dev 10:04 -!- promag [~promag@2.80.22.20] has quit [Read error: No route to host] 10:05 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:08 < fjahr> I would like to ask for feedback on my proposal for a rolling UTXO set hash (originally proposed by sipa) at the meeting today. If possible please take a look at my write up: https://gist.github.com/fjahr/fa4892874b090d3a4f4fccc5bafa0210 10:09 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 10:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 10:16 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 10:19 < fjahr> #proposedmeetingtopic Rolling UTXO set hash 10:22 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection] 10:23 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:24 -!- mdunnio [~mdunnio@208.59.170.5] has joined #bitcoin-core-dev 10:28 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 246 seconds] 10:32 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has joined #bitcoin-core-dev 10:32 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 10:34 < achow101> #proposedmeetingtopic avoid loading every wallet transaction into memory 10:37 -!- promag [~promag@bl19-22-20.dsl.telepac.pt] has quit [Ping timeout: 268 seconds] 10:41 < sipa> fjahr: cool! 10:58 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has quit [Read error: Connection reset by peer] 10:58 < jnewbery> aj: done: #16713 10:58 < gribble> https://github.com/bitcoin/bitcoin/issues/16713 | logging: Redefine CSV and segwit deployments to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 10:59 < jnewbery> thanks 10:59 -!- pinheadmz [~matthewzi@209.58.139.210] has quit [Ping timeout: 244 seconds] 10:59 -!- Skirmant [~Skirmant@78-62-14-181.static.zebra.lt] has joined #bitcoin-core-dev 11:00 -!- Velociraptor1 [~Velocirap@185.169.255.76] has quit [] 11:00 < instagibbs> any trick to these travis timeouts im seeing 11:00 < instagibbs> 10 minutes no output 11:00 < sipa> yeah i'm seeing it too 11:02 < instagibbs> I used to get these with some secp-zkp stress tests on 32 bit arch, first time seeing them anywhere else really :( 11:04 < BlueMatt> last-ditch attempt at https://github.com/bitcoin/bitcoin/pull/16421 for 0.19....already has 2.5 acks.... 11:11 -!- foobar17 [424164fe@cpe-66-65-100-254.nyc.res.rr.com] has joined #bitcoin-core-dev 11:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:12 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #16704: Don't warn about activated buried BIP 9 deployments (master...buried-versionbits-cache) https://github.com/bitcoin/bitcoin/pull/16704 11:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:17 -!- total1ty [~total1ty@185.204.1.185] has joined #bitcoin-core-dev 11:22 < sipa> i don't understand this appveyor error: 11:22 < sipa> c:\projects\bitcoin\src\script\miniscript.cpp(274): error C2220: warning treated as error - no 'object' file generated [C:\projects\bitcoin\build_msvc\libbitcoin_common\libbitcoin_common.vcxproj] 11:22 < sipa> 6>c:\projects\bitcoin\src\script\miniscript.cpp(274): warning C4101: 'error': unreferenced local variable [C:\projects\bitcoin\build_msvc\libbitcoin_common\libbitcoin_common.vcxproj] 11:23 < sipa> it'd be nice to know what variable is unreferenced 11:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:24 < bitcoin-git> [bitcoin] GChuf opened pull request #16808: GUI: fix and stylize language list (master...translation-list-fix) https://github.com/bitcoin/bitcoin/pull/16808 11:24 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:26 < MarcoFalke> the travis timeouts when running apt update in docker are known for months 11:26 < MarcoFalke> I have a ticket open with them, but no real reply or solution 11:26 < sipa> seems i haven't been submitting many PRs lately :) 11:27 < MarcoFalke> Sometimes the warnings don't come for a week or two, but at some point they are back .. 11:28 < MarcoFalke> sipa: The variable is literally 'error': https://github.com/bitcoin/bitcoin/pull/16800/files#diff-2ce6275a6ed9764e6d2917e4bca2d587R274 11:29 < MarcoFalke> I think you can fix it by removing ' error' from that line 11:29 < sipa> huh 11:29 < sipa> oops, i was looking in the wrong branch :( 11:29 < sipa> thanks 11:30 -!- xzytrewq [~quassel@64.44.80.92] has quit [Ping timeout: 245 seconds] 11:33 -!- xzytrewq [~quassel@64.44.80.92] has joined #bitcoin-core-dev 11:36 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 245 seconds] 11:36 < jb55> I might have missed the convo but has anyone looked at github actions for builds? 11:37 < sipa> yes 11:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:39 < bitcoin-git> [bitcoin] dongcarl opened pull request #16809: depends: zlib: Move toolchain options to configure (master...2019-09-improve-zlib-pkg) https://github.com/bitcoin/bitcoin/pull/16809 11:39 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:40 < dongcarl> jb55: I believe MarcoFalke talked about it a little on #bitcoin-builds, don't remember exactly but you could search the logs 11:42 -!- owowo [~ovovo@s91904426.blix.com] has joined #bitcoin-core-dev 11:42 -!- owowo [~ovovo@s91904426.blix.com] has quit [Changing host] 11:42 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 11:48 -!- xzytrewq [~quassel@64.44.80.92] has quit [Ping timeout: 268 seconds] 11:51 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 11:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 11:53 < MarcoFalke> github actions is in beta and does not accomodate our use-case (for now) 11:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 11:54 < bitcoin-git> [bitcoin] dongcarl opened pull request #16810: guix: Remove ssp spec file hack (master...2019-09-guix-remove-ssp-spec) https://github.com/bitcoin/bitcoin/pull/16810 11:54 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 11:56 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 276 seconds] 12:00 -!- mdunnio [~mdunnio@208.59.170.5] has quit [Remote host closed the connection] 12:01 < achow101> meeting? 12:01 < wumpus> #startmeeting 12:01 < sipa> meeting? 12:01 < lightningbot> Meeting started Thu Sep 5 19:01:14 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:01 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:01 < jonasschnelli> hi 12:01 < sipa> hi 12:01 < achow101> hi 12:01 < aj> hola 12:01 < MarcoFalke> hoy 12:01 < meshcollider> hi 12:02 < moneyball> hi 12:02 -!- Kvaciral [~Kvaciral@94-214-185-162.cable.dynamic.v4.ziggo.nl] has joined #bitcoin-core-dev 12:02 -!- iamtimmarchant [~iamtimmar@2600:380:6543:c82e:f4fe:38d6:8460:e87b] has joined #bitcoin-core-dev 12:02 < instagibbs> hi 12:02 < wumpus> there are three proposed topics in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a 12:02 < wumpus> - proposed by jnewbery: review/merge #16704 or #16713 to remove worrying "unknown new rules activated (versionbit 1)" warning 12:02 < wumpus> - proposed by fjahr: Rolling UTXO set hash 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/16704 | Dont warn about activated buried BIP 9 deployments by achow101 · Pull Request #16704 · bitcoin/bitcoin · GitHub 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 12:02 < wumpus> - proposed by achow101: avoid loading every wallet transaction into memory 12:02 < jeremyrubin> hi 12:02 < fjahr> hi 12:02 < jonatack> hi 12:03 < 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 12:03 < wumpus> but let's start with the usual 12:03 < wumpus> #topic High priority for review 12:04 < wumpus> 7 blockers, 7 things chasing concept ACK https://github.com/bitcoin/bitcoin/projects/8 12:04 < gleb> hi 12:04 < BlueMatt> I think its already there, but https://github.com/bitcoin/bitcoin/pull/16421 is close to landing and I still really want it for 19 12:04 < wumpus> note that the feature freeze for 0.19 is in 10 days 12:04 < BlueMatt> (and its a small diff!) 12:04 < wumpus> so we likely want to prioritize features that are close to ready now 12:04 < wumpus> right 12:05 < wumpus> would be nice if that makes it in 12:05 < gleb> #16702 is done code-wise (I think), but perhaps it's suboptimal to add it to high prio at this point when we're close to the feature freeze. 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/16702 | p2p: supplying and using asmap to improve IP bucketing in addrman by naumenkogs · Pull Request #16702 · bitcoin/bitcoin · GitHub 12:05 < wumpus> also #15759 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar · Pull Request #15759 · bitcoin/bitcoin · GitHub 12:06 < wumpus> gleb: yes, we might want to keep that for 0.20 12:07 < wumpus> also requires too much review to still make it to 0.19 anyway 12:07 < wumpus> still, great to hear you're making progress! 12:08 < sipa> yeah, that sounds like too close to make it 12:08 < jeremyrubin> Not super critical, and it's relatively new so not much time for review, but would help me to get #16766 as my work on OP_SECURETHEBAG wallet support depends on it 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/16766 | wallet: Make IsTrusted scan parents recursively by JeremyRubin · Pull Request #16766 · bitcoin/bitcoin · GitHub 12:08 < sipa> i'll review 15759 again 12:08 < BlueMatt> 16702 is probably a bit far review-wise, though it would be nice, but 15759 is also really close and should god 12:08 < jeremyrubin> And I think it is a bug 12:09 < sipa> bug fixes can go after the feature freeze 12:10 < wumpus> yes 12:10 < jeremyrubin> wasn't sure as it's a substantial behavior change for wallet, but fine :) 12:10 < wumpus> they can go any time ("scan parents recursively" sounds scary to me though, performance wise :) 12:11 < sipa> it's cached to avoid exponential blowup 12:11 < sipa> but otherwise, yeah 12:11 < instagibbs> also depends on how new the bug is. I *think* it's ancient behavior that "normally" never hits 12:11 < wumpus> phew 12:11 < instagibbs> anyways 12:11 < sipa> instagibbs: agree 12:12 < jeremyrubin> instagibbs: I think that is correct 12:12 < instagibbs> with fancier wallet setups we may actually hit it :) 12:12 < wumpus> anyhow I've added it to high priority for review as requested, people can choose for themselves what to review 12:13 < wumpus> #topic remove worrying "unknown new rules activated (versionbit 1)" warning (jnewbery) 12:13 < wumpus> yes please 12:13 < wumpus> so I guess the disussion is: #16704 or #16713 12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/16704 | Dont warn about activated buried BIP 9 deployments by achow101 · Pull Request #16704 · bitcoin/bitcoin · GitHub 12:13 < gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 12:14 < achow101> 16713 is the simpler, easier to review fix 12:14 < achow101> But I think it would be better to eventually get rid of these deployment parameters and have a more permanent solution that lets us reuse bits in the future 12:15 < wumpus> what disadvantages does it have compared to the other one? 12:15 < MarcoFalke> bits can be reused as long as they don't overlap in time 12:15 < aj> 16713 is updated as of a few hours to be even simpler; i think it lets us reuse bits fine? 12:15 < wumpus> e.g. why are there two open at all? 12:16 < wumpus> MarcoFalke: yup 12:16 < MarcoFalke> I already closed the one by achow101 *hides* 12:16 < aj> MarcoFalke: smooth 12:17 < wumpus> ok, that concludes the discussion then I guess :) 12:17 < achow101> my understanding of how consensus.vDeployments worked was that you couldn't define two forks with the same bit since they'd have to occupy the same index position and that's not possible 12:17 < wumpus> oh 12:17 < achow101> but 16713 has changed since I last reviewed it and it looks very different 12:17 < wumpus> sorry 12:18 < MarcoFalke> oh, maybe you are right when it comes to the implementation. Though, BIP9 does allow it 12:18 < wumpus> BIP9 definitely allows it, that was an important part of the design 12:18 < aj> achow101: vDeployments just matches the enum, the actual bits used are independant, and just have to not overlap per their corresponding timestamps 12:18 < sipa> i haven't looked at the code in a while, but it was certainly intended to permit reuse of bits 12:19 < sipa> the deployments array index is independent from the bip9 bit position 12:19 < instagibbs> yep 12:19 < aj> achow101: see VersionBitsConditionChecker::Mask in versionbits.cpp, it pulls out the .bit field from BIP9Deployment struct 12:20 -!- foobar17 [424164fe@cpe-66-65-100-254.nyc.res.rr.com] has quit [Remote host closed the connection] 12:21 < achow101> i'm probably wrong 12:21 < instagibbs> It was confusing the first time I read it, I came to same wrong conclusion 12:22 < aj> achow101: there's also a unit test for overlapping bit usage on mainnet in src/test/versionbits_tests.cpp, "Verify that the deployment windows of [...]" 12:22 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 12:22 < wumpus> if even experienced developers get confused by it, some documentation/comments might help in that case 12:24 < wumpus> #action please review #16713 so that it can be merged asap 12:24 < MarcoFalke> I think it shouldn't matter in practice, hopefully there are less than 27 softforks in the future 12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/16713 | Ignore old versionbit activations to avoid unknown softforks warning by jnewbery · Pull Request #16713 · bitcoin/bitcoin · GitHub 12:24 < wumpus> given that 'the future' is unbounded, that's a difficult statement 12:25 < wumpus> #topic Rolling UTXO set hash (fjahr) 12:25 < fjahr> Did anyone have time to look at the proposal? Any questions? 12:25 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 264 seconds] 12:25 < achow101> link? 12:26 < instagibbs> fjahr, pitch it to us in a few sentences :) 12:26 < fjahr> https://gist.github.com/fjahr/fa4892874b090d3a4f4fccc5bafa0210 12:26 < sipa> fjahr: it's not clear to me exactly what you're proposal :) 12:26 < fjahr> I have picked up Pieter Wuille's proposal from 2017 to use a rolling hash for the UTXO set hash. It deals with the problem of a long computation time of the UTXO set hash which results in a slow RPC call gettxoutsetinfo (can take several minutes depending on hardware). I investigated three hash functions: MuHash, ECMH and LtHash and started implementing them in Bitcoin Core for comparison. However only MuHash 12:26 < fjahr> has a rolling hash implementation so far and my LtHash code is not as optimized as MuHash and ECMH. I am looking for feedback on concept, which choice to make for the hash function and implementation details before filing a PR to Bitcoin Core. 12:27 < sipa> it's a complicated question, as the right design may depend on how we intend to use the construction 12:27 -!- spinza_ [~spin@102.132.245.16] has quit [Ping timeout: 245 seconds] 12:27 < wumpus> fjahr: thanks for picking it up! 12:27 < MarcoFalke> I think one use case is assumeutxo 12:28 < fjahr> sipa: by construction you mean the hash, right? 12:28 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 12:28 < sipa> fjahr: right 12:28 < sipa> assumeutxo (at least with a from-network-sync approach) will probably need more than just a single hash, as you want to be able to verify chunks etc 12:28 < sipa> fjahr: if i recall correctly, the biggest question i had was how to prioritize computation time vs use-from-cache time 12:29 < sipa> ECMH is slower to compute, but very fast to use from cached values (e.g. if you have precomputed the "diff" ECMH hash a transaction has, applying to a global sum is super fast) 12:29 < sipa> but MuHash is faster is overall computation time 12:29 -!- spinza [~spin@102.132.245.16] has joined #bitcoin-core-dev 12:31 < fjahr> From my benchmarks ECMH was faster overall but I am not sure why MuHash did not perform as you expect in you Mail 12:31 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: Connection reset by peer] 12:32 < sipa> where do you see a discrepancy? in the hash-to-group-element operation, or in the multity? 12:32 < sipa> *multiply? 12:32 < sipa> actually i think the discussion of what hash to pick is less important for this meeting 12:32 < sipa> we should probably focus on ways to integrate 12:33 < fjahr> ok, and also if there is enough interest for this 12:33 < aj> it's super cool 12:33 < jeremyrubin> Are both constructions one-way? 12:33 < jeremyrubin> How does that interplay with reorgs 12:33 < fjahr> In terms of integration I chose to implement this as an index, any feedback on this? 12:34 < jeremyrubin> Maybe I should read more out of band of here... 12:34 < sipa> fjahr: that really depends what for 12:34 < fjahr> jeremyrubin: hashes can also be removed again so no problem with reorgs 12:35 < sipa> i think as an index it's hard to use precomputation 12:35 < sipa> which you really want if you want the rolling part 12:37 -!- iamtimmarchant [~iamtimmar@2600:380:6543:c82e:f4fe:38d6:8460:e87b] has quit [Remote host closed the connection] 12:37 < fjahr> sipa: what would you suggest in terms of integration? 12:38 -!- iamtimmarchant [~iamtimmar@2600:380:6543:c82e:f4fe:38d6:8460:e87b] has joined #bitcoin-core-dev 12:38 < sipa> that really depends on what we want to use it for 12:39 < aj> sipa: could have it rolling, but in it's own slightly delayed thread like tx indexes, without worrying about precomputation, at least if you don't want to enforce it in consensus 12:39 < wumpus> there's 20 minutes to go and still a topic left, let's move on? 12:39 < sipa> fjahr: let's talk more after the meeting 12:40 < fjahr> sipa: sure 12:40 < wumpus> #topic avoid loading every wallet transaction into memory (achow101) 12:40 < wumpus> thanks 12:40 < sipa> btw, the secp ECMH code you have looks great 12:40 < achow101> This is a wallet topic, and probably better for the wallet meeting, but that's next week.. 12:40 < wumpus> is there any hurry? :-) 12:41 < achow101> I was thinking about ways to reduce the memory footprint of loaded wallet files 12:41 < wumpus> concept ACK anyhow 12:41 < jonasschnelli> jup. also ack 12:41 < sipa> achow101: seems hard 12:41 < achow101> I was wondering if anyone who was more familiar with the wallet tracking part of the wallet knew if this was attempted before or would majorly break something? 12:42 < wumpus> it always seemed unnecessary to me to keep all transactions, even historical ones with all outputs spent, in memory 12:42 < jonasschnelli> There is a PR where all wallettxns where kept in mem 12:42 < jonasschnelli> +different DB formst 12:42 < wumpus> but yes, it's such a part of the current wallet design, it's definitely not going to be easy 12:42 < jonasschnelli> #5686 (very old) 12:42 < gribble> https://github.com/bitcoin/bitcoin/issues/5686 | [Wallet] replace BDB with internal append only (logdb) backend by jonasschnelli · Pull Request #5686 · bitcoin/bitcoin · GitHub 12:42 < sipa> achow101: you mean not _show_ them anymore 12:42 < sipa> or just not load them in memory? 12:43 < achow101> not load them into memory, so it would read from disk when the full tx is needed 12:43 < wumpus> right 12:43 < achow101> I plan on just keeping UTXOs and txids in memory 12:43 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev 12:43 < sipa> achow101: i wish you good luck :) 12:43 < jonasschnelli> heh 12:43 < wumpus> outward behavior probably shouldn't change 12:44 < jonasschnelli> Why not just loading everything into memory? 12:44 < jonasschnelli> I think 1000+ wallets are OOS 12:44 * jeremyrubin wonders how big the largest wallet is 12:44 -!- reallll is now known as belcher 12:44 < sipa> OOS? 12:44 < jonasschnelli> out of scope 12:44 < jeremyrubin> out of scope 12:44 < wumpus> there are some heavy users of bitcoin core which have to re-cycle their wallet once in a while because it becomes to big 12:45 < sipa> i don't think memory usage is the problem there 12:45 < achow101> big wallets also take a while to load, although I don't expect this to effect that 12:45 < sipa> just the size of the maps that's being traversed for a multitude of operations 12:45 < wumpus> loading time is likely the problem, yes 12:45 < wumpus> then again that's directly related 12:45 < achow101> ideally this will also reduce the time it takes to calculate things like balances since not every single transaction will be iterated over 12:45 < wumpus> yes, exactly 12:45 < sipa> achow101: i'm very very scared of things like that 12:45 < jarthur> Are exchanges and other large-scale wallet-holders recommended to use Core purely for networking, and maintain their own non-Core wallets? 12:46 < sipa> it needs a completely new design i'm afraid 12:46 < achow101> sipa: how so? 12:46 < sipa> everything is transaction oriented in the current wallet 12:46 < wumpus> jarthur: some use core, but can't mention any names 12:46 < sipa> new transactions that can others to become conflicted etc 12:46 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #bitcoin-core-dev 12:47 < sipa> changing that to a UTXO model and keeping it in sync with the list of transactions... sounds very hard 12:47 < achow101> right, but I think those can still be done by just a list of txids, spent prevouts, and utxos 12:47 < jeremyrubin> is it a more important goal to reduce the number of txns or the amount of data each one is storing? 12:47 < sipa> but you still need all the dependency tracking between transactions to compute the utxos 12:48 < sipa> you can cache the utxo list; that would probably be a worthwhile performance improvement 12:48 < wumpus> that would likely be a better first step 12:48 -!- Victor_sueca is now known as Victorssueca 12:48 < sipa> but getting rid of the transaction entirely... i don't see how 12:48 < achow101> also, maybe just loading a neutered transaction without input scripts, because we don't need those 12:48 < sipa> achow101: yeah that can work 12:48 < jeremyrubin> achow101: that's what I was getting at :) 12:49 < sipa> achow101: also, don't let me discourage you if you see a good way to implement it :) 12:49 < sipa> i'm happy to be convinced otherwise 12:49 < wumpus> there's definitely some cut-off possible, I mean, transactions from years ago can't really become conflicted anymore 12:49 < jeremyrubin> achow101: a good first step might be to cache the scriptPubKey of inputs in a WtX 12:50 < sipa> i suspect thay in native descriptor wallets the IsMine check will be a lot faster than it currently is 12:50 < achow101> anyways, that's all. just wanted to get some opinions before diving in 12:50 < wumpus> at some point spent transactions deep enough in the chain can be permantly archived 12:51 < wumpus> might be non-trivial to come up with criteria but I don't think every transaction needs to be potentially active forever 12:51 < wumpus> achow101: good luck ! 12:53 < wumpus> #endmeeting 12:53 < lightningbot> Meeting ended Thu Sep 5 19:53:03 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:53 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-09-05-19.01.html 12:53 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-09-05-19.01.txt 12:53 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-09-05-19.01.log.html 12:53 < jarthur> MarcoFalke: glad to see the flake8 update finally made it in and you won't have to keep rebasing it. :) 12:53 -!- iamtimmarchant [~iamtimmar@2600:380:6543:c82e:f4fe:38d6:8460:e87b] has quit [Ping timeout: 250 seconds] 12:53 < jeremyrubin> achow101: you can save *some* memory by repacking the CWalletTx struct I bet :) 12:54 < wumpus> if you repack it you might as well re-retrieve it from the database 12:55 < achow101> I want to avoid touching the wallet database, although that may not be possible 12:55 < jeremyrubin> I meant just the fact that there's a lot of fields in the struct that are char then uint64 or something 12:55 < jeremyrubin> which adds a lot of interior padding 12:56 < wumpus> suure 12:56 < jeremyrubin> I did say *some* 12:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 12:56 < achow101> just a bit 12:56 < achow101> At this rate, I think I'll have rewritten the entire wallet by this time next year 12:57 < sipa> if done incrementally, i think that'd be great :) 12:57 < wumpus> if you manage to do that you're the first ever person to achieve it, people have been saying that since 2011 or so though 12:57 < sipa> haha 12:57 < sipa> in 2011 the wallet was still part of main.cpp :p 12:57 < wumpus> but I'm happy to see the work picking up lately on the wallet 12:57 < sipa> we've come a long way 12:59 < wumpus> yes, we've come a long way, for a long time there was hardly any interest in it and some devs were even arguing about removing it because it was just too bad 12:59 < wumpus> it's definitely not like that anymore 13:09 -!- xzytrewq [~quassel@199.58.187.132] has joined #bitcoin-core-dev 13:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:13 < bitcoin-git> [bitcoin] martinus closed pull request #16801: faster & less memory for sync: bulk pool allocator for node based containers (master...2019-08-bulkpoolallocator) https://github.com/bitcoin/bitcoin/pull/16801 13:13 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 13:14 < bitcoin-git> [bitcoin] martinus reopened pull request #16801: faster & less memory for sync: bulk pool allocator for node based containers (master...2019-08-bulkpoolallocator) https://github.com/bitcoin/bitcoin/pull/16801 13:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 13:27 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 13:30 -!- Deadhand [~deadhand@kntaon1614w-grc-09-74-15-95-144.dsl.bell.ca] has quit [Ping timeout: 245 seconds] 13:32 -!- Deadhand [~deadhand@kntaon1614w-grc-09-74-15-95-144.dsl.bell.ca] has joined #bitcoin-core-dev 13:54 -!- so [~so@unaffiliated/so] has joined #bitcoin-core-dev 13:56 -!- kristapsk_ [~KK@gateway/tor-sasl/kristapsk] has joined #bitcoin-core-dev 13:56 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 14:00 -!- total1ty [~total1ty@185.204.1.185] has quit [] 14:03 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 14:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 14:09 -!- Kvaciral [~Kvaciral@94-214-185-162.cable.dynamic.v4.ziggo.nl] has quit [Quit: leaving] 14:17 -!- carldani1 [~carldani@141.98.102.235] has joined #bitcoin-core-dev 14:19 < instagibbs> for all the hate on the wallet, the only other solutions are things like Electrum personal server, and other more ad hoc solutions. It's a project worth iterating on :) 14:20 < instagibbs> > jeremyrubin wonders how big the largest wallet is 14:20 < instagibbs> I've seen a multi GB testnet wallet, but that likely doesn't count 14:21 < instagibbs> if you end up using Core wallet for "industrial" wallet it indeed slows significantly. rhavar probably has some anecdotes 14:24 < sipa> change IsMine() to return true; and watch your wallet.dat explode :p 14:26 < instagibbs> I guess the slowdown is just iterating through all txns anyways, so meh :) 14:28 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Remote host closed the connection] 14:32 -!- pinheadmz [~matthewzi@209.58.139.210] has joined #bitcoin-core-dev 14:45 < phantomcircuit> instagibbs, it does count, don't down play my entirely valid usecase 14:45 * phantomcircuit runs away 14:53 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 245 seconds] 15:01 -!- Blockx [588186c3@h88-129-134-195.cust.a3fiber.se] has joined #bitcoin-core-dev 15:06 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has quit [Ping timeout: 276 seconds] 15:13 -!- promag [~promag@83.223.250.60] has joined #bitcoin-core-dev 15:14 -!- Blockx [588186c3@h88-129-134-195.cust.a3fiber.se] has quit [Ping timeout: 260 seconds] 15:30 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has joined #bitcoin-core-dev 15:30 -!- jarthur [~jarthur@207.114.244.5] has quit [] 15:37 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 15:41 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has quit [Ping timeout: 264 seconds] 15:42 -!- kristapsk_ is now known as kristapsk 15:48 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection] 16:08 < warren> instagibbs: I've seen a very large Bitcoin exchange in Asia that had suffered for years with a single wallet.dat for all customer wallets. It got to the point where ordinary RPC queries against that wallet would take several minutes. As a workaround for faster queries I told them to setup many parallel servers with bitcoind -txindex and watch-only wallets so that they could parallelize their lookups. I also warned that they check for block 16:08 < warren> height agreement before querying anything. 16:13 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:27 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 16:29 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 16:33 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 16:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev 16:47 < bitcoin-git> [bitcoin] ch4ot1c opened pull request #16812: doc: Fix whitespace errs in .md files, bitcoin.conf, and Info.plist.in (master...docs/lint-markdown) https://github.com/bitcoin/bitcoin/pull/16812 16:47 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev [] 16:56 < jb55> might be handy to have a very large test wallet for performance testing 16:56 -!- xzytrewq [~quassel@199.58.187.132] has quit [Ping timeout: 244 seconds] 17:00 -!- carldani1 [~carldani@141.98.102.235] has quit [] 17:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:11 < phantomcircuit> jb55, very large wallets basically don't work currently 17:11 < phantomcircuit> it takes AGES to even load the wallet 17:12 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev 17:17 -!- kbrosnan1 [~kbrosnan@185.169.255.76] has joined #bitcoin-core-dev 17:21 -!- shesek [~shesek@188.64.206.231] has joined #bitcoin-core-dev 17:21 -!- shesek [~shesek@188.64.206.231] has quit [Changing host] 17:21 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev 17:29 -!- lightlike [~lightlike@2001:16b8:571d:4f00:c084:9795:3807:6a25] has quit [Quit: Leaving] 17:34 -!- xzytrewq [~quassel@199.58.187.132] has joined #bitcoin-core-dev 17:34 -!- pinheadmz [~matthewzi@209.58.139.210] has quit [Quit: pinheadmz] 17:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Read error: No route to host] 17:39 -!- pinheadmz [~matthewzi@209.58.139.210] has joined #bitcoin-core-dev 17:48 < achow101> phantomcircuit: are those large wallets large in txs, large in keys, or both? 17:49 < phantomcircuit> achow101, unless something has drastically changed we load everything in the wallet into memory on start 17:50 < phantomcircuit> so it doesn't really matter 17:50 < achow101> yes, that's what I'm trying to change 17:50 < phantomcircuit> (though my ~2GB testnet wallet was mostly transactions by size, but had hundreds of thousands of keys) 17:53 -!- pinheadmz [~matthewzi@209.58.139.210] has quit [Ping timeout: 245 seconds] 17:54 -!- xzytrewq [~quassel@199.58.187.132] has quit [Ping timeout: 246 seconds] 18:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 18:13 -!- Bullitje [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev 18:14 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Ping timeout: 245 seconds] 18:20 -!- Bullitje [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Quit: Defeated by Superior] 18:21 -!- Bullit [~Bullit01@042-236-158-163.dynamic.caiway.nl] has joined #bitcoin-core-dev 18:45 -!- xzytrewq [~quassel@199.58.187.132] has joined #bitcoin-core-dev 18:52 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has joined #bitcoin-core-dev 18:53 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:07 -!- emilengler [~emilengle@unaffiliated/emilengler] has quit [Ping timeout: 268 seconds] 19:09 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Quit: May the Shwartz be with you] 19:09 -!- emilengler [~emilengle@unaffiliated/emilengler] has joined #bitcoin-core-dev 19:26 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds] 19:32 -!- pinheadmz [~matthewzi@209.58.139.210] has joined #bitcoin-core-dev 20:00 -!- kbrosnan1 [~kbrosnan@185.169.255.76] has quit [] 20:03 -!- kristapsk [~KK@gateway/tor-sasl/kristapsk] has quit [Remote host closed the connection] 20:04 < meshcollider> sipa or achow101: for #16807, to make a "generic" error detector which returns a basic error for invalid non-bech32 and does the more advanced error location for bech32, is it ok to just distinguish between the legacy/p2sh and bech32 cases based on "starts with a 1/3", or "starts with something else"? 20:04 < gribble> https://github.com/bitcoin/bitcoin/issues/16807 | Let validateaddress locate error in Bech32 address by meshcollider · Pull Request #16807 · bitcoin/bitcoin · GitHub 20:04 < meshcollider> It gets confusing based on what type of invalidity we expect, e.g. if the bech32 address is missing an HRP it'll start with a 1 20:05 < meshcollider> so just assume it'll be "vaguely correct" and just look for typos? 20:09 < achow101> meshcollider: a bech32 address missing the hrp will be larger than the longest legacy address 20:10 < achow101> s/larger/longer 20:11 < achow101> we know the length limits, I would prefer a distinguishing based on lengths and character set 20:11 < meshcollider> Can't use character set because one of the errors might be an invalid character for the intended address type 20:11 < meshcollider> Could use length + first byte 20:12 -!- pinheadmz [~matthewzi@209.58.139.210] has quit [Quit: pinheadmz] 20:17 -!- gde331 [~gde33@185.204.1.185] has joined #bitcoin-core-dev 20:18 -!- dark-1456 [~dark-1456@85.203.27.244] has joined #bitcoin-core-dev 20:19 -!- ossifrage_ [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev 20:22 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Ping timeout: 258 seconds] 20:30 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has joined #bitcoin-core-dev 20:31 -!- IGHOR [~quassel@93.178.216.72] has quit [Quit: http://quassel-irc.org ? ??????????? ?????????. ????-??.] 20:34 -!- ccdle12 [~ccdle12@cpc139350-aztw33-2-0-cust310.18-1.cable.virginm.net] has quit [Ping timeout: 244 seconds] 20:36 -!- IGHOR [~quassel@93.178.216.72] has joined #bitcoin-core-dev 20:45 < sipa> meshcollider: bech32 addresses aren't restricted to v0 witness though 20:50 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 20:53 < meshcollider> sipa: I know, I would only check expected length or start character or whatever for legacy/p2sh 20:53 < meshcollider> Minimal assumption on the bech32 20:58 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Ping timeout: 244 seconds] 20:59 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev 21:00 -!- doesnt-code [~picokerne@2603:9001:2a05:3600:8274:c8ae:43d3:9fa5] has quit [Ping timeout: 264 seconds] 21:04 -!- dark-1456 [~dark-1456@85.203.27.244] has quit [Remote host closed the connection] 21:05 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has quit [Quit: Leaving] 21:07 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 245 seconds] 21:08 -!- StopAndDecrypt [~StopAndDe@107.181.189.43] has joined #bitcoin-core-dev 21:08 -!- StopAndDecrypt [~StopAndDe@107.181.189.43] has quit [Changing host] 21:08 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 21:12 -!- niska [~niska@static.38.6.217.95.clients.your-server.de] has quit [Quit: Leaving] 21:20 < meshcollider> sipa since it was your idea in the PR, do you have any suggestions 21:20 < meshcollider> Its very messy, I don't want to just hardcode a bunch of heuristics 21:21 < meshcollider> For example if an address contains a character like "o", both base58 and bech32 deciding will fail, then how do we know which error message to return 21:22 -!- niska [~niska@static.38.6.217.95.clients.your-server.de] has joined #bitcoin-core-dev 21:22 < meshcollider> "O" sorry* 21:27 < sipa> maybe initially just use prefix 21:30 < meshcollider> And hardcode the characters for each network? Because Params() will only provide it as a data value 21:33 < meshcollider> Otherwise if the user passes a flag to validateaddress which says which type they intend it to be it would be nicer I guess, then if they say "legacy" there is no ambiguity 21:36 < sipa> or i guess: the base58 decode (without checksum), and try bech32 decode 21:36 < sipa> if both fail, report unknown enxoding 21:36 -!- rhavar_ [uid237883@gateway/web/irccloud.com/x-wmocgnozbaoossut] has joined #bitcoin-core-dev 21:36 < sipa> if they succeed, chexck version bytes 21:36 < sipa> and hrp 22:09 -!- StopAndDecrypt_ [~StopAndDe@107.181.189.45] has joined #bitcoin-core-dev 22:09 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 245 seconds] 22:16 < meshcollider> I've pushed a commit 22:16 < meshcollider> If bech32 decoding fails we ideally still want to find the source of the error though right 22:16 < meshcollider> I think my current approach is ok, let me know what you think 23:00 -!- gde331 [~gde33@185.204.1.185] has quit [] 23:17 -!- jbarnette [~jbarnette@94.229.74.91] has joined #bitcoin-core-dev --- Log closed Fri Sep 06 00:00:02 2019