< fanquake> wumpus: thanks
< kallewoof> can someone with bitcoin-core rights enable cirrus CI for btcdeb repo? i can't find the option so I assume I'm not allowed
< sipa> kallewoof: done
< kallewoof> sipa: thanks!
< sipa> yw
< bioverse> I have a nano ledger s with some bitcoin. I have the 24 words and wallet in a safe place. I went to https://iancoleman.io/bip39/ using a Ubuntu live from USB. I put the 24 mnemonic words and could not find any bitcoin address ever used. I freaked. I thought. Oh my god! I ordered a second brand new nano ledger s. Put the 24 words, using ledger live in a brand new laptop and my coins were there in the brand new ledger nano s. I am safe. But I have
< bioverse> no idea why the 24 words at that offline airgapped site don't generate any used key-pairs. Maybe is SegWit address problem. I have no idea. The fisrt 20 key-pair addresses given have never been used....
< sipa> this channel is for development; you may get better help on https://bitcoin.stackexchange.com (but search for relevant questions first)
< bioverse> I know Pieter Willie
< bioverse> but any help would be greatly appreciated
< bioverse> Sent an email to the ledger manufactor two weeks ago and got not a reply with an answer
< bioverse> Anyway, do you think bitcoin can be used in the future for time-lock encryption?
< sipa> bioverse: no
< bioverse> do you mean "no, I don't think that is possible" ?
< fanquake> he probably means "no, that's not at all on topic for this channel"
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b09ad737eef6...d8646966497f
< bitcoin-git> bitcoin/master 723eb43 Hennadii Stepanov: test: Fix Windows cross build
< bitcoin-git> bitcoin/master d864696 fanquake: Merge #21115: test: Fix Windows cross build
< bitcoin-git> [bitcoin] fanquake merged pull request #21115: test: Fix Windows cross build (master...210208-win) https://github.com/bitcoin/bitcoin/pull/21115
< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d8646966497f...a0077a80b054
< bitcoin-git> bitcoin/master fd7caae Hennadii Stepanov: build: Disable --disable-fuzz-binary for gitian builds
< bitcoin-git> bitcoin/master cb151b7 Hennadii Stepanov: build: Disable --disable-fuzz-binary for guix builds
< bitcoin-git> bitcoin/master a0077a8 fanquake: Merge #21116: build: Disable --disable-fuzz-binary for gitian/guix builds
< bitcoin-git> [bitcoin] fanquake merged pull request #21116: build: Disable --disable-fuzz-binary for gitian/guix builds (master...210208-fuzz) https://github.com/bitcoin/bitcoin/pull/21116
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a0077a80b054...c4214d0e0df0
< bitcoin-git> bitcoin/master fa0a4d6 MarcoFalke: test: remove assert_blockchain_height
< bitcoin-git> bitcoin/master c4214d0 MarcoFalke: Merge #21117: test: remove assert_blockchain_height
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21117: test: remove assert_blockchain_height (master...2102-testNoTimeout) https://github.com/bitcoin/bitcoin/pull/21117
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c4214d0e0df0...19b1ceddc716
< bitcoin-git> bitcoin/master 98db48d Gunar Gessner: doc: Fix markdown formatting
< bitcoin-git> bitcoin/master e1604b3 Gunar C. Gessner: doc: Replace tabs for spaces
< bitcoin-git> bitcoin/master 19b1ced MarcoFalke: Merge #21075: doc: Fix markdown formatting
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21075: doc: Fix markdown formatting (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21075
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/19b1ceddc716...3641ec1aacfe
< bitcoin-git> bitcoin/master ac24af4 fanquake: ci: use Ubuntu Focal for macOS cross build
< bitcoin-git> bitcoin/master 3641ec1 MarcoFalke: Merge #21112: ci: use Focal for macOS cross builds
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21112: ci: use Focal for macOS cross builds (master...actually_use_focal_in_cirrus_ci) https://github.com/bitcoin/bitcoin/pull/21112
< Kiminuo> Hi, would you mind sharing what IDE/editors you use for Bitcoin Core development?
< sipa> i use mcedit, still...
< Kiminuo> :) unexpected choice
< bitcoin-git> [bitcoin] kiminuo opened pull request #21123: code style: Add EditorConfig file (master...feature/editorconfig) https://github.com/bitcoin/bitcoin/pull/21123
< wumpus> neovim mostly ! i hava tried out vscode a bit earlier this year and it's nice but somehow fast text editors in the terminal stick better with me, once you're familiar enough with the code base the various IDE niceties don't add that much
< sipa> wumpus: yeah, and also: the actual time spent writing code isn't all that much as a fraction of development time
< Kiminuo> True. Still it very annoying to fix formatting issues. It's better to spend time on something more productive than moving braces around (if there is no automated tool to fix formatting).
< Kiminuo> I would say it saps your mental energy. Better to spend that time go for a walk or something.
< wumpus> hehe yea i'd recommend going for a walk / cardio / etc regularly anyway, not only is it good for your health it helps focus your mind and get inspiration in ways staring at a screen (or paper, for that matter) does not
< jnewbery> wumpus: I think https://github.com/bitcoin/bitcoin/pull/20557 is RFM. ACKs on latest version from ryanofsky, dhruv, naumenkogs, glozow, vasild.
< wumpus> jnewbery: thanks will take a look!
< wumpus> agree that the remaining comments can be addressed in a follow up
< wumpus> i vaguely remember there was something you could add to the github url to uncollapse all hidden comments, does anyone remember?
< fanquake> not that I can recall
< wumpus> too bad, would have liked it do be the default for ghwatch
< bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/3641ec1aacfe...b847f49717d1
< bitcoin-git> bitcoin/master b4c5fda John Newbery: [addrman] Fix new table bucketing during unserialization
< bitcoin-git> bitcoin/master 009b8e0 John Newbery: [addrman] Improve variable naming/code style of touched code.
< bitcoin-git> bitcoin/master 8062d92 John Newbery: [addrman] Rename asmap version to asmap checksum
< bitcoin-git> [bitcoin] laanwj merged pull request #20557: addrman: Fix new table bucketing during unserialization (master...2020-12-fix-addrman-bucketing) https://github.com/bitcoin/bitcoin/pull/20557
< Kiminuo> wumpus, https://github.com/editorconfig/editorconfig-vim/issues/95 - do you possibly add a space like this `[{*.am,<DO-NOT-PUT-SPACE-HERE>Makefile.*.include}]` to your .editorconfig file?
< bitcoin-git> [bitcoin] brunoerg opened pull request #21124: test: remove unnecessary assignment in bdb (master...fix-bdb-test) https://github.com/bitcoin/bitcoin/pull/21124
< jonatack_> ugh, it appears that github backpedaled on showing all the review comments via the command line with gh pr
< jonatack_> for a few days, gh pr view 20557 -c would show everything. now, for the detailed review comments it instead displays, "View the full review: https://github.com/bitcoin/bitcoin/pull/20557#pullrequestreview-586080477"
< jonatack_> wth
< bitcoin-git> [bitcoin] kiminuo opened pull request #21125: test: Change BOOST_CHECK to BOOST_CHECK_EQUAL (master...feature/boost-equal) https://github.com/bitcoin/bitcoin/pull/21125
< michaelfolkson> jonatack_: The reversion may be temporary. They might experiment with new features with subsets of users and then review
< wumpus> Kiminuo: your new syntax works
< Kiminuo> :thumbsup*
< wumpus> jonatack: huh?! was this an API side change or a client side one?
< jonatack> idk. hmph
< jonatack> didn't update
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21126: ci: Properly bump to focal for win cross build (master...2102-ciWin) https://github.com/bitcoin/bitcoin/pull/21126
< jonatack> if it's a paid feature to see everything i'd happily pay
< jonatack> looks like it didn't do what i originally thought it did: https://github.com/cli/cli/pull/2757
< jnewbery> Hi folks. Reminder that we have a p2p meeting in half an hour. There are currently no topics in the meeting page: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-IRC-meetings.
< jnewbery> Feel free to update your priorities here: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities to let people know what you're working on.
< vasild> Looks like the .ics calendar for the meetings which I downloaded from https://bitcoincore.org/en/meetings/ is off-by-one-hour - it shows the P2P meeting at 17:00 my time, while it is actually at 16:00.
< wumpus> vasild: i think that's derived from my google calender let's see
< vasild> and the Thu meeting is showing as 19:00 my time, while it is actually at 20:00 my time (off-by-one but in the other direction)
< wumpus> it shows it at 16:00 (my time) here which seems correct
< wumpus> the details say 15:00 to 16:00 GMT
< wumpus> which seems right
< vasild> could be a bug in my calendar app interpreting the .ics file
< wumpus> yes, or in google exporting it
< bitcoin-git> [bitcoin] Sjors opened pull request #21127: wallet: load flags before everything else (master...2021/02/wallet_flags) https://github.com/bitcoin/bitcoin/pull/21127
< bitcoin-git> [bitcoin] SteversIO opened pull request #21128: Update Whitepaper link in README.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21128
< jnewbery> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb 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 petertodd
< jnewbery> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< gleb> hi!
< michaelfolkson> hi
< ariard> hi
< jonatack> hi
< vasild> hi
< sipa> hi
< michaelfolkson> I like these individual summaries
< ajonas> hi
< gleb> Can I have a word for a bit?
< jnewbery> Does anyone have any suggested topics or want to give an update on their priorities?
< jnewbery> gleb: yes, go for it!
< gleb> W.r.t erlay: thanks jnewbery for making some initial review (along with sdaftuar and sipa), and lightlike for hosting a review club session tomorrow.
< wumpus> hii
< gleb> Generally speaking, I think at this point we need couple people making high-level *full* code review til the end, to make semi-code-semi-approach ACKs.
< amiti> hi
< gleb> The next step would be to split the PR into 5 or so parts and merge one by one, but I think we better have a little bit of that high-level check first.
< vasild> (or NACKS :-D)
< gleb> vasild: sure :)
< gleb> Just need to make sure the code structure overall makes sense, and we don't have some implementation-specific no-goes.
< emzy> hi
< gleb> So yeah, asking people to spend a couple hours looking at the entire PR without going into details. That would be very useful.
< gleb> That's all. I'm always willing to answer questions if any
< ariard> gleb: do you want to open an issue as an easy-endpoint to track the ongoing review effort around erlay?
< sipa> gleb, jnewbery: did you see i addressed some of your comments in https://github.com/sipa/minisketch/pull/28 ?
< jnewbery> gleb: I think an easy win would be to split the minisketch tree into its own PR.
< jnewbery> sipa: I did see that. Thank you. I mean to go back and look again
< gleb> jnewbery: yes, after we resolve those comments in the minisketch repo
< gleb> ariard: there's nothing to track before we start splitting?
< jnewbery> gleb: you mean the comments on pull/28 or something else? I don't think those should be blocking
< ariard> gleb: as soon as you start to split, I'm just worried about how GH handle PR with hundreds of comments
< michaelfolkson> I'll probably spend tomorrow looking at Erlay before the PR review club (on UK time so review club is evening for me). Will be on the bitcoin-core-pr-reviews channel trying to avoid the questions set for the review club session
< gleb> jnewbery: yeah, pull/28. I thought we merge that to minisketch, and then I create a PR to core.
< jnewbery> sounds good. I'll try to go back and make sure mine are resolved
< gleb> ariard: Not sure how issue tracking progress would help handling comments?
< gleb> i mean github troubles
< gleb> michaelfolkson: thank you!
< sipa> i'm not sure the erlay PR lends itself well for splitting it up; there may be preparatory changes like refactoring the existing code, or adding minisketch perhaps... but beyond that, what would you split it into?
< jnewbery> sipa: how much review has minisketch had already?
< sipa> jnewbery: about this much: <----------->
< gleb> sipa: For me the only reason to split is to ease the review. Same we did for big PRs like twice already. It doesn't make much sense logically to have those commits separate one from another, yeah.
< jnewbery> To enter Bitcoin Core your PR must have this much <----------------->
< aj> zzz
< gleb> sipa: do you think it should be not split?
< amiti> gleb- saw you got some comments along the lines of extracting some of the erlay code from net processing. are you planning to implement? eg. have an erlay specific module or such?
< sipa> gleb: i'm not convinced it's useful
< gleb> amiti: I think it's done already? Separate file reconciliation.cpp
< amiti> oh okay :)
< gleb> similar to txrequest.cpp
< jnewbery> sipa: I think github is almost unusable for reviewing large PRs, unfortunately
< ariard> and really bad to track small follow-ups
< sipa> jnewbery: ah, yes, for that reason
< sipa> i'd suggest dealing with that when the problem actually appears
< gleb> sipa: As a pr author, I can't judge.
< glozow> gleb: jw, is reconciliation module intended to be generic/reusable by stuff other than tx relay?
< jnewbery> #18261 if you haven't found it already
< gleb> glozow: nope, what I have implemented is not reusable. Minisketch is reusable.
< gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
< glozow> ok makes sense
< gleb> glozow: Only a very little part of reconciliation.cpp could be reused for other stuff (and that stuff is far from being designed.)
< jnewbery> already has 157 hidden review comments. That's about the point github usually falls over and doesn't let you read old comments
< gleb> jnewbery: at least I resolved most of them but the remaining open 10 comments :)
< gleb> But yeah, that's a shame.
< sipa> jnewbery: i think the algorithmic parts of minisketch are fairly well reviewed; the implementation less so
< gleb> Anyway, would be great if some people give a high-level code overview, say by next meeting in 2 weeks, so that we decide how to proceed?
< jnewbery> sipa: ok, so you think it still needs review before merging into Bitcoin Core? Would it therefore make sense to split it into a separate PR?
< sipa> jnewbery: but, ignoring field-specific logic, there are some nice tests (e.g. for a few very small fields, there are unit tests that exhaustively test literally all possible sketches)
< sipa> jnewbery: i can't judge that
< amiti> gleb: I'm confused, I see reconciliation.h but not reconciliation.cpp
< * vasild> added #18261 to his to-review list
< gribble> https://github.com/bitcoin/bitcoin/issues/18261 | Erlay: bandwidth-efficient transaction relay protocol by naumenkogs · Pull Request #18261 · bitcoin/bitcoin · GitHub
< aj> where's minisketch upstream?
< sipa> but in general, more eyes on the code would be good
< jnewbery> aj: sipa/minisketch
< gleb> amiti: sorry, yeah, everything is in the .h
< amiti> oh, why?
< aj> should it be bitcoin-core/minisketch?
< gleb> amiti: I dunno what cpp experts say about .h/.cpp. Let me know if the file should be renamed or something.
< gleb> I just mimicked something we already have the best i can :)
< ariard> yeah I'll have a look on the minisketch part
< jnewbery> gleb: it's not really about the naming. It's more about having a well-scoped interface between net processing and the reconciliation module so there's no coupling and the modules can be understood in isolation
< jnewbery> just putting some of the classes in a new header file won't help with that
< gleb> jnewbery: Okay, I'll probably ask you more after the meeting. Thanks.
< sipa> aj: i hope minisketch can be used for other entirely unrelated applications
< michaelfolkson> sipa: Such as?
< ariard> michaelfolkson: gossips on LN would be such experience
< sipa> michaelfolkson: do you know what it does?
< michaelfolkson> I think so at a high level. Allows nodes to work out which transactions they're missing right?
< michaelfolkson> Or is that wrong?
< sipa> no, it's much more low level than that
< sipa> it has no knowledge of concepts like nodes or transactions
< gleb> michaelfolkson. That's erlay. Minisketch have no idea about bitcoin or transactions and just operates over sets of numbers.
< ariard> michaelfolkson: beyond meeting scope, have a look on this : https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html
< sipa> it just operates on sets of data, and lets you discover differencss between them
< michaelfolkson> I haven't looked at Erlay in a while, my memory is hazy. Will read up for tomorrow
< gleb> Okay, I think we discussed everything on the topic.
< jonatack> Erlay notes here for tomorrow's review meeting: https://bitcoincore.reviews/18261
< gleb> Basically my review beg :)
< jonatack> I'd like to encourage people to test and review the I2P PR that adds the invisible interet project to our P2P netowrks
< amiti> I'd like to give a quick update!
< jnewbery> amiti: go for it
< michaelfolkson> Thanks for the link ariard
< jonatack> wumpus, myself and lontivero have been running nodes with i2p services
< amiti> I've put up a PR for introducing new node-level rebroadcast functionality at #21061. would love review, feel free to ask me any questions :)
< gribble> https://github.com/bitcoin/bitcoin/issues/21061 | [p2p] Introduce node rebroadcast module by amitiuttarwar · Pull Request #21061 · bitcoin/bitcoin · GitHub
< jonatack> with the tor v3 consensus attacks in the past month, having another privacy network seems useful
< amiti> also broke out a small PR that is a test helper & improvements at #21121
< gribble> https://github.com/bitcoin/bitcoin/issues/21121 | [test] Small unit test improvements, including helper to make mempool transaction by amitiuttarwar · Pull Request #21121 · bitcoin/bitcoin · GitHub
< jonatack> oops
< jonatack> sorry if that was not welcome
< amiti> thats all :)
< jnewbery> amiti: that's great. I've been looking forward to a rebroadcast PR
< michaelfolkson> Again my personal memory is hazy of rebroadcast amiti. I remember the PR review club. How has your approach changed since that?
< jnewbery> jonatack: do you have the PR number for I2P?
< gleb> amiti: subscribed for updates on that PR, please keep posted on the review state (concept ack or low-level review or whatnot)
< jonatack> #20685
< gribble> https://github.com/bitcoin/bitcoin/issues/20685 | Add I2P support using I2P SAM by vasild · Pull Request #20685 · bitcoin/bitcoin · GitHub
< jonatack> #20788
< gribble> https://github.com/bitcoin/bitcoin/issues/20788 | net: add RAII socket and use it instead of bare SOCKET by vasild · Pull Request #20788 · bitcoin/bitcoin · GitHub
< amiti> gleb: I'm currently looking for approach feedback
< jonatack> tagged for v22.0
< jnewbery> jonatack: thanks
< michaelfolkson> The rebroadcast PR review club was here: https://bitcoincore.reviews/16698
< jnewbery> ok, any other topics/updates?
< amiti> michaelfolkson: I've written up LOTS of description on the PR that you might find useful, the main changes since the previous PR is that unbroadcast was broken out into a separate PR & merged. and the frequency / timing of rebroadcast has changed.
< jnewbery> #20277
< gribble> https://github.com/bitcoin/bitcoin/issues/20277 | p2p: Stop processing unrequested transactions and extend p2p_ibd_txrelay.py coverage by ariard · Pull Request #20277 · bitcoin/bitcoin · GitHub
< wumpus> yes, i've been running a fairly busy node with the I2P patch for quite some time, haven't run into any problems
< michaelfolkson> Cool, thanks amiti
< ariard> finally updated to stop processing of unrequested tx in the goal to reduce DoS surface
< jnewbery> thanks ariard
< ariard> note, it changes few of our p2p tests, as few of them weren't compliant with the canonical tx-request sequence
< jonatack> wumpus: yes, the I2P implementation seems to be working well for me as well
< jnewbery> any final topics?
< ariard> a following of this work could be to explore better prioritization of tx-request, it's likely when we're going to introduce package relay
< jnewbery> Alright, let's call it there. Thanks everyone
< aj> review beg for #20942 -- lots easier than most of these
< gribble> https://github.com/bitcoin/bitcoin/issues/20942 | [refactor] Move some net_processing globals into PeerManagerImpl by ajtowns · Pull Request #20942 · bitcoin/bitcoin · GitHub
< ariard> like set of txn are far more DoSy and we might need to allocate package-announcement bandwidth per-peer
< jnewbery> aj: I agree. That's a good one to review!
< jnewbery> aj: wen orphanage?
< vasild> My plan is to get #20788 merged first and then simplify the I2P PR as a result of that.
< gribble> https://github.com/bitcoin/bitcoin/issues/20788 | net: add RAII socket and use it instead of bare SOCKET by vasild · Pull Request #20788 · bitcoin/bitcoin · GitHub
< jonatack> vasild: wdyt about fluffypony's light i2p client suggestion from the monero project
< aj> jnewbery: it's next after that one
< vasild> jonatack: I did not try that one, but it would be one more possible i2p router to use. I try to avoid recommending which i2p router to use, so that people find the best one for them.
< aj> (in #20758)
< gribble> https://github.com/bitcoin/bitcoin/issues/20758 | net-processing refactoring -- lose globals, move implementation details from .h to .cpp by ajtowns · Pull Request #20758 · bitcoin/bitcoin · GitHub
< jnewbery> any final final topics?
< jonatack> vasild: ok, i'll try to check it out
< jnewbery> #endmeeting
< michaelfolkson> The history on rebroadcast is a great idea https://github.com/amitiuttarwar/bitcoin-notes/blob/main/rebroadcast-history.md
< vasild> it will be ok, as long as it implements the sam protocol
< amiti> michaelfolkson: thanks. there has been lots of prior conversation & I wanted to make it as easy as possible for reviewers to glean context.
< michaelfolkson> Yeah I think a lot of these kinds of mini projects could benefit from doing this
< michaelfolkson> Especially with the unreliable PR comment history
< nehan> aj: are you looking for comment/review of orphanage impl in 20758? or not yet?
< michaelfolkson> Collect all the good observations from PR review comments into a separate doc
< jnewbery> nehan: I expect review of 20942 first would be more helpful. It's a good change independent of orphanage
< wumpus> jonatack: vasild: from what i understand the kovri router is forked from i2pd (the c++ implementation) so it should just work
< aj> nehan: sure
< aj> nehan: i mean, not /expecting/ it before it gets a separate pr, but it's certainly welcome
< wumpus> i can give it a try though, i have noticed the java I2P router is somewhat heavy
< jonatack> we can compare experiences, at some point we may need to write a doc/i2p.md and collect our notes there
< wumpus> agree, would be good to have a similar document to tor.md for i2p.md, though we can do it as follow-up to vasild's work
< wumpus> looks like this is the main repository for it https://gitlab.com/kovri-project/kovri
< bitcoin-git> [bitcoin] vasild opened pull request #21129: fuzz: check that ser+unser produces the same AddrMan (master...fuzz_addrman_serunser) https://github.com/bitcoin/bitcoin/pull/21129
< vasild> that would be easy: cp doc/tor.md doc/i2p.md ; sed -i '' -e 's/tor/i2p/' doc/i2p.md ; git commit -a -m 'add i2p documentation'
< wumpus> it's a start but i'm sure some things are different :-)
< vasild> my experience with i2pd is this: https://github.com/PurpleI2P/i2pd/issues/1568
< wumpus> typical scary c++ stuff, i think i was right to go for the java one first :-)
< wumpus> people really shouldn't be writing P2P code in a memory unsafe language *ducks*
< wumpus> gah, looks like kovri removed the SAM proxy stuff... they recomment using something called "secreta" which i've never heard of instead
< bitcoin-git> [bitcoin] fanquake closed pull request #21128: doc: Update Whitepaper link in README.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/21128
< wumpus> xkcd 927 moment
< sipa> but that's not kovri?
< sipa> i have no idea how all those projects are related
< wumpus> oh.. yet another one? i don't know anymore
< wumpus> i thought kovri was the monero one
< wumpus> but a lightweight java I2P router sounds pretty good
< endogenic> sekreta aiui is an api on top of protocols by anonimal
< endogenic> dunno how far he got w it
< endogenic> kovri was a cpp i2p router impl attempt
< bitcoin-git> [bitcoin] hebasto opened pull request #21130: script: Make LXC container size suitable for gitian builds (master...210209-lxc) https://github.com/bitcoin/bitcoin/pull/21130
< wumpus> yea what confused me is that kovri used to be under the monero project, didn't notice fluffypony mentioned something else
< wumpus> okay, i get it now: i2p-zero isn't an alternative implementation at all, it's another launcher for I2P proper which starts less services by default, and has a built-in JDK for linux/windows/macosx (this doesn't help me on fbsd)
< wumpus> s/JDK/JRE/
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b847f49717d1...d48f9e8ebbb7
< bitcoin-git> bitcoin/master c9095b7 Bruno Garcia: test: remove unnecessary assignment in bdb
< bitcoin-git> bitcoin/master d48f9e8 MarcoFalke: Merge #21124: test: remove unnecessary assignment in bdb
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21124: test: remove unnecessary assignment in bdb (master...fix-bdb-test) https://github.com/bitcoin/bitcoin/pull/21124
< jonatack> yes, am building https://github.com/i2p-zero/i2p-zero to try it
< prayank> wumpus: I think we were discussing about positives of Bitcoin Stackexchange few days back. Sad to see one of the moderators mentioning specific altcoins in answers when it could have been avoided. One of the altcoin mentioned in this answer has few people associated with it who spread misinformation about Bitcoin. And we have people with good reputation making these altcoins sound legit by mentioning in the answers.
< luke-jr> prayank: Bitcoin's Stackexchange has a history of misinformation
< wumpus> this is really off topic here
< michaelfolkson> Right #bitcoin
< prayank> luke-jr: sad but I will keep trying my best with my contribution and wumpus: Bitcoin Stackexchange is used as reference for lot of things/discussion including Bitcoin Core issues and PRs.
< jonatack> wumpus: vasild: I've been using i2pd these past weeks, been working well for me. apt install i2pd / systemctl enable i2pd.service / systemctl start i2pd.service, update bitcoin.conf, done
< sipa> jonatack: that's not too bad
< jonatack> yes. so we have i2pd (c++) https://i2pd.readthedocs.io/en/latest ... i2prouter (java) https://geti2p.net/en/download ... and i2p-zero https://github.com/i2p-zero/i2p-zero
< jonatack> s/i2prouter/i2p-router/ in my apt sources
< wumpus> jonatack: fwiw it can be useful to run ghwatch with "-x subscribed" to get only threads where you commented and direct notifications, it reduces the noise a lot
< wumpus> jonatack: oh good to know!
< wumpus> did you notice the c++ implementation taking significantly less CPU than the Java router?
< jonatack> wumpus: idk, i2pd is the only one i've managed to have running with bitcoin
< jonatack> bitcoin conf : i2psam= and i2pacceptincoming=1
< jonatack> and it just works
< sdaftuar> jonatack: thanks for mentioning these seemingly simple instructions! i'm going to give it a try
< jonatack> great -- hope they work as well
< jonatack> wumpus: thanks! i'm still figuring out how to best use ghwatch so keep the tips coming :)
< wumpus> jonatack: in general i've been thinking of adding a mode that sorts by notification reason (from specific to aspecific) before time, the 'subscribed' ones can be useful sometimes to see what is happening but they're so much more spammy than the rest
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d48f9e8ebbb7...d202054675c9
< bitcoin-git> bitcoin/master 1bca2aa Kiminuo: Introduce GetUniquePath(base) helper method to replace boost::filesystem::...
< bitcoin-git> bitcoin/master d202054 Wladimir J. van der Laan: Merge #21052: refactor: Replace fs::unique_path with GetUniquePath(path) c...
< bitcoin-git> [bitcoin] laanwj merged pull request #21052: refactor: Replace fs::unique_path with GetUniquePath(path) calls (master...feature/fs-unique-path) https://github.com/bitcoin/bitcoin/pull/21052
< sdaftuar> jonatack: everything seemed so easy, but i'm getting errors like this in my log: I2P: Error listening: Receive interrupted (received 0 bytes without terminator before that)
< sdaftuar> i assume that didn't happen to you?
< jonatack> no, do you see logs like "i2paccept thread start", "I2P: SAM session created: session id=..." and "AddLocal(i2p address...)
< jonatack> "?
< sdaftuar> yeah i don't get all that. i get the "i2paccept thread start", then Creating sam session, then 3 minutes later i get an error
< * jonatack> wonders if he forgot about having to create an i2dp.config file a few weeks back per https://i2pd.readthedocs.io/en/latest/user-guide/configuration/
< sdaftuar> looks to me like the Hello() is failing
< sdaftuar> i see in my i2pd logs a "runtime exception stoi"
< sdaftuar> unfortunately i have zero idea how to continue to debug this :(
< sdaftuar> what version i2pd are you running?
< jonatack> i2pd version 2.35.0 (0.9.48)
< jonatack> Boost version 1.74.0
< jonatack> OpenSSL 1.1.1i 8 Dec 2020
< sdaftuar> hm i have something different -- i2pd version 2.23.0 (0.9.38)
< jonatack> the versions provided by debian sources
< sdaftuar> weird that we have different versions then! i just did apt-get update, apt install like you said
< jonatack> e.g. when i run "apt show i2pd"
< jonatack> do you have: sudo apt-get install apt-transport-https
< jonatack> 2.35 is the latest release apparently and you can download it here: https://github.com/PurpleI2P/i2pd/releases/tag/2.35.0
< sdaftuar> maybe i just made a huge mistkae but trying ot upgrade a lot of packages now... will see if that improves anything but now i have to wait :)
< aj> sdaftuar: i2pd 2.23 is in debian stable, i2pd 2.35 is in testing/unstable
< jonatack> yes, checking, and i'm on unstable atm
< jonatack> i don't think any other config was needed: https://github.com/bitcoin/bitcoin/pull/20685#issuecomment-761799484
< aj> sdaftuar: (rmadison from the devscripts package will tell you the version of packages in different debian releases fwiw)
< sdaftuar> aj: ah thanks!
< jonatack> verified that i gave these instructions in this tweet and they worked for someone on ubuntu 20.04 who started bitcoind with an i2p service and connected to me https://twitter.com/jonatack/status/1351136998854176777?s=20
< jonatack> (so no other config was necessary)
< sdaftuar> ok i didn't have apt-transport-https before, but now i do. still doesn't work though after restarting i2pd. i've got i2pd running with loglevel=debug, and this is what i see in my logs: https://pastebin.com/2VsyHhbe
< sdaftuar> so i guess time to look at i2pd code if i'm going to figure this out
< jonatack> sdaftuar: i uninstalled, reinstalled, and started i2pd with --loglevel debug and see this https://imgur.com/a/2t3mZie