< 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..?
< 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.
< 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
< 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)"
< 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 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
< 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
< 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
< satoshin>
THE WARRANTIES OF MERCHANTABILITY,FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THEAUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHERLIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS INTHE SOFTWARE.
< 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
< 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
< 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
< 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
< 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>
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.
< 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...
< 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/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
< 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
< 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