< 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"
< 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
< 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
< 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?
< 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.
< 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
< 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.
< 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)
< 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.
< 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
< 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 :-)
< 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)
< 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
< 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=127.0.0.1:7656 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
< 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
< 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
< 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