< ghost43>
I've just upgraded to 0.21 and it seems to have broken a downstream app that uses the HTTP JSON-RPC API. It used to work with 0.20.1 but with 0.21 I am now getting HTTP 403 Forbidden.
< ghost43>
I have another bitcoind that still runs 0.20.1, and for that one the curl command gets the expected response, while it gets status 403 for 0.21
< ghost43>
any idea?
< sipa>
WFM
< sipa>
i suspect there is an issue with your authentication
< luke-jr>
ghost43: are you using rpcuser/rpcpassword or rpcauth?
< ghost43>
luke-jr: my bitcoin.conf has a line "rpcauth=..."
< ghost43>
and the downstream client is connecting through HTTP accessing an URL such as http://user:pass@172.19.1.10:8332/
< luke-jr>
does it work from localhost?
< ghost43>
luke-jr: oh hmm yes it does
< luke-jr>
what are your rpcbind/rpcallowip settings?
< sanket1729>
Where libsecp256k1 library is built in bitcoin core build process? I can't find it in src/.libs
< sanket1729>
nvm, found it. It is in src/secp256k1/.libs
< fanquake>
it will be in src/secp256k1/.libs
< ghost43>
luke-jr: I have "rpcbind=0.0.0.0:8332" in bitcoin.conf, and passing "-rpcallowip=::/0" on CLI. it is all part of a non-trivial docker setup; so it is not actually exposed to the internet
< ghost43>
ok I've figured it out
< ghost43>
rpcallowip=::/0 used to work but is now broken
< ghost43>
rpcallowip=0.0.0.0/0 works.
< ghost43>
luke-jr, sipa ^
< sipa>
uh
< sipa>
that's not good
< ghost43>
I will open an issue on github
< sipa>
yes, please
< luke-jr>
eh, that sounds reasonable?
< luke-jr>
if you bind IPv4 and only allow IPv6.. what do you expect? XD
< luke-jr>
(also, not a good idea to allow connections from the internet)
< sipa>
ah
< ghost43>
luke-jr: my point is that this exact setup worked up until I upgraded bitcoind
< ghost43>
how can I bind/allow both ipv4 and ipv6 btw?
< ghost43>
can the config var be duplicated or something? comma separated maybe?
< ghost43>
anyway, opened issue #21070, feel free to close. it might help others just by virtue of search engines indexing it :)
< bitcoin-git>
[bitcoin] Saibato opened pull request #21073: wallet: check when create wallets for the reserved name "wallets" (master...sanitycheck) https://github.com/bitcoin/bitcoin/pull/21073
< dongcarl>
Hi all, I will give a full Guix release plan at the meeting _next_ week if that is okay with all. Right now I'm combing through every detail making sure that I minimize my "unknown unknowns".
< luke-jr>
bitcoin-core/leveldb branch bitcoin-fork-new might be best to rename over bitcoin-fork or soemthing?
< dongcarl>
If anyone knows how to add a meeting topic to the meeting after the upcoming one, please lmk
< wumpus>
dongcarl: there's no way to do that explicitly, though you could do the normal proposedmeetingtopic then add the date you want to propose it as topic (it's not programmatic, the only thing the bot does is filter out messages with that command)
< wumpus>
dongcarl: but that sounds good to me!
< wumpus>
luke-jr: yes why not
< wumpus>
new is the new old and all that
< dongcarl>
Ah okay, will just wait until Friday then
< wumpus>
luke-jr: done
< cguida>
Hey everyone! I hope this is the right place to bring this up, let me know if somewhere else would be better.
< cguida>
I discovered some misleading discussion in https://bitcoincore.reviews/17994. The intro to the review appears to claim that undo files are always in block height order on disk, but I've recently been digging into the undo files and they're actually out of order at the file boundaries. In the discussion, it's implied that if a block is too big to fit into 128MB, it goes into the next blk file, so its corresponding undo file m
< cguida>
ust go into the next rev file. Then, if a block is found that is small enough to fit in the original blk file, it's put there along with its undo data. But at no point in the discussion does anyone explicitly say "hey actually no, that's wrong, sometimes the undo files are out of order."
< cguida>
I'm not sure if these bitcoincore.reviews are meant to be authoritative, and I'm not sure if the site can be edited, but it definitely would have saved me a lot of time knowing that the undo blocks are sometimes not in block height order. So, just a heads up, and thanks for listening :)
< sdaftuar>
cguida: #bitcoin-core-pr-reviews seems like the appropriate channel to comment, as i believe that's where the original discussion would have happened (and that's the irc home of the pr review club)
< jonatack>
hi cguida, thanks for having a look. the review club IRC channel is ##bitcoin-core-pr-reviews. would you like to open a pull request with your proposed edits here? at https://github.com/bitcoin-core-review-club/website
< luke-jr>
cguida: undo files aren't an API in the first place..
< jonatack>
sorry, the irc channel is #bitcoin-core-pr-reviews
< michaelfolkson>
Just wait until today's meeting is over (10 minutes)
< cguida>
jonatack: Oh awesome, sure!
< cguida>
luke-jr: right, that's why i'm needing to look at the raw files
< sdaftuar>
luke-jr: any chance i can get a BIP number assigned to the disabletx proposal?
< luke-jr>
cguida: my point is you shouldn't look at the raw files ;p
< luke-jr>
sdaftuar: yeah, I'll get to BIPs later today
< sdaftuar>
luke-jr: thank you!
< luke-jr>
cguida: Knots's getblocklocations will tell you which file/offset, but even then, you can't be sure it won't change under you..
< luke-jr>
cguida: what are you hoping to do with it?
< wumpus>
first the out of the blue issue about RandyMcMillan, now this
< sipa>
do the debug-only options even show up anywhere?
< Kiminuo>
it's getting interesting ^^
< midnight>
wumpus: Zoltan Konder has been issuing serious death threats against the Tor project, us, me personally, and the Human Rights Foundation. There are lawsuits ongoing against him, and due to his threats he has been barred (without a lawyer) from communicating with the US PTO.
< sipa>
oh no, it's that guy again
< midnight>
wumpus: For your sake, strongly recommend permaban on sight.
< wumpus>
midnight: will do, thank you
< sipa>
i think we banned him before
< midnight>
Yes a number of times.
< midnight>
I believe it's just a matter of time before he's arrested is he ever attempts to travel anywhere, actually, so I believe he's currently trapped where he is.
< midnight>
*if he
< jonatack>
glozow: ./src/bitcoind -help-debug | grep -A3 peertimeout ...current description lgtm, not sure it's worth changing (with or without risk of breaking user space)
< jonatack>
(ugh, sorry to see the PR polluted with the trollish behavior)
< glozow>
ya sorry 😅 it's a really tiny PR, just found it a bit misleading and i thought it'd be relatively harmless to change a debug-only description