< fanquake>
jonasschnelli: what version of Python are you using on your CI box?
< bitcoin-git>
[bitcoin] hebasto closed pull request #16469: refactoring: Use direct list initialization for Arg struct (master...20190726-remove-arg-ctor) https://github.com/bitcoin/bitcoin/pull/16469
< jonasschnelli>
fanquake: python3
< jonasschnelli>
are you setting up a CI server?
< fanquake>
jonasschnelli: yes, but 3.6, 3.7? I assume you can use something modern if setting up from scratch.
< jonasschnelli>
the readme is incomplete... and I need to commit the KVM script. the NFS setup is not mentioned...
< fanquake>
I may do, have just been looking at the .py script in the repo.
< fanquake>
#proposedmeetingtopic Do we have any contributors that are likely to be affected by GH blocking access/functionality in certain countries.
< jonatack>
fanquake: IIUC the blocking may be based on presumed nationality as well as or more than location/IP
< bitcoin-git>
bitcoin/master c88e87c Andrew Chow: Remove nFileVersion from CWalletScanState
< bitcoin-git>
bitcoin/master b3d4f6c Andrew Chow: Log the actual wallet file version
< bitcoin-git>
bitcoin/master 35e60e7 Andrew Chow: Remove ReadVersion and WriteVersion
< bitcoin-git>
[bitcoin] meshcollider merged pull request #15588: Log the actual wallet file version and no longer publicly expose the "version" record (master...rm-wallet-nfileversion) https://github.com/bitcoin/bitcoin/pull/15588
< jb55>
fanquake: they could still mail patches to the mailing list. Obviously no one does this now, but perhaps we could start making this a friendly/documented option for contributors who are blocked on GitHub.
< emilengler>
Where do I find the bitcoin-qt binary when I compile with --with-gui?
< emilengler>
Mine isn't in the src/ folder
< jonatack>
emilengler: src/qt/
< jb55>
< sipa>
< emilengler>
jonatack: Thank you
< emilengler>
sipa, jb55: Were your last messages empty or is it my system making problems because it cannot encode it?
< jb55>
emilengler: weird I see that entry in the logs, I never did a msg after jonatack
< jb55>
at that time my android weechat relay client disconnected, do you use weechat relays sipa?
< midnightmagic>
re: gitian sigs; succesful build via the "old" method is not creating identical sigs. Was there an upgrading step I missed somewhere?
< midnightmagic>
v0.18.0; all Linux builds from aarch64 to arm to riscv to x86_64 are all different for mine. Already resized the base image on my own..
< * midnightmagic>
fiddles.
< midnightmagic>
ah, did ubuntu bump bionic to a new minor? well, whatever, I'll commit my sigs anyway.
< sipa>
jb55: no i was just imitating your empty messagr
< jb55>
sipa: lol ok
< midnightmagic>
Windows builds still matching... yeah I guess the environments are different..
< midnightmagic>
Lotta new people doing the gitian builds.
< ariard>
why descriptors don't have a height prefix to ease rescanning logic instead of asking it to the user like in importmulti ?
< sipa>
ariard: because not all use cades for descriptors need that
< sipa>
there are many other pieces of metadata that are relevant when importing a descriptor ot so
< sipa>
like whether it is to be treated as change or not
< ariard>
yes but why not a height prefix as optional, like the HD derivation one ?
< sipa>
i feel like that's the wrong place to put it
< sipa>
descriptors describe a set of scriptPubKeys and the information on how to spend it
< ariard>
hmmm is it better to ask the user to remember the descriptor height ?
< sipa>
information on how it's used feels like it belongs elsewhere
< ariard>
so having a format which is a superset of descriptor to boost perfomance of rescanning logic ?
< ariard>
with more prefix annotations
< sipa>
maybe
< sipa>
i don't really care about this :)
< ariard>
got your point, but was starting to rework rescan logic, so was curious!
< ariard>
it would be useful at least for lightning backend which could send back descriptors about onchain funds to the wallet instead of transactions paying to wallet addresses
< sipa>
ariard: well the importdescriptor or whatever RPC would take a descriptor + metadata
< sipa>
for efficiency perhaps you want to even give more detailed height information (like only index 0..a after block X, but then also index a..b after block Y)
< sipa>
or information like gap limit
< bitcoin-git>
[bitcoin] hebasto opened pull request #16476: Use ArgsManager::ALLOW_STRING flag explicitly (master...20190727-pr16097-new-flags) https://github.com/bitcoin/bitcoin/pull/16476
< ariard>
sipa: yes, that would be nice optimization but IMO first step is to avoid relying on cs_main lock to do rescanning
< ariard>
by caching recent blocks in a ChainServer and serving multiple ChainClient from then
< midnightmagic>
boo, OSX mismatch too. Was there an xcode update also?
< midnightmagic>
.. except it matches post-signature combining.
< hugohn>
ariard: perhaps useful to you, I'm working on adding importdescriptors RPC command on top of achow101 ' s changes. The RPC command takes timestamps as metadata to the descriptors. But I agree with sipa that that info should not be part of the descriptor language itself. Descriptor language is strictly about describing outputs whereas time-to-scan is a user preference.
< ariard>
hugohn: thanks, yes not necessarily part of descriptors language just something easy to backup for users and easy to parse if it has rescan range/gap
< fanquake>
midnightmagic: no macOS Toolchain updates yet
< midnightmagic>
:-/
< fanquake>
midnightmagic: It’s a WIP though, theres a PR open. Feel free to leave your thoughts.