19:00:38 <wumpus> #startmeeting 
19:00:38 <core-meetingbot> Meeting started Thu Dec  3 19:00:38 2020 UTC.  The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
19:00:38 <core-meetingbot> Available commands: action commands idea info link nick
19:00:40 <jonasschnelli> hi
19:00:45 <jonatack> hi
19:00:46 <promag> howdy
19:00:51 <hebasto> hi
19:00:57 <jnewbery> hi
19:00:58 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
19:01:00 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
19:01:01 <luke-jr> wumpus: #10615 has supported a 4th field with a wallet name
19:01:04 <gribble> https://github.com/bitcoin/bitcoin/issues/10615 | RPC: Allow rpcauth configs to specify a 4th parameter naming a specific wallet by luke-jr · Pull Request #10615 · bitcoin/bitcoin · GitHub
19:01:23 <achow101> hi
19:01:30 <wumpus> luke-jr: oh okay, so separate access control per wallet
19:01:32 <amiti> hi
19:01:42 <fjahr> hi
19:01:46 <sipa> hi
19:02:22 <luke-jr> wumpus: yes; not sure what else it could be used for, but the behaviour of rejecting the line (at runtime) should be generally safe
19:02:23 <aj> hi
19:02:24 <luke-jr> hi
19:02:27 <wumpus> two proposed topics for today: rc3, 0.19 release, 0.20 release (marcofalke), bitcoin-util cli utility for 19937 (aj)
19:03:00 <MarcoFalke> hi
19:03:05 <luke-jr> wumpus: maybe should add -strict if we have time
19:03:07 <jonasschnelli> #19937 
19:03:09 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
19:03:44 <wumpus> any last minute topics anyone wants to discuss?
19:04:25 <wumpus> #topic High priority for review
19:04:25 <core-meetingbot> topic: High priority for review
19:04:46 <wumpus> https://github.com/bitcoin/bitcoin/projects/8  11 blockers, 2 chasing concept ACK
19:05:27 <jonatack> can rm #20483
19:05:30 <gribble> https://github.com/bitcoin/bitcoin/issues/20483 | wallet: deprecate feeRate in fundrawtransaction/walletcreatefundedpsbt by jonatack · Pull Request #20483 · bitcoin/bitcoin · GitHub
19:06:06 <wumpus> jonatack: done
19:06:09 <MarcoFalke> I'd like to switch mine out for #20362
19:06:12 <gribble> https://github.com/bitcoin/bitcoin/issues/20362 | test: Implicitly sync after generate* to preempt races and intermittent test failures by MarcoFalke · Pull Request #20362 · bitcoin/bitcoin · GitHub
19:06:13 <jonatack> (it can't go in until we have estimatefeerate / setfeerate)
19:07:10 <wumpus> MarcoFalke: done
19:07:14 <wumpus> jonatack: yes, makes sense
19:07:14 <MarcoFalke> thx
19:07:24 <jonatack> (e.g. sat/vB versions of settxfee and estimatesmartfee)
19:08:17 <wumpus> anything else to add/remove? or that's ready to merge?
19:08:40 <wumpus> #19937 is already a topic in itself
19:08:43 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
19:09:04 <hebasto> jnewbery: kindly reminder to rebase #19910
19:09:06 <gribble> https://github.com/bitcoin/bitcoin/issues/19910 | net processing: Move peer_map to PeerManager by jnewbery · Pull Request #19910 · bitcoin/bitcoin · GitHub
19:09:31 <jnewbery> hebasto: thanks. Will do!
19:10:35 <wumpus> #topic rc3, 0.19 release, 0.20 release (marcofalke)
19:10:36 <core-meetingbot> topic: rc3, 0.19 release, 0.20 release (marcofalke)
19:10:58 <MarcoFalke> ok, 0.19 first. Are we going to tag a release?
19:11:02 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/46 is empty
19:11:16 <wumpus> sounds fine to me
19:11:18 <MarcoFalke> if yes, are we going to gitian build?
19:11:23 <luke-jr> might as well do a rc1 at least
19:11:33 <wumpus> I think that's what he means, tag rc1
19:11:36 <luke-jr> whether there will be enough people who test it to warrant a final, dunno
19:12:24 <wumpus> well we can tag it we'll see if people care about building it
19:12:24 <luke-jr> looks like 0.19 is still pretty common use
19:12:35 <MarcoFalke> Ok, so it seems 0.19.2rc1 soon
19:12:37 <luke-jr> ~12% of the network
19:12:40 <MarcoFalke> Then 0.20
19:12:46 <wumpus> not really something I care about but tagging isn't much work
19:12:57 <wumpus> 0.20 on the other hand
19:13:02 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/49
19:13:26 <MarcoFalke> There is one issue, hasen't gotten more review
19:13:31 <MarcoFalke> What to do about that?
19:13:42 <MarcoFalke> outstanding thing is #19740
19:13:45 <gribble> https://github.com/bitcoin/bitcoin/issues/19740 | [0.20] wallet: Simplify and fix CWallet::SignTransaction by achow101 · Pull Request #19740 · bitcoin/bitcoin · GitHub
19:13:58 <luke-jr> most 0.19 nodes are 0.19.0.1 still
19:14:00 <hebasto> if 0.21 is around the coner is 0.19.2 really needed?
19:14:24 <MarcoFalke> hebasto: At least the tag, so that people building from source can use it
19:14:25 <luke-jr> hebasto: doesn't hurt
19:14:33 <hebasto> ok
19:14:50 <MarcoFalke> the branch will be deleted eventually, so a tag also helps to archive the latest branch
19:15:08 <wumpus> looks like 19740 has some difficulty getting review, please focus on that, 0.20 is much more relevant
19:15:10 <hebasto> MarcoFalke: I see
19:15:31 <MarcoFalke> does 19740 warrant holding back 0.20.2?
19:15:46 <wumpus> maybe we should add it to high prio
19:15:50 <luke-jr> probably not
19:15:56 <wumpus> achow101: here?
19:16:05 <MarcoFalke> I think we should ping reviewers directly
19:16:09 <luke-jr> IIRC I hit the bug only by some corner case
19:16:12 <achow101> MarcoFalke: IMO yes. it's a pretty significant bug
19:16:33 <MarcoFalke> achow101: Any suggestions who could review it?
19:17:01 <achow101> meshcollider and ryanofsky at least
19:17:04 <wumpus> it's ony a change in one function, a very important one though
19:17:33 <MarcoFalke> I checked that the function content is copied from master, that is easy to check
19:17:39 <achow101> and anyone who reviewed the changes leading up to descriptor wallets
19:18:30 <MarcoFalke> what is the worst thing that could happen? I guess a tx could come back unsigned?
19:18:52 <achow101> yes
19:20:11 <wumpus> the functional tests should catch that though
19:20:47 <MarcoFalke> SignTransaction is marked const, so it shouldn't modify the spkm either
19:21:08 <achow101> the bug was that a fully signed tx would come back as supposedly not complete, although nothing would change in that tx
19:21:13 <MarcoFalke> Seems almost safe to merge as-is (famous last words?)
19:21:43 <jonatack> nice simplification, surprising that no tests need to be updated if something was broken
19:21:49 <achow101> given that 0.20 only has the LegacySPKM implemented, I think this could be trivially correct?
19:22:23 <wumpus> jonatack: right seems there's no test for the fixed behavior
19:22:52 <wumpus> in any case if it's 'trivially correct' I'd like to see some ACKs soon :)
19:22:54 <jonatack> a description of what was broken/fixed in the PR or commit would be nice
19:23:11 <achow101> #17204 apparently tests this kind of accidentally
19:23:13 <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
19:24:17 <wumpus> would be worth a try then maybe
19:24:46 <MarcoFalke> #action tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
19:24:46 <core-meetingbot> tag 0.19.2rc1 now , tag 0.20.2rc1 after 19740
19:25:09 <MarcoFalke> ok, finally rc3
19:25:15 <MarcoFalke> Anything missing for rc3?
19:25:25 <jnewbery> is there definitely going to be an rc3?
19:25:35 <sipa> short topic: can people read over https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.21.0-Release-Notes-Draft? i think a few things are missing
19:25:36 <wumpus> do we have any serious issues reported for rc2 yet?
19:25:58 <MarcoFalke> https://github.com/bitcoin/bitcoin/milestone/45
19:26:09 <MarcoFalke> jnewbery: Yes, stuff has been merged, so there must be one
19:26:23 <wumpus> did we merge stuff? oh
19:26:26 <jonatack> achow101: you mean the test I added in 17204? That PR was a bit of a head-scratcher tbh
19:26:48 <sipa> #20511 : i think we should drop it for 0.21
19:26:49 <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
19:27:03 <MarcoFalke> merged stuff: https://github.com/bitcoin/bitcoin/commits/0.21
19:27:09 <sipa> it's harder to fix than i initially imagined, and anchors.dat didn't exist at all so it's a new feature anyway
19:27:10 <wumpus> did we have any regressions then?
19:27:36 <sdaftuar> what's the status of sendaddrv2/bip155, there was a report that it caused other peers to disconnect us i think?
19:27:44 <luke-jr> couldn't anchors.dat store all V2 then?
19:27:48 <jnewbery> sipa: I removed #20511 from the milestone
19:27:49 <gribble> https://github.com/bitcoin/bitcoin/issues/20511 | anchors.dat doesnt support V2 addresses · Issue #20511 · bitcoin/bitcoin · GitHub
19:28:52 <MarcoFalke> sdaftuar: Yes, the protocol version wasn't bumped, and some peers use the protocol version to determine which message types are "expected"
19:28:55 <sipa> sdaftuar: you mean gating it based on protocol version?
19:29:01 <sdaftuar> yes, that
19:29:09 <jnewbery> If we're doing an rc3, then I think we should merge a change to only send sendaddrv2 to peers on v70016+
19:29:16 <wumpus> my initial proposal was to increase the protocol version but this was almost universally hated
19:29:16 <sipa> we did bump the version number anyway, right?
19:29:31 <MarcoFalke> is 70016 the version of wtxidrelay?
19:29:45 <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
19:29:47 <wumpus> everyone wanted some other mechanism
19:29:49 <sipa> wumpus: this isn't about protocol version vs sendaddrv2; it's about using protocol version to know whether "sendaddrv2" is a legal message
19:29:52 <wumpus> so where is it given problems?
19:30:03 <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
19:30:09 <wumpus> we don't have *any* mechanism like that
19:30:10 <jnewbery> wumpus: btcd drops the connection if it receives a sendaddrv2
19:30:18 <wumpus> that's their problem
19:30:20 <MarcoFalke> libbitcoin might, too
19:30:27 <sipa> wumpus: i agree it's silly
19:30:39 <wumpus> we've always ignored unknown messages
19:30:51 <wumpus> and that's how it should be
19:31:15 <wumpus> it was always the idea that new messages could be used as an extension mechanism
19:31:21 <hebasto> ^^^ isn't this rule a part of ptotocol?
19:31:27 <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
19:31:45 <wumpus> sipa: exactly
19:31:50 <sipa> hebasto: "the protocol" will differ depending on who you ask
19:31:54 <wumpus> it shouldn't be like that in a decentralized protocol
19:32:06 <luke-jr> NACK bullying other implementations on the p2p protocol
19:32:14 <wumpus> I'm pretty sure we've added messages before without increasing the version
19:32:17 <luke-jr> though I agree it's a dumb idea to force protocol version increments like this
19:32:26 <wumpus> "bullying" wtf
19:32:29 <wumpus> come on
19:32:44 <MarcoFalke> incrementing the protocol version number doesn't mean p2p dev is centralized
19:32:45 <luke-jr> wumpus: causing them to disconnect when we could easily remain compatible?
19:32:46 <sipa> i don't think this is bullying; it's a disagreement about what the protocol entails
19:33:01 <wumpus> luke-jr: it was their choice to disconnect on a silly reason like that
19:33:08 <sdaftuar> whatever we decide to do, i think the updated bip that describes what we do should be reposted to the mailing list
19:33:09 <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?
19:33:13 <luke-jr> wumpus: this isn't their change
19:33:23 <wumpus> in any case my first proposal for the BIP was to do it with a version bump
19:33:34 <wumpus> but no one wanted it and now suddenly ...
19:33:43 <jonasschnelli> Was/is there a reason to _not_ bump the protocol version for addr2?
19:33:49 <wumpus> just because some other imnplementation does something weird
19:33:54 <jonasschnelli> like it was done for sendheaders BIP 130
19:33:55 <MarcoFalke> wumpus: Yes, I think it wasn't clear that btcd and libbitcoin did that
19:33:58 <wumpus> I honestly don't know
19:34:04 <sipa> wumpus: oh, another minor point is that the bip and the implementation currently mismatch
19:34:05 <MarcoFalke> wumpus: I just learned about that last week
19:34:12 <wumpus> I'm not going to reconsider based on that anyway
19:34:13 <sipa> wumpus: about a related thing
19:34:47 <sipa> the bip says send sendaddrv2 after receiving verack, but the implementation sends it after sending verack
19:34:59 <luke-jr> right now, the network is all talking fine; Core intentionally deploying a change that breaks it seems wrong
19:35:01 <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?
19:35:26 <wumpus> so they don't plan on implementing addrv2 at all?
19:35:31 <wumpus> let's just drop it
19:35:39 <sipa> wumpus: what?
19:35:54 <sipa> they're just concerned because their _old_ versions can't talk to new core anymore
19:36:05 <wumpus> sipa: Im ean if no one else wants to move forward on that
19:36:23 <jonasschnelli> why not just bump the protocol version?
19:36:26 <wumpus> or maybe don't send addrv2 to ipv4 and ipv6 nodes at all
19:36:54 <wumpus> they don't care about the other networks
19:37:06 <sdaftuar> i'm a bit confused. the only question is whether to send the "sendaddrv2" message on startup?
19:37:09 <luke-jr> they might
19:37:26 <MarcoFalke> I think for rc3 we should aim for a minimal fix (or no fix at all)
19:37:31 <MarcoFalke> I liked jnewbery's suggestion
19:37:45 <MarcoFalke> I suspect that can be implemented with a one-line patch
19:37:46 <jnewbery> It's really just a very small fix, moving a few lines of code
19:37:59 <jnewbery> and updating the BIP to match
19:38:01 <wumpus> but addrv2 isn't bound to any protocol version
19:38:03 <hebasto> but we bumper protocol version due to new wtxidrelay message
19:38:06 <wumpus> it shouldn't be
19:38:27 <hebasto> #18044 
19:38:29 <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
19:38:31 <wumpus> it's silly to do this now in a last minute rc chang
19:38:35 <gribble> https://github.com/bitcoin/bitcoin/issues/18044 | Use wtxid for transaction relay by sdaftuar · Pull Request #18044 · bitcoin/bitcoin · GitHub
19:38:41 <sipa> wumpus: yeah...
19:38:52 <jnewbery> wumpus: i'm confused. You said earlier you wanted it to be done with a version bump
19:38:59 <wumpus> jnewbery: at the time, yes
19:39:00 <luke-jr> anyone want to throw together a BIP saying the same protocol version bump also implies unknown messages are ignored? ;)
19:39:05 <MarcoFalke> and the workaround can be removed later on
19:39:13 <wumpus> then we spent months discussing it and no one else wanted it
19:39:19 <sipa> luke-jr: good luck opening that can of worms again
19:39:22 <luke-jr> though I suspect libbitcoin will disagree with that BIP
19:39:25 <wumpus> because it was so much easier to do it without a version bump
19:39:35 <jnewbery> wumpus: why is it easier?
19:39:43 <sdaftuar> luke-jr: i proposed something similar recently, and then withdrew it after opposition on the mailing list
19:39:49 <wumpus> because agreeing on a version bump is hard ESPECIALLY BETWEEN IMPLEMENTATIONS
19:39:54 <luke-jr> sigh
19:40:14 <wumpus> just adding an identification message allowed for a mechanism to extend the protocol without a central point of agreement !
19:40:42 <wumpus> this doensn't bind it together with other protocol changes
19:40:57 <sipa> wumpus: well, i fully agree
19:41:02 <wumpus> so implemetnations can implement and relay v2 without implementing other protocol changes
19:41:07 <wumpus> so many people told this to me
19:41:14 <sipa> but isn't it reasonable to try to not break things on the existing network, regardless of who is at fault for it?
19:41:40 <jonasschnelli> I agree. IMO it should be handled on the side of btcd/libbitcoin. Dropping on unknown messages makes backward compatibility just insanely hard.
19:41:51 <wumpus> yes
19:41:57 <luke-jr> jonasschnelli: can't change deployed nodes
19:42:04 <jonasschnelli> Sure you can
19:42:06 <luke-jr> …
19:42:10 <jonasschnelli> by upgrading
19:42:10 <sipa> jonasschnelli: ?
19:42:27 <jonasschnelli> I guess a fix send a wrong signal
19:42:29 <aj> or by adding a compatability node in between
19:42:30 <MarcoFalke> Maybe we shouldn't modify the bip, but add a temporary patch to be able to speak to non-upgraded nodes
19:42:38 <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
19:42:53 <sipa> MarcoFalke: that's my suggestion
19:43:24 <luke-jr> what about libbitcoin which fundamentally disagrees with us?
19:43:36 <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
19:43:37 <sipa> i can't comprehend their stance
19:43:44 <wumpus> as ssaid we don't need this for ipv4/ipv6 nodes
19:43:46 <luke-jr> sipa: I suspect it's just disagreement for the sake of disagreement :/
19:43:51 <MarcoFalke> luke-jr: I think that can be hashed out on the mailing list
19:44:02 <wumpus> maybe I made a mistake to try this at all
19:44:02 <MarcoFalke> no need to block rc3 on resolving that discussion
19:44:04 <sipa> wumpus: we do want torv3 addresses to relay across ipv4/ipv6 nodes
19:44:12 <jonasschnelli> wumpus: no you didn't
19:44:33 <luke-jr> MarcoFalke: true
19:44:33 <jonasschnelli> It's clearly a missimplementation
19:44:43 <sipa> wumpus: indeed you don't- i think there are just misunderstandings about what the protocol entails
19:44:53 <sipa> and it's unfortunate that this comes out now
19:45:02 <wumpus> mostly sorry for vasild who did all the actual implementation work
19:45:08 <luke-jr> jonasschnelli: it's intentional, so not mis-
19:45:11 <jonatack> is there a post on the btcd/libbitcoin position and plans? seems quite late
19:45:16 <jonasschnelli> are they (btcd) dropping on any unknown message?
19:45:46 <jonasschnelli> or to they just pin valid message to protocol versions?
19:45:47 <wumpus> jonatack: yes, why does this come up last minute? between rcs?
19:45:49 <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.
19:46:03 <sipa> wumpus: well that's when people test
19:46:15 <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
19:46:41 <luke-jr> sdaftuar: we also have no authority to impose BIP155 on them anyway
19:46:49 <sdaftuar> luke-jr: agreed
19:46:50 <sipa> sdaftuar: i think the initial discussion was about version bump vs sendaddrv2 as the negotiation mechanism itself
19:46:51 <MarcoFalke> (we still have one more topic, so we should slowly wrap up)
19:46:58 <wumpus> they're free to not implement it, but disconnecting just doens't make sese
19:47:13 <wumpus> there's no question of "authority" here
19:47:19 <wumpus> they're preventing us from implementing new messages
19:47:38 <wumpus> sipa: yes
19:47:42 <luke-jr> well, preventing it from being implemented nicely anyway
19:48:04 <sipa> wumpus: yes, agree, i believe that going forward using new messages is absolutely the right way, not tied to protocol version
19:48:18 <wumpus> it's enforcing authority by denying the upgrade method of introducing new messages
19:48:22 <sdaftuar> sipa: was that discussion on hte mailing list?
19:48:39 <wumpus> because everyone needs to agree on new version numbers then
19:48:51 <wumpus> and what messages come with them
19:48:51 <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
19:49:02 <wumpus> this is not accetpable for a protocol that is not centrally coordinated
19:49:43 <sipa> https://github.com/btcsuite/btcd/issues/1661
19:49:45 <jonasschnelli> same with the service bits (a bit more flexible)
19:49:48 <wumpus> if there was some organization like IANA it'd be different
19:50:01 <MarcoFalke> there is still the "central" BIP repo
19:50:10 <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
19:50:10 <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
19:50:13 <luke-jr> IANA and BIPs aren't that different
19:50:43 <luke-jr> sipa: that's just btcd though; IIRC, libbitcoin disagrees explicitly
19:50:43 <wumpus> MarcoFalke: well, yes, but a lot of things get accepted as BIP, not only if they're really implemented
19:51:01 <jonasschnelli> indeed.
19:51:02 <MarcoFalke> as long as the bip process doesn't allow duplicate assignments, it shouldn't lead to issues
19:51:09 <wumpus> I mean 'accepted as BIP' as in merged to the repository
19:51:10 <jonasschnelli> Overlap of version numbers might happen quicky
19:51:14 <wumpus> it only has to ofllow basic protocol for that
19:51:14 <luke-jr> MarcoFalke: well, it does even then
19:51:26 <MarcoFalke> (not advocating for it, just saying it is possible)
19:51:30 <wumpus> it's not a real selection process
19:51:35 <luke-jr> if ver 100 defines X, and ver 101 defines Y, now everyone who wants Y needs X
19:51:36 <wumpus> nor a central coordination
19:51:58 <aj> luke-jr: needs X or needs to successfully ignore X
19:52:00 <MarcoFalke> luke-jr: it would be on top of the negotiation message type
19:52:08 <luke-jr> aj: good point
19:52:23 <jonasschnelli> define a protocol version where tolerating unknown message is a must?
19:52:33 <sipa> jonasschnelli: that's what sdaftuar tried
19:52:39 <wumpus> jonasschnelli: heh, use the reasoning against themselves
19:52:40 <jonasschnelli> I see
19:53:07 <luke-jr> jonasschnelli: but they will reject the BIP defining it
19:53:24 <wumpus> I'm pretty tired of this
19:53:30 <jonasschnelli> well,.. then it should be their mess to clean up?
19:53:30 <sipa> we don't need their consent to implement anything
19:53:39 <sipa> but we can take discussion points into accoutn
19:53:41 <sdaftuar> jonasschnelli: see thread starting here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-August/018084.html
19:54:02 <wumpus> could freeze the current P2P network and define a new one :)
19:54:08 <sdaftuar> i think we should just decide what we want to do and let everyone know what that is
19:54:12 <luke-jr> jonasschnelli: that implies we have authority to impose this on them?
19:54:14 <sipa> points at BIP324
19:54:23 <wumpus> with jonasschnelli 's encryption and stuff
19:54:33 <luke-jr> oooh good idea
19:54:34 <jonasschnelli> yes. That will be a nightmare
19:54:38 <aj> luke-jr: can't impose anything on them, they can keep disconnecting if they think that's desirable
19:54:39 <luke-jr> ?
19:54:47 <luke-jr> jonasschnelli: make the ignoring unknown msgs part of it
19:54:56 <wumpus> the old one will still work and it's entirely voluntary to implement it *shrug*
19:55:01 <jonasschnelli> Its not even messages in BIP324,.. its the handshake that is headerless
19:55:16 <aj> wumpus: bender meme, we'll make our own p2p with encryption and blow?
19:55:20 <jonasschnelli> agree with sdaftuar
19:55:39 <wumpus> I really don't want these kind of questions about authority, no one needs authority to do anything, that's not the point
19:55:41 <wumpus> aj: yess
19:55:57 <jonasschnelli> aj: heh. Yes.
19:55:59 <aj> blackjack and encryption apparently
19:56:08 <wumpus> and permissionlessness
19:56:33 <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..
19:56:36 <aj> 4min left if we want to quickly discuss bitcoin-util
19:56:50 <wumpus> #topic bitcoin-util (aj)
19:56:51 <core-meetingbot> topic: bitcoin-util (aj)
19:56:52 <MarcoFalke> #action bender meme, we'll make our own p2p with encryption and blow?
19:56:52 <core-meetingbot> bender meme, we'll make our own p2p with encryption and blow?
19:56:52 <wumpus> aj: sorry
19:56:57 <aj> #19937 
19:57:00 <jonasschnelli> BIP324 is probably different since we want to get disconnected when the handshake is not supported
19:57:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19937 | signet mining utility by ajtowns · Pull Request #19937 · bitcoin/bitcoin · GitHub
19:57:16 <MarcoFalke> aj: I still don't get why it needs a new way of parsing args
19:57:40 <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
19:57:53 <MarcoFalke> this is just asking for an unmaintaible mess if new features are added
19:58:13 <aj> bitcoin-util as a generic thing has been proposed in #14671 iirc for doing things like psbt without needing a running node
19:58:15 <gribble> https://github.com/bitcoin/bitcoin/issues/14671 | Utility to replace RPC calls that dont need wallet or chain context · Issue #14671 · bitcoin/bitcoin · GitHub
19:58:15 <MarcoFalke> ACK on adding the utility in general
19:58:20 <wumpus> python bindings for libconsensus
19:58:26 <sipa> aj: any reason why it can't be an RPC?
19:58:35 <MarcoFalke> sipa: I asked that too
19:58:45 <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)
19:59:04 <aj> sipa: 14671 talks about not adding RPCs for utility functions in general, and having a separate command for that
19:59:23 <sipa> ok
19:59:27 <sipa> That's fair
19:59:44 <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
19:59:54 <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
20:00:01 <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
20:00:19 <aj> wumpus suggested adding it to bitcoin-tx which works fine (it already links libconsensus), but is klunky
20:00:34 <wumpus> it's too bad we already have bitcoin-tx with the same (in)dependency idea
20:00:37 <wumpus> yes
20:00:38 <andytoshi> in elements we had this issue with our signed blocks, we had to back out some of the separation between wallet and node
20:00:44 <andytoshi> which i was not happy about
20:00:49 <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)
20:00:58 <andytoshi> and i wish we didn't have that RPC. fwiw.
20:01:10 <sipa> andytoshi: that's useful information
20:01:30 <wumpus> aj: I don't particularly need to have that intermediate state FWIW
20:01:37 <wumpus> aj: if there are plans for bitcoin-util it's okay with me
20:01:47 <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
20:01:48 <MarcoFalke> the private keys could be passed in to the grind command. *hides
20:01:58 <wumpus> aj: and yes, it needs to use the same argument handling as our other binaries
20:02:04 <sipa> aj: btw, why is the difficulty too high for python? you control the difficulty yourself, no?
20:02:07 <luke-jr> separate repo that runs a temporary bitcoind, runs a RPC, and exits? :P
20:02:15 <sipa> also have you tried pypy?
20:02:25 <sipa> it tends to be several times faster for things like this
20:02:39 <wumpus> we definitely don't want to use differnt argument handling between binaries
20:02:44 <aj> sipa: min difficulty for signet is higher than original because the retarget calculations don't work right for particularly high targets
20:02:52 <sipa> ha
20:03:10 <aj> sipa: pypy is faster, but not crazy faster and it makes it more complicated to run
20:04:01 <sipa> aj: what is the effective min difficulty?
20:04:08 <wumpus> you can load libconsensus using ctypes
20:04:12 <wumpus> *ducks*
20:04:45 <luke-jr> if libconsensus works, the util should be a separate repo ;)
20:05:20 <sipa> libconsensus doesn't do mining; you'd still be calling python->c++ for every individual hash attempt
20:05:21 <wumpus> (ctypes works very well I've used it in the past for python bindings)
20:05:33 <sipa> pretty sure that's going to be slower than the actual time spent hashing
20:05:38 <wumpus> huh yes
20:05:45 <MarcoFalke> *libbitcoinkernel
20:05:48 <luke-jr> doesn't Python have its own hashing stuff?
20:05:57 <aj> doesn't have double sha256
20:06:01 <wumpus> yes, python has its own hashing stuff, but appearntly it's too slow
20:06:17 <luke-jr> maybe just do it in C then?
20:06:25 <luke-jr> libblkmaker has a straightforward example.c
20:06:29 <luke-jr> that could be extended
20:06:40 <wumpus> yes, loading shared libraries from python is straightforward
20:07:32 <wumpus> ok, time to end the meeting I think
20:07:40 <wumpus> #endmeeting