15:00:18 <jnewbery> #startmeeting 
15:00:18 <core-meetingbot> Meeting started Tue Dec  1 15:00:17 2020 UTC.  The chair is jnewbery. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
15:00:18 <core-meetingbot> Available commands: action commands idea info link nick
15:00:34 <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:40 <jnewbery> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
15:01:08 <glozow> hi
15:01:09 <sipa> hi
15:01:14 <gleb> hi
15:01:35 <ariard> hi
15:01:37 <jnewbery> hi folks. No proposed topics in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings#1-dec-2020 so could be a short meeting
15:01:38 <wumpus> hi
15:01:39 <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
15:01:41 <ajonas> Hi
15:01:44 <michaelfolkson> hi
15:02:00 <jnewbery> anyone have any proposed topics, or anything they want to share with the group?
15:02:43 <michaelfolkson> I'd like to chat about people's thoughts on current P2P fuzzing and whether they do it. And if not why not
15:03:16 <jnewbery> #topic p2p fuzzing
15:03:17 <core-meetingbot> topic: p2p fuzzing
15:03:40 <gleb> fuzzing is just a new concept to me, I don't do it because I need to take time to learn it first :)
15:03:43 <sdaftuar> if someone pointed me to an idiot's guide to fuzzing, i might do it.  but i'm pretty clueless.
15:03:51 <fanquake> hi
15:04:11 <michaelfolkson> Ok so it is a basic understanding issue?
15:04:16 <gleb> i think so.
15:04:22 <michaelfolkson> Don't really get what it is trying to do
15:04:39 <sipa> find bugs
15:04:51 <jnewbery> There were a couple of good PR review club meetings hosted by Marco about fuzzing: https://bitcoincore.reviews/17860 https://bitcoincore.reviews/18521
15:05:12 <jnewbery> they contain lots of references to further reading for anyone who's curious
15:05:24 <ariard> you can start with the docs of AFL/libfuzzer/hongfuzz and look for talk of their authors :)
15:05:29 <sipa> michaelfolkson: what do you mean by p2p fuzzing btw?
15:05:43 <MarcoFalke> there are already p2p fuzzers
15:06:18 <emzy> Hi
15:06:24 <michaelfolkson> Yeah there is P2P code. And P2P experts in this meeting. It would be good eventually to bring that expertise on what should be fuzzed in a P2P context
15:06:29 <michaelfolkson> (I think)
15:06:41 <MarcoFalke> I am working on increasing their coverage
15:07:03 <ariard> IIRC practicalswift added coverage for a part of the p2p stack a while ago ?
15:07:38 <michaelfolkson> I guess it is an issue of whether fuzz coverage is something the expert fuzzers do or something that everyone thinks about when they open PR etc
15:07:56 <MarcoFalke> michaelfolkson: The ci does it on every PR
15:08:06 <jnewbery> I don't run the fuzzers locally because of the extra overhead of building them. I also expect most bugs except the very shallow ones to be discovered by fuzzers running continuously on dedicated machines.
15:08:15 <vasild> hi
15:08:19 <sipa> michaelfolkson: i think you need to distintuish between "writing fuzzers" and ",running fuzzers"
15:08:20 <michaelfolkson> Presumably say the P2P experts should also think about what should be fuzzed in a P2P contexts
15:08:37 <MarcoFalke> sipa: and "generating seeds"
15:08:40 <michaelfolkson> sipa: Right, could discuss both
15:08:43 <sipa> running fuzzers is something everyone can do
15:09:08 <sipa> writing fuzzers... that's just one way among dozens of how you can increasy confidence in code you're writing
15:09:26 <sipa> up to the author and what people believe is important in that context
15:09:40 <michaelfolkson> Should we be thinking about writing fuzzers in the same way as we do writing unit tests and writing functional tests? Everybody should be thinking about adding them? Or just the fuzz test experts/team
15:10:04 <michaelfolkson> I guess that's my question on the writing them side
15:10:24 <michaelfolkson> And then on the running them side it is how do we get more people to run them as part of their workflow
15:10:56 <jnewbery> I don't think there's a problem that needs to be solved here
15:10:58 <nehan> hi. i found the PR club extremely helpful in learning how to fuzz. i was able to relatively quickly doing it having zero experience with it before.
15:11:00 <sipa> obbiously?
15:11:01 <MarcoFalke> michaelfolkson: I guess it is up to the author. Not everyone is adding unit tests or functional tests.
15:11:40 <sipa> michaelfolkson: again, it's one way among many of increasing confidence incyour code. some things lend themselves well for fuzz testing, others not so much
15:12:23 <michaelfolkson> MarcoFalke: Not everyone is but everyone should at least be considering whether to or not. Right?
15:12:35 <MarcoFalke> michaelfolkson: Ideally, yes
15:13:26 <michaelfolkson> Ok thanks, that's helpful
15:13:49 <jnewbery> any other topics?
15:13:53 <michaelfolkson> I think the jnewbery point on what should be done on dedicated machines is something I have also wondered
15:14:09 <sipa> michaelfolkson: run the fuzzers
15:14:10 <ariard> a short note on state of tx-pinning/package-relay and discussion on the LN-side?
15:14:15 <sipa> like our CI runs the tests
15:14:22 <MarcoFalke> michaelfolkson: ./test/fuzz/test_runner.py --help
15:15:04 <MarcoFalke> anyone can do it. It supports single run (ci) and generation (long running)
15:15:37 <jnewbery> #topic tx pinning / package relay
15:15:37 <core-meetingbot> topic: tx pinning / package relay
15:15:48 <ariard> so we had this discussion few irc meeting ago with LN devs
15:16:02 <ariard> we found yet-another case of tx-pinning after the new anchor spec
15:16:07 <ariard> https://github.com/lightningnetwork/lightning-rfc/pull/803
15:16:26 <ariard> we would like to demo the attack actually explained here: https://github.com/t-bast/lightning-docs/blob/master/pinning-attacks.md
15:16:49 <ariard> before to know exactly what we would be cool to ask as a change on the p2p layer
15:17:06 <ariard> so right now I'm spending time hacking with RL to have the necessary toolchain
15:17:11 <ariard> and that's all :)
15:17:33 <ariard> *the attacks, we have multiple scenarios
15:17:43 <glozow> what's the SIGHASH_SINGLE malleability? sorry i'm unfamiliar
15:18:09 <sipa> RL?
15:18:17 <fanquake> rust lightning
15:18:24 <sipa> ah.
15:18:50 <ariard> glozow: it lets you sign only the index of the output, thus adding any output without cooperation of your LN counterparty (IIRC)
15:19:14 <jnewbery> glozow: https://bitcoinops.org/en/newsletters/2020/09/16/#stealing-onchain-fees-from-ln-htlcs
15:19:24 <michaelfolkson> And by case of tx-pinning you mean another scenario in Lightning where tx pinning is a problem. Rather than a new way to tx pin in Core
15:19:40 <sipa> glozow: all sighash modes are effecrively *intentional* malleability, they're there so soke tgings can be changed in a tx without affecting the sig
15:20:08 <ariard> michaelfolkson: yes we discovered another vulnerability but it wasn't mentinonned on the ML
15:20:23 <glozow> ahhhh thanks
15:20:40 <ariard> michaelfolkson: note also that pinning doesn't only affect LN but also bitcoin protocol like vaults, DLC
15:20:45 <nehan> nit ariard: I don't think you should use the term "split brains" to describe differing mempools. as you point out in the doc, mempools are different *by design*. saying it's a "split brain" implies there should be an unsplit (single) brain.
15:21:13 <nehan> ariard: "split brain" is usually used to describe a temporary network partition in distributed systems.
15:21:16 <ariard> nehan: thanks, I think the expression is from zeeman and was just reused at it is by t-bast
15:21:21 <michaelfolkson> So the messaging is like tx pinning should be even more of a priority to solve in Core than we already knew it was
15:21:48 <sipa> i don't think it can be solved in general
15:21:50 <ariard> nehan: I think I used mempool-partition to describe the same phenomena but if you have a better distributed system expression?
15:22:24 <nehan> ariard: not off the top of my head! will think about it.
15:22:48 <jnewbery> inconsistent mempools
15:22:49 <ariard> sipa: define general ? if you mean for any bitcoin protocol without care of protocol designer I likely agree with you
15:24:11 <ariard> michaelfolkson: note that cdecker proposed a new tx-relay overlay to solve pinning instead of change to p2p tx-relay
15:24:38 <sipa> ariard: i think dos protection will always result in an inability to accept transactions in some scenarios where that transaction would have been accepted from p2p in another state
15:25:13 <sipa> we can reduce the set of situations under which that can happen using better algorithms
15:25:40 <sipa> but the problem in a generic sense seems inherent
15:25:48 <michaelfolkson> ariard: So that would potentially be run by the Core nodes that care about Lightning? And the Core nodes that don't care wouldn't run it
15:25:49 <ariard> sipa: yes I agree on this! I describe such scenario here https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html (the 3rd one)
15:26:28 <ariard> but for the other something like RBF-package relay _or_ rejecting low-fee pinning transaction might be a solution
15:26:48 <sipa> ariard: my poijt is you'll always be able to find more things like that
15:27:29 <sipa> and no solution (that doesn't introduce DOs attacks) is going to leave (possibly complicated) forms of pinning enabled
15:28:24 <sipa> if it's only speaking forms of pinning that pose problems to you then it'd be good to know what those are
15:28:31 <ariard> ariard: I don't understand fully your last sentence, if you mean we'll always have complicated cases of pinning I agree?
15:28:45 <sipa> yes
15:29:04 <sipa> ok, then we agree :)
15:29:22 <ariard> okay so we agree on this, what I'm more interested to solve are the easy-to-execute pinning describe as scenario 1) and 2) in my june mail
15:29:49 <michaelfolkson> All pinning is a problem. There are no specific forms of pinning that are particularly problematic I think...
15:30:16 <ariard> to mitigate more complicated scenario we had this disccusion with matt about redundant tx-relay broadcast, but that's outside the tx-relay model
15:31:03 <ariard> michaelfolkson: not all the pinning have the same level of difficulty :) I invite you to read this mail https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-June/002758.html
15:31:08 <sipa> redundant as in LN would do relay?
15:31:19 <sipa> or something else!
15:31:20 <sipa> ?
15:31:23 <cdecker> Notice that the alternative transport over the lightning overlay is not intended to be a complete solution, just reduce the effectiveness of pinning by making it less likely to succeed
15:31:32 <ariard> like some broadcast your transaction over DNS or radio :)
15:31:56 <sipa> oh
15:32:50 <sipa> i was hoping LN, because it's an inherently different situation than bitcoin's identityless P2P
15:32:53 <ariard> like it's easy to pin a LN transaction if you know the full-node, but if this victim has another entry point to the p2p network you won't succeed
15:33:25 <ariard> sipa: yes, we had this discussion about embedding transaction in LN's onion, it does fit in the standard onion size
15:33:41 <ariard> more you have redundant tx-relay network, better you're :)
15:34:06 <sipa> better you're what?
15:34:25 <ariard> harder it is for an attacker to jam with your tx-relay
15:34:57 <jnewbery> "the more redundant networks you have, the better off you are"
15:35:10 <ariard> cdecker: yeah and it was relying on such lighthning overlay being adopted by miners? or what was the state of the discussion :) ?
15:35:28 <sipa> jnewbery: ah thanks
15:35:31 <ariard> jnewbery: ah, thanks
15:36:13 <ariard> anyway I didn't intend to occupy the spot, I'm working on demoing the tx-pinning LN attack we know about and learn from it
15:36:21 <cdecker> Yeah, I was hoping that it'd be attractive for miners to listen to the overlay since the feerate is higher (even though they don't beat absolute fee, which is really not the miner's main motivation)
15:37:52 <ariard> that might be a way to align incentives, but still I'm not sure miners are great at maintaining an extended software stack
15:39:39 <ariard> is anyone wants to do p2p review beg ?
15:40:10 <michaelfolkson> What do you mean? You want to discuss the beg process?
15:40:22 <michaelfolkson> Or beg for particular PRs?
15:40:43 <cdecker> If there's interest from miners to get access I can write up a faux-bitcoin-node that acts as a bridge between bitcoin p2p and the ln overlay relay network
15:41:01 <ariard> michaelfolkson: I mean p2p meetings are a nice spot for people to ask for reviews on their PR
15:41:11 <michaelfolkson> Ah ok
15:41:29 <michaelfolkson> Feel free to beg :)
15:41:30 <jnewbery> any other topics?
15:41:53 <sipa> gleb: want to mention the erlay bip updates?
15:42:02 <gleb> Oh yeah sure.
15:42:08 <jnewbery> #topic erlay bip updates
15:42:08 <core-meetingbot> topic: erlay bip updates
15:42:31 <gleb> So sometimes reconciliation fails initially (first sketch is insufficient, because it's too small and allows to decode up to N differences)
15:42:48 <gleb> We then don't give up, but make one more attempt.
15:43:24 <gleb> There are 2 ways to make one more attempt while *still being 100% efficient*: bisection and extension. They are independent alternatives.
15:43:52 <gleb> We used to do bisection, because it allows to spend a bit less CPU cycles on computing sketches (and just a cool trick I guess)
15:44:08 <gleb> In practice, the implementation turned out to be too complicated on the Bitcoin Core p2p protocol side.
15:44:34 <gleb> So I switched the code to do sketch extensions instead. It's much less code, and the code complexity is now more aligned with general Bitcoin project complexity.
15:44:54 <gleb> And the fact it's a bit more CPU expensive doesn't matter because we expect sketches of very low capacity.
15:45:07 <gleb> For more rationale see the updated BIP, lemme give you a link.
15:45:16 <gleb> https://github.com/bitcoin/bips/pull/899
15:45:26 <sipa> it's also easier to extend to allow doing multiple tikes, if need be
15:45:37 <gleb> And it's all in the #18261 now, fully ready for review, please review :)
15:45:39 <gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
15:45:45 <gleb> I'm willing to do any help for review facilitation.
15:45:59 <gleb> Including 1-1 sessions over voice chat or something with code walkthrough.
15:46:06 <sdaftuar> gleb: sounds good, i will take a look
15:46:26 <jnewbery> sipa: I assume you mean 'multiple times'. Why would you want to do that? Is that part of the erlay BIP?
15:47:15 <gleb> I don't really see why we'd need more than 1 extra round for now, especially with our transaction volumes and block size :)
15:47:15 <sipa> jnewbery: no it's not; the current bip allows for extending exactly once
15:47:47 <sipa> but if we ever determine that doing it multiple times is beneficial, that'd be a trivial change for extending
15:47:57 <sipa> but not simple at all for bisection
15:48:08 <jnewbery> sipa: makes sense. Thanks
15:49:09 <jnewbery> any final topics?
15:49:37 <jnewbery> Thanks all!
15:49:39 <jnewbery> #endmeeting