AaronvanW has quit [Remote host closed the connection]
luke-jr has quit [Ping timeout: 240 seconds]
jessebarton has joined #bitcoin-core-dev
luke-jr has joined #bitcoin-core-dev
earnestly has quit [Ping timeout: 240 seconds]
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 252 seconds]
lukedashjr has quit [Ping timeout: 240 seconds]
luke-jr has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 240 seconds]
AaronvanW has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #22739: doc: link to managing-wallets from docs README (master...link_managing_wallets) https://github.com/bitcoin/bitcoin/pull/22739
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<prayank>
Interesting. Thanks for the link. Will try it today.
sipsorcery has quit [Remote host closed the connection]
sipsorcery has joined #bitcoin-core-dev
goatpig has quit [Quit: Konversation terminated!]
<sipa>
but even if that doesn't suffice, there isn't much need for this functionality to be in bitcoin core - it doesn't need an actual node
<prayank>
It doesn't need an actual node? Didn't understand this
<sipa>
the thing sending the transaction doesn't need a node
<sipa>
so it's restrictive to build it into bitcoin core; it's more usable if it's something external
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke closed pull request #20362: test: Implicitly sync after generate* to preempt races and intermittent test failures (master...2011-noSync) https://github.com/bitcoin/bitcoin/pull/20362
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<prayank>
If you are using a node it will broadcast transactions. If it is not using Tor/i2p which most of the nodes do, your peers can keep an eye on your transactions. Let's assume every time I launch Bitcoin Core it connects with 3 spy nodes. This functionality can improve privacy by making it difficult for spy nodes to follow specific pattern. But I agree few things are best when added as plugins. Unfortunately we don't have plugins in Core.
maria_elis has quit [Ping timeout: 248 seconds]
iramaro has quit [Ping timeout: 252 seconds]
<laanwj>
if you know what peer you want to send the transaction to, submittx does exactly what you want
<prayank>
Cool. Will be experimenting with it in next few hours.
<sipa>
prayank: yes, if you have a node, it will broadcast transactions for you, that's one of its functions - but other software can send transactions too
<laanwj>
it supports tor and other socks5-ish proxies, it will not connect to any peers you don't specify
iramaro has joined #bitcoin-core-dev
<laanwj>
i can't think of any reason why a "plugin" would be better here, as a separate program it's self-contained, and can be run in a different execution context, IIRC it requires nothing special, it will run on any VM with any kind of python3 installed
<laanwj>
information leakage is kept to a minimum, too, with an extra P2P connection in bitcoin core there's always the risk of some fingerprinting vector we don't yet know of, for example
lkqwejhhgasdjhgn has joined #bitcoin-core-dev
lukedashjr has joined #bitcoin-core-dev
luke-jr has quit [Ping timeout: 268 seconds]
lukedashjr is now known as luke-jr
RDK has quit [Remote host closed the connection]
RDK has joined #bitcoin-core-dev
goatpig has joined #bitcoin-core-dev
AaronvanW has quit [Ping timeout: 240 seconds]
Chris_Stewart_5 has joined #bitcoin-core-dev
<Chris_Stewart_5>
Is it possible to configure bitcoind such that
<Chris_Stewart_5>
1. It allows inbound connections, 2. Doesn't gossip the peer address across the bitcoin network
<Chris_Stewart_5>
The goal is to only allow users with the ip address to connect via p2p. The motivation for this is there is like 0 blockfilter nodes on the network, and connections get saturated with normal full nodes AFAICT rather than blockfilter clients
AaronvanW has joined #bitcoin-core-dev
<ariard>
#proposemeetingtopic coredev updates :)
<jnewbery>
Chris_Steward_5: not that I can think of. The -listen argument toggles a global fListen flag, which controls both whether we start accepting incoming connections *and* whether we self-advertise our local address
<laanwj>
only inbound connections can be done using -noconnect, i don't know if there is a way to disable gossip
<jonatack>
Chris_Stewart_5: would the section in doc/tor.md "Manually create a Bitcoin Core onion service" do what you want? e.g.
Guest45 has joined #bitcoin-core-dev
<jonatack>
-externalip= ... -bind= ... (if you are running a hidden service)
<jonatack>
(i run a blockfilter node :)
<Chris_Stewart_5>
jonatack: That might be work, but unfortunately this is needed on a short time line so I don't have time to research. Thanks for the suggestion tho :-)
<Chris_Stewart_5>
jnewbery: Thanks for the answer, it could be a useful feature in the future perhaps :man_shrugging:
<laanwj>
with -externalip you can override the IPs that are gossiped, i'm not sure you can set it to not gossip any at all
<laanwj>
-noexternalip would be interesting
<laanwj>
it might work to provide a non-gossip address e.g. -externalip=127.0.0.1
<laanwj>
but if it works that's quite an ugly hack
RDK has quit [Quit: Leaving]
<jonatack>
it's been on my list to review + play around with -externalip more (and maybe improve its help in src/init.cpp, which doesn't have the externalip info in doc/tor.md)
<prayank>
laanwj: let me know if my understanding of this tool is correct. I think this tool takes a signed transaction hex and few node addresses as input, broadcasts the tx and disconnect?
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Guest45 has quit [Ping timeout: 246 seconds]
<prayank>
Thanks. I think this will be helpful. Although I might add few things in it or maybe create similar project using other language. It should connect with a list of peers, then broadcast tx to a subset of this list and remain connected with all peers until users closes it manually.
<laanwj>
keeping it connected should be pretty straightforward
<laanwj>
i don't see why to stay connected though, it's just wasting connection slots
<laanwj>
i should probably merge the outstanding PRs as well (sorry achow101)
<ariard>
achow101: yeah a negative covid test is pretty the norm for any cross-border travel those days
<gleb7>
that was also my experienw
<ariard>
achow101: i expect tests to be pretty available in zurich?
<sipa>
i can't imagine that that would be a problem
<sipa>
that would be very hard i think
<luke-jr>
michaelfolkson: if it were possible, it'd make more sense for everyone to tele
<michaelfolkson>
I guess...
<sipa>
coredev isn't really organized... lots of just random people starting a conversation
<luke-jr>
but the point of in person is that it's in person
<michaelfolkson>
Ok
<luke-jr>
(and the benefits you get from that)
<gleb7>
I think we should ask aus people of what they think they could use from the meeting, based on the previous experience and their personal view of productivity.
<jonatack>
michaelfolkson: i've never attended coredev, but i imagine previously holding some of them (roughly one in three?) in tokyo helped with this
<luke-jr>
(also reminder that not only aus/nz are isolating)
<michaelfolkson>
Right, those are examples I know of
<ariard>
Yeah I'll reach out to aussies if they have topics to propose
<ariard>
And last thing, if you wanna to stay for the weekend feel free to do so, few people were willingly to do outdoor activities/team building :)
<ariard>
voila voila, the following on signal
<laanwj>
thanks for the update ariard
<laanwj>
#topic Erlay update (gleb7)
<core-meetingbot>
topic: Erlay update (gleb7)
<jarolrod>
thanks for the update!
<gleb7>
Okay so to move forward with erlay I created 2 meta-issues in my repo. I want to use them for discussion, as I need some help at this point.
<gleb7>
First, there is an issue describing all the stuff going on with transaction announcement bandwidth.
<michaelfolkson>
Chasing concept? :)
<gleb7>
After protocol change we agreed on with greg and peter lately, the overall node saving is probably gonna be about 15-30% bandwidth...
<gleb7>
So for example I wanna hear that we are willing to add complexity and that's justified by the gain.
<sipa>
gleb7: how much was it before?
<gleb7>
sipa: i claimed to save up to 50% in the paper (for 8 conns)
<sipa>
but higher numbers with more connections, i assume?
<gleb7>
yes indeed
<sipa>
because that's the real justification - having sublinear bandwidth growth as the number of connections increases
<gleb7>
I was thinking about that as well... Connectivity increase doesn't necessarily mean tx relay over them, right?
<gleb7>
Relaying txs over more links is good too (for compact blocks, for privacy potentially)
<sipa>
block-only connections are an obvious way of increasing connectivity without increasing bandwidth (much)
<sipa>
but ideally, with erlay you should be able to get nearly the same
<gleb7>
that holds.
<gleb7>
Also, there is a bandwidth/latency trade-off again. A bit slower relay gives better bandwidth savings. That's also to re-discuss probably.