cryptapus has quit [Quit: Konversation terminated!]
mattdrollette has joined #bitcoin-core-dev
mdrollette has quit [Ping timeout: 252 seconds]
haakon has quit [Ping timeout: 252 seconds]
haakon has joined #bitcoin-core-dev
cryptapus has joined #bitcoin-core-dev
Yihen has joined #bitcoin-core-dev
Yihen has quit [Remote host closed the connection]
gnaf has joined #bitcoin-core-dev
spencore has quit [Read error: Connection reset by peer]
<gnaf>
;;auth gnaf
<gribble>
Request successful for user gnaf, hostmask gnaf!~gnaf@86-91-224-60.opennet.kpn.net. Your challenge string is: zirconium.libera.chat:#bitcoin-otc:8f2f03563f52e38a1022450907e9108c382606db9dfba6f1284e3bac
<bitcoin-git>
bitcoin/master 54de7b4 Andrew Chow: Allow the long term feerate to be configured, default of 10 sat/vb
<bitcoin-git>
bitcoin/master d5069fc Andrew Chow: tests: Use SelectCoinsBnB directly instead of AttemptSelection
<bitcoin-git>
bitcoin/master 6a023a6 Andrew Chow: tests: Add KnapsackGroupOutputs helper function
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] meshcollider merged pull request #22009: wallet: Decide which coin selection solution to use based on waste metric (master...cs-waste-2) https://github.com/bitcoin/bitcoin/pull/22009
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
roconnor has quit [Ping timeout: 252 seconds]
gnaf has left #bitcoin-core-dev [#bitcoin-core-dev]
gnaf has joined #bitcoin-core-dev
jarthur has quit [Ping timeout: 250 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] siv2r opened pull request #22851: [WIP] Add Python ChaCha20 implementation and bindings for CPP ChaCha20 implementation (master...chacha20-test-coverage) https://github.com/bitcoin/bitcoin/pull/22851
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
gnaf has quit [Remote host closed the connection]
gnaf has joined #bitcoin-core-dev
jarthur has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
fch has joined #bitcoin-core-dev
goatpig has quit [Quit: Konversation terminated!]
Henrik has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
gnaf has left #bitcoin-core-dev [#bitcoin-core-dev]
goatpig has joined #bitcoin-core-dev
gnaf has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
fch has joined #bitcoin-core-dev
fch has quit [Quit: Leaving]
Yihen has quit [Remote host closed the connection]
sipsorcery has quit [Ping timeout: 252 seconds]
kabaum has quit [Quit: Leaving]
Henrik has joined #bitcoin-core-dev
saranshsharma has joined #bitcoin-core-dev
saranshsharma has quit [Ping timeout: 252 seconds]
bomb-on has joined #bitcoin-core-dev
bomb-on has quit [Client Quit]
earnestly has joined #bitcoin-core-dev
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
sipsorcery has joined #bitcoin-core-dev
<laanwj>
just reminded again that we don't currently have metadata backup for the GUI repository like we have for bitcoin/bitcoin in zw/bitcoin-gh-meta
<laanwj>
this would be useful for ghwatch and the list-pulls script, as well as for archival in general
<laanwj>
it would make sense to do it for all repos under bitcoin and bitcoin-core
<laanwj>
but it would be a lot of hassle to create a mirror-repo for every one
<laanwj>
mmy grouping it into one archive repo would be best-it's not like the most of the other repositories see a lot of traffic on top of what bitcoin/bitcoin gets
<laanwj>
secp256k1's discussion would be also pretty important to archive
Talkless has quit [Quit: Konversation terminated!]
<sipa>
haha
<sipa>
silly gribble
<michaelfolkson>
gribble wants us to go back to 0.22 versioning. Can't cope
<michaelfolkson>
I do wonder if that will cause headaches for other people
jonatack has joined #bitcoin-core-dev
<shiza>
It's not too late to roll back such mistake. :D
<michaelfolkson>
gribble ACKs that :)
<jonatack>
laanwj: heh nice, the script handles unicode in PR titles :D ... a few 22.0 pulls seem to be missing: manually edit the wiki? send info by IRC?
prayank has joined #bitcoin-core-dev
Guest32 has joined #bitcoin-core-dev
<prayank>
1. Is there anything in Bitcoin Core that prevents situation in which my node has 8 outbound connections (2 ipv4, 2 ipv6, 2 onion, 2 i2p) but in reality they are addresses of 2 nodes.
<prayank>
2. If my node has only 2 outbound connections: onion and i2p. What are the things that can help me know they are both addresses of same node?
dongcarl has quit [Ping timeout: 248 seconds]
Guest32 has quit [Quit: Client closed]
<sipa>
prayank: there is generally no way to identify nodes, so no, you can't know
<jonatack>
prayank: (you know this, but just saying for anyone reading) in addition to the 8 outbound full and 2 outbound block relay peers, there are 8 additional outbound slots one can use for -addnode (manual) connections to peers selected for their diversity, connectedness, honesty or other desirable qualities
<prayank>
sipa: blocks synced, UA, rebroadcast txs, version and maybe other p2p messages can help? Question 1 above is about avoiding getting connected to attackers/spy and assume we have different nodes in outbound. Question 2 affects privacy of people listening on multiple networks especially onion and garlic.
<sipa>
prayank: if you find a way to tell that two connections are to the same node, it means you can infer the network topology
<sipa>
opinions on this differ, but imho, that's undesirable
<sipa>
well, not quite the full topology, but it's part of it
<prayank>
What should be the best practices? Maybe have lots of outbound and inbound connections? Other things can be avoid using fancy things in UA, don't share addresses on social media and maybe that rebroadcast PR if merged can also help
<michaelfolkson>
Any view on I2P versus Tor if you had to choose one jonatack (or anyone else)? I read that I2P is maybe more robust, reliable than Tor which surprised me given that I'd never heard of I2P until you started working on it
<sipa>
more connections generally means worse privacy (just more things that can be observed)
<sipa>
more connections help the network, and in particular partition resistance
<sipa>
michaelfolkson: anonymity set with I2P is smaller, just by being a smaller network
bomb-on has joined #bitcoin-core-dev
<michaelfolkson>
More connections, harder to be eclipsed
<sipa>
yes, that's what partition resistance means
<sipa>
well, it's broader - eclipse attacks are attempts to isolate a single target node
<michaelfolkson>
Oh I had them as separate things. Partition resistance as the network splitting in two and eclipse as the network potentially being fine but an adversary controlling all your peers
<sipa>
partitions are broader, where you just have two groups of nodes that are not interconnected
<sipa>
(or only interconnected by attackers)
<michaelfolkson>
Global versus local partitions I guess
jonatack has quit [Quit: Client closed]
<michaelfolkson>
Certainly in the Erlay discussions/motivation more connections is seen as a good thing to avoid eclipse attacks and improve tx propagation. Depends if you are interested in that more or privacy more
<michaelfolkson>
You can't really have best practices if there are trade-offs and everyone has different preferences with regards to those trade-offs
jonatack has joined #bitcoin-core-dev
<sipa>
imho those are design decisions, about how things should work by default
<sipa>
you can't assume that people follow best practices, at least not w.r.t your own privacy
Guyver2 has quit [Quit: Going offline, see ya! (www.adiirc.com)]
<sipa>
and certainly can't assume people read documentatiom
<michaelfolkson>
Cool you are contributing to Learning Bitcoin from Command Line
<prayank>
michaelfolkson: that page was last updated in 2016, so I had researched few things from other places and wrote in the table
<sipa>
prayank: i agree, but just telling people not to reuse addresses isn't going to do much; designing software such that not reusing is easier is
<prayank>
+1
<sipa>
that's not to say that documentation is pointless; obvioisly not, it goes a long way towards educating
<michaelfolkson>
prayank: Nice. I'm assuming the I2P site might be a touch biased in favor of I2P too :)
<sipa>
but just that isn't going to cut it
<jonatack>
michaelfolkson: for now there are only a few dozen i2p peers, as sipa mentioned. maybe it depends on your goals, but running dual tor+i2p (or all networks ip/tor/i2p) might be interesting from a robustness standpoint; if one of the privacy networks has issues, like the tor consensus nodes causing network liveness issues last jan and feb, or if
<jonatack>
your i2p router stops working and needs to be restarted, the other may function as a backup.
<earnestly>
nudge theory is quite a horrible technique in practice
Aaronvan_ has joined #bitcoin-core-dev
<michaelfolkson>
jonatack: Right for now that makes sense. Just wondering about long term "winner" and if I2P has long term strengths over Tor
<michaelfolkson>
Don't know if it is winner take all in privacy protocols, perhaps it isn't
<sipa>
in terms of paryition resistance, more networks is just better :)
AaronvanW has quit [Ping timeout: 244 seconds]
bomb-on has quit [Quit: aллилѹіа!]
Aaronvan_ has quit [Remote host closed the connection]
<jonatack>
bitcoind p2p over i2p generally seems to have higher latency (slower), some router reliability issues afaics (at least, with older versions of i2pd or recent versions on some platforms), and some people say it has a history of bugginess. otoh, i do not know if the i2p network sees fewer attacks like what tor v3 saw at the start of this year. at
<jonatack>
any rate it's a little early to run only i2p, but some people began their first experiments trying bitcoin over i2p by running onlynet=i2p (and reported two months for IBD)
<jonatack>
that's only what i see/hear. it might not be accurate :)
AaronvanW has joined #bitcoin-core-dev
<michaelfolkson>
jonatack: Interesting, have you chatted to I2P devs? Presumably having it in Core is a win for them
AaronvanW has quit [Ping timeout: 245 seconds]
<michaelfolkson>
Trusted directory servers (Tor) versus Distributed network database (I2P)
<b10c>
prayank: authors claim they (and the entity launching the attack) can find out the addresses for a node listening on multiple interfaces. eg IPv4, IPv6, Tor and I2P
<b10c>
sipa: based on my understanding, their claims are reasonable. do you agree?
AaronvanW has joined #bitcoin-core-dev
<prayank>
b10c: Interesting. Reading pdf.
<sipa>
b10c: yes, it's a reasonable theory that that's the goal of the attack
<sipa>
and i also believe that they indeed can infer connections to the same node... which is why i'd consider it an attack
AaronvanW has quit [Ping timeout: 245 seconds]
<sipa>
some of the improvements in 22.0 will make this harder (the rate limiting of addr relay etc), but it won't fix it entirely
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 252 seconds]
AaronvanW has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 256 seconds]
<b10c>
sipa: any other, not yet implemented, ways of making similar attacks harder? slight randomness in the addr msg timestamp when relaying or breaking the addr msg fingerprint by replacing IPs with other previously learned IPs if the msg contains >X IPs?
AaronvanW has joined #bitcoin-core-dev
<sipa>
b10c: the real solution, i fear, is having a separate addrman for each network
<b10c>
sipa: hmm. thanks though!
AaronvanW has quit [Ping timeout: 252 seconds]
* b10c
thinking about building more monitoring for these addr attacks (or P2P anomalies in general)
bomb-on has joined #bitcoin-core-dev
<sipa>
b10c: great
sipsorcery has quit [Ping timeout: 252 seconds]
AaronvanW has joined #bitcoin-core-dev
<lightlike>
b10c: did you see https://www.dsn.kastel.kit.edu/bitcoin/index.html by the authors of the paper? the "Churn" graph there (I think their nodes try to connect to every node they get an addr for) went into the roof when the addr spam started
sipsorcery has joined #bitcoin-core-dev
Bullit has quit [Read error: Connection reset by peer]