bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23042: net: Avoid logging AlreadyHaveTx when disconneting misbehaving peer (master...2109-netLogDisconnect) https://github.com/bitcoin/bitcoin/pull/23042
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23043: ci: Set --nocleanup for Windows functional tests (master...2109-ciWinCleanup) https://github.com/bitcoin/bitcoin/pull/23043
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
vysn has quit [Remote host closed the connection]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
smartin has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<darosior>
achow101: thanks for raising #22949 during the meeting. FWIW another round of review and hacking around with the `tx_pool` fuzzing target gave me more confidence this is not a policy change.
<gribble>
https://github.com/bitcoin/bitcoin/issues/22949 | fee: Round up fee calculation to avoid a lower than expected feerate by achow101 · Pull Request #22949 · bitcoin/bitcoin · GitHub
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
luke-jr: is this for the distribution binaries or self-built?
<laanwj>
will try it out on my armhf hw, but useful to know what the build conditions were ... it's weird, i don't think the 32-bit ARM is supposed to do 64-bit loads for crc, because it doesn't have a 64 bit crc isntruction
Henrik has joined #bitcoin-core-dev
<laanwj>
so does HAVE_ARM64_CRC32C get set when building for armhf
<laanwj>
These built-in intrinsics for the ARMv8-A CRC32 extension are available when the -march=armv8-a+crc switch is used "uint32_t __crc32d (uint32_t, uint64_t)" Form of expected instruction(s): Two crc32w r0, r0, r0 instructions for AArch32
<laanwj>
so: no, unless somehow that flag is passed to the autoconf test, i think the distro binary is fine
<laanwj>
but it is sneaky that gcc will 'emulate' the 64-bit intrinsic on ARM32
<laanwj>
in any case we need to explicitly check for 64-bit ARM in your build system, the crc32c code is not ARM-specific it is ARM64-specific
<laanwj>
oh crap--I think our detection is entirely wrong, we're detecting 32-bit ARM CRC32 instead of 64-bit?
<laanwj>
configure:17553: checking for ARM CRC32 intrinsics" fails for me on
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bodhi has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<laanwj>
the issue must have been there since we first introduced crc32c, afaik its ARM code has always been the same, and so was our build system check, and it's never been reported before (it's a clear immediate crash) so the conditions where it is accidentally enabled on armhf must be rare
<prayank>
My understanding with an example: Consider I am using 127.0.0.1:8080 as proxy, onlynet is not used, proxy remains for all networks but may not work for one or more depending on different things. If onlynet is used, only those networks will be tried to reach via proxy but proxy still remains for all networks. 127.0.0.1:7656 is only used for i2p.
<sipa>
prayank: i don't understand the question
<prayank>
sipa: if an IP address and PORT is mentioned in proxy by user, does it make sense to classify it as only applicable for some networks? 127.0.0.1:7656 being an exception
<laanwj>
prayank: i think that's how it's supposed to be: if you configure a proxy for a certain network and the proxy doesn't work for that network, it will try to use it when connecting out on that, then fail--it definitely shouldn't try connecting outside the proxy, that would be some kind of leak
<laanwj>
a 'the proxy doesn't work let's connect directly' fallback would be really bad. but maybe i'm misunderstanding
<sipa>
prayank: you can configure which network it is for
<prayank>
laanwj: agree
<ryanofsky>
Can add #22976 to high prio since I don't have on there right now?
<prayank>
sipa: I guess that would require more things in config
<sipa>
there is just -proxy and -onion; i thought i saw something to restrict which networks -proxy is for
Yihen has joined #bitcoin-core-dev
<laanwj>
prayank: btw please don't take my IRC posts out of context on github this is very stressful
<prayank>
It's not completely out of context. Sorry if it looks wrong but things were related and discussed at several places in which I finally had this conclusion proxies are just proxies and should be used for all networks if possible.
<laanwj>
yes, sure, I understand how it can be somewhat confusing: that's true *if* specified with -proxy, then it's intended to be used as cover-all proxy for all networks (including DNS names), however, network-specific proxies are applied to addresses of a specific network
<laanwj>
and that's the information you get with getnetworkinfo
<laanwj>
name connections (where the network isn't known) are a special case that's outside of the normal per-network proxy handling, names never come from the P2P network but only in special cases (as mentioned in https://github.com/bitcoin/bitcoin/pull/22959#issuecomment-922915197)
c_arc has joined #bitcoin-core-dev
<prayank>
I think I still believe saying proxy 1 is used for ipv4 only can be misleading. Because it's used for only ipv4 either because you restricted outgoing to ipv4 only or used externalip in config. Proxy can still be used for other networks if user changes config. This might give false information that proxy only works for some networks.
<laanwj>
sipa: there's not currently a way to only set a proxy for ipv4 and not ipv6 or vice versa, theoretically it'd be easy to implement, but the use case doesn't really come up, what almost everyone wants is to set a proxy for everything
<laanwj>
(sometimes including or excluding onion)
<laanwj>
prayank: i don't follow you here, the information returned is exactly what the network code uses
<sipa>
prayank: externalip is completely unrelated; that's about advertising an address for incoming connections
<sipa>
-proxy and -onion are purely about outgoing connections
<laanwj>
all that -getinfo does is format it in a nice way, but it's simply the internal proxy information it gets from getnetworkinfo, that is used by the P2P code
<jonatack>
prayank: also, remember that -getinfo is only a wrapper for a batch of RPCs, including getnetworkinfo, so the relevant discussion there is on how to present the data they provide.
<prayank>
laanwj: As a user what would you prefer 1. Proxy 127.0.0.1:9150 (ipv4) 2. Proxy 127.0.0.1:9150 (onlynet=ipv4)
<jonatack>
laanwj: right
<sipa>
prayank: i don't understand what you're trying to convey
<sipa>
onlynet is about which automatic connections are made
<sipa>
proxy is about how to make connections in general, including non-automatic ones
<prayank>
sipa: Networks being associated with a proxy looked incorrect to me but at this point it looks like I am more confused than before so will take some time to try things and comeback in few days with fresh thoughts.
<sipa>
prayank: internally, every network can have a proxy associated with (plus a separate one for name-based connections). -proxy sets all of them. -onion sets the one for tor hidden services only.
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
<prayank>
sipa: externalip assumption was based on the command shared in end of 'manual' section here which says you can use this if proxy should only work for onion and not ipv4
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<sipa>
prayank: there is no such thing as a "proxy for incoming"
<sipa>
-externalip is just telling bitcoind on which address it can be reached, so it can.rumour that address to other peers
mersible has joined #bitcoin-core-dev
Yihen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<sipa>
because if you manually configure your tor node to have a hidden service for your bitcoind, bitcoind has no way of figuring out what its hidden service address is
c_arc has joined #bitcoin-core-dev
<laanwj>
right, or when your node is behind a NAT, it's not a proxy-specific option
<laanwj>
(+and manually port-forwarded)
<sipa>
prayank: are you confused about the mention of -proxy in the example in section 3? that's just setting the proxy for outbound connections
<luke-jr>
laanwj: is the 2x crc32w worse for performance?
<luke-jr>
laanwj: and again, 0.21 built and ran tests fine :/
<laanwj>
luke-jr: yes, i think all the instructions execute in the same number of cycles, so doing 64 bits at once is twice as fast
<sipa>
(because it's an example of all the tor related settings to use in such an example)
<sipa>
i guess.i comfused.you by saying section 3 is purely about inbound... the example are about the whole thing
<luke-jr>
laanwj: but ARM won't be doing 64 bits; if we disable this, it will use plain C?
<laanwj>
luke-jr: it has always used plain C on ARM32, your case is really a strnge misdetection
<laanwj>
the code in crc32c is for 64 bit ARM, it doesn't work for 32-bit
<laanwj>
(it even queries the wrong getauxval bit for the instruction set in src/crc32c/src/crc32c_arm64_check.h if you manage to compile that code for 32-bit, it's all in all, pretty bad)
<luke-jr>
laanwj: crc32c itself doesn't check for aarch64
<luke-jr>
ah, I wonder if that's why it detected it at runtime
<laanwj>
luke-jr: maybe it's an upstream bug then
<laanwj>
in any case, we need to fix itin our own build system, as we don't use theirs
<luke-jr>
right
<sipa>
laanwj: do ARM32 implementations (with necessary extensions) have the same instructions, actually? (perhaps without the 64-bits at once one)?
<sipa>
because maybe it's less work to make (upstream) crc32c actually work propertly on arm32 then
<laanwj>
sipa: yes, but they are extremely rare in the first place
Henrik has joined #bitcoin-core-dev
<sipa>
i guess the relevant question is: does any raspberry pi have them>
<laanwj>
crc32c extension was introduced with arm8, which tend to be 64 bit
<laanwj>
luke-jr: does your hardware actually list crc32c in /proc/cpuinfo?
<prayank>
sipa: yes
<sipa>
laanwj: but rpi4 is actually aarch64, but with (iirc) typically a 32-bit OS on it
<laanwj>
sipa: ok well for that case it could work
<sipa>
but apparently with misaligned input...
<laanwj>
if anyone actually has hardware to test i'm happy with making crc32c work on 32-bit ARM instead
<sipa>
i have access to an aarch64 machine (developerbox); i can easily compile in 32-bit mode and test on that
<laanwj>
you'd need to specialize for __arm__: a) getauxval linux bit b) make sure the 64 bit path is ifdef'ed out
<laanwj>
(pretty much exactly like the x86/x86_64 distinction)
<sipa>
yeah
<sipa>
it seems there are a lot of analogies between arm32/aarch64 on the one hand and x86/x86_64 on the other hand
<luke-jr>
laanwj: it will take me hours to find out, but I will check
<luke-jr>
I would expect to find it's aarch64-capable running a 32-bit VM or container
<laanwj>
luke-jr: ok no hurry
<luke-jr>
in any case, separating the bugfix from the feature of adding 32-bit support to it, seem like two different tasks/PRs
davterra has joined #bitcoin-core-dev
<sipa>
luke-jr: agree
<laanwj>
luke-jr: in any case the /proc/cpuinfo 'features' will be what getauxval(AT_HWCAP*) returns, if there is no crc32c in there then it shouldn't even have tried to go into the hw-accelerated code path
<laanwj>
it's probing the wrong bit which means something completely different on a different architecture
<laanwj>
luke-jr: yes
<laanwj>
my PR (disabling it where we know it's not going to work) is the safe baseline
<laanwj>
Features : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm -- no crc32 :/
* luke-jr
wonders how crc32w is normally detected
<sipa>
getauxval is the correct approach, i think
Guest3749 has joined #bitcoin-core-dev
<laanwj>
it's a bit in HWCAP2
<laanwj>
looking it up now
<sipa>
Note ID_ISAR5.CRC32 indicates whether this instruction is supported in the T32 and A32 instruction sets.
<laanwj>
HWCAP2_CRC32
<laanwj>
in getauxval(AT_HWCAP2)
<luke-jr>
strange that /proc/cpuinfo lacks it
<Guest3749>
Hello, I was wondering if the BTCC is on sale and if so where can I buy some? thank you
<luke-jr>
Guest3749: wrong channel. (and note that "BTCC" may be a scam, not related to Bitcoin) further discussion somewhere else please
<laanwj>
in aarch64 it's in AT_HWCAP instead and a different bit (HWCAP_CRC32 = 1<<7) .. that same bit would on ARM32 be HWCAP_EDSP (1 << 7)
<laanwj>
as you have edsp, that checks out... :)
<sipa>
laanwj: but that doesn't mean the same machine binary opcode is used for edsp and crc32?
<laanwj>
sipa: oh definitely not
<sipa>
right, so it's strange luke is getting a misaligned error
<sipa>
i'd expect an "unknown instruction" or so instead
<laanwj>
wait, the crc* instructions don't access memory at all
<laanwj>
it's the memory fetch before it that gets a SIGBUS
<sipa>
ah
<laanwj>
it doesn't even get to the instruction
<sipa>
right, it's 3 registry operands
<laanwj>
right, i think the code, right now, makes the assumption pointers are 64-bit aligned, which isn't true on 32-bit ARM, so it bolts out even before getting to the instruction itself
<sipa>
17:07:22 < luke-jr> crc32c/src/crc32c_arm64.cc:101:20: runtime error: load of misaligned address 0x06d96d36 for type 'uint64_t', which requires 8 byte
<sipa>
that's not even 4-byte aligned!
<laanwj>
heeh
<luke-jr>
XD
<Guest3749>
no answer to my question? must we mine BTCC OR can we buy it somewhere? Thank you for answering me.
<sipa>
Guest3749: off topic, sorry
<prayank>
Guest3749: Where did you get the link for this IRC channel?
<Guest3749>
I am also a developer. there is the irc on the website, then i dont know why even if it is not the right place why no one just answers my question. or buy BTCC, simple question.
<sipa>
Guest3749: this channel is about the development of the bitcoin core software; anything else is off-topic; last warning
<luke-jr>
Guest3749: even if someone knows, they respect the topic of the channel and won't answer here.
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<Guest3749>
so you are idiots ... in the street if someone asks you the time when you are going to buy bread i hope you will answer him anyway .. not like saying no i am going to get my bread there is none report. answer a simple question and move on. anyway, the mentality is pretty low for dev.
Guest3749 was kicked from #bitcoin-core-dev by ChanServ [Banned: off-topic]
<laanwj>
wait i do have a Odroid-C2 which has them, but it's used for something important i can't just install another OS on it, does 32-bit software run on 64-bit ARM? i don't remember
<sipa>
it does
<sipa>
either by having a full 32-bit OS only, or if you have 32-bit userspace libraries installed
<sipa>
same as with x86_64/x86
<laanwj>
right, i didn't know for sure because it's not like that for riscv32/64
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
achow101 has quit [Quit: Bye]
<laanwj>
it indeed looks like "dpkg --add-architecture armhf && apt update && apt install libc6:armhf" is enough to run armhf release bitcoin-cli on aarch64 host
achow101 has joined #bitcoin-core-dev
<laanwj>
no need to install a 32-bit OS
<laanwj>
although i haven't checked yet what the AT_HWCAP flags look like, i'd guess they'd be passed correctly to 32-bit userspace though, and that the same extension instruction sets are available
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
<laanwj>
... getauxval(AT_HWCAP2)=0x00000010 looks like it, as expected, getauxval in a 32-bit binary on 64-bit ARM returns the correct value for 32-bit ARM, and also, 1<<4 (HWCAP2_CRC32) is available in 32-bit mode
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] jb55 closed pull request #18985: bloom: use Span instead of std::vector for `insert` and `contains` [ZAP3] (master...2020-05-bloom-span) https://github.com/bitcoin/bitcoin/pull/18985
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<sipa>
Kiminuo: but that's about feerate; this is a fee, not a feerate
<Kiminuo>
This is a PR where I got the impression that "fee (rate)" is fine in sat/vB
<Kiminuo>
sipa: ok, then
<Kiminuo>
So just to have some conclusion here: Should I try to create a follow-up PR for the Luke's one to change `ancestorfees` to BTC denomination? Or is anyone calling dibs? :)
<laanwj>
right, this is not per vB
<laanwj>
well if you're going to change it, it needs to be changed before the release, once it's in a release for better or worse we're stuck with this inconsistency
<bitcoin-git>
[bitcoin] jonatack opened pull request #23050: log: change an incorrect fee to fee rate, and vice-versa (master...fee-vs-feerate) https://github.com/bitcoin/bitcoin/pull/23050
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<Kiminuo>
haha
<Kiminuo>
I thought that Jon has just created the PR :)
<jonatack>
hehe, thought this would be a good time to open this silly patch I've had on the side for a while
<jonatack>
Kiminuo: confusion is normal....until Murch[m] opened my eyes to it a year ago, I didn't realize how often fees are mixed with fee rates/feerates
<Kiminuo>
but you probably have discovered all invalid cases already
<jonatack>
it was just something I wondered about during review of another pull, didn't look anywhere else
<Kiminuo>
jonatack: https://github.com/bitcoin/bitcoin/pull/12677#pullrequestreview-759043318 - I don't really want to try to beat somebody in addressing these but I should have some time over the coming days to address that so I'll do it, ok? Saying that just because I don't want to compete with somebody
<luke-jr>
Kiminuo: laanwj: all other ancestorfees use satoshis
<sipa>
oh, that's a good reason
<luke-jr>
I'm not sure about the doc type tho. Maybe it should be NUM or such
<sipa>
right
<jonatack>
luke-jr: not sure it's related, but in #22689 (open) the four mempool rpcs are returning the ancestor fee fields and others in BTC, maybe have a look
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<laanwj>
if you have quantities that you could plausibly compare it makes sense to use the same unit
<laanwj>
fee*rate* and amount are clearly different units of course
<laanwj>
i don't think you can say the same for fee and amount
<laanwj>
but i'm sure this is very controversial for some reason, sorry for merging something that makes things even more of a mess
<jonatack>
"this PR has been open since 2018, i'm sure it was good to move forward with it and fix some things in a follow-up" ... agree :) admirable patience by luke, too
jesseposner has quit [Ping timeout: 252 seconds]
jesseposner has joined #bitcoin-core-dev
<laanwj>
yes exactly
jeremyrubin has joined #bitcoin-core-dev
jeremyrubin has quit [Client Quit]
jeremy has joined #bitcoin-core-dev
<jeremy>
👋 finally got my IRC setup working again, I hope :)
<jeremy>
Can folks see this?
<laanwj>
jeremy: welcome!
c_arc has joined #bitcoin-core-dev
<luke-jr>
Libera working is easy. Try getting on freenode these days otoh… >_<
<achow101>
ancestorfees in satoshis is used everywhere we have mempool entries in the RPC. except that that format is deprecated and has been replaced with one that has the fees in BTC
Henrik has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
<luke-jr>
should we just drop ancestorfees and replace it with ⁇? then?
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
gene has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
stonefox has quit [Ping timeout: 252 seconds]
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 246 seconds]
c_arc has joined #bitcoin-core-dev
gene has joined #bitcoin-core-dev
grettke has joined #bitcoin-core-dev
gene has quit [Quit: gene]
bomb-on has quit [Quit: aллилѹіа!]
c_arc has joined #bitcoin-core-dev
c_arc has joined #bitcoin-core-dev
Jackielove4u has quit [Quit: Connection closed for inactivity]