< sdaftuar> well, i dunno, the wtxidrelay code was originally written before the 0.20 branchoff, so backporting shouldn't be terrible, but it's a much bigger change than i think necessary, so just wanted to mention other alternatives
< sipa> it's probably independently useful to make AreInputsStandard reject WITNESS_UNKNOWN- it's not a semantics change as such spends are rejected by the script verifier anyway, but it'd make that happen before script execution is triggered
< aj> jnewbery has a draft backport of wtxid relay already fwiw
< sdaftuar> yeah i agree with that. if we did make that change, that would help with the transaction-change case that came up in wtxid-relay review, i think ariard flagged it. ie a taproot transaction has a child transaction, that causes pre-taproot nodes to redownlaod the parent (as a txid) repeatedly, only to reject
< sdaftuar> transaction-chain*
< sipa> ah, good point
< sipa> i missed that
< sdaftuar> if we are serious about backporting, we should get your follow on pr merged too, as i guess we'd wnat to backport that as well?
< sdaftuar> i have a PR that conflicts with yours and would make the backport worse if it were merged first
< aj> oh, jnewbery pr'd already #19606
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] fanquake opened pull request #19617: doc: Clang 8 or later is required with FORCE_USE_SYSTEM_CLANG (master...note_that_clang_8_is_required_with_force_system_clang) https://github.com/bitcoin/bitcoin/pull/19617
< bitcoin-git> [bitcoin] TheBlueMatt closed pull request #15481: Restrict timestamp when mining a diff-adjustment block to prev-600 (master...2019-02-600s-gbt) https://github.com/bitcoin/bitcoin/pull/15481
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #19518: Simplify IsFinalTx logic. (master...IsFinalTx) https://github.com/bitcoin/bitcoin/pull/19518
< achow101> did gmax's github get hacked?
< jeremyrubin> no I think he's just goofin' while doing mutation testing
< achow101> half of it seemed incomprehensible
< aj> maybe gmax's brain got snowcrashed
< sipa> achow101: pretty sure it's him :)
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 commits to master: https://github.com/bitcoin/bitcoin/compare/a41ae6805338...2f71a1ea3566
< bitcoin-git> bitcoin/master b223111 James O'Beirne: txdb: add CCoinsViewDB::ChangeCacheSize
< bitcoin-git> bitcoin/master f36aaa6 James O'Beirne: Add CChainState::ResizeCoinsCaches
< bitcoin-git> bitcoin/master 8ac3ef4 James O'Beirne: add ChainstateManager::MaybeRebalanceCaches()
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18637: coins: allow cache resize after init (master...2020-04-au.cache-resize) https://github.com/bitcoin/bitcoin/pull/18637
< jonatack> #19590 haz acks by jonasschnelli, vasild and theStack if anyone iz inna mergin mood
< gribble> https://github.com/bitcoin/bitcoin/issues/19590 | p2p, refactor: add `CInv` transaction message helpers; use in net processing by jonatack · Pull Request #19590 · bitcoin/bitcoin · GitHub
< instagibbs> achow101, 1337 h4x3d maeb3
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/2f71a1ea3566...a76ccb01b964
< bitcoin-git> bitcoin/master 100c64a Vasil Dimov: net: document `enum Network`
< bitcoin-git> bitcoin/master bcfebb6 Vasil Dimov: net: save the network type explicitly in CNetAddr
< bitcoin-git> bitcoin/master a76ccb0 Wladimir J. van der Laan: Merge #19534: net: save the network type explicitly in CNetAddr
< bitcoin-git> [bitcoin] laanwj merged pull request #19534: net: save the network type explicitly in CNetAddr (master...explicit_network_type_in_CNetAddr) https://github.com/bitcoin/bitcoin/pull/19534
< bitcoin-git> [bitcoin] ryanofsky opened pull request #19619: Remove wallet.dat path handling from wallet.cpp, rpcwallet.cpp (master...pr/path) https://github.com/bitcoin/bitcoin/pull/19619
< bitcoin-git> [bitcoin] instagibbs closed pull request #19520: refactor: Rename signal TransactionRemovedFromMempool to better describe behavior (master...not_block) https://github.com/bitcoin/bitcoin/pull/19520
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/a76ccb01b964...400f45ec9bab
< bitcoin-git> bitcoin/master 2e9e637 fanquake: build: add -Wl,-z,separate-code to hardening flags
< bitcoin-git> bitcoin/master 65d0f1a Wladimir J. van der Laan: devtools: Add security check for separate_code
< bitcoin-git> bitcoin/master 400f45e Wladimir J. van der Laan: Merge #19525: build: add -Wl,-z,separate-code to hardening flags
< bitcoin-git> [bitcoin] laanwj merged pull request #19525: build: add -Wl,-z,separate-code to hardening flags (master...z_separate_code) https://github.com/bitcoin/bitcoin/pull/19525
< bitcoin-git> [bitcoin] sdaftuar opened pull request #19620: Add txids with non-standard inputs to reject filter (master...2020-07-reject-unknown-wit) https://github.com/bitcoin/bitcoin/pull/19620
< phantomcircuit> achow101, he's been very amused by https://github.com/openai/gpt-3 recently
< bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/400f45ec9bab...8db23349fe9b
< bitcoin-git> bitcoin/master 65fb880 Andrew Chow: Combine BerkeleyEnvironment::Verify into BerkeleyDatabase::Verify
< bitcoin-git> bitcoin/master 4fe4b3b Andrew Chow: walletdb: track database file use as m_refcount within BerkeleyDatabase
< bitcoin-git> bitcoin/master d86efab Andrew Chow: walletdb: Move Db->open to BerkeleyDatabase::Open
< bitcoin-git> [bitcoin] laanwj merged pull request #19335: wallet: Cleanup and separate BerkeleyDatabase and BerkeleyBatch (master...bdb-cleanup-refactors) https://github.com/bitcoin/bitcoin/pull/19335
< wumpus> taproot implementation review meeting in #bitcoin-core-pr-review now
< CubicEarth> wumpus: channel seems empty
< sipa> it's #bitcoin-core-pr-reviews
< sipa> with an s
< wumpus> oh sorry
< CubicEarth> thanks :)
< jnewbery> sorry for the stupidly verbose channel name!
< bitcoin-git> [bitcoin] ariard opened pull request #19621: [RFC] Package-relay : sender-initiated (master...2020-07-sender-package-relay-poc) https://github.com/bitcoin/bitcoin/pull/19621
< bitcoin-git> [bitcoin] hebasto opened pull request #19622: build: Drop ancient hack in gitian-linux descriptor (master...200729-multilib) https://github.com/bitcoin/bitcoin/pull/19622
< jeremyrubin> sipa: do we have a p2p version such that we can inform peers we only want to receive txs without any v1 inputs?
< sipa> jeremyrubin: in general there is no way to negotiate relay policy with peers
< sipa> and we in general have no knowledge about it
< sipa> the only exceptions are (1) segwit, which introduced a p2p change along with a consensus change and (2) bip133 feefilter
< sipa> as far as i know
< jeremyrubin> Why not do this? Would save a lot of bandwidth right?
< sipa> well conceptually it's pretty strange, as the protocol cannot provide any guarantees about relay
< sipa> nodes are free to choose whatever rules
< jeremyrubin> Is it though? feefilter is similar right?
< sipa> so i'd feel uncomfortable with trying to do this explicitly... but for common cases it may make sense (not as a way to try to predict the full policy, but a "heads up: i'm not interesting in transactions with property X"
< jeremyrubin> yeah i think we could make/backport an inputfilter message
< jeremyrubin> and you can add a couple useful ones, e.g. witness version, tapleaf version. Anything that is O(1) to answer about a txn you have
< sipa> i'm not sure it's needed post wtxidrelay
< jeremyrubin> Well with wtxid relay you still get hit with 1 initial tx broadcast of something you don't want
< sipa> sure
< sipa> but that's rate limited by the total confirmation rate of the network
< sipa> the upper bound isn't changed by receiving and rejecting things that the network will eventually confirm, as long as it doesn't scale with the number of peers
< sipa> (and bandwidth per connection can already be trivially DoS'ed; the solution to that is measuring it, and slowing down processing if exceeded)
< jeremyrubin> :shrugs:
< sipa> my point is: this won't change per-connection bandwidth in attack scenarios
< sipa> the goal should be avoided network-wide bandwidth waste by honest nodes
< jeremyrubin> I think it does actually
< jeremyrubin> Because it gives you a better justification to ban a node
< jeremyrubin> sending you lots of e.g. v3 stuff you can't handle and silently reject
< sipa> there will always things you can't negotiate, e.g. sending transactions with unknown parents
< sipa> and sure, you could set some rate limit on those... but even then, would it be ok if suddenly the entire network would start being bombared with orphans at whatever that limit it?
< sipa> my view is that we shouldn't bother with setting explicit limits on "how" misbehaving a peer is allowed to be; instead we should track how many resources we're spending on behalf of some peer, and if our aggregate resource usage is too high, throttle the worst ones
< sipa> but - that's about attack cases - we should absolutely make p2p affordances to avoid wasting work just through honest nodes behaving correctly
< jeremyrubin> but specifically if we're looking at what we can backport easily to old node versions, allowing a witnessversion filter message would be relatively small to implement the logic to disconnect peers who don't respect it for backport
< jeremyrubin> and only new nodes need to implement the logic around not forwarding it
< sipa> and i believe - but am willing to be convinced otherwise - that wtxidrelay actually already fixes the asymptotic behavior there
< sipa> we can go further to improve the constant factors a bit
< sipa> but i'm not sure that's worth the effort
< sipa> and if so, to what extent
< jeremyrubin> I think it depends on the model
< jeremyrubin> I think it's still possible to get all your peers to relay something to you per-input spent
< jeremyrubin> and a rule banning v1 would make this impossible
< sipa> if they're honest peers, they'll never send you more on average than what can be confirmed by the network (modulo some RBF/expiration epsilon, which have economic incentives against)
< sipa> so sure, maybe 95% of what peers send you you cannot accept if you're too far behind, but the total won't be much different from what you'd be processing in case nobody was using future feature and all those transactions were acceptable to you
< jeremyrubin> So let's say I gossip to the network simultaneously N different txns spending an input X, and assume they spread uniformly. Every peer will attempt to relay a different txn to you right?
< jeremyrubin> I guess this is true even without v1/v0?
< sipa> yeah - and arguably that's an attack already
< jeremyrubin> Ah
< jeremyrubin> but it's not an attack *by your peers*
< jeremyrubin> it's by a third party somewhere
< sipa> yeah, that's fair
< sipa> but as soon as you're a few steps removed from the attacker, the only nodes who'll end up processing more than 1 version are those on borders of "equal propagation speed" partitions
< sipa> (well, plus 1 version that ends up in a block)
< jeremyrubin> I guess the general fix for this would be some sort of input tracking relay system
< jeremyrubin> where you know which inputs your peer's mempool is spending, and what feerate they're getting
< jeremyrubin> And decide to relay or not based on that basis
< jeremyrubin> Some bigger notion of understanding conflicts I guess.
< jeremyrubin> Then if you ever see something you don't like for a given input, you can tell your peers you don't want it. Seems complex tho