< Bilnon> I dont know how these idiot get their papers published, this is a terrible idea written by morons who clearly cant grasp even the basic concepts of bitcoin
< Bilnon> how the hell is this paper on arvix
< Bilnon> all this paper is useful for is reference material to backup an elaborate scam project
< sipa> arxiv is not "published"; it's a preprint server
< sipa> it is not reviewed
< Bilnon> ah i see
< Bilnon> where would I find published papers
< roconnor> Published in: 2019 IEEE International Conference on Blockchain and Cryptocurrency (ICBC)
< sipa> now, that's more concerning
< Bilnon> what is more concerning sipa?
< sipa> oh, roconnor was just giving an example, not claiming this particular paper was also published in ICBC?
< Bilnon> https://ieeexplore.ieee.org/Xplore/home.jsp > 5,357,020 articles X'D
< Bilnon> sipa yes i believe he was just pointing me in the right direction
< Bilnon> I think Vitalik is a complete fraud too tbh
< Bilnon> I thought his "Ethereum 2.0" whitepaper was a shambles, and most of what he says online just seems to be regurgitated copy-pasta
< sipa> this is getting off-topic
< Bilnon> a pseudo intellectual - just trying to maintain a peg as a creditable voice within cypto
< Bilnon> this guy is just as bad, rattles on about some nonsense for most of it treating the reader like they just picked up a "teach yourself ML for dummies in 6 hours" book
< Bilnon> urgh they all revolve around using ML as intelligent mining alternatives so unorignal and vague, throw these sub-humans in the blender plz
< roconnor_> Bilnon's arxiv paper was published at that IEEE conference.
< roconnor_> sorry, you are right this is off topic
< Bilnon> "hybrid consensus (DAG PoS + uPoW)"
< Bilnon> suggested ontopic grouo?
< Bilnon> what gets to me the most with acronyms like "uPoW" is how much these people take for granted the proof-of-work scheme used in bitcoin, like that useful proofs of work could be integrated at all without converting the entire system to a PoS system,
< Bilnon> how can people be this thick and not understand how PoW works at all, completely miss the point of what makes it such a good system.
< sipa> you're preaching to the choir here
< sipa> and it's unrelated to the development of the bitcoin core software
< Bilnon> just throwing it out there, thought there might be some people who agree
< Bilnon> https://ieeexplore.ieee.org/document/8855738 - "Is Bitcoin Mining Halal? Investigating the Sharia Compliance of Bitcoin Mining"
< sipa> last warning: this is off topic
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/531c2b7c0489...fdf9b3eba3bc
< bitcoin-git> bitcoin/master 0c845e3 Hennadii Stepanov: test: Fix wallet_listdescriptors.py if bdb is not compiled
< bitcoin-git> bitcoin/master fdf9b3e fanquake: Merge bitcoin/bitcoin#22446: test: Fix wallet_listdescriptors.py if bdb is...
< bitcoin-git> [bitcoin] fanquake merged pull request #22446: test: Fix wallet_listdescriptors.py if bdb is not compiled (master...210714-desc) https://github.com/bitcoin/bitcoin/pull/22446
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/fdf9b3eba3bc...e2c4ac7cfb58
< bitcoin-git> bitcoin/master 5a1ed96 Jon Atack: test: whitelist rpc_rawtransaction peers to speed up tests
< bitcoin-git> bitcoin/master a3d6ec5 Jon Atack: test: move rpc_rawtransaction tests to < 30s group
< bitcoin-git> bitcoin/master e2c4ac7 fanquake: Merge bitcoin/bitcoin#22447: test: whitelist rpc_rawtransaction peers to s...
< bitcoin-git> [bitcoin] fanquake merged pull request #22447: test: whitelist rpc_rawtransaction peers to speed up tests (master...speed-up-rpc_rawtransaction-test) https://github.com/bitcoin/bitcoin/pull/22447
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e2c4ac7cfb58...97153a702600
< bitcoin-git> bitcoin/master fa11fec MarcoFalke: doc: Move buried deployment doc to the enum that enumerates them
< bitcoin-git> bitcoin/master fa5658e MarcoFalke: Use DeploymentEnabled to hide VB deployments
< bitcoin-git> bitcoin/master 97153a7 MarcoFalke: Merge bitcoin/bitcoin#22385: refactor: Use DeploymentEnabled to hide VB de...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22385: refactor: Use DeploymentEnabled to hide VB deployments (master...2107-dep) https://github.com/bitcoin/bitcoin/pull/22385
< jnewbery> laanwj MarcoFalke: looks like #22415 is RFM
<@gribble> https://github.com/bitcoin/bitcoin/issues/22415 | Make m_mempool optional in CChainState by jamesob · Pull Request #22415 · bitcoin/bitcoin · GitHub
< tutwidi[m]> Why satoshi 21.1 only one peers in real connected? Can you explain
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22453: fuzz: Speed up rolling_bloom_filter fuzz test (master...2107-fuzzRoll) https://github.com/bitcoin/bitcoin/pull/22453
< tutwidi[m]> there really shouldn't be any debate here. this should be the place to focus on better development
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22454: fuzz: Limit max ops in tx_pool fuzz targets (master...2107-fuzzPool) https://github.com/bitcoin/bitcoin/pull/22454
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/97153a702600...c0224bc96287
< bitcoin-git> bitcoin/master 6176617 James O'Beirne: validation: make CChainState::m_mempool optional
< bitcoin-git> bitcoin/master 46e3efd James O'Beirne: refactor: move UpdateMempoolForReorg into CChainState
< bitcoin-git> bitcoin/master 4abf077 James O'Beirne: refactor: no mempool arg to GetCoinsCacheSizeState
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22415: Make m_mempool optional in CChainState (master...2021-07-mempool-ptr) https://github.com/bitcoin/bitcoin/pull/22415
< bitcoin-git> [bitcoin] vasild opened pull request #22455: addrman: detect on-disk corrupted nNew and nTried during unserialization (master...addrman_detect_negative) https://github.com/bitcoin/bitcoin/pull/22455
< bitcoin-git> [bitcoin] hebasto opened pull request #22456: [WIP] build: Use specific cross-compilers instead of multilib one (master...210715-multilib) https://github.com/bitcoin/bitcoin/pull/22456
< vasild> jnewbery: https://github.com/bitcoin/bitcoin/pull/22455 -- the underlying issue is that nNew came as -1 from disk (fuzzer), from here one way or another we are f**d up
< vasild> one more clarification: if ResetI2PPorts() is removed from Unserialize() (== remove commit e0a2b39), then that fuzzer input does not produce a crash, which may create the impression that ResetI2PPorts()/e0a2b39 is the problem, but it is not. It does not crash because that fuzzer input contains nNew=-1 and only "tried" entries (no "new" ones) and in order to crash later in serialize it is
< vasild> necessary to have at least one "new" and nNew=-1
< vasild> ResetI2PPorts() just adds one "new" entry
< vasild> It should be possible to produce an input which crashes even when ResetI2PPorts()/e0a2b39 is removed: nNew=1 and one new entry
< vasild> I mean nNew=-1 and one new entry
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/c0224bc96287...21998bc028d6
< bitcoin-git> bitcoin/master 566357f Jon Atack: refactor: move GetRandomNodeEvictionCandidates() to test utilities
< bitcoin-git> bitcoin/master 5adb064 Jon Atack: bench: add peer eviction protection benchmarks
< bitcoin-git> bitcoin/master 02e411e Jon Atack: p2p: iterate eviction protection only on networks having candidates
< bitcoin-git> [bitcoin] laanwj merged pull request #22284: p2p, refactor: performance improvements to ProtectEvictionCandidatesByRatio() (master...ProtectEvictionCandidatesByRatio-perf-enhancements) https://github.com/bitcoin/bitcoin/pull/22284
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #22457: refactor: Remove unused disconnectpool is nullptr feature (master...2107-refactorDisconnectPool) https://github.com/bitcoin/bitcoin/pull/22457
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/21998bc028d6...d86e6625e857
< bitcoin-git> bitcoin/master 2584929 Wladimir J. van der Laan: doc: Add steps for transifex to release process
< bitcoin-git> bitcoin/master a16378e Wladimir J. van der Laan: doc: Remove unnecessary steps from translations update process
< bitcoin-git> bitcoin/master d86e662 W. J. van der Laan: Merge bitcoin/bitcoin#22369: doc: Add steps for Transifex to release proce...
< bitcoin-git> [bitcoin] laanwj merged pull request #22369: doc: Add steps for Transifex to release process (master...update-transifex-release-process) https://github.com/bitcoin/bitcoin/pull/22369
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d86e6625e857...853ac47705c8
< bitcoin-git> bitcoin/master fa84cae Brian Liotti: doc: added info to bitcoin.conf doc
< bitcoin-git> bitcoin/master 853ac47 MarcoFalke: Merge bitcoin/bitcoin#22393: doc: added info to bitcoin.conf doc
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #22393: doc: added info to bitcoin.conf doc (master...patch-1) https://github.com/bitcoin/bitcoin/pull/22393
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/853ac47705c8...a88fa1a55519
< bitcoin-git> bitcoin/master ba45f02 Vasil Dimov: net: relay I2P addresses even if not reachable (by us)
< bitcoin-git> bitcoin/master 8674281 Vasil Dimov: test: use NODE_* constants instead of magic numbers
< bitcoin-git> bitcoin/master 33e211d Vasil Dimov: test: implement ser/unser of I2P addresses in functional tests
< bitcoin-git> [bitcoin] laanwj merged pull request #22211: net: relay I2P addresses even if not reachable (by us) (master...i2p_IsRelayable) https://github.com/bitcoin/bitcoin/pull/22211
< laanwj> rc1 looks pretty close? just #22387 (well-reviewed, alsmost ready to merge?) and #22421 (rfm, but a small refactor is requested, no need for it to be a blocker though), #21711 (documentation, ready to go, but could go in later)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22387 | Rate limit the processing of rumoured addresses by sipa · Pull Request #22387 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22421 | Make IsSegWitOutput return true for taproot outputs by sipa · Pull Request #22421 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/21711 | guix: Add full installation and usage documentation by dongcarl · Pull Request #21711 · bitcoin/bitcoin · GitHub
< laanwj> depending on #22450 i guess
<@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
< laanwj> depending on how serious that problem is we might still do rc1 without it, just to get wider testing going, as there will likely be many other issues (due to changing the build system, for example), it'd be unlikely for rc1 to be final
< jonatack> yay! (will propose an update for the hardcoded seeds and doc/i2p.md -- warn it can be slow for IBD and maybe some info about routers, that people continue to report / ask for -- those can go in later)
< laanwj> great! yes might be a good idea to make those wait for after rc1, a lot of people will likely be testing with I2p for the first time so i suppose there will be more changes there
< robertspigler> Exciting times!
< ariard> #proposemeetingtopic coredev quick updates
< ron-slc> any word on why bitcoin.org is down?
< luke-jr> ron-slc: Cobra was ranting about it being DDoS'd on Twitter
< luke-jr> off-topic here tho, further ?s to #bitcoin please
< jnewbery> laanwj: it looks to me like #22112 introduced a way for addrman's data to become inconsistent. I think we need a fix for that before we cut an rc1
<@gribble> https://github.com/bitcoin/bitcoin/issues/22112 | Force port 0 in I2P by vasild · Pull Request #22112 · bitcoin/bitcoin · GitHub
< sipa> that sounds scary
< bitcoin-git> [bitcoin] achow101 opened pull request #22461: wallet: Change ScriptPubKeyMan::Upgrade default to True (master...implement-desc-upgrade) https://github.com/bitcoin/bitcoin/pull/22461
< laanwj> it wasn't clear to me how the bug can be triggered
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #22457: refactor: Remove unused "disconnectpool is nullptr" feature (master...2107-refactorDisconnectPool) https://github.com/bitcoin/bitcoin/pull/22457
< MarcoFalke> This should only affect I2P?
< MarcoFalke> which is experimental anyway
< laanwj> it affects nodes that have I2P addresses in their addrman, but i guess pre-0.22 won't store them
< laanwj> but it may cause problems later, as they accumulate; as long as we don't know the exact cause it's risky
< laanwj> #startmeeting
< core-meetingbot> Meeting started Thu Jul 15 19:00:17 2021 UTC. The chair is laanwj. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< hebasto> hi
< meshcollider> hi
< laanwj> #bitcoin-core-dev Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos
< laanwj> nehan NicolasDorier paveljanik petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
< achow101> Hi
< kvaciral[m]> hi
< laanwj> one proposed meeting topic: coredev quick updates (ariard)
< laanwj> any last minute ones?
< ariard> hi
< laanwj> #topic 22.0
< core-meetingbot> topic: 22.0
< MarcoFalke> blocked by #22450, I guess (per previous discussion)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
< laanwj> we're getting even closer, the last PRs are nearly ready for merge https://github.com/bitcoin/bitcoin/milestone/47 , after which we should tag rc1 imo, but some last-minute issue came up while fuzzing addrman serialization (#22450)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22450 | addrman serialize: nNew was wrong, oh ow · Issue #22450 · bitcoin/bitcoin · GitHub
< jonatack> hi
< MarcoFalke> sipa: What is the status of #22421 ?
<@gribble> https://github.com/bitcoin/bitcoin/issues/22421 | Make IsSegWitOutput return true for taproot outputs by sipa · Pull Request #22421 · bitcoin/bitcoin · GitHub
< jamesob> hi
< laanwj> it seems to do what is said, so i'm fine with merging it as-is and doing the requested refactor later
< laanwj> but as rc1 is blocked on something else there is no need to rush
< MarcoFalke> Agree that there is no rush, but I have a slight preference to merge code that will be removed again right after
< MarcoFalke> *not
< gene> hi
< sipa> hi
< laanwj> that's what i mean with there being no rush, we can wait a few days probably for sipa to change it or someone else to open a PR that takes it over if he isn't able to
< sipa> sorry, my computed died
< laanwj> if we wanted to cut rc1 tonight it'd be different and we could just merge it as-is
< laanwj> but that's not going to happen
< sipa> what do you need me to change?
< luke-jr> [19:04:24] <gribble> https://github.com/bitcoin/bitcoin/issues/22421 | Make IsSegWitOutput return true for taproot outputs by sipa · Pull Request #22421 · bitcoin/bitcoin · GitHub
<@gribble> https://github.com/bitcoin/bitcoin/issues/22421 | Make IsSegWitOutput return true for taproot outputs by sipa · Pull Request #22421 · bitcoin/bitcoin · GitHub
< sipa> oh, the switch case? will do
< laanwj> MarcoFalke's suggestion about using a switch statement so future added TxoutTypes will turn up ac ompiler warning about a missing case
< laanwj> yes
< laanwj> #topic Coredev quick updates (ariard)
< core-meetingbot> topic: Coredev quick updates (ariard)
< ariard> hi
< ariard> so i sent the invits beginning of weeks, have already 19 yes
< ariard> half-americans/half-europeans
< laanwj> nice!
< ariard> bad news, the health policy of the location has changed drastically in the last 48 hours
< luke-jr> >_<
< ariard> 19, excluding orgas
< ariard> the nos so far are in majority are aussies friends :/
< ariard> hard to them to leave the country
< hebasto> ariard: is there a link to the updated list of vaccines that are approved by France?
< ariard> hebasto: i think that's an european thing, but will check and follow with you
< hebasto> thanks!
< MarcoFalke> The thing that changes was the "health passport"?
< MarcoFalke> *changed
< jonatack> i've been following things very closely. the announcement is potentially pretty inconvenient for the non-treated. however, it remains to be seen what will be passed.
< ariard> we crunched a bit of news with orgas on the last days and it sounds this health pass will be really applied
< ariard> MarcoFalke: yep, and really enforcement of it and clear will of local authorities to harden it
< luke-jr> "non-treated"?
< jonatack> for now, it's only an announcement by macron and the "science council"
< jonatack> luke-jr: those who did not get the injection, as the french govt would say
< ariard> luke-jr: either recovery/vaccinate or PCR every 48h to do any kind of public activities
< jonatack> PCR or antigen or a test result in the last 6 months that one was positive
< ariard> it's still super early and we have the option to change the location in another country, more peaceful
< ariard> still with the same date as a fixed point
< luke-jr> tbh that sounds reasonable tho
< sipa> will they recognize vaccinations given in other countries? the US doesn't really give you any kind of recognizable certificate
< sipa> just a piece of paper that the pharmacist fills in
< ariard> sipa: i think so, at least it's expected to make thing bearable for us tourists
< jonatack> for entry, as before, and what macron is asking is for all of the shopping centers, bars, and restaurants to check identity and health status for each customer....i'm not sure how realistic it is
< ariard> though things can change from a week to another, and the eu wake up a morning and withdraw a vaccin from the authorized list
< jonatack> again, law not passed, only proposed by the executive
< sipa> the location does seem a bit annoying to reach, though
< sipa> needs 1+ extra flight compared to most major european cities
< ariard> yeah french curfew wasn't effectively applied in the last week of its validity in may/june
< ariard> sipa: i know though restrictions if existent will be far more cool, which was the rational
< ariard> given it's not major hub
< sipa> hmm, i don't follow
< sipa> but ok, doesn't really matter for me
< ariard> countryside might not enforce covid restrictions
< jonatack> there can be pretty wide gulf between what is said and what is done
< sipa> ah, i'd expect it to be country-wide, but perhaps that makes sense
< jonatack> this is a latin country ;)
< ariard> sipa: yeah it's france there is was decreted in paris and the rest of the country
< jonatack> the police don't want to enforce it. will likely be enforced via exceptions, not the rule.
< ariard> s/was/what/g
< sipa> well, people still need to be able to enter the county
< sipa> +r
< jonatack> we were talking about destinations that have no restrictions. atm seems like mexico and costa rica.
< ariard> that said, we reviewed quickly alternative europeans/middle america locations with loosened covid restrictions
< ariard> sipa: us can enter eu since beginning of june for tourisms travels purpose
< sipa> well, keep us posted
< ariard> the question: is it worhty to play a safer fallback plan now, with lesser covid restrictions to replace france ?
< ariard> like portugal or switzerland
< laanwj> right, let's see how this develops for a bit, better to not book travel yet
< ariard> agree, or if you do so tick the repleacable box for once
< jonatack> portugal just became a hot zone that is hard to return from
< BlueMatt> ariard: I mean the restrictions as-proposed don't seem insane or even that annoying, its moreso if those restrictions change.
< ariard> okay let's how things evolve, we keep in mind a sound fallback plan if we have to do so
< ariard> BlueMatt: yeaaah it should be okay for now if it stays as so...
< luke-jr> less restrictions now could mean more later due to COVID spread?
< BlueMatt> right, also that
< BlueMatt> not to mention less restrictions now could mean people dont want to go if there's covid spread there come end-of-year lol
< jonatack> BlueMatt: TBH what they want is vaccinations, if you are then you're good. for those who aren't, it could be more inconvenient. that is their goal.
< ariard> luke-jr: we're considering really geographically isolated places with stable covid restrictions on the last 9 months
< jonatack> unless they close the borders again but last year that didn't happen until december IIRC
< BlueMatt> jonatack: I mean have y'all bothered to ask if people *are* vaccinated? In my experience among bitcoin *developers* its like 100%. among bitcoin twitter users its much different.
< jamesob> not vax'd
< luke-jr> definitely not 100%
< ariard> BlueMatt: lol i'm not and don't plan to do so :p
< sipa> wut
< luke-jr> I know at least 3 who aren't
< jonatack> BlueMatt: nope, many aren't and a number indicated to me that they won't come if it's a requirement
< BlueMatt> ariard: sure, some qualify under "had postitive test and thus dont care" :)
< ariard> BlueMatt: mainly that if you've aready bee positive in the last months
< sipa> oh, sure
< ariard> we have also few folks in countries when its *hard* to get a vaccin :/
< sipa> that may change in the coming months though
< ariard> hopefully, yes
< BlueMatt> let me rephrase, is there anyone who (a) hasn't *had* covid such that they otherwise qualify, (b) haven't been vax'd, and (c) want to come in spite of the fact that they have no antibodies to covid?
< jonatack> BlueMatt: yes
< ariard> BlueMatt: yes
< sipa> that seems to be the key word around this event, "hopefully"
< ariard> sipa: hopefully we won't have covid restrictions 2 years from now but who knows?
< sipa> of course
< ariard> we might yet-another year running on this pace
< BlueMatt> well another option then is the us pending watching restrictions over the coming month or so. it seems likely the us will relax the inbound-tourist restirctions given eu pressure on the us to be symmetric.
< BlueMatt> and once here there's much less likely to be any new restrictions on movement/gathering than other places.
< luke-jr> FL hasn't really ever had any restrictions if you can get into the country :p
< ariard> okay let's play hope for now, keep a consistant fallback plan if france get in some administrative folly, and don't take travel plans without cancelling options
< ariard> luke-jr: was there a month ago, nice state :)
< sipa> so the plan is still same date, same place?
< sipa> barring other news?
< ariard> BlueMatt: yeah if the us really relax fallbacking on NYC/boston could be easy
< ariard> sipa: for now, yes and we're keeping a strong eye on evolution
< BlueMatt> right, nyc is probably easy.
< jonatack> the US is difficult for many people. would suggest a destination people can enter
< sipa> US is not easy to enter i assume, right now
< BlueMatt> right, that's assuming the entering restriction is relaxed, but there's lots of eu pressure on dc to do that sooner rather than later.
< luke-jr> maybe El Salvador would make exceptions as needed XD
< ariard> yes have this issue with UK, not legally friendly hmmmm
< BlueMatt> I dont think the UK is an option right now.
< jonatack> nope (csw etc)
< ariard> i know some contributors who had issues getting in the us in the past
< ariard> well, not other news :)
< laanwj> any other topics?
< laanwj> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu Jul 15 19:34:39 2021 UTC.
< luke-jr> fwiw achow101 made gitian descriptors that do the guix build for you
< luke-jr> #22439
<@gribble> https://github.com/bitcoin/bitcoin/issues/22439 | build: Use guix within gitian by achow101 · Pull Request #22439 · bitcoin/bitcoin · GitHub
< gene> thanks for the meeting everybody
< robertspigler> What's the purpose of using guix within gitian? Doesn't that reintroduce dependencies/security concerns that were the purpose of transitioning from gitian->guix?
< luke-jr> robertspigler: it's familiar, and more secure. Guix doesn't actually provide most of the benefits claimed.
< laanwj> only for the people that use it that way, assuming they'll compare their output to builders that use guix differently, they'll notice
< luke-jr> unfortunately, even within gitian there is still a huge increase in resource cost and debatable reduction in security, but it's better than nothing
< bitcoin-git> [bitcoin] kiminuo opened pull request #22463: [TESTBED][NO-MERGE] Verbosity level 3 getblock rebase (master...verbosity-level-3-getblock-rebase) https://github.com/bitcoin/bitcoin/pull/22463
< kanzure> catching up on the backlog- so france is still the pick?
< luke-jr> kanzure: yes, but "wait and see"
< robertspigler> Does it not make the build bootstrappable? And solve the issue of a malicious compiler?
< luke-jr> robertspigler: no, it makes it even less bootstrappable than it was under Ubuntu
< luke-jr> robertspigler: you *have* to use Guix's third party binaries
< robertspigler> My understanding was that gitian was reproducible, but not bootstrappable, and that guix is an improvement to bootstrappable and reproducible
< luke-jr> (Ubuntu was more 3p bins, but at least you could build them yourself if you wanted to)
< luke-jr> robertspigler: maybe someday
< dongcarl> robertspigler: Hi, the 3p binaries in Guix are significantly smaller, and can be reproduced with `guix build bootstrap-tarballs`
< luke-jr> dongcarl: not really
< luke-jr> using them to reproduce themselves doesn't count
< dongcarl> Ubuntu's the same situation then.
< luke-jr> no, you can build all of Ubuntu with non-Ubuntu compilers
< luke-jr> and Ubuntu was run in a VM for gitian
< luke-jr> which gets back to the original question:
< luke-jr> this is why one would run Guix inside gitian ;)
< robertspigler> dongcarl: that makes sense
< robertspigler> Which brings me back to my original question - why run guix in gitian
< dongcarl> Sure, I'm not going to stop anyone from choosing their own security model, that's their own choice! :-)
< robertspigler> luke-jr: but those compilers aren't bootsrappable
< luke-jr> robertspigler: ?
< luke-jr> Guix's compiler is the only one that isn't bootstrappable
< luke-jr> going from A to A proves nothing
< robertspigler> It has the smallest binary seed bootstrap
< luke-jr> irrelevant, it's still a binary seed
< * dongcarl> goes back to work
< robertspigler> :)
< luke-jr> pretty sure the binary seed won't boot or inspect itself either, so it's snake oil really ;)
< bitcoin-git> [bitcoin] jonatack opened pull request #22464: bench: fix 32-bit narrowing warning in bench/peer_eviction.cpp (master...fix-32bit-narrowing-warning) https://github.com/bitcoin/bitcoin/pull/22464
< jonatack> /query hebasto
< hebasto> jonatack: testing...
< jonatack> hebasto: thanks (wanted to ask you how to do a 32-bit depends build)
< hebasto> what system on?
< jonatack> debian (Debian 5.10.40-1 (2021-05-28) x86_64 GNU/Linux)
< hebasto> `apt install g++-multilib`
< hebasto> it could conflict with other packages (
< hebasto> ^ related to #22456 (draft)
<@gribble> https://github.com/bitcoin/bitcoin/issues/22456 | [WIP] build: Use specific cross-compilers instead of multilib one by hebasto · Pull Request #22456 · bitcoin/bitcoin · GitHub
< jonatack> thanks -- installed it and seems to be ok
< hebasto> conflicts are if you made cross builds for other archs
< bombingmiami> belcher is a liar piece of shit is that right belcher? He got 50.000 dollars from hrf.org to attack me and my organization. I had edit privileges on Bitcoin Wiki since 2015 with the username "humanrightsfoundation" https://web.archive.org/web/20151031001911/https://bitcointalk.org/index.php?topic=1025908.40. On 2020 Jun belcher was attacked me and
< bitcoin-git> [bitcoin] hebasto closed pull request #22456: [WIP] build: Use specific cross-compilers instead of multilib one (master...210715-multilib) https://github.com/bitcoin/bitcoin/pull/22456