< 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
< 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/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] 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