< midnight> luke-jr: My little baby-PR is sitting waiting for author. This implies you're waiting for me to correct the bits suggested in the PR and push to my PR branch..?
< luke-jr> midnight: which PR is that?
< midnight> luke-jr: #19430 I think
< gribble> https://github.com/bitcoin/bitcoin/issues/19430 | build: configure.ac and netbsd-build.md for NetBSD by midnightmagic · Pull Request #19430 · bitcoin/bitcoin · GitHub
< midnight> So I *think* all that's left is to address wumpus' request that I re-arrange the ./configure invocation..
< luke-jr> and rebase
< midnight> (In the netbsd build doc)
< midnight> k.
< luke-jr> note #19614 is merged and probably affects it
< gribble> https://github.com/bitcoin/bitcoin/issues/19614 | util: use HAVE_FDATASYNC to determine fdatasync() use by fanquake · Pull Request #19614 · bitcoin/bitcoin · GitHub
< luke-jr> mayeb silently
< midnight> likely not, as 19430 disables it on NetBSD. Likely it can be re-enabled in the future if leveldb upstream ever corrects the invocation on a directory but right now it basically just has to be disabled on NetBSD..
< midnight> So.. actually I think that corrects it more thoroughly.
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e9b30126545d...44f66d2f10cb
< bitcoin-git> bitcoin/master 333329d MarcoFalke: doc: Fix getmempoolancestor RPC result doc
< bitcoin-git> bitcoin/master 44f66d2 fanquake: Merge #19765: doc: Fix getmempoolancestors RPC result doc
< bitcoin-git> [bitcoin] fanquake merged pull request #19765: doc: Fix getmempoolancestors RPC result doc (master...2008-rpcDoc) https://github.com/bitcoin/bitcoin/pull/19765
< midnight> Hrm.. no wait that's on a file. Apologies, you're correct.
< sipa> midnight: do you have power9 hardware?
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/44f66d2f10cb...70d7ddbcbbea
< bitcoin-git> bitcoin/master 45cf55c Dhruv Mehta: test: remove `CNodeNoVersionMisbehavior` from p2p_leak.py
< bitcoin-git> bitcoin/master f6f082b Dhruv Mehta: test: remove `CNodeNoVersionIdle` from p2p_leak.py
< bitcoin-git> bitcoin/master ed5cd12 Dhruv Mehta: test: Distinguish between nodes(bitcoind) and peers(mininodes) in p2p_leak...
< bitcoin-git> [bitcoin] fanquake merged pull request #19727: test: Remove unused classes from p2p_leak.py (master...test-p2p-leak) https://github.com/bitcoin/bitcoin/pull/19727
< kallewoof> sipa: don't wanna derail the thread, but in https://github.com/bitcoin/bitcoin/pull/19628#discussion_r473522167 you are saying it's UB, but if I read your code, the only difference is that you cast `a` to a uint8_t* in the `memcpy` call; or are you referring to my second option without `memcpy`?
< sipa> kallewoof: casting any pointer to uint8_t* is allowed
< sipa> the other direction isn't
< kallewoof> freaky. i never realized casting something would have beyond-compile-time consequences
< sipa> kallewoof: you should think of memory as a bunch of objects, and those objects have a strict type
< sipa> memory is NOT a byte array
< sipa> you can access those objects through compatible pointers
< sipa> which are either the right type for the object they're pointing to (possibly with const added, or supertypes if inheritance is involved, or a few more things), OR char* OR unsigned char*
< midnight> sipa: I sure do, yes. Two of them. The second one I'm just in the process of carefully rebuilding from PNOR/BMC up to self-built OS (FreeBSD in this case.)
< midnight> Hundreds of GB RAM, and hundreds of TB of drive storage in the arrays attached to them (to greater or lesser degree.) One of them has a 4x NVMe array for speed tests, and they both have some nice SSD sprinkled around..
< sipa> midnight: luke-jr was asking about PRs for power9 support, maybe you can test things
< midnight> I can try. :)
< kallewoof> sipa: i understand what you're saying, but i'm still not entirely clear on how casting a uint32_t to a uint8_t[] would change how memcpy behaves. googling around i come up with stuff about strict aliasing which seems unrelated.
< sipa> kallewoof: what?
< sipa> memcpy has nothing to do with i
< sipa> you can't have an object of type uint8_t[], and then tell the compiler to pretend it's a uint32_t*
< kallewoof> i thought you said memcpy((uint8_t*)&a, ...) was fine but memcpy(&a, ...) was UB
< sipa> no
< sipa> `uint32_t a = *(uint32_t*)m_addr.data();` is UB
< kallewoof> that explains my confusion. okay, cool
< sipa> sorry if that wasn't clear!
< kallewoof> all good!
< kallewoof> I think https://github.com/bitcoin/bitcoin/pull/18267 is close to merge ready
< shesek> it seems like `getblockstats`'s `txs` field does count the coinbase, despite the documentation saying otherwise? `bitcoin-cli getblockstats 644498 '["txs"]'` returns 1
< shesek> the docs describe the field as "The number of transactions (excluding coinbase)"
< bitcoin-git> [bitcoin] luke-jr closed pull request #14066: gitian-linux: Build binaries for 64-bit POWER (master...gitian_power64) https://github.com/bitcoin/bitcoin/pull/14066
< sipa> #18267
< gribble> https://github.com/bitcoin/bitcoin/issues/18267 | BIP-325: Signet [consensus] by kallewoof · Pull Request #18267 · bitcoin/bitcoin · GitHub
< kallewoof> shesek: yeah it does include the coinbase: ret_all.pushKV("txs", (int64_t)block.vtx.size());
< kallewoof> sipa: BIP-325: Signet [consensus] #18267
< gribble> https://github.com/bitcoin/bitcoin/issues/18267 | BIP-325: Signet [consensus] by kallewoof · Pull Request #18267 · bitcoin/bitcoin · GitHub
< sipa> indeed, i wonder why it claims "(excludes coinbase)"
< shesek> #19766
< gribble> https://github.com/bitcoin/bitcoin/issues/19766 | getblockstatss txs field is incorrectly documented as excluding the coinbase transaction · Issue #19766 · bitcoin/bitcoin · GitHub
< shesek> sipa, total_size does exclude it, maybe this got confused somehow?
< shesek> which itself seems somewhat unexpected, and inconsistent with the `getblock` size field
< sipa> yeah, that's weird
< luke-jr> ret_all.pushKV("avgtxsize", (block.vtx.size() > 1) ? total_size / (block.vtx.size() - 1) : 0);
< luke-jr> _that_ is weird
< luke-jr> oh, it's actually measuring size manually (and does actually exclude the generation)
< jonatack> shesek: rebased PR 19405 per our irc discussion yesterday http://www.erisian.com.au/bitcoin-core-dev/log-2020-08-19.html#l-375
< shesek> jonatack, very nice, thank you!
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/70d7ddbcbbea...27eeb0337b08
< bitcoin-git> bitcoin/master 667bc7a Fabian Jahr: rpc: Add getindexinfo RPC
< bitcoin-git> bitcoin/master c447b09 Fabian Jahr: test: Add tests for getindexinfo RPC
< bitcoin-git> bitcoin/master 124e1ee Fabian Jahr: doc: Add release notes for getindexinfo RPC
< bitcoin-git> [bitcoin] laanwj merged pull request #19550: rpc: Add getindexinfo RPC (master...index_rpc) https://github.com/bitcoin/bitcoin/pull/19550
< fjahr> Review beg for #19601, would be good to get it in both for #17977 and #19055. It has two ACKs but went a bit stale the last 2 weeks.
< gribble> https://github.com/bitcoin/bitcoin/issues/19601 | Refactoring CHashWriter & Get{Prevouts,Sequence,Outputs}Hash to SHA256 (Alternative to #18071) by JeremyRubin · Pull Request #19601 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17977 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #17977 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
< theStack> is anyone here familiar with BIP 152? i try to understand the impact of receiving a sendcmpct(0) message ("low bandwidth relaying") from a peer
< theStack> looking at the code, it seems that a node happily serves cmpctblocks as response to getdata(CMPCT), even without having received sendcmpct(0) before
< theStack> so the only purpose of sendcmpct(0) is deactivating a previous sendcmpct(1) -- what did i miss?
< instagibbs> theStack, IIRC "low bandwidth" means you are telling peer to only send headers, then you can respond with a getdata for the cmpctblk
< instagibbs> high bandwidth means just send the compact version
< satoshin> Hello
< satoshin> the bitcoincore.org website is legit? I mean it is owned by core developers or it is just a stunt?
< satoshin> I own the https://bitcoin.foundation website and wish to create a list of core developers
< theStack> instagibbs: okay, i was just wondering if nodes that never received sendcmpct(0) should reply to getdata for cmpctblks or not
< theStack> https://github.com/bitcoin/bips/blob/master/bip-0152/protocol-flow.png <- it seems like the right case (C) works without the "sendcmpct(0)" as well
< satoshin> I actually trying to figure out the way to not to have Bitcoin node on public IP addresses at all. The real problem with Bitcoin is that nodes are stored on a IP address and not on devices of the participants. I did created a fork of ZeroNet (https://zeronet.io) but I did failed to share the blockchain between two nodes on this network.
< luke-jr> satoshin: soliciting donations on behalf of people without their knowledge or permission looks pretty scammy
< satoshin> luke-jr what are you talking about?
< luke-jr> satoshin: "Donate Bitcoin to the Bitcoin Foundation by sending Bitcoin donations to the Human Rights Foundation."
< satoshin> That is correct
< luke-jr> no, it isn't
< satoshin> and why you think that?
< luke-jr> well, first of all, you're not the Bitcoin Foundation
< luke-jr> the Bitcoin Foundation's website is https://bitcoinfoundation.org/
< satoshin> lol
< satoshin> You talk about the real scammers bother
< luke-jr> secondly, IIRC this "Human Rights Foundation" is itself a scam?
< satoshin> We are a Swiss human rights organization
< luke-jr> the legitimacy or not of the Bitcoin Foundation is debatable, but they are the entity
< satoshin> and we do accept Bitcoin for years pulicly
< satoshin> the New York based ultra right-wing hrf in the other hand started they website for Bitcoin to attack our finances
< satoshin> https://web.archive.org/*/hrf.org/donate-bitcoin is started in March of 2019 after that they failed to bully us with trademarks in EU and USA
< sipa> please, take this elsewhere
< sipa> this channel is for technical discussion on bitcoin core development
< satoshin> Better just not talk about
< satoshin> I know sipa
< satoshin> so I come here for a full list of code developers
< satoshin> can you give me that list?
< satoshin> core*
< achow101> satoshin: look at github
< satoshin> Thank you
< sipa> for questions on how to use bitcoin core like your question above, i suggest https://bitcoin.stackexchange.com (some people here including me are pretty active there)
< satoshin> I also would like to ask why a peer-to-peer software is developed on a centralized (censorable) network like GitHub.com we can't have something else which is not subject of abuse?
< achow101> because decentralized code repos don't work
< luke-jr> sorry, thought this was #bitcoin
< satoshin> is not true https://github.com/imachug/gitcenter this is hosted on ZeroNet achow101 do is definitelly possible to develop software on a truly peer-to-peer network
< luke-jr> … that's a GitHub link
< achow101> and now you have restricted development to the 5 people willing to set it up
< sipa> satoshin: it's a good question, and something we have discussed before - but ultimately, we don't strongly rely on github - git repositories can easily be moved
< elichai2> Is there any reason *not* to use std::array?
< luke-jr> satoshin: connection refused
< sipa> and github's ecosystem is very valuable for gathering participation
< satoshin> because it is pointed to localhost port 43110 which is requires you to install ZeroNet
< luke-jr> ZeroNet doesn't appear to even be available for Gentoo
< satoshin> it is written in python
< satoshin> you can run even on Android
< sipa> we're not going to make contributors participate through zeronet
< sipa> sorry
< satoshin> this sounded very authoritarian sipa
< sipa> there are legitimate concerns about github's centralization, and we have to be watchful for those
< sipa> but this discussion isn't helpful
< luke-jr> ZeroNet doesn't even look decentralised
< achow101> the more steps it takes to get new people to contribute means that there will be fewer contributors. we need more people to contribute and making it more difficult to contribute in the name of decentralization is not helpful
< satoshin> you basically saying we not going to develop a peer-to-peer electronic cash system on a peer-to-peer network which is absurd in my opinion. you make a decision about where Bitcoin will be developed like you own the copyright to Bitcoin or something
< elichai2> (trying to figure out why will people use fresh hell code like `void f(uint8_t (&arr)[N])`)
< satoshin> Copyright (c) 2009 Satoshi NakamotoPermission is hereby granted, free of charge, to any person obtaining a copyof this software and associated documentation files (the "Software"), to dealin the Software without restriction, including without limitation the rightsto use, copy, modify, merge, publish, distribute, sublicense, and/or sellcopies of the
< satoshin> Software, and to permit persons to whom the Software isfurnished to do so, subject to the following conditions:The above copyright notice and this permission notice shall be included inall copies or substantial portions of the Software.THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS ORIMPLIED, INCLUDING BUT NOT LIMITED TO
< achow101> sipa is stating a fact, not making a decision
< satoshin> This is from bitcoin version 0.1.0
< sipa> satoshin: we have discussed alternatives for github many times among contributors and maintainers
< * luke-jr> goes to figure out why #19614 seems to be completely broken and merged
< gribble> https://github.com/bitcoin/bitcoin/issues/19614 | util: use HAVE_FDATASYNC to determine fdatasync() use by fanquake · Pull Request #19614 · bitcoin/bitcoin · GitHub
< sipa> satoshin: copyright has nothing to do with it, you are free to create your own branch that you maintain anywhere
< sipa> elichai2: that's a good question...
< satoshin> That is correct but feels very restricted to contribute to the core
< luke-jr> satoshin: I am happy to open pull requests for any contributors who don't want to sign up for GitHub
< phantomcircuit> satoshin, please don't copy paste things like that
< satoshin> okay
< sipa> elichai2: i could imagine that there is a use for accepting string literals of compile-time known length
< sipa> and interaction with legacy code, i guess
< sipa> satoshin: as luke said, if somehow github isn't an option for whatever reason for someone who wants to contribute, you're always welcome to use email or other mechanisms to send a patch to other contributors, or maintainers
< satoshin> I also uploaded the Bitcoin white paper dating from October 3 2008 to here: https://archive.org/details/bitcoin-a-peer-to-peer-electronic-cash-system I was astonished that this is not shared on bitcoin.org! What I uploaded to archive is what Satoshi Nakamoto announced on https://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html and
< satoshin> not what shared on bitcoin.org/bitcoin.pdf
< sipa> if that were needed on a regular basis, that would be a good reason to reconsider the use of github to host things
< sipa> satoshin: open an issue: https://github.com/bitcoin-dot-org/bitcoin.org
< achow101> satoshin: it's right here: https://bitcoin.org/bitcoin.pdf
< achow101> literally the same url as in the email
< satoshin> that is not the original white paper archow101
< sipa> (bitcoin.org is owned and operated indepedently from the bitcoin core project)
< harding> achow101: I think he means that the papers differ. Nakamoto edited the version served from Bitcoin.org at some point.
< elichai2> sipa: yeah compile time length string literals is nice
< sipa> satoshin: getting very off topic
< satoshin> Fine, I go open that issue on https://github.com/bitcoin-dot-org/bitcoin.org
< satoshin> They don't have IRC channel?
< theStack> just out of curiosity, what is the difference in the whitepaper versions? e-mail seems different
< sipa> i don't know
< satoshin> theStack there are some differences if you read it, even page number differs not to mention the creation date which is October 3 2008 weeks before he announced it
< satoshin> Actually at one point https://archive.org/details/bitcoin-a-peer-to-peer-electronic-cash-system was uploaded to Bitcoin.org according to his announcement. I actaully do have Bitcoin v 0.1.0 also which is compressed by Satoshi for release on 7 January 2009, 4 days after the genesis block.
< harding> For Bitcoin nostalgia, #bitcoin is a better room.
< satoshin> Just to be clear actually Satoshi made a mistake in January of 2009 and I was able to track him down. I know who is him. He is over 50 now, lives in the UK and has children. He also loves Sushi. Beleive me I do know who is Satoshi Nakamoto and I can tell you that much that the Bitcoin white paper was not his first white paper. I did tested all his
< satoshin> publications with JGAAP (Java Graphical Authorship Attribution Program) and it is confirmed that he wrote the Bitcoin white paper. Satoshi made a huge mistake when started promoting Bitcoin with Hal Finney and this allowed me Zoltan Konder to track him down. I will announce his identity on https://bitcoin.foundation in the coming days!
< satoshin> If you want to know before who is Satoshi Nakamoto or you think is the best to not to share his identity I would like to read your arguments by email: contact@bitcoin.foundation (Satoshi Nakamoto is one person and he still lives until this day in the UK) I swear to God. Again the real reason why he used a Japanese name is because he loves Sushi! :)
< satoshin> Which is kind of funny.
< sipa> please leave, now
< satoshin> LOL you afraid that Satoshi Nakamot returns sipa and your fame ends? Well that exactly going to happen my friend. I do know who is him and you my friend will go to the trash.. you become useless right after the entire world will know his name
< luke-jr> so fyi, fdatasync is broken in master until #14501 is merged
< gribble> https://github.com/bitcoin/bitcoin/issues/14501 | Fix possible data race when committing block files by luke-jr · Pull Request #14501 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] luke-jr closed pull request #15421: torcontrol: Launch a private Tor instance when not already running (master...tor_subprocess) https://github.com/bitcoin/bitcoin/pull/15421
< jeremyrubin> Anyone have any opinions on standardizing (I know, I know... build first then standardize) some different ways to refer to TXID?
< jeremyrubin> It might be kinda nice for human I/O to have something that is encoded in fewer chars with error correcting
< jeremyrubin> and can refer to either a TXID or an outpoint in the same length
< jeremyrubin> you could imagine using a bech format to encode these.
< jeremyrubin> Supporting software would have to keep a larger index around for full support
< sipa> what do you mean by fewer chars?
< jeremyrubin> E.g., a TXID hex encoded is 64 characters
< jeremyrubin> a COutpoint hex encoded is 72 characters
< jeremyrubin> using a bech32 encoding would be shorter than hex and you'd get error correction
< sipa> it'd be 60 characters with bech32 at least
< sipa> and it's not really designed for error correction
< jeremyrubin> err detection
< sipa> i feel it's one of those things that's just a decade too late to change
< sipa> it would have made sense, but adding a new format now is just going to confuse everyone
< luke-jr> woohoo #17356 is now hack-free
< gribble> https://github.com/bitcoin/bitcoin/issues/17356 | RPC: Internal named params by luke-jr · Pull Request #17356 · bitcoin/bitcoin · GitHub
< jeremyrubin> sipa: do we even have any standard format for TXIDs/COutpoints?
< sipa> for txids, definitely
< sipa> outpoints less so i think; some places use txid-idx, some places used txid:idx
< jeremyrubin> And are idxs hex encoded or integer?
< sipa> decimal, iirc
< jeremyrubin> lol
< jeremyrubin> so might not be too late to do a std format for outpoints if it's a split ecosystem (motivation -- I was looking for how to properly handle user input and didn't have anything to go on)
< wumpus> is there a way we can make "good first issue" only available for frequent contributors?
< wumpus> people are using it for everything it's kind of getting out of hand https://twitter.com/GoodFirstIssues
< jeremyrubin> available? visisble? taggable?
< wumpus> yes
< jeremyrubin> not sure what you're asking
< jeremyrubin> Only frequent comitters can solve them?
< wumpus> to be able to make issues like that
< sipa> wumpus: or make the bot only report them if they come from frequent contributors?
< wumpus> yes, that would be another possibility
< jeremyrubin> sounds like a good first issue to fix the bot
< wumpus> but it would be better to just hide the option I think, non-contributors don't know what it's for
< sipa> where are the available labels even configured?
< wumpus> but I guess there's no way to set permissions
< bitcoin-git> [bitcoin] luke-jr opened pull request #19770: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by "permissions") (master...deprecate_whitelisted) https://github.com/bitcoin/bitcoin/pull/19770
< sipa> can we perhaps remove the "good first issue" label from that template?
< sipa> and have it be assigned by maintainers instead of it's not bogus
< sipa> ... more manual work though :s
< wumpus> hmm maybe that might be the best compromise
< sipa> what are permissions on labels, actually?
< sipa> can someone who opens an issue set them arbitrarily?
< luke-jr> I don't think I can change labels :/
< luke-jr> quite annoying tbh
< luke-jr> at least I don't see any way to do it
< sipa> oh, ok, so the issue is just that the template comes with a preset label
< luke-jr> is there a reason to have a template for good first issue?
< luke-jr> doesn't seem like soemthing an issue opener would typically be qualified to evaluate
< wumpus> it's just for convenience, to have form items necessary to be filled in for a good first issue
< wumpus> and yes for normal label setting (that doesn't come with a template) it's restricted to people with 'triage' permission IIRC
< luke-jr> oh, it's separate from commit?
< luke-jr> any reason not to just give access to everyone usual then?
< wumpus> yes there is a permission between 'read' and 'write' which is enough to change labels but not enough to commit to the repository (unfortunately, "write" is still required to put issues in projects)
< wumpus> #startmeeting
< lightningbot> Meeting started Thu Aug 20 19:00:47 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
< jnewbery> hi
< jonasschnelli> hi
< kanzure> hi
< sipa> hi
< ariard> hi
< troygiorshev> hi
< hebasto> hi
< sipsorcery> hi
< wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
< wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
< achow101> hi
< luke-jr> wow, those 'hi's seem coordinated
< instagibbs> hi
< fjahr> hi
< luke-jr> did someone make a cronjob to 'hi'?
< sipa> we were all waiting wumpus to ring the bell
< luke-jr> heh
< amiti> hi
< wumpus> there have been no proposed topics this week, any last minute ones?
< wumpus> hehe
< jamesob> hi
< luke-jr> wumpus: maybe giving everyone triage is worth a discussion? shrug
< wumpus> nah
< elichai2> hi
< ajonas> hi
< wumpus> I think it will only be confusing if everyone adds "needs backport" labels and such, I don't think we have any problkem with labeling, usually fanquake is fast enough that by the time I click the link here an issue is already labeled
< wumpus> xD
< sipa> i have the same impression, and i'm in a completely different timezone...
< wumpus> #topic High priority for review
< jeremyrubin> hi
< wumpus> https://github.com/bitcoin/bitcoin/projects/8 there's 10 blockers, a bugfix and 3 chasing concept ACK
< wumpus> is there anything you want to add or remove or replace?
< hebasto> please replace #18710 with #19710 as the former is based on the latter now
< gribble> https://github.com/bitcoin/bitcoin/issues/18710 | Add local thread pool to CCheckQueue by hebasto · Pull Request #18710 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19710 | bench: Prevent thread oversubscription and decreases the variance of result values by hebasto · Pull Request #19710 · bitcoin/bitcoin · GitHub
< achow101> Since #19077 is waiting on #19619, replace it with that?
< gribble> https://github.com/bitcoin/bitcoin/issues/19619 | Remove wallet.dat path handling from wallet.cpp, rpcwallet.cpp by ryanofsky · Pull Request #19619 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
< wumpus> hebasto: done
< hebasto> thanks
< luke-jr> #14501 might be a candidate
< gribble> https://github.com/bitcoin/bitcoin/issues/14501 | Fix possible data race when committing block files by luke-jr · Pull Request #14501 · bitcoin/bitcoin · GitHub
< jnewbery> wumpus: I believe people with the inbetween permission can move PRs and issues in and out of projects
< wumpus> achow101: done
< luke-jr> especially since we have a regression in master that is now fixes
< wumpus> jnewbery: not with triage last time we checked! might have changed ofc
< wumpus> luke-jr: ok added
< wumpus> any other topics?
< wumpus> #endmeeting
< lightningbot> Meeting ended Thu Aug 20 19:11:32 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< michaelfolkson> What is the thinking around any other topics? Is it literally throw anything out there and people can leave if they want or should topics be of interest to most attendees so that we value everyone's time?
< luke-jr> depends on how many topics we have I think
< michaelfolkson> Ok that's fair
< achow101> IMO an "any other topics" that's at the start of a meeting is an invitation to talk about almost anything
< achow101> at the end of the meeting, it's more of "something important that we should discuss"
< michaelfolkson> To throw some things out there then we were discussing switching from Qt widget to Qt QML on the GUI. This would bloat the binary so interested in whether this is most likely an overall Concept NACK (that was our guess)
< wumpus> as long as it has to doe with bitcoin core development, preferably something you're working on, it's okay
< wumpus> I don't have any principled issues about it, if you can demonstrate a better UI using QML, I think it's okay
< wumpus> please don't do it if you just want an animated bitcoin logo or something
< wumpus> like the increase of binary size of dependencies needs to be worth the improvement in UX
< michaelfolkson> Yeah understood. May not pursue it but it is useful sometimes to put feelers out and see whether something is a clear Concept NACK or not
< achow101> michaelfolkson: is there a relevant issue that has some existing discussion?
< wumpus> and not just 'fancyness'
< achow101> what are the benefits of QML?
< michaelfolkson> The GUI discussion is just getting started so no not yet achow101
< wumpus> see #16883 I think
< gribble> https://github.com/bitcoin/bitcoin/issues/16883 | WIP: Qt: add QML based mobile GUI by icota · Pull Request #16883 · bitcoin/bitcoin · GitHub
< wumpus> it's better suited for mobile atleast
< michaelfolkson> On the call with some potential new contributors (designers) just trying to work out exactly what the constraints were likely to be
< michaelfolkson> I won't name people at this stage but one designer had a lot of experience with QML
< wumpus> qt widgets are very oldschool desktop, it's almost impossible to use them on android conveniently for example
< achow101> ah, so it makes it look like we're an electron app :p
< wumpus> it's definitely much more efficient than electron
< luke-jr> wumpus: is there an actual reason for that, or just Qt not implementing mobile for widgets, preferring to rewrite GUI logic for QML? <.<
< luke-jr> does QML require a JS engine?
< michaelfolkson> Yeah as I understand
< wumpus> QML is used in a lot of embedded systems like kiosks and in-flight entertainment systems etc
< wumpus> yes, I think so
< luke-jr> ugh
< sipa> is it really a JS engine?
< sipa> or is it compiled to C++?
< wumpus> it's really a scripting engine
< wumpus> which also means you can iterate the GUI without recompiling, which can be great
< sipa> The JavaScript environment provided by QML is stricter than that in a web browser. For example, in QML you cannot add to, or modify, members of the JavaScript global object. In regular JavaScript, it is possible to do this accidentally by using a variable without declaring it. In QML this will throw an exception, so all local variables must be explicitly declared. See JavaScript Environment
< sipa> Restrictions for a complete description of the...
< sipa> restrictions on JavaScript code executed from QML.
< wumpus> it's also 'local only'
< wumpus> you can only open images from the local resourcees IIRC not accidentaly from the network/internet
< luke-jr> seems like a good way to lag the UI :x
< wumpus> no, it's faster
< wumpus> uses opengl ES2 for rendering
< jonasschnelli> How about the memory footprint?
< luke-jr> how can JS be faster than C++?
< luke-jr> wumpus: Qt Widgets uses OpenGL too. But that's not a good thing :P
< luke-jr> there's no reason 2D should use OpenGL..
< jonasschnelli> And how indifferent will it look on win/Linux/Mac?
< wumpus> well it can do all kinds of fancy animations, alsao on low end hardware
< wumpus> maybe the per-frame processing happens in C++ still
< luke-jr> low end hardware without OpenGL?
< wumpus> the scipting just defines the animation
< wumpus> even the most low-end embedded crap has OpenGL ES 2 these days
< jonasschnelli> Sounds interesting... I guess it would look different then the typical system UI?
< luke-jr> wumpus: with non-free drivers maybe
< wumpus> anyhow, I didn't actually mean to defend QML, but if we reject it we should do it for proper reasons not just 'because it's a different way of doing things'
< sipa> ^
< luke-jr> jonasschnelli: kinda would defeat the purpose of Qt if so
< michaelfolkson> "IMHO it's still too early to consider QML since that there are some issues regarding long operations blocking the Qt event loop." This was promag in Sep 2019
< wumpus> I agree that'[s a long-running issue, and this is just as much a problem for qt widgets though :)
< bitcoin-git> [bitcoin] luke-jr opened pull request #19771: net: Replace enum CConnMan::NumConnections with enum class ConnectionDirection (master...enum_conndir) https://github.com/bitcoin/bitcoin/pull/19771
< sipa> did anyone stop receiving github mail notifications ~an hour ago?
< fanquake> sipa: I don’t think so. Seem to have plenty from drahtbot
< sipa> apparently my mail app changed semantics, and now right swiping is mark spam by default... so i had some github thread marked as spam, and subsequently all other github mails were marked as spam too
< sipa> resolved now!
< fanquake> #innovative UI
< bitcoin-git> [bitcoin] luke-jr closed pull request #19117: RPC: Add getrpcwhitelist method (master...rpc_getrpcwhitelist) https://github.com/bitcoin/bitcoin/pull/19117