< bitcoin-git>
bitcoin/master 1ccb9f3 Luke Dashjr: Move Win32 defines to configure.ac to ensure they are globally defined
< bitcoin-git>
bitcoin/master 8e0f341 fanquake: Merge #15704: Move Win32 defines to configure.ac to ensure they are global...
< bitcoin-git>
[bitcoin] fanquake merged pull request #15704: Move Win32 defines to configure.ac to ensure they are globally defined (master...win32_defines_globally) https://github.com/bitcoin/bitcoin/pull/15704
< fanquake>
I only looked briefly, but does that mean it's "completely broken" there too? There's also two checks for fdatasync in the knots configure?
< fanquake>
Regardless, if you spot an issue with master, I'd much prefer you open a new PR (or issue) clearly explaining the problem and the fix.
< fanquake>
Rather than bundling the fix into a in multi-year-old, semi-related PR.
< luke-jr>
AC_SUBST only provides it within Makefiles, not as a #define
< luke-jr>
Not sure it's merely semi-related. It fixes issues with the same logic already. I noticed the issues in 19614 rebasing it because it is the same stuff
< luke-jr>
doesn't seem to make sense to split up the fix?
< fanquake>
It makes sense to split up the fix, because fixing this doesn't seem predicated on 14501 being merged.
< fanquake>
wumpus / sipa: can you block StanislavKlimov95
< fanquake>
spamming addresses and nonsense
< wumpus>
fanquake done
< fanquake>
wumpus: thanks
< bitcoin-git>
[bitcoin] theStack opened pull request #19801: test: check for all possible OP_CLTV fail reasons in feature_cltv.py (BIP 65) (master...20200825-test-check-all-failure-reasons-for-CLTV) https://github.com/bitcoin/bitcoin/pull/19801
< jnewbery>
hi folks. We'll get started with the p2p meeting in a few minutes. We'll start like last week with a chance for people to share what they're working on and their priorities are, so if you're planning on attending perhaps have a think about whether there's anything you want to share.
< sdaftuar>
maybe don't need to do a roll call on everyone to share, just let people jump in on anything that has changed since last time?
< jnewbery>
#startmeeting
< lightningbot>
Meeting started Tue Aug 25 15:00:13 2020 UTC. The chair is jnewbery. Information about MeetBot at http://wiki.debian.org/MeetBot.
< jnewbery>
Does anyone have any updates that they want to share since last week?
< jonatack>
y
< jnewbery>
feel free to jump in
< jnewbery>
s/last week/last meeting/
< jonatack>
My prios were BIP155, BIP324, and BIP325 implementation PRs, and they seem to be moving forward.
< hebasto>
just after jon :)
< ariard>
hi
< jonatack>
BIP155 addrv2: #19628 has been receiving review from sipa, elichai, ryanofsky, kallewoof, sipsorceryand myself, and now has 4 ACKs; vasild is deferring further (minor) changes to the PR in order to preserve existing review, but there's no reason to not review it
< jonatack>
BIP325 signet: #18267 has been through a few more rounds of review and seems to be getting close, with recent review by fjahr, pinheadz, MarcoFalke, instagibbs, and myself
< jonatack>
BIP324 v2 p2p encrypted message transport protocol: right after the last p2p meeting, jonasschnelli rebased and updated #18242 (changes only used in tests for now) and I've begun re-reviewing it along with the BIP, which has some open questions.
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< sipa>
unfortunately no; i haven't gotten to rebasing/updating the tx overhaul, by being distracted on taproot and a few generic secp256k1 issues; i did reviews for 19628 though; happy to see that moving along
< jonatack>
I encourage people to review BIP 324 and the PR 18242.
< nehan>
hi
< jonatack>
19731 was merged yesterday, which allows some interesting possibilities for eviction tests and I have added those columns into my dev branch of cli -netinfo
< jonatack>
19643 achieved a pretty massive rough consensus with ~9/10 Concept/Approach ACKs and 6 full tested ACKs by wumpus, 0xB10C, fjahr, vasild, practicalswift and pinheadz.
< jonatack>
It's an extremely useful tool for anyone rrrrunning a node, particularly developerrrs and p2p reviewerrrs, and is completely encapsulated in a single class in bitcoin-cli.cpp that is both easy to maintain and easy to rrrip out in 2 minutes if no longer wanted
< jonatack>
finnaly
< sipa>
jonatack: yeah, i need to respond to llfourn's comments
< jonatack>
19610 is a net processing pure refactoring and simplification with jnewbery, that splits AlreadyHave() up into AlreadyHaveTx() and AlreadyHaveBlock() since they are now two totally separate concepts; the block and transaction paths have drifted apart sufficiently that it no longer makes sense to have a common function there. The PR also simplifies CInv::type and INV/TX processing code.
< jonatack>
Thanks to fjahr, jnewbery, and vasild who have reviewed it so far! Review welcome.
< jonatack>
that's it for me :p
< vasild>
hi
< ajonas>
I've been trying to keep track of the #18044 clean-ups.
< ajonas>
I've checked in with jnewbery and amiti on them. sipa has some he's said he's going to do. instagibbs has already pushed a test. jeremy has a few that he's been discussing with amiti as well.
< gribble>
https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
< fanquake>
I don't think there's any rush to do the backports until any followup discussion changes/have been finalized. Might as well backport all that's needed at once.
< sipa>
ajonas: i think my followup is dome already (#19569)
< ariard>
sipa: what was llfourn main proposal of change for bip324? He didn't propose to MAC the length field, so no BIP change
< ajonas>
sipa: I'll take a look. Thanks.
< MarcoFalke>
The one to 0.19 should be ready, right? No other p2p backports are planned for that release and we might as well ship 0.19 after that backport
< ariard>
and the DoS concern are more theoritical, given you have easier alternatives
< sipa>
ariard: no changes, just commentary, iirc - but i need to go through it in more detail
< sdaftuar>
i've been thinking about small topology improvements, specifically picking up the main idea of #16859
< sdaftuar>
well, that's only sort of a topology improvement, depending on implementation, actually
< sdaftuar>
the main idea is to sync headers with more peers, and potentially replace peers with new ones as well
< sdaftuar>
hopefully PR to come soon-ish
< sipa>
are we eventually just going to split up all functionality, and have header-peers, block-peers, tx-peers, addr-peers? :)
< ariard>
we might learn headers from feelers, but are we going to actively maintain connections to them if we learn about a potential better chain?
< aj>
sipa: separating addr-peers sounds weird, but all the rest of it...
< sdaftuar>
i don't know! :) i have two implementations of that idea that i'm playing with, one where i introduce a new peer type (headers-sync-peer) which gets quickly dropped
< ariard>
like upgrading them to block-peers and evvicting one in consequence if max outboounds reach
< sdaftuar>
and the other where i treat it as an extra block-relay-only peer that can evict another block-relay peer
< aj>
sipa: that segues to what i've been working on which is supporting "regular" peers and "taproot-enabled" (and "anyprevout-enabled") peers for signet, indicated via service flags...
< ariard>
right, for the headers-sync-peer variant, you can store headers with addrs, and if we stale tip randomly pick up a better-chain-known-addr, open a connection with them
< ariard>
though likely more compelx of implementation
< sipa>
aj: just so that txn would propagate well?
< amiti>
sdaftuar: you had mentioned thinking about a way to distinguish incoming block-relay-only connections. I’m guessing this has something to do with the feature negotiation topic on the mailing list? what are your current thoughts?
< ariard>
maybe not store headers, just mark them as known-as-useful-peers
< aj>
sipa: s/well/at all/, yeah
< sdaftuar>
oh right, now that i have clarity on how to propose new feature negotiation, yeah i'm thinking about a simple way to negotiate block-relay only connections at peer connection time, so that both sides of a connection know they can devote less resources to each other
< sdaftuar>
which is mostly a per-peer memory savings
< sdaftuar>
and then hopefully we can increase the number of inbounds (specifically carve out extra inbound slots for block-relay peers)
< sdaftuar>
and then increase the number of block-relay outbound connections we make too
< sdaftuar>
so i'm planning to pick that up as well in the near term
< jnewbery>
> now that i have clarity on how to propose new feature negotiation
< jnewbery>
^ it wasn't clear to me what the outcome of the mailing list discussion was. What are you proposing?
< sipa>
aj: for segwit, this preferential peering was critical, as blocks wouldn't propagate from old modes to new ones... for the things you're talking about it's just about transactions
< sdaftuar>
jnewbery: just accompany new features with a protocol version bump
< sdaftuar>
but otherwise copy what has been done before
< sdaftuar>
seems to me that path is basically unobjectionable
< sipa>
it works okayish
< jnewbery>
forcing protocol changes to be serial seems not as good as being able to opt in to different features
< sdaftuar>
i think we can deal with that when we actually get protocol version number conflicts?
< sdaftuar>
seems like it doesn't happen in practce
< aj>
sipa: yeah, not much fun if your transactions don't propogate though
< sipa>
sdaftuar: fair
< sdaftuar>
and i don't think we can force other implementations to adopt anything generic (like i proposed)
< sdaftuar>
so i think it's easy for now to accommodate those preferences
< aj>
sipa: atm i'm telling it once you've got 50% peers connected, only add more outbounds if it improves your tx connectivity
< sipa>
aj: yeah, and with a better separation between block and tx connections (or block-only and full connections) it may be possible to apply such peering only on the tx-carrying ones
< sdaftuar>
hm, we've not historically used service bits for tx-relay properties right?
< aj>
sipa: yep. blocks-only happens after tx-carrying ones atm; which is maybe backwards?
< sipa>
sdaftuar: indeed
< sipa>
i'm a bit hesitant about that...
< sdaftuar>
we don't have a good framework for thinking about transaction propagation imo
< ariard>
right, and that's something we need for higher layer :)
< amiti>
sdaftuar: care to elaborate? what would a good framework look like? or, what is something we do have a good framework for thinking about?
< aj>
is there anything that'd make more sense than service flags? i think you want something that's in addrman, in case there's 5000 nodes, and only 5 of them support the feature you want
< sipa>
aj: also, this isn'ta actually specific to softforks, but to policy cjangs
< sdaftuar>
sipa: exactly
< aj>
sipa: yep
< sdaftuar>
but i think there is something to be said for splitting up policy issues into things you can deal with, and things that are hopeless?
< sipa>
so far we haven't assumed we can reasom about peer's tx policies
< sdaftuar>
i don';t know
< ariard>
at least there is a difference between propagation validity and ensuring your tx-propagation paths aren't intersected by malicous/buggy peers
< sipa>
arguably, we do already, in the form of feefilter
< sipa>
that is effectively tellings peer part of our relay policy
< sipa>
with automatic tx rebroadcast there may be slightly less need for this
< sdaftuar>
there are so many things that can go wrong with respect to transactions you have not propagating well
< aj>
perhaps it should be an entirely separate addressbook, and you have to look up via a separate seed, rather than flags in the existing address book?
< sipa>
aj: i feel it's a can of worms, trying to do this well
< ariard>
policy has to be hardcoded in higher layers, like minimum transaction size, unless you assume you higher stack to fetch your node to learn peer policies negotiated
< sdaftuar>
automatic tx rebroadcast + tx-relay-peer rotation might be the most robust thing we can do?
< ariard>
at least a subset
< sipa>
plus the philosophical issue that it means assumptions on being to rely on (claimed/standardized) policy
< aj>
sipa: sure. i only really care about doing it adequately at this point :)
< sipa>
so, eh
< sipa>
why hasn't this historically been needed?
< sdaftuar>
:)
< ariard>
sipa: I agree that's a philosophical issue but that was implicetely part of any payment channel design with timelocks
< aj>
sipa: because everyone upgrades before the policy change activates?
< sipa>
aj: right
< aj>
sipa: then no one transacts with the changed policy for a while anyway
< instagibbs>
none of your peers accepting a softfork policy may tell you something too :)
< ariard>
wait for some LN implementation being broken for forgetting some policy check
< sipa>
ariard: i feel that's a mistake, tbh
< ariard>
sipa: ofc but the fact that they are not well-documented contribute to this, like no proper toolchain to test them in separation
< ariard>
and you have the issue of a time-sensitive A propagating wrt to policy set X but not with policy set Y and your full-node being only connected to peers Y
< ariard>
time-sensitive tx A
< sdaftuar>
ariard: that could be addressed by tx-relay-peer rotation, for what it's worth
< sdaftuar>
but if the miners aren't running your policy you're in trouble!
< ariard>
I agree assuming you rotate quick enough with regards to security timelocks
< sipa>
ariard: aren't time sensitive things done on a scale of days/weeks/..., where this should be far less of a problem?
< ariard>
sdafturar: I know, LN security is in fine dependent of power miners policy, i.e the ones likely to mine a block during the timelock
< ariard>
and it's kinda a black box :(
< aj>
sipa: i suppose on mainnet it could be amusing to have a well-known set of nodes that allow rbf-without-pinning (ie, will relay any tx as long as it has the rbf bit set, and pays more than the tx it's replacing, no worries how many it invalidates)
< sipa>
so you can even do things like warning a user their time-sensitive tx isn't confirming
< ariard>
sipa: here the tradeoff, we can always pickup higher timelocks, both for punishement and cltv delta but that come at the price in case of channel failure
< ariard>
you increase the timevalue of locked funds for nothing
< aj>
sipa: everybody else ignores it as spam, but it still gets to miners so avoids lightning txs getting pinned or whatever
< ariard>
sipa: you might be under attack in the middle of the night, I lean to assume the same kind of automatic security model we have wrt to block validation
< sipa>
aj: that seems problematic
< ariard>
increasing timelocks on the long-term increase cost of LN routing fees, and thus utility of the overall system
< sipa>
a node's rational policy should be to try to approximate the network's behavior
< ariard>
because someone has to pay for the average expected failure, even if right now it's not priced at all by routing nodes
< ariard>
sipa: I agree on this, like accept the lower bound to improve your feerate view, and also improve your local fee estimation
< ariard>
thus lowering your fees, theoritically
< jnewbery>
sorry, I've lost the thread a bit here. Are we specifically trying to solve a problem for taproot on signet here?
< ariard>
jnewbery: thanks for the nudge, are p2p meeting for more theoritically discussions too :p ?
< troygiorshev>
yeah for those of us looking to organize this, anyone want to summarize and/or give this a title?
< aj>
jnewbery: allocating some service flags on signet seems to solve the problem okay on signet; trying to see if there's a better solution that usefully generalises to something that would be helpful on mainnet?
< sipa>
i think we got a bit sidetracked... i don't think we're going to solve all problems with tx relay of time-sensitive transactions in a reliable way today..
< sdaftuar>
i think the general question is whether it's worth worrying about differing transaction relay policies on our p2p network, and if so, to what extent
< sipa>
aj: oh, just signet?
< jnewbery>
it's fine to have theoretical discussions, i'm just a little lost as to what exactly we're discussing
< sipa>
aj: can't you just create a new signet with taproot from the start?
< sipa>
as in separate network
< aj>
sipa: just signet, and only for the period while a soft-fork is in development, retired after it activates on mainnet (or becomes obsolete)
< aj>
sipa: we're working on having this work in the default signet; having custom signets is definitely an additional/alternative option
< ariard>
sdaftuar: I'll open an issue resuming conversation, to scope security worries ones might have with tx-relay discrepancies
< jnewbery>
thanks. Are you asking for review yet?
< aj>
jnewbery: it allocates service flag 32 to indicate the current version of taproot; will bump to 33 when even-R taproot happens i think
< aj>
jnewbery: not really; i'm trying to get it to run on a second node of my own first
< sipa>
aj: so you will do a hardfork in signet?
< sdaftuar>
amiti: i realized i never answered your question before, but i think that we don't even know exactly what our tx-relay goals are, let alone how to measure our progress against those goals, or how to improve things.
< aj>
sipa: the idea is if you run "bitcoind -signet -experimental=taproot" then you'll get a hardfork event, and either have to drop the -experimental=taproot or upgrade to continue following the chain
< aj>
sipa: the upgraded code will have taproot activate at a later mediantime so any prior transactions will just be random garbage that didn't need to be validated
< aj>
sdaftuar: "that people don't complain on twitter and reddit about their txs not confirming" ? :)
< * sipa>
suggests hardforking in paypal support
< sdaftuar>
aj: haha if that's our only goal we can just get the moderators to filter those complaints out!
< aj>
sdaftuar: censorship for the win
< ariard>
aj: if we were binding to twitter-driven developpement why taproot isn't already activated :) ?
< sdaftuar>
TDD = twitter driven development? TIL
< instagibbs>
ariard, maybe it is *spooky music*
< jnewbery>
Did everyone who wanted to have a chance to share what they're working at the start of the meeting?
< jnewbery>
troygiorshev, amiti, fanquake, gzhao408, MarcoFalke, nehan: did you want to share anything?
< troygiorshev>
i'll jump in briefly
< troygiorshev>
since last time, I hosted a PR review club on #19509 per-peer message logging. thanks to everyone who came! some changes have been made and a few more will be in in the next few days.
< troygiorshev>
i also encourage review on 19628 (myself included...)
< troygiorshev>
if anyone is looking to dive into a relatively tedious net/net_processing unraveling, #19107 is still looking for review!
< gribble>
https://github.com/bitcoin/bitcoin/issues/19107 | p2p: Move all header verification into the network layer, extend logging by troygiorshev · Pull Request #19107 · bitcoin/bitcoin · GitHub
< troygiorshev>
that's all :)
< jnewbery>
thanks troy!
< MarcoFalke>
jnewbery: thx :). I was mostly working on 100% test coverage for p2p, but then got sidetracked/slowed down. I hope to pick that up soon
< amiti>
marcofalke: 100%! I like this ambition.
< jnewbery>
MarcoFalke: any PRs you want to shill, or still WIP?
< MarcoFalke>
still WIP (or needing rebase)
< aj>
(btw 50 days / 7 weeks 'til 0.21 feature freeze per 18947)
< nehan>
jnewbery: thanks! i have a tiny PR to fix the lack of lock around vRecvGetData and orphan_work_set which I will open soon. Other than that, noting things here that need review.
< fanquake>
I have nothing to share other than I’m trying to merge p2p PRs in some kind of sane order. Sorry if you have to rebase.
< jnewbery>
MarcoFalke: let me know if there's any interaction/conflict with #19791
< MarcoFalke>
jnewbery: Shouldn't be any interaction
< jnewbery>
sdaftuar: good idea. Let's see if there anyone else wants to share priorities/focus then move on to that
< ariard>
wrt 0.21, tx-request overhaul? erlay?
< amiti>
sdaftuar: agreed. I had spent a while trying to distill tx-relay goals, but its definitely tricky. have you seen sipa's description on #19184? it specifies a very clear list of goals
< sdaftuar>
amiti: yes i think sipa's writeup is great for what we want a single node to do, i was referring to what we want overall network behavior to look like -- i think that is a big unknown
< amiti>
ahhh
< jnewbery>
and I also need to backport #19569 to v0.20 once 19606 is merged
< jnewbery>
and once 19681 is in, I think we can do a 0.19 release
< fanquake>
jnewbery: is there any particular rush?
< fanquake>
I think there’s still a few more things tagged for 0.19 before we cut a release
< jnewbery>
fanquake: for 0.19 or the other ones?
< jnewbery>
ah, ok
< fanquake>
Either
< aj>
maybe add the non-std input reject to high-pri? i thought there used to be a backports thing on that?
< jnewbery>
aj: I'll add them
< jnewbery>
although most of the people who'd review them are here right now :)
< jonatack>
Is anyone working on overhauling peer misbehavior (e.g. measure resource usage by peers and penalise those peers consuming more of ours?) I think jnewbery is moving it into PeerManager, but besides that?
< jnewbery>
#topic 0.21 p2p goals
< sdaftuar>
so i think #19184 should be a goal for 0.21
< jnewbery>
sdaftuar: want to start? We only have 9 minutes left
< sdaftuar>
other than that, i don't feel strongly -- and am curious what other things people would like
< troygiorshev>
jonatack: i've been working on a pr measuring per peer resource usage
< sdaftuar>
i'm guessing erlay is too ambitious
< jonatack>
troygiorshev: great, ty
< jnewbery>
+1 for 19184. I did a quick review, but I'm holding off doing a full review until sipa says it's ready
< sdaftuar>
in particular, if there are some concrete features people want added, with 7 weeks to go we should try to round up review effort
< sipa>
jnewbery: will do actually soon
< aj>
progress on p2p testing a la amiti/marcofalke would be nice?
< jnewbery>
19184 may be ambitious for 0.21 if it's code freeze in 7 weeks?
< ariard>
especially p2p testing of the eviction logic, if we aim to improve it in the future
< sipa>
wow, 7 weeks already?
< aj>
jnewbery: feature freeze, not code freeze
< MarcoFalke>
aj: no progress from me for now
< sipa>
well, should be doable i think
< sdaftuar>
i haven't been following addrv2 very much
< jonatack>
I think BIP155 addrv2 is a priority, according to vasild the next steps should be smaller and easier
< ajonas>
this may have been asked elsewhere but is 19184 a requirement for taproot?
< sdaftuar>
is that something that needs to be on a shorter timetable?
< jnewbery>
ajonas: no
< amiti>
I'd like to see #17428 make progress. reviewers have agreed on the benefits of at least some of the changes, but momentum slowed down on some of the specifics. if anyone wants to review and weigh in :)
< gribble>
https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
< amiti>
ariard: p2p testing of eviction logic would be awesome.
< jonatack>
Tor v2 deprecation begins Sept 15
< sdaftuar>
what's the addvr2 roadmap look like? i don't know where we are at all.
< troygiorshev>
sdaftuar: deprecated sept 15, and gone july 15 2021
< jonatack>
addrv2 in 0.21 would be v worthwhile and agree, 19628 was probably the biggest chunk and it seems RFM
< sdaftuar>
that sounds to me like we should prioritize it
< aj>
troygiorshev: so desirable for 0.21 essential for 0.22?
< jnewbery>
ok, 1 minute left. Anyone have anything they wanted to share before the end?
< ariard>
amiti: wrt 17428, I concede gleb last point, too much advanced for now, though that would be great to have a clear map of connection types fingerprints
< sipa>
#17428
< gribble>
https://github.com/bitcoin/bitcoin/issues/17428 | p2p: Try to preserve outbound block-relay-only connections during restart by hebasto · Pull Request #17428 · bitcoin/bitcoin · GitHub
< jnewbery>
#endmeeting
< troygiorshev>
aj: I think that's right!
< lightningbot>
Meeting ended Tue Aug 25 16:00:18 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< sipa>
sdaftuar: yeah, seems it also picked up a lot of momentum by the impending doom
< sdaftuar>
thanks all! that was very helpful
< troygiorshev>
great meeting everyone!
< jonatack>
ariard: i need to review 19315, idk what's in it yet
< sdaftuar>
sipa: ok good, i can take a look and try to help get it reviewed too, i have just totally lost track of the issues
< jonatack>
ariard: amiti: if you work on eviction testing, happy to collaborate or look at stuff.
< aj>
sipa, sdaftuar: so sounds like (ab)using some service flags in a signet specific way will be fine for an initial proposal if i can make it work, or at least that you don't have any better ideas yet?
< sdaftuar>
aj: for just signet i don't have a view on what testing makes sense. but i'd be hesitant to do service-flags-for-tx-relay-policy on mainnet
< sdaftuar>
vasild: thank you, i will take a look at those as well!
< vasild>
I am doing the implementation as if they are merged
< aj>
sdaftuar: yes, 100% on not for mainnet (though not sure there's a good reason to do it for mainnet either? we didn't come up with one did we?)
< vasild>
the commits so far that were merged were agnostic to those PRs
< sdaftuar>
aj: ok great. can you explain what the motivation is for doing it on signet?
< lightlike>
jonatack, ariard: are you specifically talking about inbound eviction tests? I don't quite follow how 17428 (although great!) can help with that - doesn't it add new types of outbound connections to the framework?
< sdaftuar>
aj: i'm just curious what the testing is aiming for
< aj>
sdaftuar: so there are two ideas for "testing taproot on signet" -- one is to run a custom signet for taproot, in which case everything is easy. the other is to have the testing happen on the default signet.
< aj>
sdaftuar: the/my idea is for this testing to be happening at the current stage of the code -- so it should work pretty well, but there's still potential for hard-forking changes, like the even-R change that'll happen soon
< vasild>
sdaftuar: signaling of addrv2 support was decided to be done via new dedicated message (sendaddrv2), rather than service bits or protocol version bump. But you never know...
< aj>
sdaftuar: the advantage of doing it on the default signet is that all the infrastructure should keep working -- the faucet, the explorer, and any wallets/lightning-clients/etc that have added support for signet, so you can see how it acts in the ecosystem, not just in purely lab conditions. so i think that's worth the extra effort
< bitcoin-git>
bitcoin/master 102867c Vasil Dimov: net: change CNetAddr::ip to have flexible size
< bitcoin-git>
bitcoin/master 8d6224f MarcoFalke: Merge #19628: net: change CNetAddr::ip to have flexible size
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19628: net: change CNetAddr::ip to have flexible size (master...make_CNetAddr_ip_flexible) https://github.com/bitcoin/bitcoin/pull/19628
< vasild>
\o/
< aj>
sdaftuar: given all that, then we'll ideally have bunches of non-taproot aware nodes on signet, and some handful of taproot-aware nodes as well -- including some/all of the block signers/miners
< aj>
sdaftuar: the two practical problems are then working out when the soft-fork becomes active, and tx's in blocks can be validated against the rules in a way that copes reasonably cleanly with hardfork changes like even-R; and letting peers connect to each other to relay tx's to the signers (atm, there's < 8 signet nodes, so that's trivial really)
< aj>
sdaftuar: (this isn't really crucial for taproot; but I think having a live net for testing eltoo operability and attacks will be a big win for making sure anyprevout is sane)
< sdaftuar>
aj: yeah so i guess is there a tx-relay testing issue you're trying to solve?
< sdaftuar>
i mean, why not just connect to the signers?
< aj>
sdaftuar: (the activation approach i think will work is hardcoding an activation mediantime in the Signet chainparams, requiring the user to say --experimental=$forkname, and having activation happen on a retarget boundary once the mediantime has passed the constant. everyone then just has to upgrade to the new code prior the given mediantime, and everything works; and you don't need to worry about
< aj>
different custom signets activating soft-forks at different heights. once something goes live on mainnet, set the mediantime to the time it went live on mainnet, and remove the --experimental= requirement)
< sdaftuar>
it just seems to me like for modeling the network behavior as a whole, we don't have a clear goal for what the topology should look like on mainnet after activation (to my knowledge -- maybe someone can think abotu that and come up with a goal)
< aj>
sdaftuar: if there's more than 100 taproot nodes, you can't have everyone connect to the signers?
< sdaftuar>
aj: it's possible i really have no idea what the goals of signet are. :) so apologies if my suggestions are unhelpful.
< sdaftuar>
but i guess it just seems like modeling the p2p behavior of mainnet isn't something that is necessarily being aimed for?
< aj>
sdaftuar: i think the goals aren't really clear to anyone yet? :)
< sdaftuar>
then i feel less bad!
< sdaftuar>
:)
< aj>
sdaftuar: certainly the real answer to why not just connect directly to the signers is "i didn't think of it"
< sdaftuar>
i was just thinking abotu the issues we had with segwit on testnet a few years ago
< aj>
sdaftuar: story time?
< sdaftuar>
and there were plenty of p2p connectivity issues that would happen on testnet
< * aj>
has no recollection of testnet/segwit things
< sdaftuar>
well the main issue is that if you were running a testnet node, you might not be connected to anyone with NODE_WITNESS or whatever
< sdaftuar>
and so someone might relay a block, but the witness would get stripped, and a bunch of nodes would receive it without witness.
< sdaftuar>
old nodes would think it was valid anyway, and old-miners would build a chain on it
< sdaftuar>
new nodes would not
< sdaftuar>
and so there would be these big chain splits periodically
< aj>
was that with the preferential-connect-to-NODE_WITNESS or before that?
< sdaftuar>
anyway long story short, it was a sort of disaster, so i can see why having a situation not be as bad as that, is a good thing
< sdaftuar>
aj: the preferential peering went through a couple iterations, but probably it was done after, yet there were so few NODE_WITNESS nodes at the time of testnet activation that we still ran into problems
< aj>
right, makes sense
< sdaftuar>
maybe it was just because segwit was such a big change, i was focused on chain splits more than tx propagaton back then
< sdaftuar>
and at any rate solving the chain split issue (maintaining a bridge between the old and new networks) also resolved the segwit tx relay concerns, if they had been raised
< sdaftuar>
(at one point, i coded up a node to guess the coinbase witness (which is usually just a zero, the witness nonce) and resolved a giant fork that way)
< sdaftuar>
anyway - if you want to preferentially peer with taproot nodes on signet so that you know your transactions are making it to the miners, who would also be running that same preferential peering code, i think that makes sense
< sdaftuar>
s/miners/signers/
< jonatack>
lightlike: yes, adding inbound eviction test coverage. it was one of the motivations for #19731 that was merged yesterday.
< gribble>
https://github.com/bitcoin/bitcoin/issues/19731 | net, rpc: expose nLastBlockTime/nLastTXTime as last block/last_transaction in getpeerinfo by jonatack · Pull Request #19731 · bitcoin/bitcoin · GitHub
< sdaftuar>
because you're basically deciding that you don't want to test transaction propagation but still be able to test that validation is working as you expect, which i think is reasonable
< sdaftuar>
i mean, you're not trying to simulate mainnet conditions with transaction propagation
< aj>
sdaftuar: (atm, kalle's miner is non-taproot aware, while mine is; both refuse nonstd txs)
< gribble>
https://github.com/bitcoin/bitcoin/issues/19728 | Increase the ip address relay branching factor for unreachable networks by sipa · Pull Request #19728 · bitcoin/bitcoin · GitHub
< aj>
sdaftuar: it'd be nice if, given a large network of signet peers, tx propogation behaviour was like mainnet, i guess
< sdaftuar>
aj: i feel like the lesson from testnet has been that is not really possible to achieve? but i dunno.
< sdaftuar>
or another way of putting it -- why would signet be any better than testnet?
< aj>
sdaftuar: testnet is crazy though
< sdaftuar>
you mean because of the reorgs?
< aj>
sdaftuar: that and the rate at which blocks are found making CSV/CLTV not really sane
< aj>
sdaftuar: but yeah, it's an "it'd be nice if", not a "i'm sure it'll work out this way"
< sdaftuar>
fair enough
< aj>
sdaftuar: (i mean, my daydream is along the lines: signet is stable and usable, so people run and actually maintain test services against it, so there's a whole bunch of reliable nodes and web sites and things like LN that have actual uptime on it)
< bitcoin-git>
[bitcoin] vasild opened pull request #19802: doc: elaborate on release notes wrt netmasks (master...elaborate_netmasks_relnotes) https://github.com/bitcoin/bitcoin/pull/19802
< jnewbery>
aj: some may say you're a dreamer, but you're not the only one
< aj>
jnewbery: someday we'll find it, over a p2p connection, the hodlers, the scammers, and me?
< aj>
jnewbery: (i'm in ur earwigs upgradin' your tunez)
< bitcoin-git>
[bitcoin] luke-jr opened pull request #19803: Bugfix: Define and use HAVE_FDATASYNC correctly outside LevelDB (master...fix_fdatasync_check) https://github.com/bitcoin/bitcoin/pull/19803
< luke-jr>
fanquake: removed the no-longer-accurate commit message detail; I still don't see why the rest of #14501 shouldn't get fixed at the same time, but whatever
< aj>
jnewbery: hmm, it appears to work with two nodes! if i set -maxconnections=2 the second slot gets succesffully reserved for a taproot advertising node. still doesn't have a "-experimental=taproot" flag though
< bitcoin-git>
[bitcoin] practicalswift opened pull request #19809: log: Prefix log messages with function name if -logfunctionnames is set (master...logfunctionnames) https://github.com/bitcoin/bitcoin/pull/19809