< bitcoin-git>
bitcoin/master c82d15b Hennadii Stepanov: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux
< bitcoin-git>
bitcoin/master a3186b6 Wladimir J. van der Laan: Merge #20520: depends: Do not force Precompiled Headers (PCH) for building...
< bitcoin-git>
[bitcoin] laanwj merged pull request #20520: depends: Do not force Precompiled Headers (PCH) for building Qt on Linux (master...201127-pch) https://github.com/bitcoin/bitcoin/pull/20520
< miketwenty1>
Question about bitcoin builds and gitian builds, when you build from source you can put in build options/flags to exclude/include certain things like whether or not the wallet, UPnP, zmq.. are these build options baked into gitian builds to enable everything? If I for example wanted to do a gitian build and not build someone or include something do I have this flexibility?
< miketwenty1>
not build something* like exclude wallet
< fanquake>
yes
< fanquake>
just adjust the CONFIGFLAGS in the gitian descriptor
< miketwenty1>
ok.. but this would now result in different binaries if you start messing with the descriptor files right?
< fanquake>
yes
< miketwenty1>
in the future / even with guix .. would you imagine gitian sigs for multiple common options for each minor/major release of bitcoin? like one with everything enabled.. another build is just the node.. another build with zmq and maybe a few other things .. etc..
< fanquake>
Yes that's possible, and probably quite likely. I'd imagine there are many people running bitcoin nodes, that have no interest in it supporting UPNP, ZMQ, or even having the wallet compiled into it.
< luke-jr>
jnewbery: are you trolling? "to make life easier for maintainers of downstream projects."
< luke-jr>
I mean, not only is the premise false, but you're saying you want to reject my PRs simply to go out of the way to discriminate against and make things harder for me personally?
< promag>
> On the command line only, not in config files
< promag>
why?
< promag>
what's the reason for this behavior? I wasn't aware of it
< promag>
and are you saying that -rpcauth=foo on the cmdline should fail?
< luke-jr>
promag: config files are expected to possibly have unknown options
< luke-jr>
-rpcauth=foo on the cmdline failing sounds okay - I can't think of a use case for tolerating that
< promag>
this is a known option though
< luke-jr>
and it would match the existing behaviour
< promag>
it's a known option with an invalid value
< luke-jr>
promag: >3 fields is unknown
< promag>
no, it's invalid
< luke-jr>
…
< promag>
for instance, -zmqpubrawtx=foo is invalid, not unknown
< luke-jr>
except rpcauth isn't zmqpubrawtx
< luke-jr>
it's a group
< luke-jr>
it also has no effect on startup/running
< promag>
iirc invalid zmqpubrawtx fails init
< promag>
hmm checking
< luke-jr>
as it needs to
< luke-jr>
ZMQ is something that needs to be understood at startup..
< luke-jr>
it actually affects what startup does
< sipa>
why would rpcauth be any different?
< sipa>
if software doesn't know what an option means, it should fail
< luke-jr>
it can fail at runtime, for that one user
< sipa>
this seems especially true for something as security-sensitive as rpcauth
< luke-jr>
it can be reasonably assumed that >3 fields would be used for more details in the future
< sipa>
what if the option means "only allowed to run certain RPCs"?
< luke-jr>
that's why it fails at runtime ;)
< sipa>
that seems incredibly annoying
< luke-jr>
how?
< sipa>
"wth is this not working"
< luke-jr>
we don't throw errors if the config file has GUI options, in non-GUI builds..
< luke-jr>
sipa: well, that's why my first PR had an explanatory error..
< sipa>
because they have a known meaning
< harding>
But if the future config says that user foo can only run RPC bar and you use that config with an old node, now user foo can run dumpwallet. That doesn't sound sane.
< luke-jr>
harding: that's not correct; it will refuse to let user foo do anything
< sipa>
harding: luke-jr's point is that this should be detected, and then refuse *any* RPCs from that user
< luke-jr>
sipa: that's how it always worked, yes
< sipa>
which is not crazy, but still far more annoying than just failing
< luke-jr>
sipa: #20548 would give the user "Invalid rpcauth configuration line" as an error
< luke-jr>
sipa: annoying in theory for some corner case that probably has never occurred, perhaps; but the new behaviour is annoying in practice for real users..
< luke-jr>
(or if you want to pretend Knots doesn't exist, it's a lot more realistic a hypothesis to talk about users of a future Core version making use of the 4th+ field)
< sipa>
luke-jr: i don't think the existence of Knots is relevant in this discussion
< luke-jr>
my point is it's a lot more realistic an annoyance to error at startup, than to error at runtime might be in some weird case
< sipa>
i'm not confinced about that
< luke-jr>
k
< promag>
tbh I prefer startup errors
< luke-jr>
err, how not? (sorry, misread "convinced" as "confused")
< luke-jr>
promag: even when it isn't actually an error?
< luke-jr>
users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
< sipa>
i can see the argument in favor of instituting a policy that future rpcauth flags are reserved for future restrictions of the permission, and thus that it is safe to treat unknown ones as "act as if the auth line didn't exist"
< sipa>
but that's orthogonal to the question if we should in general aim to reject unknown options
< luke-jr>
and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
< luke-jr>
(error at startup vs runtime means the latter needs to fix the problem either way)
< sipa>
yes, but at startup you immediately know the problem is there and fix it
< sipa>
if it happens at runtime it may result in wondering why CoinFancyPoolMixer stopped working
< luke-jr>
but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
< luke-jr>
all to workaround an erroneous error message..
< sipa>
but it's not an erroneous message; if the node can't do what you're asking it to do in the configuration, something is wrong and you need to fix it
< sipa>
as it's won't do what you ask it to do
< luke-jr>
[17:49:33] <luke-jr> promag: even when it isn't actually an error?
< luke-jr>
[17:50:15] <luke-jr> users of Core 99.0 intentionally putting these rpcauth lines in their config file, is far more likely than someone putting a truly erroneous line
< luke-jr>
[17:51:17] <luke-jr> and the former would be forced to jump through hoops to workaround the behaviour, where the latter wouldn't really need to do anything different
< luke-jr>
[17:51:34] <luke-jr> (error at startup vs runtime means the latter needs to fix the problem either way)
< luke-jr>
[17:52:15] <luke-jr> but with erroring at startup, the former case has no real solution but to maintain two config files and keep renaming them
< sipa>
if you're going to frequently switch between different versions, it seems entirely reasonable to have 2 config files and use -conf
< * luke-jr>
peers at freenode
< sipa>
or, more likely, not rely on any features that are only present in one version
< luke-jr>
all the avoid one node restart of some hypothetical guy with a truly erroneous rpcauth line that is unlikely to ever exist…?
< sipa>
no
< sipa>
to make sure that someone who is relying on a future command line option doesn't need to break his head over why it isn't working
< sipa>
i'm talking generically, not specifically about rpcauth
< promag>
I'd bet lots of startups were lost to bad -rpcauth :)
< luke-jr>
I'm starting to like promag's -strict idea
< sipa>
i think that will fail to have the same effect; people just won't turn it on
< luke-jr>
sipa: it could possibly be on by default
< sipa>
that's fair
< luke-jr>
then people who want to switch between versions regularly can just put strict=0 in bitcoin.conf
< promag>
yeah, on by default
< promag>
like gcc -Werror
< luke-jr>
well, -Werror is not on by default :P
< promag>
right, bad example because it is an error in the first place x)
< luke-jr>
promag: so do you want to do the PR, or should I? :p
< promag>
you mean -strict ?
< luke-jr>
yes
< promag>
hmmm
< promag>
:) I mean, if it gets concept ack why not, it could be discussed in the meeting
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #20561: p2p: periodically clear m_addr_known, and choose new peers to receive relayed addresses (master...2020-12-moar-addrz) https://github.com/bitcoin/bitcoin/pull/20561
< jnewbery>
luke-jr: not trolling. If a PR is opened where the goal is primarily to make things easier for downstream projects, then (1) that should be explicitly declared in the PR description (2) it should be judged for inclusion in Bitcoin Core solely on whether it's a benefit to the users of this project.
< wumpus>
agreed...
< luke-jr>
jnewbery: that wasn't even the case here
< wumpus>
what is this altnerative syntax that you introduced in a downstream project anyway?
< jonatack>
meeting?
< achow101>
meeting?
< sipa>
meeting?
< wumpus>
we could, I guess, ignore alternative syntax that we know about and don't support, though it's a bit strange
< wumpus>
but it's better than ignoring all errors
< hebasto>
if 0.21 is around the coner is 0.19.2 really needed?
< MarcoFalke>
hebasto: At least the tag, so that people building from source can use it
< luke-jr>
hebasto: doesn't hurt
< hebasto>
ok
< MarcoFalke>
the branch will be deleted eventually, so a tag also helps to archive the latest branch
< wumpus>
looks like 19740 has some difficulty getting review, please focus on that, 0.20 is much more relevant
< hebasto>
MarcoFalke: I see
< MarcoFalke>
does 19740 warrant holding back 0.20.2?
< wumpus>
maybe we should add it to high prio
< luke-jr>
probably not
< wumpus>
achow101: here?
< MarcoFalke>
I think we should ping reviewers directly
< luke-jr>
IIRC I hit the bug only by some corner case
< achow101>
MarcoFalke: IMO yes. it's a pretty significant bug
< MarcoFalke>
achow101: Any suggestions who could review it?
< achow101>
meshcollider and ryanofsky at least
< wumpus>
it's ony a change in one function, a very important one though
< MarcoFalke>
I checked that the function content is copied from master, that is easy to check
< achow101>
and anyone who reviewed the changes leading up to descriptor wallets
< MarcoFalke>
what is the worst thing that could happen? I guess a tx could come back unsigned?
< achow101>
yes
< wumpus>
the functional tests should catch that though
< MarcoFalke>
SignTransaction is marked const, so it shouldn't modify the spkm either
< achow101>
the bug was that a fully signed tx would come back as supposedly not complete, although nothing would change in that tx
< MarcoFalke>
Seems almost safe to merge as-is (famous last words?)
< jonatack>
nice simplification, surprising that no tests need to be updated if something was broken
< achow101>
given that 0.20 only has the LegacySPKM implemented, I think this could be trivially correct?
< wumpus>
jonatack: right seems there's no test for the fixed behavior
< wumpus>
in any case if it's 'trivially correct' I'd like to see some ACKs soon :)
< jonatack>
a description of what was broken/fixed in the PR or commit would be nice
< achow101>
#17204 apparently tests this kind of accidentally
< gribble>
https://github.com/bitcoin/bitcoin/issues/17204 | wallet: Do not turn OP_1NEGATE in scriptSig into 0x0181 in signing code (sipa) by meshcollider · Pull Request #17204 · bitcoin/bitcoin · GitHub
< wumpus>
would be worth a try then maybe
< MarcoFalke>
#action tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
< core-meetingbot>
ACTION: tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
< MarcoFalke>
ok, finally rc3
< MarcoFalke>
Anything missing for rc3?
< jnewbery>
is there definitely going to be an rc3?
< MarcoFalke>
sdaftuar: Yes, the protocol version wasn't bumped, and some peers use the protocol version to determine which message types are "expected"
< sipa>
sdaftuar: you mean gating it based on protocol version?
< sdaftuar>
yes, that
< jnewbery>
If we're doing an rc3, then I think we should merge a change to only send sendaddrv2 to peers on v70016+
< wumpus>
my initial proposal was to increase the protocol version but this was almost universally hated
< sipa>
we did bump the version number anyway, right?
< MarcoFalke>
is 70016 the version of wtxidrelay?
< jnewbery>
and if we're doing that (which means changing the code and spec), then we should also move it to be done between version and verack like wtxidrelay
< wumpus>
everyone wanted some other mechanism
< sipa>
wumpus: this isn't about protocol version vs sendaddrv2; it's about using protocol version to know whether "sendaddrv2" is a legal message
< wumpus>
so where is it given problems?
< sdaftuar>
i think the feedback from maintainers of other software was a preference to bump the version numbers when we roll out new messages like this, since that is easy, i think we should
< wumpus>
we don't have *any* mechanism like that
< jnewbery>
wumpus: btcd drops the connection if it receives a sendaddrv2
< wumpus>
that's their problem
< MarcoFalke>
libbitcoin might, too
< sipa>
wumpus: i agree it's silly
< wumpus>
we've always ignored unknown messages
< wumpus>
and that's how it should be
< wumpus>
it was always the idea that new messages could be used as an extension mechanism
< hebasto>
^^^ isn't this rule a part of ptotocol?
< sipa>
apparently historically new messages have always been accompagnied with a protocol bump; i'm kind of surprised by this, as it forces serialized coordination for adding new messages
< wumpus>
sipa: exactly
< sipa>
hebasto: "the protocol" will differ depending on who you ask
< wumpus>
it shouldn't be like that in a decentralized protocol
< luke-jr>
NACK bullying other implementations on the p2p protocol
< wumpus>
I'm pretty sure we've added messages before without increasing the version
< luke-jr>
though I agree it's a dumb idea to force protocol version increments like this
< wumpus>
"bullying" wtf
< wumpus>
come on
< MarcoFalke>
incrementing the protocol version number doesn't mean p2p dev is centralized
< luke-jr>
wumpus: causing them to disconnect when we could easily remain compatible?
< sipa>
i don't think this is bullying; it's a disagreement about what the protocol entails
< wumpus>
luke-jr: it was their choice to disconnect on a silly reason like that
< sdaftuar>
whatever we decide to do, i think the updated bip that describes what we do should be reposted to the mailing list
< aj>
btcd would stay connected to 0.20 and earlier nodes so won't drop off from the network entirely, no? is this that big a problem?
< luke-jr>
wumpus: this isn't their change
< wumpus>
in any case my first proposal for the BIP was to do it with a version bump
< wumpus>
but no one wanted it and now suddenly ...
< jonasschnelli>
Was/is there a reason to _not_ bump the protocol version for addr2?
< wumpus>
just because some other imnplementation does something weird
< jonasschnelli>
like it was done for sendheaders BIP 130
< MarcoFalke>
wumpus: Yes, I think it wasn't clear that btcd and libbitcoin did that
< wumpus>
I honestly don't know
< sipa>
wumpus: oh, another minor point is that the bip and the implementation currently mismatch
< MarcoFalke>
wumpus: I just learned about that last week
< wumpus>
I'm not going to reconsider based on that anyway
< sipa>
wumpus: about a related thing
< sipa>
the bip says send sendaddrv2 after receiving verack, but the implementation sends it after sending verack
< luke-jr>
right now, the network is all talking fine; Core intentionally deploying a change that breaks it seems wrong
< Victorsueca>
´causing them to disconnect when we could easily remain compatible?´ < The reverse could also be said, causing us to implement things in a specific way when they could easily ignore the messages?
< wumpus>
so they don't plan on implementing addrv2 at all?
< wumpus>
let's just drop it
< sipa>
wumpus: what?
< sipa>
they're just concerned because their _old_ versions can't talk to new core anymore
< wumpus>
sipa: Im ean if no one else wants to move forward on that
< jonasschnelli>
why not just bump the protocol version?
< wumpus>
or maybe don't send addrv2 to ipv4 and ipv6 nodes at all
< wumpus>
they don't care about the other networks
< sdaftuar>
i'm a bit confused. the only question is whether to send the "sendaddrv2" message on startup?
< luke-jr>
they might
< MarcoFalke>
I think for rc3 we should aim for a minimal fix (or no fix at all)
< MarcoFalke>
I liked jnewbery's suggestion
< MarcoFalke>
I suspect that can be implemented with a one-line patch
< jnewbery>
It's really just a very small fix, moving a few lines of code
< jnewbery>
and updating the BIP to match
< wumpus>
but addrv2 isn't bound to any protocol version
< hebasto>
but we bumper protocol version due to new wtxidrelay message
< wumpus>
it shouldn't be
< hebasto>
#18044
< sipa>
that part doesn't even need a bip change; we can just as courtesy decide to not send sendaddrv2 below a certain protocol version, because we know locally that things with lower protocol version don't support it anyway
< wumpus>
it's silly to do this now in a last minute rc chang
< jnewbery>
wumpus: i'm confused. You said earlier you wanted it to be done with a version bump
< wumpus>
jnewbery: at the time, yes
< luke-jr>
anyone want to throw together a BIP saying the same protocol version bump also implies unknown messages are ignored? ;)
< MarcoFalke>
and the workaround can be removed later on
< wumpus>
then we spent months discussing it and no one else wanted it
< sipa>
luke-jr: good luck opening that can of worms again
< luke-jr>
though I suspect libbitcoin will disagree with that BIP
< wumpus>
because it was so much easier to do it without a version bump
< jnewbery>
wumpus: why is it easier?
< sdaftuar>
luke-jr: i proposed something similar recently, and then withdrew it after opposition on the mailing list
< wumpus>
because agreeing on a version bump is hard ESPECIALLY BETWEEN IMPLEMENTATIONS
< luke-jr>
sigh
< wumpus>
just adding an identification message allowed for a mechanism to extend the protocol without a central point of agreement !
< wumpus>
this doensn't bind it together with other protocol changes
< sipa>
wumpus: well, i fully agree
< wumpus>
so implemetnations can implement and relay v2 without implementing other protocol changes
< wumpus>
so many people told this to me
< sipa>
but isn't it reasonable to try to not break things on the existing network, regardless of who is at fault for it?
< jonasschnelli>
I agree. IMO it should be handled on the side of btcd/libbitcoin. Dropping on unknown messages makes backward compatibility just insanely hard.
< jonasschnelli>
I guess a fix send a wrong signal
< aj>
or by adding a compatability node in between
< MarcoFalke>
Maybe we shouldn't modify the bip, but add a temporary patch to be able to speak to non-upgraded nodes
< sipa>
i'm happy to reach out to btcd and tell them this is silly, and we don't think it makes sense to continue this... but in order not to break their existing nodes, we'll not send sendaddrv2 to older versions this one time
< sipa>
MarcoFalke: that's my suggestion
< luke-jr>
what about libbitcoin which fundamentally disagrees with us?
< jonasschnelli>
Probably an adequate trade-off. There is just the risk our codebase will have many workaround in the future to protect falling alternative implementations
< sipa>
i can't comprehend their stance
< wumpus>
as ssaid we don't need this for ipv4/ipv6 nodes
< luke-jr>
sipa: I suspect it's just disagreement for the sake of disagreement :/
< MarcoFalke>
luke-jr: I think that can be hashed out on the mailing list
< wumpus>
maybe I made a mistake to try this at all
< MarcoFalke>
no need to block rc3 on resolving that discussion
< sipa>
wumpus: we do want torv3 addresses to relay across ipv4/ipv6 nodes
< jonasschnelli>
wumpus: no you didn't
< luke-jr>
MarcoFalke: true
< jonasschnelli>
It's clearly a missimplementation
< sipa>
wumpus: indeed you don't- i think there are just misunderstandings about what the protocol entails
< sipa>
and it's unfortunate that this comes out now
< wumpus>
mostly sorry for vasild who did all the actual implementation work
< luke-jr>
jonasschnelli: it's intentional, so not mis-
< jonatack>
is there a post on the btcd/libbitcoin position and plans? seems quite late
< jonasschnelli>
are they (btcd) dropping on any unknown message?
< jonasschnelli>
or to they just pin valid message to protocol versions?
< wumpus>
jonatack: yes, why does this come up last minute? between rcs?
< MarcoFalke>
wumpus: I think it was the right choice, and everyone agreed with you. the mismatch on the live network was just not anticipated back then.
< sipa>
wumpus: well that's when people test
< sdaftuar>
i am not sure an updated version of bip155 was ever sent to the mailing list describing that the version bump was being dropped. so it's hard to blame them, imo, other than for a long-running misunderstanding of how we think unknown messaegs should be treated
< luke-jr>
sdaftuar: we also have no authority to impose BIP155 on them anyway
< sdaftuar>
luke-jr: agreed
< sipa>
sdaftuar: i think the initial discussion was about version bump vs sendaddrv2 as the negotiation mechanism itself
< MarcoFalke>
(we still have one more topic, so we should slowly wrap up)
< wumpus>
they're free to not implement it, but disconnecting just doens't make sese
< wumpus>
there's no question of "authority" here
< wumpus>
they're preventing us from implementing new messages
< wumpus>
sipa: yes
< luke-jr>
well, preventing it from being implemented nicely anyway
< sipa>
wumpus: yes, agree, i believe that going forward using new messages is absolutely the right way, not tied to protocol version
< wumpus>
it's enforcing authority by denying the upgrade method of introducing new messages
< sdaftuar>
sipa: was that discussion on hte mailing list?
< wumpus>
because everyone needs to agree on new version numbers then
< wumpus>
and what messages come with them
< sipa>
wumpus: but it's kind of similar to "don't break userspace" in linux's philosophy... somehow someone ended up relying on something that wasn't guaranteed; we can be courteous and make sure it doesn't cause problems
< wumpus>
this is not accetpable for a protocol that is not centrally coordinated
< jonasschnelli>
same with the service bits (a bit more flexible)
< wumpus>
if there was some organization like IANA it'd be different
< MarcoFalke>
there is still the "central" BIP repo
< sipa>
looks like they were just completely unaware that ignoring unknown messages was the right thing to do, but are ok with ignoring unknown messages otherwise
< bitcoin-git>
[bitcoin] achow101 opened pull request #20562: tests: Test that a fully signed tx given to signrawtx is unchanged (master...test-signraw-fullysigned) https://github.com/bitcoin/bitcoin/pull/20562
< wumpus>
could freeze the current P2P network and define a new one :)
< sdaftuar>
i think we should just decide what we want to do and let everyone know what that is
< luke-jr>
jonasschnelli: that implies we have authority to impose this on them?
< * sipa>
points at BIP324
< wumpus>
with jonasschnelli 's encryption and stuff
< luke-jr>
oooh good idea
< jonasschnelli>
yes. That will be a nightmare
< aj>
luke-jr: can't impose anything on them, they can keep disconnecting if they think that's desirable
< luke-jr>
?
< luke-jr>
jonasschnelli: make the ignoring unknown msgs part of it
< wumpus>
the old one will still work and it's entirely voluntary to implement it *shrug*
< jonasschnelli>
Its not even messages in BIP324,.. its the handshake that is headerless
< aj>
wumpus: bender meme, we'll make our own p2p with encryption and blow?
< jonasschnelli>
agree with sdaftuar
< wumpus>
I really don't want these kind of questions about authority, no one needs authority to do anything, that's not the point
< wumpus>
aj: yess
< jonasschnelli>
aj: heh. Yes.
< aj>
blackjack and encryption apparently
< wumpus>
and permissionlessness
< luke-jr>
wumpus: when existing nodes on the network stop working because of a change we make, it takes authority to say that the blame is on someone else..
< aj>
4min left if we want to quickly discuss bitcoin-util
< wumpus>
#topic bitcoin-util (aj)
< core-meetingbot>
topic: bitcoin-util (aj)
< MarcoFalke>
#action bender meme, we'll make our own p2p with encryption and blow?
< core-meetingbot>
ACTION: bender meme, we'll make our own p2p with encryption and blow?
< wumpus>
aj: sorry
< aj>
#19937
< jonasschnelli>
BIP324 is probably different since we want to get disconnected when the handshake is not supported
< MarcoFalke>
aj: I still don't get why it needs a new way of parsing args
< aj>
signet mining has high enough difficulty that grinding in python doesn't work. but gridning needs libconsensus code so can't be stuck in bitcoin-cli without bloating it
< MarcoFalke>
this is just asking for an unmaintaible mess if new features are added
< aj>
bitcoin-util as a generic thing has been proposed in #14671 iirc for doing things like psbt without needing a running node
< MarcoFalke>
ACK on adding the utility in general
< wumpus>
python bindings for libconsensus
< sipa>
aj: any reason why it can't be an RPC?
< MarcoFalke>
sipa: I asked that too
< sipa>
(i know it doesn't *need* to be an RPC, but in this specific case, is there a reason why that'd be problematic)
< aj>
sipa: 14671 talks about not adding RPCs for utility functions in general, and having a separate command for that
< sipa>
ok
< sipa>
That's fair
< wumpus>
I guess the drawback is adding yet another executable, which links in a lot of stuff, but if we have other plans for bitcoin-util apart from just the signet grinding it may be worth it
< aj>
sipa: could be, but would be a bit weird. no specific problem i thnk. making "generate" just work is a pain since signet signing needs a wallet
< MarcoFalke>
aj: If someone already has the server running, it might be faster to call the rpc instead of figuring out how to run the util
< aj>
wumpus suggested adding it to bitcoin-tx which works fine (it already links libconsensus), but is klunky
< wumpus>
it's too bad we already have bitcoin-tx with the same (in)dependency idea
< wumpus>
yes
< andytoshi>
in elements we had this issue with our signed blocks, we had to back out some of the separation between wallet and node
< andytoshi>
which i was not happy about
< aj>
might make sense to do it in bitcoin-tx now, and have a new PR later that adds bitcoin-util with multiple functionality bits (and better arg handling like MarcoFalke suggests)
< andytoshi>
and i wish we didn't have that RPC. fwiw.
< sipa>
andytoshi: that's useful information
< wumpus>
aj: I don't particularly need to have that intermediate state FWIW
< wumpus>
aj: if there are plans for bitcoin-util it's okay with me
< andytoshi>
esp as, in practice, the requirements for a blocksigner are different from the requirements for a generic wallet, so probably signers would want their own sepaarte software anyway. the RPC is mostly just good for testing
< MarcoFalke>
the private keys could be passed in to the grind command. *hides
< wumpus>
aj: and yes, it needs to use the same argument handling as our other binaries
< sipa>
aj: btw, why is the difficulty too high for python? you control the difficulty yourself, no?
< luke-jr>
separate repo that runs a temporary bitcoind, runs a RPC, and exits? :P
< sipa>
also have you tried pypy?
< sipa>
it tends to be several times faster for things like this
< wumpus>
we definitely don't want to use differnt argument handling between binaries
< aj>
sipa: min difficulty for signet is higher than original because the retarget calculations don't work right for particularly high targets
< sipa>
ha
< aj>
sipa: pypy is faster, but not crazy faster and it makes it more complicated to run
< sipa>
aj: what is the effective min difficulty?
< wumpus>
you can load libconsensus using ctypes
< wumpus>
*ducks*
< luke-jr>
if libconsensus works, the util should be a separate repo ;)
< sipa>
libconsensus doesn't do mining; you'd still be calling python->c++ for every individual hash attempt
< wumpus>
(ctypes works very well I've used it in the past for python bindings)
< sipa>
pretty sure that's going to be slower than the actual time spent hashing
< wumpus>
huh yes
< MarcoFalke>
*libbitcoinkernel
< luke-jr>
doesn't Python have its own hashing stuff?
< aj>
doesn't have double sha256
< wumpus>
yes, python has its own hashing stuff, but appearntly it's too slow
< luke-jr>
maybe just do it in C then?
< luke-jr>
libblkmaker has a straightforward example.c
< luke-jr>
that could be extended
< wumpus>
yes, loading shared libraries from python is straightforward
< aj>
so conclusion is stick with -util and fix up marcofalke's arg handling objections?
< jonatack>
sipa: thanks for the link to the btcd issue
< luke-jr>
example.c is 135 lines and mines a block from a GBT template
< wumpus>
even better, shared libraries have less call overhead than a separate process
< sipa>
aj: seems reasonable to me
< aj>
luke-jr: there's also the nbits to target and comparison against target stuff that arith_uint256 currently handles
< luke-jr>
aj: true
< aj>
wumpus: shared libraries seem like it'd be a super pita to make work for people running mac and windows?
< wumpus>
aj: why?
< wumpus>
aj: windows has dlls and mac simply has so's
< aj>
wumpus: everything seems like a pain for mac and windows? i don't know :)
< luke-jr>
dunno about mac, but it's even easier on Windows
< luke-jr>
Windows will prefer a DLL in your working directory ;)
< wumpus>
windows has a better shared library implementatin than POSIX imo *ducks*
< MarcoFalke>
#20483 is also tagged for 0.21.0
< gribble>
https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
< luke-jr>
wumpus: well, Windows has no way out of DLL hell system-wide
< MarcoFalke>
is 20483 needed?
< jonatack>
MarcoFalke: for 0.21 I agree with your review, it seems too late as the current plan is to not merge it until estimatefeerate/setfeerate in sat/vB
< luke-jr>
yeah, too late for 0.21 IMO
< jonatack>
based on the discussion in luke-jr's estimatesmartfee PR
< jonatack>
yeah
< wumpus>
luke-jr: I'm very much exagaratting, what I like about windows is their separation between link libraries (.lib) and the dlls themselves, the versioning stuff is much worse on windows
< wumpus>
jonatack: ok let's remove it then
< MarcoFalke>
ok, removed milestone on #20483
< gribble>
https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
< wumpus>
I think we should only tag regression fixes for 0.21 for now
< wumpus>
I guess so, especially as there is still discussion in the PR what way to go
< wumpus>
it's fine for backport -- for 0.21.1
< wumpus>
I mean, not everything that could be backported to 0.21 needs to go in between rcs
< vasild>
Is there any email post, chat message or anything from btcd or libbitcoin on sendaddrv2? I think is it ok to proceeed with 0.21 as it is now in current master because as mentioned above agreeing on a protocol version is indeed too centralized. What if there are 7 implementations and they never agree?
< luke-jr>
vasild: uh, as things are now, we have *disagreement*
< vasild>
luke-jr: thanks, I will read and followup tomorrow
< wumpus>
yes, breaking the network would be a bad thing
< wumpus>
i don't think torv3 support is more important than breaking the network, if push comes to shove they win
< bitcoin-git>
[bitcoin] hebasto opened pull request #20563: build: Check that Homebrew's berkeley-db4 package is actually installed (master...201203-bdb) https://github.com/bitcoin/bitcoin/pull/20563
< wumpus>
do they have a proposal to support torv3? or is that just not important
< luke-jr>
wumpus: I think they just want the protocol number bumped
< wumpus>
I could see how it would be beneficial to some parties to break tor hidden service support
< sipa>
wumpus: the discussion there isn't about addrv2 at all, but in general (and started by the wtxid discussion)
< wumpus>
it wouldn't be so much of a hurry if v2 support wasn't deprecated
< sipa>
and in any case it's a minor thing - it's not like the entire network is suddenly going to run 0.21
< wumpus>
sipa: so essentailly this means that clients before that version (and implement *all* its features) could never support torv3 relaying
< sipa>
wumpus: well the last few years at least all new features have used a combination of protocol version bump that triggers a "sendFEATURE" message
< wumpus>
which means they can't support tor hidden services at all anymore in short time
< wumpus>
period
< luke-jr>
wumpus: from my understanding, libbitcoin's vision is that every new feature bumps the version number *and* negotiates availability
< sipa>
wumpus: so really all that a version bump does is "sendaddrv2 and addrv2 now exist" - if they're not negotiated they'll still not be used
< wumpus>
it was already short while and I'm very disappointed people try to sabotage this
< luke-jr>
so you could support the latest version number by simply ignoring the negotiation of everything
< sipa>
wumpus: there are two separate discussions here
< wumpus>
just send version number 9999999
< sipa>
wumpus: the libbitcoin one, which was related to wtxid relay
< luke-jr>
XD
< wumpus>
deprecate protocol version numbers
< sipa>
and now the btcd disconnecting when sendaddrv2 is sent
< sipa>
wumpus: yes, agree
< sipa>
i don't think it's constructive to call this sabotage
< wumpus>
well no one else came up with a solution to this even with so little time left
< sipa>
what do you mean? there is a solution, it works, it's tested, and it'll be in the next release
< luke-jr>
?
< wumpus>
sipa: if it's up to me, yes
< sipa>
oh i assumed "solution to this" was about addrv2 itself; not about protocol negotiation
< sipa>
my suggestion is to just only send sendaddrv2 to clients with protocol version>=70016, as i believe that'll just work with no practical downsides
< sipa>
and tell btcd people that it's in their own interest to not keep expecting such bumps going forward, as a single version number for negotiation things just doesn't work
< sipa>
i don't know what to do about libbitcoin - it seems we just fundamentally disagree about what the protocol is there
< luke-jr>
as long as we ensure they can't continue their silliness into BIP324, at least it has an end date?
< luke-jr>
(we can just add new features only within the context of BIP324)
< wumpus>
luke-jr: I just had the idea we could recycle the alert message, it allows arbirary content, right, and as long as the signature doesn't check out old clients won't interpret it as an actual alert
< sipa>
haha
< luke-jr>
wumpus: O.o
< luke-jr>
eh, IMO not worth it
< luke-jr>
easier to just gratuitously bump the protocol version number for everything
< luke-jr>
until we switch to BIP324
< wumpus>
I'm not seriously considering it, but if people want silly I can do silly very well :)
< luke-jr>
:p
< wumpus>
it's always possible to find a away to shuttle data over some protocol
< wumpus>
and impossible to block all such vectors
< wumpus>
one thing I had never imagined was having to do this for the bitcoin P2P protocol, I mean usually it's about trying to smuggle bitcoin P2P data like blocks and transactions over some other layer
< wumpus>
but in any case, no, they can't block permissionless extensibility
< wumpus>
there are sneaky ways to negotiate :p
< wumpus>
maybe one day we have the entire protocol running over the alert message
< wumpus>
Connecting to chat.freenode.net:6697 with nick bitcoin-git and channels: #bitcoin-commits,#bitcoin-core-dev: There was a problem sending messages to IRC: timed out
< wumpus>
eh hopefully it's a temporary problem
< bitcoin-git>
[bitcoin] laanwj closed pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476
< wumpus>
seems so
< bitcoin-git>
[bitcoin] laanwj reopened pull request #20476: contrib: Add test for ELF symbol-check (master...2020_11_test_symbol_check) https://github.com/bitcoin/bitcoin/pull/20476