< 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>
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
< 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>
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
< 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)
< 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
< 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
< 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)
< 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
< 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
< 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)
< 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