< bitcoin-git>
bitcoin/master 7cd0a69 fanquake: build: test for __declspec(dllexport) in configure
< bitcoin-git>
bitcoin/master f054a08 fanquake: build: remove AX_GCC_FUNC_ATTRIBUTE test for dllimport
< bitcoin-git>
[bitcoin] laanwj merged pull request #19522: build: fix building libconsensus with reduced exports for Darwin targets (master...libconsensus_visibility_clang) https://github.com/bitcoin/bitcoin/pull/19522
< bitcoin-git>
bitcoin/master fe3e993 Dhruv Mehta: [p2p] No delay in adding fixed seeds if -dnsseed=0 and peers.dat is empty....
< bitcoin-git>
bitcoin/master e9c037b Wladimir J. van der Laan: Merge #19884: p2p: No delay in adding fixed seeds if -dnsseed=0 and peers....
< bitcoin-git>
[bitcoin] laanwj merged pull request #19884: p2p: No delay in adding fixed seeds if -dnsseed=0 and peers.dat is empty (master...no-delay-fixed-peer-seeds) https://github.com/bitcoin/bitcoin/pull/19884
< ariard>
thinking about initial transaction broadcasting, has making our own node "amnesic" already be considered ?
< ariard>
by "amnesic" I mean not logging in the mempool, until it's announced back by some peer
< ariard>
I think it would be a worry rn when you broadcast chain of unconfirmed txns but with the upcoming package testmempoolaccept you might call sendrawtransaction with the whole chain
< ariard>
to assert validity of the parents, but without rebroadcasting them
< ariard>
the advantage would be a privacy gain to mask a transaction origin
< wumpus>
ariard: have you looked at #21061? i think it's a clever way to hide (re)broadcasts in the noise
< wumpus>
instead of specific wallet broadcast we would broadcast anything that seems it should be mined
< ariard>
wumpus: ofc already reviewed the old one
< wumpus>
okay
< ariard>
but I don't think this approach are opposite, you might broadcast a set of transaction
< ariard>
but not log it you mempool when someone query it with a getdata
< ariard>
*those approaches
< ariard>
ah no, that would be a fingerprint compared to the "noise" set of transaction, to not find a owned transaction in the mempool
< wumpus>
i still think in practice broadcasting transactions over tor is the best approach
< ariard>
yes, making one-shot connection over tor/i2p for transaction broadcast might be a really interesting approach
< wumpus>
right—one of the reasons we added -walletbroadcast=0 is to make it possible to do so with an external script (e.g. it was my idea with https://github.com/laanwj/bitcoin-submittx)
< wumpus>
this could tunnel the transaction over anything and would even work if bitcoin core doesn't itself use tor/i2p/etc
< aj>
ariard: aren't you redescribing dandelion?
< wumpus>
of course it could be better automated i never really got around to that
< ariard>
wunpus: yeah I'm back working on altnet, but will start with headers-over-dns as a first integration :)
< ariard>
aj: hmmmm but I'm thinking with all the refactoring around tx-requester and likely the ones around tx-announcement for erlay if we can't rework a lightweight version of dandelion
< aj>
ariard: i think we can totally do that! especially with glozow's tx-package testmempoolaccept stuff
< ariard>
because IIRC the blocker for dandelion was mostly an implementation concern about its DoS robustness
< sdaftuar>
i think hes describing one hop dandelion which should be easy to do
< ariard>
aj: you want to flood "noise" package of transaction to propagate them fast and then fallback on reconciliation for the fluff phase?
< aj>
ariard: do stem phase by making a new i2p/tor connection, sending 1-n tx's with a "testmempoolaccept this, then stem it to a neighbour immediately, then fluff/flood it later" semantics, then closing the connection -- seems like it might be workable to me
< aj>
ariard: fluff/flood being normal tx propogation
< jonasschnelli>
As for adding guix to bitcoinbuilds.org/CI, I would be worried about the consumed time. I haven't measured the time required for a complete guix build. But during a "mergefull" day, it could easly consume the system entierly?
< jonasschnelli>
But there are probably some caching that could be done
< wumpus>
agree caching would definitely be necessary to consider that
< wumpus>
ariard: good to see that again i almost forgot about the altnet proposal!
< wumpus>
(#18988)
< gribble>
https://github.com/bitcoin/bitcoin/issues/18988 | RFC: Introducing AltNet, a pluggable framework for alternative transports by ariard · Pull Request #18988 · bitcoin/bitcoin · GitHub
< bitcoin-git>
[bitcoin] jnewbery opened pull request #21160: Net/Net processing: Move tx inventory into net_processing (master...2021-02-tx-in-peer) https://github.com/bitcoin/bitcoin/pull/21160
< bitcoin-git>
[bitcoin] jnewbery opened pull request #21162: Net Processing: Move RelayTransaction() into PeerManager (master...2021-02-relay-transactions-peer-manager) https://github.com/bitcoin/bitcoin/pull/21162
< aj>
sdaftuar: 21161 above could use your wisdom; i kind of took a hatchet to the code and may have made a mess of things, but hopefully you can make sense of it
< sdaftuar>
oh no fee estimation
< sdaftuar>
ok i will see what i can figure out
< aj>
sdaftuar: hopefully the comments in the PR and issue should make sense at least
< aj>
MarcoFalke: i am loving this vendetta against random test failures btw
< MarcoFalke>
aj: It's been going on for years now, and I am unsure if there is progress, but at least we are trying, heh
< fanquake>
Have to keep development exciting with the occasional “random” failure
< MarcoFalke>
Right. Otherwise, how would we know the re-run button is working in the CI GUI?
< aj>
MarcoFalke: don't the CI systems themselves fail often enough to keep that button well-oiled?
< MarcoFalke>
Cirrus detects if the failure was on the google cloud or in the tests and can re-run itself
< MarcoFalke>
jonasschnelli: DrahtBot caches depends and the gnu store and it takes about the same time as the gitian build
< MarcoFalke>
(mod whenever the guix manifest changes)
< jonatack>
vasild: thanks for checking. i'm thinking of opening an altenative pull that does more (takes a jnewbery feedback to make m_inbound_onion public, does the refactoring we discussed and refactoring to add unit test coverage) and leaving the current pull as-is, for the simpler version
< jonatack>
to see which way is preferred
< vasild>
ok
< jonatack>
as the currently open one is a smaller diff. will update soon (tm)
< sipa>
not much of a topic, but i've been working on adding taproot descriptor support (and, hopefully, signing); hopefully i have something showable next week
< jonatack>
as it were, i've never had a "project" and could be in the market for one (as long as people want to see it done enough to review it)
< bitcoin-git>
[bitcoin] achow101 opened pull request #21166: Pass through SignatureExtractorChecker methods to base (master...fix-sig-extractor-checker) https://github.com/bitcoin/bitcoin/pull/21166
< jonatack>
though i'm fine with continuing to test and review others' projects and helping them move forward
< glozow>
ariard aj: unfamiliar with dandelion but trying to catch up on what was said earlier. you're imagining a dandelion where instead of a stempool, you testmempoolaccept to verify it's correct (you'd need all parents ofc), maybe cache wtxid and some info, and relay? with some probability stem / some probability fluff?
< glozow>
and separate from that, all initial broadcasts with a temporary i2p/tor connection + dandelion if possible?
< bitcoin-git>
[bitcoin] jonatack opened pull request #21167: net: make CNode::m_inbound_onion public, initialize explicitly (master...m_inbound_onion-make-public-and-explicit) https://github.com/bitcoin/bitcoin/pull/21167
< ariard>
glozow: what I'm thinking of is with all the ongoing refactors around tx-relay/mempool it'll be become easier to allocate per-peer dandelion "bandwidth", either to relay solo tx or package
< ariard>
testmempoolaccept can be used to evaluate stuff, which if valid will be cached in a stempoool
< ariard>
and yes doing initial broadcast on a single-shot connection modulo are tor folks going to be happy if we redirect that much traffic on their infra?
< ariard>
and maybe if we start to have this notion of strategic outbound peers with erlay map our stem paths on them?
< sipa>
as far as i know, there are no known solutions to dandelion's dos issues
< ariard>
I think aj point is actually to testmempoolaccet those stem transactions and further you can allocate per-peer resources by limiting their announcements?
< sipa>
that
< sipa>
ah, i haven't seen that
< sipa>
but per-peer resources generally don't work i think, as dandelion has a natural funnel effect (and nodes don't know where in the funnel they are), so if i send to a node a stream of stem transaction equal to the rate limit (and thus occupying all of that node's outbound rate limit as well) i can successfully prevent anyone else from using that node as a router
< sipa>
also, it's really hard to decide what that rate limit should be... the mempool has a natural rate limit because it can assume that transactions relayed through it will confirm and thus pay its fee, you can't make the same assumption about stem transactions (if you receive two conflicting stem transactions from two distinct nodes, you must relay them both, or otherwise you leak the existence of the
< sipa>
first to the second)
< ariard>
yeah I did hit the same limit when I worked on my package relay a while back, it was about caching the package ids to save bandwidth, the solution I thought about was round-robin incoming announcements on the outgoing
< ariard>
but sounds fairly complex I admit
< ariard>
what about a rate limit based on near-confirmation txn?
< sipa>
what does that mean?
< ariard>
I accept your stem transactions only if its feerate is a good candidate for near-inclusion in a block
< ariard>
though an attacker might have broadcast a conflicting transation on the rest of the network
< sipa>
right, but the problem is you have to make that decision independently of any other stem transaction you've seen
< sipa>
so if you have 100 peers, they can all send you distinct conflicting stem transactions... and even if they're all individually good feerate, only one will confirm
< ariard>
"you must relay them both, or otherwise you leak the exsitence of the first to the second" can you silently drop one or at least inobservable what's your relay decision was?
< sipa>
if the transaction was unique, the sender can easily see that you never relayed theirs to the network
< ariard>
*at least make inobservable
< sipa>
but just observing it not appearing
< sipa>
*by
< ariard>
if you have a multi hop stem path, the drop might have happen anywhere on the path?
< ariard>
and we assume the stem path to be unknown to the initial-broadcaster?
< sipa>
yeah, perhaps
< sipa>
it feels icky,
< ariard>
yeah I agree it's complex
< sipa>
like the obvious solution is to give each node their own separate stempool, which is kept consistent with the real mempool, but not consistent with other stempools
< sipa>
but that's obviously terrible for resource usage
< ariard>
you just dup the mempool?
< sipa>
well, the mempool is shared in this model
< sipa>
but the stempools are all distinct
< ariard>
also about conflicting transactions if we care about masking transaction origin, it's up to the utxo owner to not produce conflicting transactions
< sipa>
oh sure
< sipa>
but we also have to make sure conflicting transactions don't result in connection graph leaks
< sipa>
which is another form of privacy
< sipa>
(or at least, don't worsen it significantly; it's hard to make any guarantees about it in the first place0
< ariard>
what do you mean by connection graph ? your topology of tx-relay peers?
< sipa>
yeah
< sipa>
the ability to infer two peers of yours are connected, for example
< ariard>
yeah sadly I think on that point it's more about not making it worst