<instagibbs>
achow101 would like to bring up a couple PRs to attention, since there's been some concept drift, and I think at least one can make it into 28.0 along with 1P1C relay.
<instagibbs>
(not sure if this is the right slot)
<achow101>
instagibbs: go ahead
<instagibbs>
#30352 this is a new output type called Pay To Anchor
<instagibbs>
made standard to spend, to be used in an anchor pattern.
<instagibbs>
This does not include the ability to make dust, which
<instagibbs>
is now a separate feature I'm calling Ephemeral Dust.
<gribble>
https://github.com/bitcoin/bitcoin/issues/30352 | policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending by instagibbs · Pull Request #30352 · bitcoin/bitcoin · GitHub
<instagibbs>
#30239 is Ephemeral Dust, which leverages TRUC to allow dust that is spent in the same transaction package. With 1P1C relay in place, this should allow simpler smart contracts to be created.
<achow101>
prehaps #30352 to chasing comcept ack then?
<gribble>
https://github.com/bitcoin/bitcoin/issues/30352 | policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending by instagibbs · Pull Request #30352 · bitcoin/bitcoin · GitHub
<instagibbs>
It's got some concept ACKs(and rocket emojis), it's not a new idea, but if you like yeah
<Sjors[m]1>
hi
<achow101>
glozow: i'll add it to the milestone
<achow101>
also, 28.0 feature freeze is 4 weeks
<achow101>
Any other topics to discuss?
<sipa>
i'd like to see #28280 make it in, and it's getting close i think
<achow101>
sipa: yeah, i've been looking at that too
<lightlike>
Was also planning to review that again
<fjahr>
Review begs #29519 and #30320 so we can get mainnet assumeutxo
<gribble>
https://github.com/bitcoin/bitcoin/issues/29519 | p2p: For assumeutxo, download snapshot chain before background chain by mzumsande · Pull Request #29519 · bitcoin/bitcoin · GitHub
<gribble>
https://github.com/bitcoin/bitcoin/issues/30320 | assumeutxo: Dont load a snapshot if its not in the best header chain by mzumsande · Pull Request #30320 · bitcoin/bitcoin · GitHub
<achow101>
#endmeeting
Emc99 has quit [Quit: Client closed]
<pinheadmz>
Sjors[m]1 wanna chat about abstract connman for stratum and http servers?
<cfields>
instagibbs: re 30352 I followed a maze back to a dead link for an ephemeral anchors bip. Is there a current one?
<Sjors[m]1>
pinheadmz: sure, that would be useful.
<instagibbs>
cfields I killed off the BIP because it just became very implementation-specific. Would a slightly longer description of how the two PRs link together help on a gist/PR?
andrewtoth_ has joined #bitcoin-core-dev
<cfields>
instagibbs: more like a very high-level description for someone who's not familiar with your policy goals but is interested in reviewing the code for sanity :)
<instagibbs>
I'll take that as a hint to rewrite the OP. Will do.
<pinheadmz>
Sjors[m]1 sorry, distracted. ok. so, seems like a big refactor of conman, and like, itd need an abstract client that can tell us if that client needs to read or write so we can compare with WaitMany
<Sjors[m]1>
pinheadmz: what seems a big refactor? Your WIP?
puchka has quit [Ping timeout: 272 seconds]
<Sjors[m]1>
For #30332 I need something much simpler than all of connman, so I can avoid copy-pasting the socket handling stuff.
<pinheadmz>
yeah just running a server without libevent. theres a loop that accepts connections, checks sockets for readiness, and sends or receives messages depending on whats ready.
<pinheadmz>
connman does that and i copy pasted much of that into a http server as well
<Sjors[m]1>
Indeed
<Sjors[m]1>
Right, so we both have a shared interest in less copy-paste.
<Sjors[m]1>
Are you just doing this for REST or also RPC?
<pinheadmz>
both yeah
<pinheadmz>
so yeah what i meant by refactor is pulling out of connman something generic and reusable
<cfields>
Mmm, I probably should've asked during the meeting...
<cfields>
I've just written up a plan for the next few weeks for cmake. (review beg starts next week, which is why I didn't bring it up this week). But I do think it makes sense to start sketching out a plan/roadmap to begin setting expectations...
<cfields>
achow101: Would it make sense to go ahead and setup a CMake project on github?
puchka has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
mcey has quit [Ping timeout: 255 seconds]
kevkevin has joined #bitcoin-core-dev
RaphaelH has joined #bitcoin-core-dev
mcey has joined #bitcoin-core-dev
mcey_ has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 252 seconds]
preimage has joined #bitcoin-core-dev
RaphaelH has quit [Changing host]
RaphaelH has joined #bitcoin-core-dev
Guest82 has joined #bitcoin-core-dev
Guest82 has quit [Client Quit]
<RaphaelH>
Hello, I am currently studying bitcoin core network protocol and I was wondering how the 1000 addresses in ADDR message (responding to a GETADDR) were chosen among the new/tried tables. I have looked at the codebase but I don't really understand where this is done nor have I found documentation/a wiki. Does anyone have helping ressources please?
<lightlike>
RaphaelH: They are chosen randomly, we don't care about maintaining some specific new/tried ratio at all.
<lightlike>
since nodes often have more new entries than tried ones (especially when they haven't been running for months), this can result in pretty low-quality getaddr responses, so there have been ideas to change that. On the other hand, we wouldn't want to reveal our tried table to other peers due to eclipse attacks, so it's not completely trivial.
<RaphaelH>
lightlike sipa Thanks a lot for your answers. Do you also know what happen when two different clients both send a GETADDR to a client (in a short period of time), do they both get the same answer or do the "random choice" change at some point?
<lightlike>
RaphaelH: all nodes (from a given network such as IPv4) get the same cached answer within 24h. This caching was introduced a couple years ago to prevent probing.
<RaphaelH>
lightlike Ok thanks a lot, I'm starting to understand. Also, I'm not sure I understand the "from a given network" part, is it possible to get two differents results depending if the nodes are in the IPv4/IPv6 network? I thought the address were always sent in IPv6 format
emcy__ has quit [Ping timeout: 265 seconds]
mcey has joined #bitcoin-core-dev
instagibbs has quit [Server closed connection]
mcey_ has joined #bitcoin-core-dev
instagibbs has joined #bitcoin-core-dev
mcey has quit [Ping timeout: 255 seconds]
kvaciral[m]1 has quit [Server closed connection]
kvaciral[m]1 has joined #bitcoin-core-dev
mcey_ has quit [Ping timeout: 255 seconds]
dermoth has quit [Server closed connection]
dermoth has joined #bitcoin-core-dev
RaphaelH has quit [Quit: Client closed]
<lightlike>
RaphaelH: it means that you send a peer connected to you via tor a different cached addr message than another peer connected to you via IPv4. That makes it harder for others to fingerprint you (connecting your tor with your ipv4 identity).
Talkless has quit [Remote host closed the connection]
_andrewtoth_ has joined #bitcoin-core-dev
kevkevin has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 276 seconds]
kevkevin has joined #bitcoin-core-dev
kevkevin has quit [Ping timeout: 260 seconds]
<harding>
Is there an appropriate resource within the project (e.g. issue to bitcoin/bitcoin, a bitcoin-core/ repo, the bitcoin-dev mailing list) to discuss non-security-sensitive matters relating to the security@bitcoincore mailing list?
<achow101>
harding: possibly bitcoin-core/meta? we're currently only using that for moderation related things, but in theory, it could be a general "meta topics" repo