15:00:35 <jnewbery> #startmeeting
15:00:35 <lightningbot> Meeting started Tue Sep 22 15:00:35 2020 UTC.  The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:35 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:00:41 <hebasto> hi
15:00:44 <gzhao408> hi
15:00:44 <jnewbery> #bitcoin-core-dev P2P Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
15:00:50 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
15:00:57 <ajonas> hi
15:01:00 <ariard> hi
15:01:00 <aj> holla
15:01:06 <amiti> hi
15:01:09 <gleb> hi
15:01:22 <jnewbery> Hi folks. Two proposed topics today: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#22-sept-2020
15:01:24 <gribble> https://github.com/bitcoin/bitcoin/issues/22 | Update the list of hard-coded node IP addresses · Issue #22 · bitcoin/bitcoin · GitHub
15:01:29 <fanquake> hi
15:01:39 <jnewbery> - Follow-up on "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard)
15:01:40 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
15:01:45 <jnewbery> - Overview of https://github.com/bitcoin/bitcoin/pull/19988 (motivation/design philosphy rather than technical details that can be found in the PR)
15:02:13 <jnewbery> Before we get to those, are there any other proposed topics, or does anyone have any short announcements to make?
15:02:19 <gleb> Yeah, I have one.
15:02:41 <vasild> hi
15:02:49 <gleb> I suggested to rename "feeler" connection to "probe" all along the codebase, because feelers currently capture two distinct features: feelers and test-before-evict.
15:02:50 <jnewbery> gleb: feelers -> probes ?
15:03:06 <jnewbery> ok. Let's do that first (and not spend 50 minutes on it :)
15:03:17 <jnewbery> #topic feelers -> probes (gleb)
15:03:25 <gleb> There's some support of renaming, but also couple hesitations and wladimir said we would rather not, because of rebase conflicts etc
15:03:37 <gleb> So I'm planning to drop this idea for now, and just improve the documentation.
15:04:12 <gleb> If someone is strongly in favor of renaming feelers to probes, please comment in the PR sometime soon :)
15:04:17 <sipa> fixing documentation is always good
15:04:19 <gleb> #19958
15:04:22 <gribble> https://github.com/bitcoin/bitcoin/issues/19958 | Rename feelers to probes by naumenkogs · Pull Request #19958 · bitcoin/bitcoin · GitHub
15:04:27 <sipa> or at least, making it less confusing
15:05:03 <gleb> That's it, we now can discuss other topics, unless someone have something to say right now :)
15:05:17 <amiti> thanks for the doc fix :)
15:05:51 <jnewbery> I'm generally in favour of making names more meaningful. If we're going to make this name change, I think it's preferable to do it before connection types are exposed in the RPC
15:06:07 <jnewbery> But I haven't looked at the specifics here, and don't have an opinion on this change
15:06:43 <jnewbery> ok, next topic?
15:06:50 <gleb> Good point wrt RPC
15:06:57 <gleb> yeah, we can move on i guess
15:07:00 <jnewbery> #topic Follow-up on "What would a good transaction propagation framework look like? See a first draw Transactions propagation design goals #19820 (ariard)
15:07:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19820 | Transactions propagation design goals · Issue #19820 · bitcoin/bitcoin · GitHub
15:07:29 <ariard> I think we have a problem ecosystem-wise as we have protocols being designed and deployed
15:07:57 <ariard> which are completely insecure because of implicit assumptions on the tx-relay network and mempools behavior which are false
15:08:19 <sipa> anything that relies on specific properies of tx relay being guaranteed is broken
15:09:04 <gleb> how should we approach this problem? :)
15:09:14 <ariard> yes and I was aiming to synchronize people's model to suggest some kind of join IRC meeting
15:09:25 <ariard> with the LN devs, rusty, cdecker & all were down
15:09:27 <sipa> i think it's a good idea to work towards better analysing and documenting the design goals for transactions, but that's not going to result in any guarantees
15:09:35 <sdaftuar> i think tx relay works pretty well for transactions whose inputs are all confirmed?
15:10:35 <aj> sdaftuar: not if the transaction is RBF'ing something else that was previously relayed?
15:10:52 <ariard> sipa: I agree it's more how do we establish a common mental model ecosystem-wise ?
15:10:52 <sdaftuar> aj: agreed that we can continue to make improvements there!
15:11:05 <sdaftuar> aj: but i think we have something that is pretty reliable right now
15:11:07 <ariard> like either modifiyng second-layer protocols or tx-relay but not staying in-between
15:12:11 <gleb> The problem can be at least split into several
15:12:17 <vasild> Some LN protocol or implementation relies on a transaction propagating to every node?
15:12:17 <sipa> ariard: to me, the only solution if you need things that must confirm within a fixed amount of time is loudly yelling at the user if the timeout runs close
15:12:29 <gleb> For example, "assuming I can pay whatever fee, can I guarantee that my transaction will reach miners"?
15:12:51 <sdaftuar> guarantee is a very hard word to use
15:13:11 <ariard> sipa: I think we should dissociate propagation guarantee from confirmation guarantee, ofc you can't promise confirmation
15:13:13 <sipa> ariard: that's independent of potential improvements to tx relay that can make it more reliable in more varied scenarios - but if your security assumption is that relay (and confirmation!) are guaranteed, nothing can provide that
15:13:55 <ariard> sipa: yes I think we agree on the confirmation part, it's more the relay one which can be exploited by a malicious counterparty
15:13:59 <sipa> ariard: and i feel that framing this as "we need better tx relay because higher level protocols rely on some of its assumptions" is kind of missing the point
15:14:06 <bitcoin-git> [13bitcoin] 15MarcoFalke pushed 3 commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/77376034d4ab...d692d192cda3
15:14:06 <bitcoin-git> 13bitcoin/06master 14fa80c81 15MarcoFalke: Assert that RPCArg names are equal to CRPCCommand ones (blockchain)
15:14:06 <bitcoin-git> 13bitcoin/06master 14fa6bb0c 15MarcoFalke: Assert that RPCArg names are equal to CRPCCommand ones (rawtransaction)
15:14:07 <bitcoin-git> 13bitcoin/06master 14d692d19 15MarcoFalke: Merge #19849: Assert that RPCArg names are equal to CRPCCommand ones (bloc...
15:14:30 <gleb> sipa: so you're suggestion it should be users' responsibility?
15:14:31 <bitcoin-git> [13bitcoin] 15MarcoFalke merged pull request #19849: Assert that RPCArg names are equal to CRPCCommand ones (blockchain,rawtransaction) (06master...062008-rpcAssertNames) 02https://github.com/bitcoin/bitcoin/pull/19849
15:14:45 <gleb> To act when the timeout is too close. Go to a miner, or use other software, or whatelse
15:15:26 <sipa> i don't see what else you can do
15:15:44 <ariard> sipa: if I understand your point correctly we can deterministically guarantee propagation it's more a probabilistic issue
15:15:52 <ariard> *we can't
15:16:26 <gleb> I'm not even sure about probabilistic, facing an incentivised attacker.
15:16:30 <instagibbs> of course you can't, otherwise we wouldn't need PoW
15:16:31 <sipa> indeed
15:17:19 <sipa> so we should look at what features are useful for common cases in higher-level protocols, and to what extent those can be improved upon
15:17:23 <gleb> Random idea: a node could probe random nodes in the network to see how many of them knows about a tx.
15:17:42 <sipa> but if you frame this as "otherwise higher-level protocols are insecure", that's besides the point - if they were before, they'll still be insecure after
15:18:57 <vasild> if improved from 90% to 95% that is better but still not guaranteed (100%)
15:19:11 <ariard> I think the changes I'm proposing are more feature-wise than "making better tx relay"
15:20:05 <aj> sipa: i think it's more "spam prevention should be hard to use as an attack vector to prevent relay" when currently it's fairly easy to use it as an attack vector? (i consider rbf rules as spam prevention, adjust the wording if you disagree i guess)
15:20:07 <sdaftuar> is there a concrete set of proposed changes to consider?
15:20:23 <ariard> sipa: what do you understood by "we need better tx relay" ?
15:20:38 <gleb> I would propose to be more clear that "tx relay is not reliable no matter how much fees you pay"?
15:21:09 <ariard> sdaftuar: a) better documentation of policy to avoid someone hitting them for lack of testing b) something like package relay or consorts
15:21:36 <aj> gleb: there's reliable as in works 99% of the time, and reliable as in it's secure even in the face of a state-level attacker
15:22:06 <sdaftuar> ariard: i don't know what consorts means, but i don't think "package relay" is sufficiently fleshed out yet, unless there's a proposal i've missed?
15:22:12 <gleb> aj: "not guaranteed" perhaps. I'm not pushing the exact wording right now :)_
15:22:26 <ariard> sdaftuar: but there is a more philosophical question, "what if we tighten a policy rule and someone has built on it being liberal"
15:22:33 <ariard> lik increasing the mininal transaction size
15:23:01 <sipa> ariard: basically, my problem is with the word "need" - i don't know that we need anything, but that doesn't mean there can't be improvements
15:23:33 <sdaftuar> ariard: i agree that is a good question
15:24:17 <ariard> sipa: right, my wording is bad, it's more how we define clear rules a la BIP 125, and that's it don't make assumptions outside
15:25:21 <ariard> AFAIK, BIP 125 is the only standard on a mempool policy aiming to offer an interface usable by wallets/applications?
15:25:51 <sdaftuar> i think it's reasonable to ask whether policy changes to Bitcoin Core should always be documented in a BIP so that wallet authors can take those changes into account
15:26:17 <ariard> sdaftuar: voila, that's what I've in mind :)
15:26:20 <ariard> or protocol authors
15:26:21 <sdaftuar> that was exactly why i had asked for BIP 125 to be drafted in the first place, fwiw
15:26:37 <sipa> ariard: documenting the relay policy more accurate definitely sounds like a good idea
15:26:55 <sdaftuar> unfortunately we're starting from a place where none of it (except for bip 125) is documented
15:27:27 <ariard> sdaftuar: yes like we didn't have a bip for carve-out and some folks are trying to reuse it beyond LN
15:27:30 <ariard> sadly insecurely
15:28:38 <jnewbery> I don't think p2p policy belongs in BIPs. https://github.com/bitcoin-core/bitcoin-devwiki/wiki seems like a more appropriate place for it
15:28:53 <sdaftuar> jnewbery: thanks i was just going to say that it's not clear to me that BIPs are the right place either
15:29:08 <sdaftuar> on one hand, policy changes may have effects on other software, so a BIP might seem the right place
15:29:17 <ariard> I agree not necessarily a BIP as far it's documented somewhere
15:29:25 <luke-jr> strict policy, no, but things that coordinate yes
15:29:27 <ariard> though we have the example of BIP 125
15:29:41 <luke-jr> BIP 125 gives meaning to particular sequence values
15:29:52 <sdaftuar> however there is also a sense that we make implementation-specific changes frequently enough that it woulnd't make sense to always publish things in the BIP repo to reflect them
15:30:18 <ariard> sdaftuar: I agree that's too heavy to update anytime we change the rejection filter
15:30:23 <luke-jr> ariard: it's a bug for software to rely on node policies
15:30:57 <ariard> luke-jr: how do you frame BIP 125, it's a node policy ?
15:31:39 <luke-jr> ariard: it's not a node policy, it's a definition of sequence values; implementations can honour or ignore the request
15:31:49 <luke-jr> the latter decision is the policy
15:31:58 <jnewbery> I feel like we're getting into the semantic weeds here. The important thing is that policy is documented somewhere, not what you call it.
15:32:01 <luke-jr> (text aside)
15:32:30 <sdaftuar> jnewbery: i don't think that's exactly true. i think the point luke is making (or at least making me consider harder) is whether there are some aspects of node policy that are different from others
15:32:32 <jnewbery> and to me, the wiki feels like the obvious place. This is information about Bitcoin Core's policy that is being communicated to external developers
15:33:54 <luke-jr> stuff external developers should design around, makes sense to have in a BIP; but generally, that should not include most node policy
15:34:06 <luke-jr> (we can still document policy of course)
15:34:09 <ariard> luke-jr: okay if I follow your semantic BIP 125 define a request mechanism ; choosing to implement this mechanism is a policy decision
15:34:37 <luke-jr> ariard: yes, basically
15:34:59 <ariard> luke-jr: and I agree with you we can't enforce that node operators are effectively deploying this policy
15:35:12 <sdaftuar> luke-jr: in general, though, external developers are desiging around the policy already
15:35:22 <luke-jr> sdaftuar: that's a bug in their design IMO
15:35:23 <ariard> luke-jr: no more we can guarantee that everyone isn't running with blocksonly
15:35:24 <sdaftuar> and in fact that is the source of this whole discussion
15:35:34 <luke-jr> and not something we should encourage
15:36:52 <ariard> what was the thinking when bloom filters where turn off by default ?
15:37:11 <ariard> it's this kind of software setting default which encourage/discourage network-wise behaviors?
15:37:18 <ariard> *were
15:38:13 <jnewbery> we have one more topic, so I suggest we move on to that soon
15:38:30 <sipa> ariard: it was turned off because there is an obvious resource usage attack enabled by them (high disk I/O and CPU usage, barely any bandwidth for the attacker), and discussed quite widely before done so
15:38:34 <sdaftuar> luke-jr: perhaps the right way to think about this is that wallet authors should use their best understanding of what policy rules are deployed on the network to generate transactions that will propagate well, but the bug is in relying on that for security?
15:39:41 <ariard> security isn't binary, it's more how do you diminish the risk of transactions not propagating well
15:40:12 <vasild> rely on relay is bad :)
15:40:14 <sdaftuar> security is also not probabilistic
15:41:13 <aj> (20min left)
15:41:23 <jnewbery> thanks aj, let's move on to the next topic
15:41:27 <ariard> sdaftuar: I think we're going to switch off-topic but it sounds like second layers have somehow to have this probabilistic model
15:41:37 <jnewbery> #topic Overview of https://github.com/bitcoin/bitcoin/pull/19988 (motivation/design philosphy rather than technical details that can be found in the PR)
15:41:49 <jnewbery> over to you, sipa
15:41:53 <sipa> hi!
15:41:53 <ariard> jnewbery: wait before to switch do people would like to coordinate an IRC meeting with LN devs to talk about those issues ?
15:42:20 <ariard> or anyone else interested by those propagation issues
15:42:54 <gleb> ariard: The only common understanding we currently have here seem to be "need more docs". I don't see how talking to LN devs helps here?
15:42:57 <luke-jr> sdaftuar: wallets should use standards, and node policies ideally will allow standard transactions
15:43:40 <ariard> gleb: because they have implemented most of the content which could be in those "need more docs" :)
15:44:15 <jnewbery> ariard: can you co-ordinate your next meeting after this meeting? Let's move on to 19988!
15:44:32 <gzhao408> woo 19988!
15:44:33 <ariard> jnewbery: sure let's move on
15:44:38 <jnewbery> thanks!
15:44:41 <sipa> hi!
15:45:18 <sipa> so i recently PR'ed #19988, which is a rebase of 19184
15:45:20 <gribble> https://github.com/bitcoin/bitcoin/issues/19988 | Overhaul transaction request logic by sipa · Pull Request #19988 · bitcoin/bitcoin · GitHub
15:45:52 <sipa> the idea is that our tx fetching logic has really grown over time
15:46:17 <sipa> with various data structures needed for coordination, and unclear specification of what they actually implement
15:46:50 <sipa> there are biases in favor/against fetching from certain nodes, but they're all implemented indirectly through random delays and insertions/lookups in maps, that are hard to reason about
15:47:40 <sipa> so instead, my idea was to create a clear specification of what should be fetched from what, or at least something that can be defined in function of a simple data structure
15:47:58 <sipa> and then have one class that encapsulates a very efficient implementation of that
15:48:51 <sipa> 19988 does that
15:49:34 <sipa> to test that, i wrote a fuzz tester which contains a naive reimplementation with the exact same behavior, and which tries to find sequences of operations that makes them diverge
15:50:33 <sipa> (which, it turns out, found a lot of them... but all within ~minutes - it has now run for several weeks altogether...)
15:51:09 <vasild> what does it mean if the naive implementation differs from the real one?
15:51:29 <instagibbs> sorry naive version of what?
15:51:38 <jnewbery> vasild: probably that there's a bug in the real one :)
15:51:48 <instagibbs> like, legacy logic, vs, your encapsulation, vs another implementation?
15:51:51 <vasild> jnewbery: or in the naive one :)
15:52:10 <sipa> instagibbs: difference between the efficient boost::multi_index based implementation, and the naive one in the fuzzer
15:52:21 <instagibbs> ah!
15:52:29 <sdaftuar> concept ACK from me... feature freeze is oct 15, do people have thoughts on getting this in for 0.21?
15:52:29 <instagibbs> naive efficiency-wise
15:52:53 <instagibbs> sdaftuar, don't mean to touch the third rail, but taproot implementation?
15:53:07 <instagibbs> I guess that doesn't intersect aside from PR author
15:53:30 <jnewbery> instagibbs: taproot wouldn't be merged before 0.21, so I think this is the priority
15:53:38 <jnewbery> (in terms of sequencing)
15:53:39 <sdaftuar> yeah i don't know what one has to do with the other, i'd just like to make our review time be efficient
15:53:58 <instagibbs> jnewbery, mmmm ok I guess I hadn't heard that decision
15:54:15 <instagibbs> sdaftuar, same author means limited reaction bandwidth, just noting
15:54:16 <sipa> i was hoping for both :)
15:54:37 <jnewbery> This is +2000/-450 LOC, so reviewing and being comfortable to merge in three weeks seems ... ambitious
15:54:44 <instagibbs> it's not new code.
15:55:06 <sipa> jnewbery: most is in tests
15:55:14 <sipa> (but the non-test code is quite hairy, i admit)
15:55:51 <instagibbs> vast majority of changes were test changes recnetly
15:55:58 <sipa> i'd encourage reviewers to really look at the fuzz test first - even ignoring the fuzzing aspect, the naive reimplementation probably gives a pretty good idea of what the thing *should* do
15:56:07 <instagibbs> (sorry, stopping)
15:56:30 <ajonas> I'd be happy to try some organized nagging if people want to give it a shot to get this in
15:56:52 <instagibbs> concept ACK the actual topic
15:57:15 <jnewbery> it might be better to wait until after 0.21 to merge, so that it has more soak time before being in a release?
15:57:41 <jnewbery> it's not like ADDRv2, where we have some external dependency driving deadlines (torv2 deprecation)
15:58:42 <ajonas> with two min to go can we check in on those 0.21 priorities?
15:58:43 <sipa> well, it depends on reviewer time of coursew
15:58:43 <aj> seems like putting it in early in a cycle would make backporting other p2p things (ie from 0.22pre to 0.21) harder, and there's some reasonable soak time between feature freeze and rc?
15:59:01 <sipa> aj: yeah
15:59:09 <sdaftuar> release date is december 3 right now
15:59:12 <sdaftuar> so that is a fair point
15:59:21 <sdaftuar> (estimated i guess)
15:59:22 <jnewbery> one minute left!
15:59:38 <bitcoin-git> [13bitcoin] 15MarcoFalke opened pull request #19994: Assert that RPCArg names are equal to CRPCCommand ones (net, rpcwallet) (06master...062009-rpcAssertNames) 02https://github.com/bitcoin/bitcoin/pull/19994
16:00:19 <ajonas> The other two priorities mentioned were:
16:00:19 <ajonas> - ADDRv2 - #19031 (next in sequence is 19845, which is close)
16:00:19 <ajonas> - outbound & block-relay-only connections in functional tests (#19315)
16:00:22 <gribble> https://github.com/bitcoin/bitcoin/issues/19031 | Implement ADDRv2 support (part of BIP155) by vasild · Pull Request #19031 · bitcoin/bitcoin · GitHub
16:00:25 <jnewbery> #endmeeting