<stickies-v>
rest: we use libevent, which for my PR requires me to import the TAILQ_FOREACH macro from <sys/queue.h>. This seems fine, except for the Win64 [unit tests, ...] test, which does not seem to have this header: https://github.com/bitcoin/bitcoin/pull/24012/checks?check_run_id=4753584875. Is this an issue with CI, or should I avoid using <sys/queue.h>, even though it's fine on the other tests?
<sipa>
That's a nonstandard header. You can't assume it exists on anything but Linux/BSD.
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] vincenzopalazzo opened pull request #24016: [WIP] utils: introduce a runtime error in case of overflow in GetArgInt (master...vincenzopalazzo/cmd_atoi) https://github.com/bitcoin/bitcoin/pull/24016
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
yanmaani has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<stickies-v>
But in the same file httpserver.cpp we also include <sys/stat.h> and <sys/types.h>, which I think are also nonstandard? These headers are specified in AC_CHECK_HEADERS in configure.ac though, should I do something similar for <sys/queue.h>? Sorry, I'm a bit out of my depth here and it's hard to debug with the remote CI and quite long running process.
outfox has quit [Ping timeout: 256 seconds]
outfox has joined #bitcoin-core-dev
outfox has quit [Changing host]
outfox has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 256 seconds]
<sipa>
Those are defined by POSIX.
<sipa>
This TAILQ_FOREACH seems super simpler. You don't need the macro to walk the result.
<stickies-v>
Ah, thanks. I was looking at https://en.cppreference.com/w/cpp/header which didn't have any <sys> headers. And thanks for the pointer, I'll have a look at not using the TAILQ macros.
<stickies-v>
oh shit you're right, that actually was super simple. TIL. thx!
<sipa>
@prayank Seems like a reasonable amount of time for review + merging + doing a release + people widely updating to use that release.
brunoerg has quit [Ping timeout: 268 seconds]
<sipa>
And certainly people don't need to wait to use non-default ports after there is some adoption of node software that permits non-default ports.
<sipa>
But that's not the same as including it as a suggestion in that document. I think that should only be done when it's so widely adopted there aren't any connectivity downsides to it anymore.
<prayank>
some people already use it
<sipa>
Yes, but using it right now comes with a huge downside; almost no nodes will connect to you.
<sipa>
I don't think it should be a recommendation until that downside disappears.
<prayank>
Makes sense. Okay I can remove it.
<prayank>
I was also thinking to approach NACK the non-default ports PR because my suggestions were not implemented and nobody on Github moderated for me :)
<sipa>
What are your suggestions?
<sipa>
And do you think the non-default ports are not an improvement without them?
<sipa>
What do you mean by moderated?
<prayank>
sipa: 1. to add more ports or have clear definition what we consider as bad port 2. they are still an improvement and vasild has done lot of contributions to improve privacy and security 3. I suggested a topic for meeting which could have been done by anyone. I was asked to draft a doc with some things that make would clear the concept. One user that has done only 2 reviews in this repo: both for my PR suddenly calls everything
<prayank>
non-sense. Irony same user wants to to remove/restrict rpcbind which nobody has objection with. Sorry neither I need to make changes based on that user's comments nor I prefer language "non sense" "you don't listen". I am not a working for managers in a company but trying to contribute to an open source project used by 90% bitcoin nodes.
mikehu44 has quit [Ping timeout: 240 seconds]
<sipa>
You don't need to make changes just based on that user's opinion alone, but in some cases, they are right, and others have commented too. That may be a sign you're incorrect about things too.
mikehu44 has joined #bitcoin-core-dev
<prayank>
to add more to moderation: I can add lot of things but not interested to ruin my whole weekend which already is only a few hours I get for myself in a week. Nobody is dumb and people should try to use the same policy for all pull requests.
sipsorcery has quit [Ping timeout: 240 seconds]
<sipa>
I don't think wpeckr's tone is particularly helpful in that PR, by the way.
<prayank>
sipa: there is nothing incorrect in saying *notify options trigger scripts based on some events and people should be careful or use restrictions/alerts.
<prayank>
I am sure most of the devs here use firewall and rules
<sipa>
I agree. But I do think it is misleading/
<prayank>
sipa: yes
<sipa>
And I think the point shouldn't be "Beware of -notify* options" as if they are somehow a particular security risk. I think the point should be "Be careful about accepting configuration changes and commands from third parties. Here is a non-exhaustive list of things that may go wrong: ...". The -notify* commands could be mentioned in such a list, but I wouldn't even consider the most important one.
<prayank>
I would rephrase it based on this in next update. Will need few hours.
<sipa>
There is also no rush in this, take your time.
<prayank>
Thanks
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
sipsorcery has joined #bitcoin-core-dev
vysn has quit [Ping timeout: 240 seconds]
goatpig has quit [Remote host closed the connection]
goatpig has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
RDK_ has quit [Quit: Leaving]
brunoerg has quit [Ping timeout: 240 seconds]
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
yanmaani has quit [Ping timeout: 276 seconds]
yanmaani has joined #bitcoin-core-dev
sdfgsdfg has joined #bitcoin-core-dev
AaronvanW has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
Alina-malina has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 256 seconds]
Alina-malina has joined #bitcoin-core-dev
<luke-jr>
some guy on Twitter says he can't get a working full node in China because the firewall blocks everything - surely there's some nodes within China? should we be prioritising Chinese IPs in DNS seeds when the DNS request comes from China? (Would that even work?)
AaronvanW has joined #bitcoin-core-dev
rex4539 has quit []
prayank has joined #bitcoin-core-dev
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
prayank has joined #bitcoin-core-dev
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
prayank has joined #bitcoin-core-dev
anandn has joined #bitcoin-core-dev
yanmaani has quit [Remote host closed the connection]
brunoerg has joined #bitcoin-core-dev
<prayank>
luke-jr: he should move to India, we use everything from china, pretend to fight over one border but can't do shit, cheaper life, kashmir china++ where you can't use internet and even need permission to live life from a person in uniform HOWEVER you can move to other parts live a life, have contacts, be a politician and businessman, people won't care if he looks chinese but says something dumb in hindi, makes money and shares i
<prayank>
t others that allow him to do everything
brunoerg has quit [Ping timeout: 240 seconds]
<luke-jr>
I'm not sure that's a viable solution for people living in China :P
<prayank>
luke-jr: that was sarcasm, I feel bad for them and even one of my friend in merchant nacy was stuck there in covid times who was not even on land but had lot of issues. IDK they are humans and would realize at some point this does not work. Although its become bigger with time and they do attack on other countries like shitposting in IRC. They dont care. Because they are good at it compated to some people. Example: DRDO was ata
<prayank>
cked in India by China indirecly few years back and they finally moved to their own linux distro from Windows
bomb-on has quit [Quit: aллилѹіа!]
<prayank>
viable solution: cannot suggest one without being in that situation but tor bridges should help but you hate tor
ron-slc has quit [Quit: Ex-Chat]
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
<luke-jr>
I don't hate tor :P
prayank has joined #bitcoin-core-dev
jb55 has joined #bitcoin-core-dev
<prayank>
I mean you consider it centralized. And always comment this when someone says it about privacy so I assumed. You also think DNS seeds should not be trusted and there can be other ways to bootstrap but did not suggest anything in the related docs PR. Would be helpful if I could more suggestions from you to improve those docs. I respect you and your knowledge in security. One of the maintainers didnt like your medium article so s
<prayank>
hared CVE link.
sipsorcery has quit [Ping timeout: 240 seconds]
brunoerg has joined #bitcoin-core-dev
prayank has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has quit [Ping timeout: 268 seconds]
<luke-jr>
prayank: it's a fact that tor is centralised, and a security risk if it is your only path to the Bitcoin network.
<fanquake>
prayank: I commented "and I'd rather not have us linking to personal medium accounts." Who's account it is, is irrelevant. What I don't want, is us having no-context links to outside resources, when suggestions / information could just be in-lined in our own documentation.
<fanquake>
In regards to the actual issue, the medium post suggests upgrading to an alternative client, which has an experimental fix, for a problem that bitcoin core didn't even post an advisory for (you can see why in the IRC logs). I think that would be confusing to link to, rather than just linking to our own documentation in json-rpc-interface.md, which was added in response to the same problem.