--- Log opened Thu Jul 26 00:00:22 2018 01:04 -!- Orion3k [~Orion3k@24-176-200-142.static.mtpk.ca.charter.com] has joined #bitcoin-core-dev 01:09 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 01:26 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 01:29 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:39 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 02:06 -!- polydin [~delphi@2602:306:b8b6:b970:d992:3519:28f0:d0cb] has quit [Ping timeout: 276 seconds] 02:06 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 02:58 < provoostenator> Could someone tag #13426 for a Gitian build? 02:58 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 02:59 < jonasschnelli> provoostenator: will do.. 02:59 < provoostenator> (I haven't given up on cross-compiling, but it's often a hit or miss for me) 03:00 < jonasschnelli> provoostenator: https://bitcoin.jonasschnelli.ch/build/715 03:07 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 03:09 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 256 seconds] 03:13 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:14 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 03:15 -!- ken2812221 [~User@1.200.198.248] has joined #bitcoin-core-dev 03:21 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 03:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:34 -!- ren0v0 [~ren0v0@host213-122-101-73.range213-122.btcentralplus.com] has quit [Ping timeout: 244 seconds] 03:47 -!- rex4539 [~textual@2a02:587:3516:600:755d:6904:8b22:298] has quit [Quit: Textual IRC Client: www.textualapp.com] 03:53 -!- rex4539 [~rex4539@2a02:587:3516:600:755d:6904:8b22:298] has joined #bitcoin-core-dev 04:00 -!- osue [~osue@89.249.64.163] has joined #bitcoin-core-dev 04:04 < jonasschnelli> gitian: is there a solution if make-base-vm complains with "E: Couldn't find these debs: git-core"? 04:04 < jonasschnelli> Is that an Apt-Cacher-NG issue? 04:06 < Fuzzbawls> jonasschnelli: AFAIK all references to "git-core" have been replaced with just "git" in the gitian descriptors. could be a local caching issue (though I myself have never encountered such a thing). 04:09 < ken2812221> jonasschnelli: Use the latest version of gitian-builder 04:09 -!- osue [~osue@89.249.64.163] has quit [Remote host closed the connection] 04:09 < jonasschnelli> Thanks... will try 04:10 < jonasschnelli> ken2812221: updating gitian-builder fixed the issue. Thanks 04:10 < jonasschnelli> I didn't updated since I'm pretty sure I added some local modifications. :) 04:11 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev 04:11 < Fuzzbawls> did you ever get a self-compile of LXC 3 working on debian? think i saw it was you that was trying to use version 3...or maybe a later version 2 that wasn't supplied by the distro packages 04:18 < ken2812221> IIRC make-base-vm does not use apt so it may not know about package alias. 04:21 < jonasschnelli> Fuzzbawls. I self compiled 2.1.1 04:23 -!- SopaXT [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 260 seconds] 04:25 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 04:27 < provoostenator> jonasschnelli: got it, thanks 04:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:35 < ken2812221> bitcoin-git is dead? 04:38 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 04:39 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 264 seconds] 04:41 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer] 04:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 04:43 -!- osue [~osue@89.249.64.163] has joined #bitcoin-core-dev 04:45 -!- Krellan [~Krellan@12.151.67.253] has quit [Remote host closed the connection] 04:48 -!- osue [~osue@89.249.64.163] has quit [Ping timeout: 260 seconds] 04:57 < provoostenator> jonasschnelli: the Windows build thinks it's version b591ece04 rather than 5ca74904 04:57 < achow101> ken2812221: sipa killed it by setting +n 04:57 < achow101> to prevent spamming that was happening 04:58 < provoostenator> I guess it makes a merge commit first 04:59 < ken2812221> achow101: thanks 05:04 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection] 05:07 < jonasschnelli> ken2812221: any idea how to fix "E: Package 'curl' has no installation candidate" (inside the gitian VM) during gbuild? 05:07 < jonasschnelli> gbuild exists with: ./bin/gbuild:21:in `system!': failed to run on-target -u root -e DEBIAN_FRONTEND=noninteractive apt-get --no-install-recommends -y install ca-certificates curl g++ git pkg-config autoconf librsvg2-bin libtiff-tools libtool automake faketime bsdmainutils cmake imagemagick libcap-dev libz-dev libbz2-dev python python-dev python-setuptools fonts-tuffy > var/install.log 2>&1 (RuntimeError) 05:14 < ken2812221> I haven't seen that error message before, is that a network issue? 05:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 05:23 -!- osue [~osue@89.249.64.147] has joined #bitcoin-core-dev 05:25 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev 05:28 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Ping timeout: 260 seconds] 05:28 -!- osue [~osue@89.249.64.147] has quit [Ping timeout: 256 seconds] 05:32 -!- Sinclair6 [~sinclair6@2602:306:c4b1:2570:c961:a817:b54:4cdc] has quit [Ping timeout: 260 seconds] 05:39 -!- Sinclair6 [~sinclair6@2602:306:c4b1:2570:e879:935f:66dd:62cc] has joined #bitcoin-core-dev 05:57 -!- ken2812221 [~User@1.200.198.248] has quit [Ping timeout: 256 seconds] 06:01 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 06:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:20 -!- ken2812221 [~User@1.200.198.248] has joined #bitcoin-core-dev 06:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 06:34 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 06:49 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has quit [Ping timeout: 256 seconds] 07:05 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev 07:10 <@wumpus> any objections to adding "skeees" to the github orgs? -- he's been fairly active as a contributor 07:12 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ 07:12 < fanquake> wumpus +1 07:16 -!- opdenkamp [~opdenkamp@kodi/staff/dushmaniac] has joined #bitcoin-core-dev 07:23 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 07:24 -!- osue [~osue@89.249.64.163] has joined #bitcoin-core-dev 07:29 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer] 07:29 -!- osue [~osue@89.249.64.163] has quit [Ping timeout: 264 seconds] 07:37 -!- farmerwampum [~farmerwam@88.202.178.98] has joined #bitcoin-core-dev 07:39 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 07:46 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 240 seconds] 07:53 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:53 -!- Aaronva__ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 07:54 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving] 07:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds] 07:57 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 07:59 < BlueMatt> Ugh, ok, poll time, what are peoples' thoughts on what to call the witness version of the redeemScript? https://github.com/bitcoin-core/bitcoincore.org/issues/581 and https://github.com/rust-bitcoin/rust-bitcoin/pull/109 for debate context 08:01 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev 08:01 < jamesob> wumpus: +1 08:03 -!- TheRec [~toto@drupal.org/user/146860/view] has quit [] 08:12 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 08:21 < Chris_Stewart_5> wumpus: +1 08:21 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 08:22 < gmaxwell> BlueMatt: it's called the redeemScript. 08:23 < gmaxwell> Or witnessScript. 08:24 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 08:27 < BlueMatt> gmaxwell: hmm witnessScript is confusing af, imo 08:29 < arubi> redeemscript is even more confusing when it's say a p2sh-p2wsh transaction 08:30 < achow101> it's been called the witnessScript. Changing it now would probably introduce more confusion 08:30 < arubi> DDG first result for "scriptWitness" is the transaction.h file in the repo, and for "witnessScript bitcoin" the first result is is the core-dev docs site 08:30 < arubi> +1 witnessScript 08:34 < arubi> (posted on the issue) 08:36 < BlueMatt> arubi: well you could call it "witness redeem script" pretty easily 08:36 < BlueMatt> scriptWitness already refers to the full witness 08:36 < BlueMatt> so now scriptWitness and witnessScript are different things? 08:38 < arubi> "witness redeem script" might be better than "witness redeemScript" if it's going to be called that then. and yea I see your point about this but at least these two terms are easily distinguishable in search 08:39 < BlueMatt> from my github comment: "Also, further confusing is that its easy to see the witness as a replacement for the scriptSig (though that's not entirely accurate due to it being a list of pushes, not an executed script), at which point scriptWitness/witnessScript would be easy to assume referred to the full witness." 08:39 < BlueMatt> funny that people had been calling it witnessScript and I'd never actually seen that anywhere lol 08:41 < arubi> maybe "witnessSource" ? sort of the source code for the witness program? :) 08:42 < BlueMatt> I mean I dont hugely care, I just think witnessscript/scriptwitness is absolutely a terrible idea 08:46 <@sipa> awww i'm sorry :) 08:46 -!- mode/#bitcoin-core-dev [-o sipa] by sipa 08:46 < sipa> witnessscript = script in the witmess 08:47 < sipa> scriptwitness = witne for a script 08:47 < BlueMatt> ok, so given there's already like three terms to describe witnessscript, lets stop calling it witnessscript :p 08:48 < sipa> witness redeemscript sgtm 09:02 -!- Aaronva__ is now known as AaronvanW 09:05 -!- grafcaps [~haroldbr@104.137.194.255] has joined #bitcoin-core-dev 09:08 -!- Sinclair6 [~sinclair6@2602:306:c4b1:2570:e879:935f:66dd:62cc] has quit [] 09:11 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 09:15 -!- michaelsdunn1 [~mdunn@38.126.31.226] has joined #bitcoin-core-dev 09:16 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 09:16 < satwo> Hi all. BIP-141 defines 4 ways to measure the size of a transaction: weight, virtual size, base size, and total size. Bitcoin-cli decoderawtransaction returns weight, vsize ("virtual size" - obvious), and size (“total size" - not obvious). I must not be the only one to have found it nontrivial to figure out how base size, total size in BIP141 and “size” in RPC are related. Even once one figures out that “BIP 141 09:16 < satwo> total size” = “RPC size”, base size and witness data size must be calculated with a little backwards-engineered DIY algebra. Is there room for improvement in documentation/RPC fields here, or am I missing something? 09:19 < BlueMatt> sipa: plz2comment on bitcoincore.org issue, then 09:23 < gmaxwell> satwo: "base size" is basically completely meaningless in the protocol. It's not used for anything. 09:24 < sipa> BlueMatt: what issue? 09:24 < gmaxwell> (okay, it's used in the minimum size standardness rule, but I think nowhere else) 09:25 < satwo> gmaxwell: That was my intuition, but some things threw me off; i.e. its being used as a tx field in BlockSci, and the fact that many block explorers seem to refer to the base size of a tx in their size field (other explorers refer to total size) 09:25 -!- osue [~osue@89.249.64.155] has joined #bitcoin-core-dev 09:26 < sipa> satwo: explorers should only show vsize 09:26 -!- rex4539 [~rex4539@2a02:587:3516:600:755d:6904:8b22:298] has quit [Quit: Textual IRC Client: www.textualapp.com] 09:26 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 09:26 < sipa> all the rest are technical details that most users won't care about 09:27 -!- rex4539 [~rex4539@2a02:587:3516:600:755d:6904:8b22:298] has joined #bitcoin-core-dev 09:27 < gmaxwell> satwo: unfortunately people have promoted a lot of crazy misunderstandings that make people think things that matter don't. 09:27 < gmaxwell> e.g. people saying that the limit is "1mb base + 3mb witness", which is not at all how it works, but if it did it would make sense to print two size figures. 09:28 -!- rex4539 [~rex4539@2a02:587:3516:600:755d:6904:8b22:298] has quit [Client Quit] 09:28 -!- rex4539 [~rex4539@2a02:587:3516:600:755d:6904:8b22:298] has joined #bitcoin-core-dev 09:30 -!- osue [~osue@89.249.64.155] has quit [Ping timeout: 264 seconds] 09:31 < satwo> sipa: very few do, it seems. For example the tx 88d87642bc1534b9d6f8d62e6e9ae55e5971c0efec30d9139f817eb55c307c71 has a "size" of 381 on Blockchair, blockchain.info, btc.com, and smartbit.au, and a "size" of 126 on Blockcypher, Blocktrail and blockexplorer.com. 381 is the total size and 126 is the base size. So clearly there's some confusion with nomenclature 09:32 < satwo> Of course vsize is nowhere to be found except on smartbit 09:34 < sipa> satwo: i'm aware 09:34 < sipa> i've contacted a few 09:36 < sipa> it was probably a mistake to introduce a new namw.for it; we should jusr have replaced size everywhere with vsize 09:36 < sipa> but that would have run into issues with people who assumed size = len(serialization) 09:40 < satwo> Would modifying bitcoin-rpc to say something like "size (total):" or "total size:" be messy overkill? At the very least it would bring RPC and BIP 141 in harmony, potentially reducing some confusion 09:41 < gmaxwell> We should probably drop size out of the rpcs. 09:41 -!- Urgo [~Urgo@cpe-107-15-142-254.nc.res.rr.com] has quit [Ping timeout: 240 seconds] 09:50 < BlueMatt> sipa: https://github.com/bitcoin-core/bitcoincore.org/issues/581 09:52 < satwo> gmaxwell: makes sense. Easier said than done I assume? 09:54 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 09:55 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 09:56 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 09:58 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:15 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev 10:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 10:28 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 10:31 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Read error: Connection reset by peer] 10:39 -!- dqx__ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev 10:42 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds] 10:54 < skeees> wumpus: thanks for the org invite :) 10:54 < skeees> also, 10:54 < skeees> AMAZING NEWS TODAY!!! I'm giving away .... 10:55 < sipa> /report skeees 11:02 -!- osue [~osue@89.249.64.235] has joined #bitcoin-core-dev 11:03 < wumpus> skeees: welcome to the org! 11:06 -!- osue [~osue@89.249.64.235] has quit [Ping timeout: 248 seconds] 11:23 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 11:23 -!- polydin [~delphi@2602:306:b8b6:b970:18b3:4dc2:268f:c5cc] has joined #bitcoin-core-dev 11:33 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:658f:7cd8:c293:965c] has joined #bitcoin-core-dev 11:41 -!- nmnkgl [uid306870@gateway/web/irccloud.com/x-qtontbebeybvvyng] has quit [Quit: Updating details, brb] 11:50 -!- nmnkgl [sid306870@gateway/web/irccloud.com/x-ifmueqruyivmzrel] has joined #bitcoin-core-dev 12:01 < jonasschnelli> DING / DONG 12:01 < wumpus> #startmeeting 12:01 < lightningbot> Meeting started Thu Jul 26 19:01:30 2018 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 < jnewbery> hi 12:01 < achow101> hi 12:01 < jamesob> hi 12:01 < nmnkgl> hi 12:01 < jonasschnelli> hi 12:01 < provoostenator> hi 12:01 < sipa> hi 12:01 < cfields> hi 12:02 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi 12:02 < wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator 12:02 < kanzure> hi. 12:02 < BlueMatt> I have a somewhat strange topic: what to call the witness version of the p2sh redeemScript...not quite the right venue to discuss it, but there's not a much better one and we have to pick something for bitcoincore.org, sooooo 12:02 < wumpus> #topic naming of witness version of the p2sh redeemScript 12:02 < achow101> hasn't this been called "witnessScript" for a while? 12:03 < sipa> yes 12:03 < achow101> that's what i have used for bip 174 at least 12:03 < BlueMatt> I had never seen that 12:03 < BlueMatt> though I admit it was in the BIP 12:03 < BlueMatt> and I know people who've called it the witness redeem script or so 12:03 < BlueMatt> which is also confusing cause of p2sh-wrapped segwit 12:04 < BlueMatt> but witnessScript is confusing given scriptWitness refers to the whole witness :( 12:04 < jonasschnelli> how is this important to define? 12:04 < BlueMatt> so every option is shit 12:04 < sipa> perhaps it should be called P2WSH redeemscript, as it's arguably specific to P2WSH (P2WPKH doesn't have it, and future witness versions may not either) 12:04 < BlueMatt> jonasschnelli: well we need to call it *something* and it seems everyone has a different one 12:04 < kanzure> using ambiguous jargon will cause errors and bugs 12:05 < sipa> BlueMatt: scriptWitness is just in bitcoin core's source code though; is it called that way anywhere else? 12:05 < BlueMatt> sipa: I'm not sure that it is, but that was MarcoFalke's comment to me 12:05 < jonasschnelli> IMO it's specified in the BIP, but people are free to form a new term. I don't think there is need to an authoriity to define it. 12:05 -!- leishma__ [~leishman@50.237.29.22] has joined #bitcoin-core-dev 12:05 -!- leishma__ is now known as leishman__ 12:05 < BlueMatt> but, given the witness can be seen as a "scriptSig replacement" calling it that I could see being incredibly confusing to some people 12:06 < sipa> yes, i agree it's confusing and we could have picked a better name 12:06 < BlueMatt> jonasschnelli: well I ask because there is debate about what to write in some docs in rust-bitcoin, and also what to call it on bitcoincore.org docs 12:06 < sipa> the cat may also already be out of the bag since 2 years ago 12:06 < BlueMatt> jonasschnelli: so this is the right venue to discuss bitcoincore.org 12:06 < BlueMatt> sipa: sure, but I've seen it referred to as other things too already :( 12:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 12:06 < promag> hi 12:06 < gmaxwell> I think this discussion is a waste of time for this venue. 12:06 < provoostenator> For now, maybe just explain that it's confusing and someone should propose a BIP to deconfuse it? 12:06 < kanzure> cfields: are the poll results due today? 12:07 < jonasschnelli> Can we also rename "wallet"? *duck* 12:07 < cfields> kanzure: ah, thanks for the reminder. poll closed at the end of yesterday's meeting. winner: current time 12:07 < cfields> er, last week's meeting 12:07 < wumpus> #topic meeting time 12:08 < provoostenator> Even just pointing out that something_is_ confusing, helps the reader pay attention, otherwise they might think they just don't get it. 12:08 < cfields> poll results: https://civs.cs.cornell.edu/cgi-bin/results.pl?id=E_a80f9a69d20aab2a 12:08 < kanzure> cfields: is that a selection effect of mostly current-meeting participants answering the survey? 12:09 < provoostenator> So was the idea still to alternate between two times? 12:09 < cfields> kanzure: possibly, but I'm not sure how else to get the word out. 12:09 < gmaxwell> cfields: what was the runner up time? 12:09 < cfields> gmaxwell: see link above 12:09 < sipa> gmaxwell: one hour earlier 12:10 < gmaxwell> oh sorry. 12:11 < promag> quick question, when 0.17 branch? 12:11 < achow101> promag: August 1st or so 12:11 < wumpus> #12624 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/12624 | Release schedule for 0.17.0 · Issue #12624 · bitcoin/bitcoin · GitHub 12:12 < achow101> according to the release schedule 12:12 < wumpus> 2018-08-13 12:12 < wumpus> is the plan 12:12 < sipa> also w.r.t. scantxoutset, are we going to mark it experimental? 12:12 < wumpus> I think everyone agreed on that 12:12 < jonasschnelli> Yes. I can PR that. 12:13 < promag> +1 12:13 < gmaxwell> jonasschnelli: thanks. 12:13 < jonasschnelli> Sorry for the delayed review on sipas descriptor work... will comment soon on the PR 12:14 -!- LeMiner [~LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 12:15 < wumpus> #topic 0.16.2 final 12:15 < BlueMatt> ack 12:15 < wumpus> rc2 was tagged ~a week ago, I don't think any issues came up 12:15 < gmaxwell> I haven't seen or heard any issues with the RC. 12:15 < wumpus> so I think it's time to tag final 12:15 < jonasschnelli> agree 12:15 < cfields> +1 12:16 < wumpus> ok, will do so after the meeting 12:16 < gmaxwell> not have any OMG-must-fix-now bugs cropped up that I'm aware of. 12:16 < promag> +1 12:16 < achow101> yay 12:16 < wumpus> any other topics? 12:17 < cfields> quick personal announcement: A small health issue has been taking up a good amount of my time lately, and I've been struggling to keep up with review, let alone writing new code. I've decided to take a week or two to try to finish up outstanding things, then take a month away to try to get back to 100%. I'll try to at least keep up with emails and pings during that time. 12:17 < wumpus> as for high priority for review, please review everything under the 0.17 milestone: https://github.com/bitcoin/bitcoin/milestone/33 12:17 < kanzure> cfields: good luck with your health. 12:17 < sipa> cfields: take all the time you need 12:17 < jamesob> rest up, cfields! 12:17 < cfields> so if I owe anyone review on something, please give me a ping! 12:17 < jonasschnelli> sad to hear and hope you will recover soon cfields! 12:17 < gmaxwell> #13756 might want to have some coordination on the UI/GUI side. (or someone to come yell at me to not creep the scope) 12:17 < gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: -avoidreuse feature for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub 12:18 < wumpus> cfields: yes, just take the rest you need 12:18 < provoostenator> gmaxwell I'll try that one. 12:19 < jonasschnelli> thanks provoostenator 12:19 < promag> re 13756, I have some too 12:19 < cfields> thanks, all, but ping away. 12:19 < promag> *questions :/ 12:20 < wumpus> is kallewoof there to answer them? 12:20 < wumpus> if not, I don't think it makes sense to ask them during the meeting 12:20 < sipa> it's 4:20 AM for him 12:20 < promag> sure, in I'll do in gh 12:20 < wumpus> right 12:21 < wumpus> ok 12:22 < gmaxwell> I brought it up in part because kallewoof doesn't make meetings. :) 12:22 < jonasschnelli> JP timezone I guess 12:23 < wumpus> the PR missed the feature freeze so there's not that much hurry 12:24 < wumpus> any other topics? 12:24 < luke-jr> steak? 12:25 < jamesob> did we decide to stop maintaining/pushing a high-prio PR list? 12:25 < wumpus> steak! 12:25 < midnightmagic> +1 steak 12:25 < sipa> jamesob: it's just overshadowed now by the 0.17 milestone 12:25 < wumpus> jamesob: < wumpus> as for high priority for review, please review everything under the 0.17 milestone: https://github.com/bitcoin/bitcoin/milestone/33 12:25 < jamesob> oops, thanks 12:26 < gmaxwell> because we're near 0.17, its the 0.17 list that is high prio right now. 12:26 < wumpus> maintainging a separate high priority list is just confusing at the moment, I think 12:27 -!- schmidty_ [uid297174@gateway/web/irccloud.com/x-rzgqgmwltkhczvft] has joined #bitcoin-core-dev 12:27 < promag> agree, 0.17 is high priority 12:29 < wumpus> any other 0.17 PR s that need to be discussed? 12:29 < ken2812221> #13426 12:29 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 12:30 < ken2812221> Is it allowable to add wmain function? 12:30 < wumpus> #topic encoding issue on windows (ken2812221( 12:30 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 12:31 < cfields> there are a bunch of current PRs for depends and gitian descriptors. I assume it's no problem to continue working on those for 0.17? There are a few fixes that may be non-trivial that I would greatly prefer over the one-liner fixes. 12:31 < wumpus> ken2812221: I'd prefer not, I think we had multiple entry points at some point, with special one for windows but this was cleaned up to just main(), if there is really no other way 12:31 < gmaxwell> i hate strings 12:32 < wumpus> so do I, but unfortunately they're needed for path names 12:32 < cfields> windows strings cause 2x developer hate :( 12:32 < luke-jr> they string us along? 12:32 < gmaxwell> so the issue here is that windows APIs want UTF16 strings or something? 12:32 < cfields> luke-jr: i would characterize it that way, hes 12:33 < wumpus> gmaxwell: yes :-/ 12:33 < ken2812221> Windows does not use utf8 12:33 < gmaxwell> I'm vaguely aware of that. 12:33 < wumpus> I think #13426 is too big a change 12:33 < gribble> https://github.com/bitcoin/bitcoin/issues/13426 | [bugfix] Fix encoding issue for Windows by ken2812221 · Pull Request #13426 · bitcoin/bitcoin · GitHub 12:33 < gmaxwell> Originally it was UCS2 but then they realized that chinese exists and it became UTF16 to get the worst of all worlds or soemthing like that. 12:34 < wumpus> is this reallky all necessary? it changes pretty much all uses of paths in the code 12:34 < sipa> yeah, they adopted unicode very early, and picked a different encoding than what the rest of the world eventually ended up pickin 12:34 -!- LeMiner [~LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 12:35 < gmaxwell> ken2812221: what keeps you from intercepting a couple places at a low level and inserting at UTF8->UTF16 conversion? 12:35 < wumpus> I hate waltzing over the entire code to accomodate windows' crappyness 12:36 < ken2812221> The command line argument, I think. 12:36 < wumpus> most of the changes seem .string() versus .u8string() 12:36 < gmaxwell> ken2812221: the commandline arguments come in as utf8 strings, right? 12:37 < ken2812221> no, it is ANSI or UTF-16. 12:37 < wumpus> on POSIX platforms that's what we assume, in windows they come as utf16 strings 12:37 < ken2812221> on Windows 12:38 < sipa> since windows 10 apparently you can select a codepage for the "ansi" encoding that is utf8 12:38 < wumpus> sipa: oh! 12:38 < sipa> oh no 12:38 < gmaxwell> wumpus: so how do we deal with like ua comment coming in and not sticking UTF16 into our network messages? 12:38 < sipa> only possible since windows 10 insider build 17035 (November 2017) 12:38 < cfields> gmaxwell: we sanitize those 12:39 < gmaxwell> cfields: but given UTF16 wouldn't our sanitizer just corrupt the string? (throw out all characters?) 12:39 < cfields> (unsure what gets lost in the conversion, but we know what can't go out) 12:39 < wumpus> gmaxwell: it needs to be converted to UTF8 for the internal use 12:39 < gmaxwell> okay, I clearly know nothing here so I should probably just go read. 12:39 < wumpus> so the arguments come in as UTF-16, then are converted to UTF-8 for storage 12:39 < gmaxwell> wumpus: right I guess I was just assuming the argument processing conerted it all to utf8 before we saw any of it. 12:39 < wumpus> which makes complete sense in ken2812221 's PR 12:40 < cfields> gmaxwell: nah, I think you're right. I was just making the point that it at least won't go over the wire that way. 12:40 < sipa> ok, 17035 was finally released as "April 2018 update" 12:40 < sipa> that's... a decade too late 12:40 < wumpus> sipa: yes... 12:40 < gmaxwell> In which case I'd assume the path issue could be solved by wrapping the file IO with something that converts our internal utf8 to utf16 for windows. 12:40 < luke-jr> XD 12:40 < wumpus> though microsoft is twisting people's arms really hard to upgrade to windows 10 12:40 < sipa> don't we already have the fs space for that? 12:41 < wumpus> yes, that's what his PR does 12:41 < sipa> hmm, i would expect it's just changing one or two functions 12:41 < gmaxwell> ^ 12:41 < sipa> sorry, i'm not very familiar with this part of the code; i should probably go look 12:41 < wumpus> it makes sense, the only thing is dislike is the size of the diff because he uses .u8string instead of .string in so many places, but it's fairly simple 12:43 < ken2812221> There are some TODO: leveldb and fstream 12:43 < wumpus> should probably get over it and review it... 12:43 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:43 < ken2812221> They are not support utf-8 in this PR. 12:44 < wumpus> so that will still fail with datadirs with, say, Chinese characters in it? 12:44 < ken2812221> Yes, still fail, but success if you set your setting to Chinese. 12:44 < ken2812221> Before this PR, both fail. 12:45 < wumpus> okay, that's good 12:46 < ken2812221> Thanks 12:47 < jtimon> I guess #13311 doesn't deserve to be in the 0.17.0 milestone since it is not a feature nor a bugfix 12:47 < gribble> https://github.com/bitcoin/bitcoin/issues/13311 | Dont edit Chainparams after initialization by jtimon · Pull Request #13311 · bitcoin/bitcoin · GitHubAsset 1Asset 1 12:52 < wumpus> it's not really about 'deserve', I don't see a point to add it to the milestone, but if it is ready for merge before branching off 0.17 it can make it into 0.17 12:53 < jtimon> sure, perhaps not the right word, "I guess there's no point for in to be in the milestone" 12:53 < wumpus> yes, I agree with that 12:54 < jtimon> I guess I was just review begging by mentioning it, sorry 12:54 < wumpus> that's okay 12:56 < wumpus> I guess we're out of topics 12:56 < wumpus> #endmeeting 12:56 < lightningbot> Meeting ended Thu Jul 26 19:56:16 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:56 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-26-19.01.html 12:56 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-26-19.01.txt 12:56 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-07-26-19.01.log.html 12:56 -!- masonicboom [~masonicbo@2600:8802:5501:17c0:658f:7cd8:c293:965c] has quit [Ping timeout: 256 seconds] 13:05 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 13:06 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 13:21 < gmaxwell> Does anyone have any idea on how we could tell if dbcache flush events are becoming correlated across the network? 13:26 -!- farmerwampum [~farmerwam@88.202.178.98] has quit [Quit: farmerwampum] 13:38 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 13:38 < wumpus> no idea how to do that without adding instrumentation and metrics reporting 13:39 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 13:39 < gmaxwell> I suppose we could check logs from a number of our own long running nodes and see if they line up, but I bet most of us are changing the default dbcache size. 13:40 < skeees> thats a pretty tricky, but interesting problem, would flushing db cache introduce a measurable delay in responding to a ping? 13:41 < skeees> how close of an interval becomes problematic in your opinion? 13:41 < wumpus> tes but so does validation of blocks 13:41 < wumpus> gmaxwell: indeed, logs would also be good 13:43 < gmaxwell> skeees: yes but validating a block does too 13:43 < gmaxwell> Basically the concern is that if nodes are synchronizing their flushes, it will slow down block propagation somewhat. 13:43 < gmaxwell> Because you get a block, validate it, flush (if needed), aand relay it. 13:44 < gmaxwell> if nodes aren't synced propagation will just route around flushing nodes. 13:44 < gmaxwell> HB mode with forward-before-validate like we have now I'm sure greatly reduces the issue. 13:44 < kanzure> relay and flush are in same thread? 13:45 < gmaxwell> I was talking to matt in private about some relay improvements, and we observed that even for relay the stuff we were talking about was probably not the low hanging fruit. 13:46 < gmaxwell> kanzure: non-oppturnistic realy blocks on validation (as it must per protocol), and validation blocks on flushing (as it kind-of must to avoid excess memory usage) 13:46 < skeees> well i do have that pr that puts net and validation (/flush) in separate threads - it would still require additional work though to remove cs_main from relay I think 13:46 < gmaxwell> in theory everything could be rejiggered to make that less bad, but that effort would probably be better spent in making flushing a non-issue via incremental flushing which we changed the design to facilitate a few releases ago. 13:46 < gmaxwell> skeees: putting it in seperate threads is irrelevant. 13:47 < skeees> that wouldn't enable you to relay while the flush happened? 13:47 < gmaxwell> A question of threading isn't the source of delays. 13:48 < kanzure> it's validation. if you want non-opportunistic relay. 13:49 < kanzure> hence the mention of a refactor 13:49 < gmaxwell> skeees: you'd be able to do just the same by moving the flush ahead of the next verification operation, without changing anything with threading. 13:50 < gmaxwell> in any case, I asked because if they're syncing it's probably a completely safe one line of code change to make them no longer sync up. 13:51 < gmaxwell> (just make each node randomly make its dbcache zero to four blocks of worth of data smaller.) 13:54 < wumpus> * [new tag] v0.16.2 -> v0.16.2 13:55 < gmaxwell> The right bigger change is to make it so that we only flush a small amount, and then flush every block. A few versions ago we relaxed the invarient that the chainstate database has to be consistent with a particular block. 13:56 < sipa> wumpus: \o/ 13:56 < gmaxwell> But even that isn't worth doing for latency reasons; it's worth doing because it should speed up sync a lot by better overlapping writing. 13:57 < gmaxwell> (not worth it for latency because esp with oppturnistic sends, latency is already stupid low) 13:57 < skeees> if you flush every block - won't that affect propagation of blocks that come in very close succession? (i assumed this was why you suggested a randomized flush) 13:59 < gmaxwell> skeees: if its flushing every block each flush will only take a fraction of a millisecond. 14:00 < gmaxwell> right now a 'flush' writes out the entire dbcache, not just one block worth of it. 14:00 < skeees> ah 14:01 < gmaxwell> that used to be required so that the chainstate on disk would be consistent with a specific block, but we don't require that anymore. 14:01 < gmaxwell> because on restart we'll just replay the effect recent blocks had on the chainstate. 14:03 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds] 14:08 < jtimon> randomly reducing the cachedb a little bit seems like an inofensive temporal fix, also simple to remove when we have the better fix 14:09 < gmaxwell> if a fix is needed at all. 14:09 < gmaxwell> which was my question. 14:11 * jtimon nods 14:24 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has quit [Quit: Oh no, not again] 14:30 -!- michaelsdunn1 [~mdunn@38.126.31.226] has quit [Remote host closed the connection] 14:30 -!- savil[m]2 [savilmatri@gateway/shell/matrix.org/x-rhajeqmfmgutpydc] has joined #bitcoin-core-dev 14:33 -!- Squidicuz [~squid@pool-173-48-82-37.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 15:04 -!- BGL [twenty@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer] 15:07 -!- tryphe_ is now known as tryphe 15:25 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 15:36 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 15:38 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 15:48 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [Ping timeout: 244 seconds] 15:50 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 15:59 -!- bitbee [~bitbee@138.197.209.248] has quit [Remote host closed the connection] 16:02 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 250 seconds] 16:05 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev 16:06 -!- satwo [~textual@2602:306:378a:6fb0:e430:daf7:201e:b7e4] has quit [Quit: Textual IRC Client: www.textualapp.com] 16:08 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 16:27 -!- vicenteH [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds] 16:28 -!- BGL [thirty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 17:06 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has quit [] 17:07 -!- StopAndDecrypt [~StopAndDe@unaffiliated/stopanddecrypt] has joined #bitcoin-core-dev 17:10 -!- grafcaps [~haroldbr@104.137.194.255] has quit [Ping timeout: 256 seconds] 17:13 -!- dqx__ [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection] 17:15 -!- dqx_ [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev 17:16 -!- dqx_ [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection] 17:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 18:05 -!- jpe_ [~jpe@200116b84209f800147509125f2bc37d.dip.versatel-1u1.de] has joined #bitcoin-core-dev 18:08 -!- jpe__ [~jpe@200116b8428ba500d32346fca66cf31a.dip.versatel-1u1.de] has quit [Ping timeout: 265 seconds] 18:17 -!- savil [~savil@c-71-202-1-72.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 18:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 18:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 18:49 -!- leishman__ [~leishman@50.237.29.22] has quit [Remote host closed the connection] 19:02 -!- jarthur [~jarthur@pool-108-4-183-133.ronkva.east.verizon.net] has joined #bitcoin-core-dev 19:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 19:34 -!- savil [~savil@c-71-202-1-72.hsd1.ca.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 20:32 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.0] 20:32 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 21:00 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 21:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 244 seconds] 21:29 -!- jarthur [~jarthur@pool-108-4-183-133.ronkva.east.verizon.net] has quit [Remote host closed the connection] 21:35 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 21:46 -!- grubles [~grubles@unaffiliated/grubles] has quit [Quit: Leaving] 21:56 -!- schmidty_ [uid297174@gateway/web/irccloud.com/x-rzgqgmwltkhczvft] has quit [Quit: Connection closed for inactivity] 21:56 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 22:09 -!- BillSmith4lyfe [BillSmith4@ip72-207-116-245.sd.sd.cox.net] has joined #bitcoin-core-dev 22:42 -!- jtimon [~quassel@213.28.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 22:53 -!- leishman [~leishman@2604:5500:c225:c500:5461:e42d:72d6:c22f] has joined #bitcoin-core-dev 22:55 -!- leishman [~leishman@2604:5500:c225:c500:5461:e42d:72d6:c22f] has quit [Remote host closed the connection] 23:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:32 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has quit [Remote host closed the connection] 23:33 -!- no_input_found [no_input_f@gateway/vpn/privateinternetaccess/noinputfound/x-24977668] has joined #bitcoin-core-dev --- Log closed Fri Jul 27 00:00:22 2018