19:00:55 <wumpus> #startmeeting 19:01:01 <jonasschnelli_> (again) 19:01:10 <jonasschnelli> hi 19:01:11 <kanzure> hi 19:01:13 <ajonas> hi 19:01:17 <hebasto> hi 19:01:17 <achow101> hi 19:01:18 <amiti> hi 19:01:20 <jnewbery> hi 19:01:44 <wumpus> one proposed meeting topic: blocksonly mode and transaction relay (jnewbery) 19:01:52 <fjahr> hi 19:01:55 <wumpus> #bitcoin -core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow 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:58 <wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus 19:01:58 <sipa> hi 19:02:35 <promag> o/ 19:02:39 <wumpus> any last-minute topics? 19:02:45 <jonatack> hi 19:02:49 <ajonas> wumpus: I just have a brief mention of the developer survey 19:03:04 <wumpus> ajonas: great! 19:03:43 <wumpus> #topic High priority for review 19:03:57 <jonasschnelli> I added #20664 to the hiprio list 19:04:00 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 9 blockers, 2 chasing concept ACK 19:04:00 <gribble> https://github.com/bitcoin/bitcoin/issues/20664 | Add scanblocks RPC call by jonasschnelli ÷ Pull Request #20664 ÷ bitcoin/bitcoin ÷ GitHub 19:04:40 <wumpus> does anyone else want to add or remove anything ? 19:04:47 <jonatack> maybe add #20197 please, if the list isn't too long 19:04:50 <gribble> https://github.com/bitcoin/bitcoin/issues/20197 | p2p: protect onions in AttemptToEvictConnection(), add eviction protection test coverage by jonatack ÷ Pull Request #20197 ÷ bitcoin/bitcoin ÷ GitHub 19:05:24 <wumpus> jonatack: added! 19:05:33 <jonatack> wumpus: ty! 19:06:46 <wumpus> is there anything (almost) ready for merge? 19:07:45 <ariard> hi 19:07:52 <achow101> #20536 has 3 acks 19:07:53 <gribble> https://github.com/bitcoin/bitcoin/issues/20536 | wallet: Error with "Transaction too large" if the funded tx will end up being too large after signing by achow101 ÷ Pull Request #20536 ÷ bitcoin/bitcoin ÷ GitHub 19:07:55 <elichai2> hi 19:07:58 <MarcoFalke> hi 19:07:59 <ajonas> There are a few old tests that have got some new review... nothing major though 19:08:04 <wumpus> achow101: good to know 19:08:53 <wumpus> i guess that's all for this topic, let's go to next one then 19:08:53 <ajonas> #18795 , #19393, #14604 19:08:55 <gribble> https://github.com/bitcoin/bitcoin/issues/18795 | Test: wallet issue with orphaned rewards by domob1812 ÷ Pull Request #18795 ÷ bitcoin/bitcoin ÷ GitHub 19:08:57 <gribble> https://github.com/bitcoin/bitcoin/issues/19393 | test: Add more tests for orphan tx handling by hebasto ÷ Pull Request #19393 ÷ bitcoin/bitcoin ÷ GitHub 19:08:59 <gribble> https://github.com/bitcoin/bitcoin/issues/14604 | tests: Add test and refactor feature_block.py by sanket1729 ÷ Pull Request #14604 ÷ bitcoin/bitcoin ÷ GitHub 19:09:13 <wumpus> ajonas: thank you 19:09:39 <wumpus> #topic Blocksonly mode and transaction relay (jnewbery) 19:09:59 <jnewbery> hello! 19:10:03 <jnewbery> There is a `-blocksonly` option in Bitcoin Core, which disables transaction relay for a node. 19:10:14 <jnewbery> It does this by setting fRelay=false on the version message on all of its connections. 19:10:24 <jnewbery> This was added in PR #6993 and was made a public documented option #15990 (https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md#4-turn-off-transaction-relay--blocksonly) 19:10:26 <gribble> https://github.com/bitcoin/bitcoin/issues/6993 | Add -blocksonly option by pstratem ÷ Pull Request #6993 ÷ bitcoin/bitcoin ÷ GitHub 19:10:29 <gribble> https://github.com/bitcoin/bitcoin/issues/15990 | Add tests and documentation for blocksonly by MarcoFalke ÷ Pull Request #15990 ÷ bitcoin/bitcoin ÷ GitHub 19:10:31 <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format ÷ Issue #4 ÷ bitcoin/bitcoin ÷ GitHub 19:10:40 <jnewbery> One strange (and potentially footgun-ish aspect) of -blocksonly is that if a transaction is submitted to the node over RPC, or sent by a whitelisted peer, then the node will relay that transaction to all its peers. 19:10:52 <jnewbery> This makes it very obvious that the node is the origin of the transaction, since it doesn't relay any other transaction! 19:11:02 <jnewbery> Are there legitimate use cases for this behaviour? 19:11:22 <ariard> I would say emergency broadcast, you don't care about the privacy 19:11:29 <sipa> fRelay=false is also set in other cases, right? 19:11:46 <sipa> for blocks relay connections, even if you're not in blocksonly mode? 19:11:50 <ariard> like when your main node is upgrading/power outage/... 19:12:01 <jnewbery> by Bitcoin Core? We set fRelay=false for -blocksonly mode, or for the block-relay-only connections, even if you're not in -blocksonly mode 19:12:33 <sipa> oh, nvm, i was confusing things; this isn't relevant 19:12:49 <jnewbery> bloom filter clients also set fRelay=false when connecting to supress tx relay until they've loaded the filter 19:13:21 <sipa> i'm not sure what the right behavior is 19:13:35 <sipa> it's clearly a privacy leak, but i think it would also be incorrect to just not relay 19:13:41 <wumpus> maybe reject it by default but add a 'force' flag to override, i dunno 19:13:50 <sipa> there is an expectation that a transaction is relayed if you call sendrawtransaction 19:14:00 <fjahr> I was just going to suggest a force flag too 19:14:03 <wumpus> yea failing silently would be the worst of both worlds 19:14:05 <ariard> yeah force flag sounds good 19:14:08 <jonasschnelli> +1 for the force flag 19:14:12 <jnewbery> always fail sendrawtransaction if -blocksonly is set? 19:14:28 <jonasschnelli> jnewbery: seems a bit to hand-holdish 19:14:50 <MarcoFalke> Seems a bit too hand-holdish to add a force flag for this 19:15:04 <MarcoFalke> The privacy leak is well documented in the option help 19:15:13 <jnewbery> a force flag seems the worst of all worlds 19:15:15 <sdaftuar> can't someone use bitcoin-qt in blocksonly mode? i'm not understanding hte force flag in that scenario 19:15:24 <sdaftuar> some warnign popup i guess? 19:15:34 <jonasschnelli> The GUI could have a warning, yes. 19:15:42 <jnewbery> oh, one thing I should add: -blocksonly will soft-set -walletbroadcast to false 19:15:51 <jonasschnelli> Which is more or less the UX adaption of a "force" CLI flag 19:15:52 <luke-jr> MarcoFalke: it fits well with your force-past-policy PR 19:15:54 <wumpus> it doesn't imply walletbroadca.. right 19:16:17 <wumpus> so we did think of that 19:16:21 <jonatack> sendrawtransaction help states the issue clearly 19:16:22 <jonasschnelli> sendrawtransaction respectes walletbroadcast? 19:16:23 <MarcoFalke> as jnewbery points out the wallet should disable the broadcast with blocksonly 19:16:29 <jnewbery> I don't expect users to understand the privacy implications of this. Putting an option in the GUI seems overly complex 19:16:37 <wumpus> i also remember this came up before 19:16:38 <MarcoFalke> but the rpc is separate 19:16:47 <sdaftuar> so are we only talking about changing behavior in the case that -blocksonly=true and -walletbroadcast=true? 19:16:59 <jnewbery> sendrawtransaction is not a wallet rpc, so should have no interaction with walletrebroadcast 19:17:07 <sdaftuar> if the user has set that, it seems clear waht the intent is 19:17:28 <luke-jr> sdaftuar: the intent of sendrawtransaction is also clear and contradicts it 19:17:28 <wumpus> sdaftuar: +1 19:17:55 <MarcoFalke> luke-jr: It doesn't contradict. It overwrites for a specific tx 19:18:04 <jonasschnelli> if you don't have transaction relay, doesn't the wallet always need manual fee settings (problematic either)? 19:18:18 <MarcoFalke> jonasschnelli: This is also documented 19:18:21 <jnewbery> jonasschnelli: indeed 19:18:25 <MarcoFalke> https://github.com/bitcoin/bitcoin/blob/master/doc/reduce-traffic.md#4-turn-off-transaction-relay--blocksonly 19:18:27 <gribble> https://github.com/bitcoin/bitcoin/issues/4 | Export/Import wallet in a human readable, future-proof format ÷ Issue #4 ÷ bitcoin/bitcoin ÷ GitHub 19:18:48 <MarcoFalke> If we assume that no one reads the docs, what is the point of adding it in the first place. 19:19:02 <jonasschnelli> yes. that is a valid point. 19:19:11 <jonasschnelli> Maybe we should expect people read the docs 19:19:12 <jnewbery> My baseline assumption is that users don't read docs 19:19:25 <amiti> MarcoFalke: I think its not boolean? I'd expect some users to read docs, but not all 19:19:35 <sipa> i'm a bit confused about the context... this is only about the sendrawtransaction RPC, not about wallet sending? 19:19:43 <jnewbery> and I don't think documenting bad behaviour is better than removing bad behaviour 19:19:45 <jonasschnelli> jnewbery: if so, how do they even find out about the blocksonly mode? :-) 19:20:00 <luke-jr> jonasschnelli: reading *some* docs but not others! XD 19:20:04 <MarcoFalke> sipa: I think this is a general discussion about the version message fRelay field 19:20:25 <jnewbery> jonasschnelli: because someone suggests that they enable it on a twitter thread to save themselves some bandwidth? 19:20:42 <jonasschnelli> yes... that 19:20:55 <sipa> what specifically are we discussing changing? 19:20:57 <sdaftuar> the followup question to this, i believe, is whether it's reasonable for our software to ignore transactions from a peer that has set fRelay=false -- do i have that right jnewbery? 19:21:19 <jnewbery> sdaftuar: that's the wider context, yes 19:21:33 <sdaftuar> so this question is to establish whether our current relay behavior is sort of reasonable at all 19:21:39 <jonasschnelli> Aren't there any valid use-cases that use blocksonly & wallet broadcast (like a private network, designated connection)? 19:21:40 <MarcoFalke> jnewbery: There is the use case where the node(s) with blocksonly only connect to trusted nodes. It seems too broad to call the feature bad 19:22:02 <jonasschnelli> Agree with MarcoFalke 19:22:17 <sipa> MarcoFalke: i'd expect people to set whitelisting in that case, though (or they'll experience more broken behavior) 19:22:18 <sipa> like rebroadcasting won't work 19:22:22 <jnewbery> I don't understand this use case 19:23:13 <sdaftuar> sipa: i think rebroadcasting would work fine? it'll relay to your node in the same circumstances that your node would succeed in relaying it to their peers, no? 19:23:14 <luke-jr> jnewbery: maybe the user just doesn't care about privacy? 19:23:49 <jnewbery> luke-jr: that's fair, but is that a use case we want to support? 19:23:55 <luke-jr> ⦠19:24:05 <MarcoFalke> sipa: sendrawtrasnaction is designed to do a rebroadcast every time you call it 19:24:36 <sipa> MarcoFalke: right, but wallet rebroadcasting won't work, because alreadyhave logic will think the (only) peer already has it 19:24:51 <sipa> not alreadyhave; inventoryknown 19:24:51 <MarcoFalke> permission flags can't override the inv-getdata filter either, IIRC 19:25:25 <sipa> hmm, fair; even if you announce again, the peer won't fetch it again 19:25:26 <MarcoFalke> your inventoryknown is the other peer's alreadyhave ;) 19:25:29 <sipa> i'm confused now 19:25:40 <jnewbery> transaction relay is a public network function, and it should be designed in such a way that is optimal for users connecting to public networks 19:25:46 <sipa> i thought that was the reason we introduced whitelisting in the first place 19:25:49 <luke-jr> jnewbery: I never liked the idea of telling users what they can and can't do. And if Core is going to do that, at least the protocol needs to be neutral. 19:26:10 <sdaftuar> oh! we never clear filterInventoryKnown? that seems potentially problematic 19:26:35 <amiti> I find it unexpected that the default behavior of -blocksonly mode is to disable wallet broadcast, but if you submit via sendrawtransaction RPC the node will still relay your transaction 19:26:36 <sipa> doesn't look like it 19:26:47 <sipa> amiti: that's inconsistent for sure 19:26:56 <sipa> but i don't really know what to do about it 19:27:33 <jnewbery> I'm still curious about the supposed use cases. jonasschnelli and MarcoFalke thing there are use cases, but I don't understand them 19:27:33 <ariard> actually you can be willingly to not participate in tx-relay to mask your connection graph 19:27:41 <ariard> and only broardcat when you really need it 19:27:44 <amiti> sipa: what's the issue with just giving the user an error message if they attempt sendrawtransaction? 19:28:04 <amiti> maybe not desirable, but one way to make it consistent 19:28:23 <jonasschnelli> jnewbery: Assume someone runs a blockonly node at home (bandwith) but connects it to a trusted peer over wireguard 19:28:38 <MarcoFalke> sendrawtransaction is explicitly called. Wallet broadcast is implicit, so I think the current behavior makes sense 19:28:53 <MarcoFalke> (It is possible to enable wallet broadcast explicitly as well) 19:29:00 <amiti> MarcoFalke: fair 19:29:01 <jnewbery> jonasschnelli: that'd associate all of your transactions to your node 19:29:07 <luke-jr> bandwidth vs privacy is a tradeoff. Users may prefer bandwidth. 19:29:13 <sdaftuar> jnewbery: does that matter to tor users? 19:29:16 <MarcoFalke> jnewbery: Which is no problem because you control the other node 19:29:28 <lightlike> Am I right to assume that this issue with sendrawtransaction doesn't apply to regular blocks-only connections in normal mode - only in full blocksonly mode? 19:29:39 <ariard> but even if you don't control the other node, you prefer the transaction propagating over the privacy gain 19:29:41 <jnewbery> MarcoFalke. Presumably the home node is relaying the transaction on to the network? 19:29:42 <luke-jr> wonders if Tor nodes can/should make a dedicated connection just for broadcast 19:29:49 <amiti> lightlike: yes 19:29:55 <ariard> you *might* prefer (e.g time-sensitive txn) 19:30:11 <MarcoFalke> sdaftuar: If you don't control the tor node, I'd say yes. (The other peer will learn your whole wallet contents over time) 19:30:17 <sipa> so sendrawtransaction does not relay over fRelay=false connections in general, only in -blocksonly mode? 19:30:37 <jnewbery> sipa: I belive that is correct 19:30:45 <sipa> curious 19:30:54 <MarcoFalke> sendrawtransaction will send it out to all peers that have send you a fRelay=true 19:30:56 <sdaftuar> fRelay=false isn't a "category" of connection, really 19:30:56 <luke-jr> jnewbery: in that scenario, the home node talks exclusively to your dedicated server somewhere over VPN 19:31:22 <MarcoFalke> sendrawtransaction doesn't take into account what fRelay you sent to the peer 19:31:23 <sdaftuar> we have full-relay-outbound connections, which might actually be fRelay=false if we're in -blocksonly mode 19:31:29 <jnewbery> luke-jr: I don't think that's what jonasschnelli was describing 19:31:31 <sipa> ah, i see 19:31:42 <sdaftuar> but we treat them as our tx relay peers anyway (which is correct, in the sense that fRelay=false only instructs our peer to not relay to us, not the other way around) 19:31:47 <sipa> jnewbery: that's how i interpret jonasschnelli's scenario as well 19:31:53 <jonasschnelli> yes. m2 19:32:08 <sipa> (only one connection, blocksonly to a trusted peer; you don't care about privacy w.r.t. that peer) 19:33:00 <sipa> i think in general "i don't care about privacy w.r.t. this peer" is something to be captured by whitelisting 19:33:08 <sipa> but of course... who knows what people read 19:33:14 <luke-jr> hmm 19:33:28 <MarcoFalke> Another use case might be to create a larger gap from your hot wallet to the live p2p network (multiprocess isn't a thing yet) 19:33:43 <ariard> sipa: whitelisting is static, you might willingly to bypass "i don't care about privacy w.r.t this peer" for a one-shot broadcast 19:33:53 <MarcoFalke> sipa: It is called permission flags now ;) 19:33:59 <sipa> MarcoFalke: right, thanks 19:34:43 <jnewbery> ah, thank you. I was misunderstanding. I think if you control both ends of the connection, then it'd make more sense for the home node to set feefilter=max to the trusted peer 19:34:46 <sipa> ariard: that seems more like something you'd want for tor connections (and as a specific way of broadcasting transactions) 19:35:02 <MarcoFalke> And permission flags don't work for outbound connections (yet) 19:35:39 <luke-jr> MarcoFalke: have a PR for that for a year+ now :P 19:35:56 <wumpus> what is holding it up? 19:36:02 <luke-jr> lack of review last I checked 19:36:09 <MarcoFalke> either that or "Needs rebase" 19:36:22 <sipa> pr number? 19:36:29 <sipa> (mentioning it here may help :p) 19:36:35 <wumpus> yes 19:36:36 <luke-jr> #17167 19:36:38 <gribble> https://github.com/bitcoin/bitcoin/issues/17167 | Allow whitelisting outgoing connections by luke-jr ÷ Pull Request #17167 ÷ bitcoin/bitcoin ÷ GitHub 19:36:46 <luke-jr> looks like it needs rebase at the moment 19:36:56 <MarcoFalke> jnewbery: Sending feefilter=max to the trusted peer could work 19:37:04 <wumpus> i have always liked the idea of being able to whitelist ^D^D permission outgoing connections 19:37:26 <jnewbery> 17167 has needed rebase since December 19:37:27 <MarcoFalke> jnewbery: Can we replace fRelay with feefilter=max? 19:37:33 <jonasschnelli> The current wallet broadcast in normal operations isn't privacy preserving either (AFAIK without dandelion or similar)? 19:37:36 <jonatack> FWIW regarding fRelay, I mentally rename it to m_wants_tx_relay 19:37:40 <luke-jr> if there's renewed interest I can go ahead and rebase it 19:38:13 <MarcoFalke> jonasschnelli: I think the wallet broadcast has been reworked to be less agressive 19:38:28 <sdaftuar> MarcoFalke: would we then require that the peer support feefilter to stay connected? 19:38:53 <jonasschnelli> sure. AFAIK chainanalysis companies are still able to capture it 19:39:06 <amiti> jonasschnelli: no its not, but I'm working on it :) #21061 19:39:08 <gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar ÷ Pull Request #21061 ÷ bitcoin/bitcoin ÷ GitHub 19:39:17 <jonasschnelli> amiti: nice 19:39:42 <jonasschnelli> Just saying because if we flag blockonly privacy leaking we imply normal operation isn't 19:39:54 <MarcoFalke> sdaftuar: We also assume the node to support BIP 60 for blocksonly, so it is not a large change? 19:40:11 <sipa> if we believe that wallet privacy is a lost cause, there is no reason to improve it; but i don't think it is, and with improvements in the pipeline i don't think suboptimal privacy right now is a reason not to think about other issues 19:40:12 <MarcoFalke> (nodes will be disconnected if they don't support BIP 60, no?) 19:40:18 <sdaftuar> MarcoFalke: well my guess is that bip37/bip60 is more widely supported on the network. feefilter has always been optional 19:40:20 <jnewbery> MarcoFalke: BIP60 is version 70002. feefilter is version 70013. 19:40:28 <amiti> sipa: strong +1 19:40:43 <jonasschnelli> yes. thats a good point sipa 19:41:00 <jnewbery> but I think being able to send feefilter before verack would be nice 19:41:39 <sipa> still, i'm not sure exactly what we're talking about? blocksonly + sendrawtransaction? or also blocksonly + walletbroadcast + wallet send? something else? 19:41:46 <sdaftuar> but wait feefilter doesn't help right jnewbery? 19:42:02 <jnewbery> feefilter doesn't help here, no 19:42:06 <jnewbery> we'd still need BIP 338 19:42:15 <wumpus> both security and privacy are always about making attacks marginally more difficult/expensive, not absolutes, would not call it a lost cause 19:42:31 <jnewbery> some way to signal tx relay 19:43:18 <sipa> wumpus: right, my point was that sometimes an argument of "you're trying to improve X, but X is always going to be bad because of Y, and we can't fix Y" is a valid argument not to work on something... but i don't think that's the case here 19:44:07 <jnewbery> sipa: the specific reason I'm asking is that other than these edge cases, fRelay=false means "I don't want txs on this connection and I'll never send txs on this connection". That's a nice property 19:44:23 <sipa> what happens right now if someone runs bitcoin-qt in -blocksonly mode and creates a transaction? 19:44:25 <sdaftuar> that's only true in a world where NODE_BLOOM isn't supported 19:44:37 <jnewbery> I was trying to understand if those edge cases are actually important, or whether they're just things that people are speculating about 19:44:39 <jonatack> jnewbery: only the first of the two? 19:44:59 <jnewbery> *only true for nodes that don't support serving bloom filters, yes 19:45:08 <luke-jr> jnewbery: didn't sdaftuar just add a new flag for that? 19:45:17 <sipa> while still supporting fRelay 19:45:18 <wumpus> sipa: sure, agree 19:45:50 <sdaftuar> luke-jr: not merged yet 19:45:52 <jnewbery> sipa: it wouldn't be broadcast because walletbroadcast is set to false. I don't know what the GUI shows 19:46:14 <sipa> that seems bad 19:46:24 <luke-jr> sdaftuar: right, but it would make fRelay having this property redundant..? 19:46:33 <sipa> conjectures that barely anyone uses -blocksonly on nodes they actually use as wallets 19:46:44 <jnewbery> this was also my conjecture 19:46:47 <sdaftuar> luke-jr: i think jnewbery's proposal is to scrap the BIP 19:46:51 <luke-jr> ah 19:47:28 <wumpus> i don't think blocksonly was ever officially supported for the GUI, it works, sure 19:47:30 <MarcoFalke> so replace BIP338 with a breaking p2p change and blocksonly meaning "feefilter=max"? 19:47:42 <jnewbery> my original proposal was to script fRelay, but it seems that people rely on it to mean 'blocks only' 19:47:42 <wumpus> but it was originally intended to be some kind of internal, rarely used thing 19:47:52 <wumpus> not something GUI end users would face 19:47:55 <jnewbery> *scrap fRelay 19:48:09 <ariard> fwiw, core doesn't even commit to bip60 as a supported bip 19:48:41 <MarcoFalke> ariard: It only does when -blocksonly 19:48:41 <darosior> Fwiw i believe the GUI would show a fee estimation error in this case if no fallbackfee is set 19:48:43 <wumpus> e.g. there is no configuration dialog option to enable it 19:48:54 <sipa> darosior: fair point 19:49:14 <ariard> MarcoFalke: i mean here https://github.com/bitcoin/bitcoin/blob/master/doc/bips.md, for a dev writing another bitcoin client and trying to understand core behavior 19:49:22 <wumpus> darosior: i think so too 19:49:27 <sipa> we don't support bip60 and never have 19:49:34 <jonasschnelli> darosior: Yes. It will. But users with just set a manual fee 19:49:38 <sipa> or at least, we don't assume our peers do 19:49:44 <luke-jr> sipa: we send it 19:49:55 <luke-jr> iirc 19:49:56 <jnewbery> we always send fRelay, but don't expect our peers to 19:50:15 <sipa> luke-jr: BIP60 is about predictably-sized version messages, not just the fRelay flag 19:50:57 <jnewbery> we also don't require that our peers send starting height, subversion, etc 19:50:58 <luke-jr> sipa: but on the sender side 19:51:00 <sdaftuar> sipa: but we're compatible with bip60 peers, and i think we now expect our peers to always read our fRelay flag if its' set to false, right? 19:51:02 <ariard> even the original bip37 is really unclear if fRelay semantic is to disable tx-relay or just tx-announcement 19:51:05 <luke-jr> it doesn't require breakign non-BIP60 peers 19:51:10 <sipa> sdaftuar: hmm, true 19:52:20 <jnewbery> sdaftuar: you mean we expect them to read fRelay because we'll disconnect them if they send us a tx? 19:52:34 <sdaftuar> right, if we set fRelay=false i think we now disconnect if they ignore it 19:52:42 <ariard> unless you signal NODE_BLOOM 19:53:16 <MarcoFalke> Bitcoin Core implements BIP60, but doesn't require peers to implement it. (Like any other optional BIP) 19:53:38 <jnewbery> I'm not sure we do disconnect peers for that 19:53:58 <amiti> orly? I thought we disconnected for that too 19:54:02 <sdaftuar> jnewbery: it is possible i'm misremembering , i know i thought this at some point in the past and was wrong 19:54:09 <sipa> so i guess we could list BIP60 as implemented, actually 19:54:21 <MarcoFalke> jnewbery: I am pretty sure there is a "tx sent in violation of protocol" log 19:54:26 <ariard> iirc #15759 introduce the change of disconnecting block-relay-only peers sending us a transaction 19:54:30 <gribble> https://github.com/bitcoin/bitcoin/issues/15759 | p2p: Add 2 outbound block-relay-only connections by sdaftuar ÷ Pull Request #15759 ÷ bitcoin/bitcoin ÷ GitHub 19:55:08 <jnewbery> but not if we send fRelay=false because we're in -blocksonly 19:55:24 <wumpus> 5 minutes to go for the meeting, ajonas still had an announcement wrt the developer survey 19:55:28 <MarcoFalke> jnewbery: Oh, I didn't know 19:55:47 <jnewbery> I may be wrong. I searched for fRelayTxes in net_processing 19:55:50 <sdaftuar> looks likew e disconnect in that case to me? can look later jnewbery 19:55:50 <amiti> https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L3001 19:56:07 <MarcoFalke> (Side note: we also don't disconnect on feefilter=max violations) 19:56:13 <ariard> jnewbery: correct this was a pre-15759 behavior 19:56:26 <jnewbery> sdaftuar: ah, you're right. Thanks! 19:56:39 <jnewbery> ok, shall we let jonas have his three minutes? :) 19:56:41 <phantomcircuit> sipa, would the headers sync thing be appropriate in this meeting? 19:56:42 <wumpus> #topic Developer survey (ajonas) 19:56:54 <MarcoFalke> m_ignore_incoming_txs means "blocksonly" 19:56:55 <ajonas> Hi. A summary of the latest dev survey is at https://adamjonas.com/bitcoin/coredev/retro/coredev-2020-retro/. Thank you to everyone who participated. 19:57:06 <MarcoFalke> ajonas: Thanks for summing those up! 19:57:07 <jnewbery> MarcoFalke: yup. You're right 19:57:13 <wumpus> ajonas: thanks for doing this 19:57:27 <ajonas> Happy to! 19:57:42 <jnewbery> thank you ajonas! 19:57:52 <MarcoFalke> One major theme is "It is unclear which status a pr is in". I was thinking how to improve that, but couldn't find a solution 19:58:15 <ajonas> I think a labeling system might be worth trialing 19:58:24 <MarcoFalke> Obviously it can't be an objective metric (that a computer could measure), because then it would be gameable 19:58:32 <amiti> imo, communicating PR status should be the responsibility of the pr author instead of maintainers 19:58:52 <ajonas> But we could also add some meta data in the first comment that can be updated over time 19:58:59 <wumpus> what are the PR statuses in the first place? 19:59:08 <MarcoFalke> I think the best metric is a heuristic "A pr is closer to merge the more ACKs it has relative to its potential risk" 19:59:22 <wumpus> i mean we have a few like 'waiting for author' 'needs rebase' but not sure what you mean here 19:59:43 <wumpus> MarcoFalke: yes, definitely 19:59:43 <ajonas> I think concept / approach ack vs deep code review 19:59:53 <MarcoFalke> wumpus: I'd say when there is no "needs rebase" label, the status is implicitly "needs review" 20:00:04 <wumpus> ok so like 'needs concept ACK' 20:00:21 <wumpus> we could add that, but yes, like amiti says, authors have to request this 20:00:46 <ariard> draft status doesn't mean "needs concept ACK"? 20:00:55 <MarcoFalke> I am not sure if that makes sense. How would you know when to remove the "needs concept ACK" label? 20:00:59 <wumpus> ariard: maybe 20:01:05 <ajonas> I think the use of draft is inconsistent 20:01:08 <wumpus> ariard: we could use it for that 20:01:21 <wumpus> MarcoFalke: good point 20:01:28 <ariard> good thing with draft you can do it just a pr author, doesn't special repo permisions iirc 20:01:42 <wumpus> yes that is good 20:02:17 <wumpus> self-organizaing is good, anything that gives the maintainers more on their plate is probably not going to fly 20:03:15 <amiti> something I'm trying on #21061 is adding an explicit "status" section at the top of OP. not super relevant yet because the PR hasn't gotten much attention, but was hoping to make this easier for reviewers as the comments accumulate 20:03:15 <wumpus> that concludes the meeting for today 20:03:17 <gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar ÷ Pull Request #21061 ÷ bitcoin/bitcoin ÷ GitHub 20:03:27 <wumpus> #endmeeting