< bitcoin-git>
bitcoin/master 84f3939 Pieter Wuille: Remove support for subdescriptors expanding to multiple scripts
< bitcoin-git>
bitcoin/master a917478 Pieter Wuille: refactor: move population of out.scripts from ExpandHelper to MakeScripts
< bitcoin-git>
bitcoin/master 4441c6f Pieter Wuille: Make DescriptorImpl support multiple subscripts
< bitcoin-git>
[bitcoin] laanwj merged pull request #21238: A few descriptor improvements to prepare for Taproot support (master...202102_descriptor_prepare_taproot) https://github.com/bitcoin/bitcoin/pull/21238
< MarcoFalke>
looks like ci is red
< MarcoFalke>
There was a silent merge conflict
< MarcoFalke>
script/descriptor.cpp:498:16: error: parameter 'script' not found in the function declaration [-Werror,-Wdocumentation]
< wumpus>
strange, i did build locally
< MarcoFalke>
Maybe Wdoc only works on a specific compiler?
< MarcoFalke>
wumpus: Obviously not blaming you. It is impossible to find all silent merge conflicts.
< wumpus>
my compiler (clang 13) does accept the flag, no idea if it does anything with it
< wumpus>
right it's just that i try to be careful to avoid them by always running the build + tests locally, but definitely cannot do so for every platform / compiler combo
< wumpus>
anyhow i'll do a PR...
< bitcoin-git>
[bitcoin] laanwj opened pull request #21736: doc: Fix doxygen comment silent merge conflict in descriptor.cpp (master...2021-04-parameter-documentation) https://github.com/bitcoin/bitcoin/pull/21736
< wumpus>
it looks like my compiler does have the warning enabled, it is just not fatal, i've had bad experiences with Werror in the past (due to divergence between compiler versions) but will try enabling --enable-suppress-external-warnings --enable-werror locally maybe it is better now
< aj>
wumpus: those options work for me fwiw
< wumpus>
aj: i don't doubt they work :) the problem is that the set of warnings very much differs between compilers, it is often that new gcc has some new warnings
< wumpus>
or clang for that matter (thinking of the locking annotation warnings)
< aj>
wumpus: yep
< wumpus>
so it is not a guarantee in any case, there might be local failures due to this that do not arise in the CI and the other way around
< aj>
wumpus i took the release cadence date stuff to be referring to 23.0 not 22.0 fwiw
< wumpus>
let's discuss that at the time we are planning the 23.0 date then, that will only be after the 22.0 release
< aj>
wumpus: yeah
< wumpus>
definitely agree with the principle that planning a release around xmas is a bad idea
< wumpus>
december tends to be a really quiet month in bitcoin dev
< MarcoFalke>
yeah, it might be good to aim for October (or earlier) as a release month, as November might often delay into December
< MarcoFalke>
Also branch-off right at the start of the new year might not be good either. Better wait till February (or later) to give reviewers some time to make up for the lack of review during December
< wumpus>
october seems really early for 0.23?
< wumpus>
or do you mean for 22, that doesn't make sense to me either (postpone it by two months?)
< MarcoFalke>
Could aim for February 2022?
< MarcoFalke>
No need to change the 0.22 timeline
< MarcoFalke>
I think that is already set pretty much
< wumpus>
feb for 0.23 that would make sense (but as said, let's discuss 0.23 timeline when we get there)
< MarcoFalke>
sure, just wanted to mention that 0.22+6 months collides with December ;)
< fanquake>
yea -Wdocumentation requires --enable-suppress-external-warnings to be enabled
< MarcoFalke>
reset all failed ci builds from the last two hours
< wumpus>
harding: your taproot activation write-up seems very clear to me, i'll leave it on the wiki for a few days so people can make corrections if they think that is necessary, then add it to the release notes on the 0.21 branch
< bitcoin-git>
[bitcoin] hebasto closed pull request #19213: util: Get rid of RecursiveMutex in Get{Blocks,Data}Dir (master...200608-path-mx) https://github.com/bitcoin/bitcoin/pull/19213
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #21738: test: Use clang-12 for ASAN, Add missing suppression (master...2104-asan) https://github.com/bitcoin/bitcoin/pull/21738
< ShapeShifter499>
so I have a question about the client. I'm on linux and I'm wondering does it matter what Berkeley Database Bitcoin is compiled against if I want to recover old wallets?
< wumpus>
hebasto: sorry for only noticing this now in #21694 btw while i commented on the gitignore before :)
< gribble>
https://github.com/bitcoin/bitcoin/issues/21694 | build: Use XLIFF file to provide more context to Transifex translators by hebasto · Pull Request #21694 · bitcoin/bitcoin · GitHub
< hebasto>
wumpus: does this mean that src/qt/locale/bitcoin_en.xlf should be a part of the repo?
< wumpus>
hebasto: if it is what you want transifex to read, yes
< wumpus>
thanks for making me check, it is not good if it keeps updating from master and the translations diverge
< hebasto>
wumpus: nice that everything is ok now
< wumpus>
btw; do we still need bitcoin_en.ts *at all* now? i think its only goal was to provide it to transifex? or is it used for other things as well?
< wumpus>
hmm i guess it is embedded in the binary but is effectively a no-op]
< hebasto>
is it used to generate `bitcoin_en.qm` for `QObject::tr()`?
< hebasto>
yes. in en_US locale it is no-op :)
< wumpus>
that seems a very useless thing to do :) but sure it might anyway
< wumpus>
but yeah, let's leave it like that for this PR, no need to touch that
< hebasto>
ok
< wumpus>
i hope we'll still get .ts translations back from transifex with tx pull
< hebasto>
we'll find out :)
< wumpus>
if not the maintainer-tools/update-translations.py script will need to convert too
< wumpus>
we'll find out for 22.0 i suppose (no good reason to backport this)
< bitcoin-git>
bitcoin/master 99686b6 Hennadii Stepanov: qt [experimental]: Add a translation comment and a disambiguation string
< bitcoin-git>
[bitcoin] laanwj merged pull request #21694: build: Use XLIFF file to provide more context to Transifex translators (master...210415-xliff) https://github.com/bitcoin/bitcoin/pull/21694
< wumpus>
btw we might want to do future translation-related changes in the gui repository
< hebasto>
because they will touch the qt/ directory only?
< wumpus>
yes, and because translation is only done for the GUI
< wumpus>
i guess the exception is messages from bitcoind that get translated as well, but i mean changes that only affect src/qt sources yes
< hebasto>
#21463, for example, is mixed qt and non-qt
< jeremyrubin>
Would anyone be opposed to adding an address type for OP_RETURN?
< jeremyrubin>
I don't think they should be universally available, but it can be kind of annoying working in generic code that you can't get an address for an OP_RETURN output
< jeremyrubin>
I guess this is better suited for mailing list...
< luke-jr>
addresses define a recipient. OP_RETURN doesn't have a recipient.
< jeremyrubin>
then why can I pay a P2SH OP_RETURN and that has an address?
< luke-jr>
furthermore, OP_RETURN should not be used except to represent something else more specific; that something else perhaps might need an address, which would then be impeded by a generic OP_RETURN address by folks who think there should only be one possible address per script
< luke-jr>
there is no such thign as a P2SH OP_RETURN
< jeremyrubin>
Howso?
< jeremyrubin>
i can create a p2sh op_return quite easily
< luke-jr>
OP_RETURN as a transaction type is defined as a scriptPK that begins with OP_RETURN
< jeremyrubin>
That's beside the point
< jeremyrubin>
[4/20/21 08:13] <luke-jr> addresses define a recipient. OP_RETURN doesn't have a recipient.
< luke-jr>
you can't prove on-chain that a P2SH contains an OP_RETURN, and such an output will enter the database
< belcher>
you could create it but why would you? op_return is used for embedding data but if that data is hashed behind a p2sh then it cant even do that(?)
< luke-jr>
belcher: it's supposed to only be used for embedding hashes; one extra layer doesn't impede that
< luke-jr>
but the P2SH does impede being able to prune it
< jeremyrubin>
i'm less worried about the pay-to support, more worried about the parsing of data generically
< pinheadmz>
jeremyrubin could propose to define a segwit version `16` (for example) that decodes to <OP_RETURN> <data>
< luke-jr>
and prunability is what distinguishes OP_RETURN from other unspendable outputs
< luke-jr>
jeremyrubin: it sounds like your undefined use case really ought to use raw scripts, not addresses
< jeremyrubin>
not really
< jeremyrubin>
I want to split out "is this something we know about" or "is this some custom thing entirely"
< luke-jr>
there's no distinction in this case
< luke-jr>
OP_RETURN is some custom thing entirely
< jeremyrubin>
Every p2sh is also some custom thing
< jeremyrubin>
because a p2sh can contain an OP_RETURN <blah>
< luke-jr>
beside the point
< jeremyrubin>
That is the point
< luke-jr>
anyway, I think I've gone over the reasons not to do it afaik.
< jeremyrubin>
If i can try to explain it back...
< jeremyrubin>
We should only have addresses or descriptors for things we know exactly what they are, and also for things that represent something that is not only payable but also potentially spendable.
< jeremyrubin>
OP_RETURN, being unspendable and usually proprietary in purpose, should not have an address
< jeremyrubin>
Is that a correct restatement of your concern?
< amiti>
I've mentioned it in a few different places, but I'll start with an overview of goals & motivation
< amiti>
The goal is to reduce addr blackholes- aka relaying self advertisements to peers who are unlikely to continue relaying it to the network. Doing so would be a standalone improvement for addr propagation, and also, in my opinion, help with the disabletx project.
< amiti>
The PR serves as a proof of concept for how this can be implemented in Bitcoin Core, but is currently in a draft because I have been trying to build confidence that this wouldn’t harm other software on the network.
< amiti>
looks like almost all other clients are definitely ok. the only one I was very confused about is bitcore, so I'm hoping someone will respond to the issue I opened
< amiti>
so, my main question for today is- do people think its reasonable for me to move forward with these changes? aka bring the PR into a "ready for review" state ?
< ariard>
does it document bitcoinj, it's still maintained afaik?
< gleb>
It looks like the stuff I attempted to do around a year ago, and at the time I also concluded it won't hurt other software.
< amiti>
bitcoinj is not on the list. will look & add
< gleb>
The PR is only covers a subset of stuff I was suggesting
< gleb>
I'll take a look and probably close mine, in case your work auguments it.
< amiti>
cool, I'll check it out
< sipa>
amiti: where did you land on sending/nonsending to non-relay peers? i remember you had some comments for sdaftuar_
< sipa>
*from
< jnewbery>
gleb: your PR disables addr relay based on the service bits sent by the peer. amiti's enables addr relay based on previous addr/getaddr messages received from the peer
< amiti>
I'm still exploring the approach of not sending to non-relay peers
< amiti>
sdaftuar expressed concern that if there is other software that doesn't send addr/getaddr messages but are relying on addr messages to discover peers, this change could make them vulnerable to a poor addrman / eclipse attacks
< sipa>
but that's what the PR does?
< amiti>
sipa: what?
< lightlike>
I think an important difference is that the new PR would prevent sending to peers for whom we are their block-relay-only peer.
< sipa>
amiti: not announcing to (assumed to be) non-relaying peers
< amiti>
sipa: correct
< amiti>
sipa: sorry, I don't understand your question
< sipa>
amiti: just wanted to make sure i was up to date on the approach
< amiti>
some context for the group: an alternative approach would be to identify "potential blackholes" and then add redundancy if those are selected. eg if you intend to relay to 2 peers but select a "potential blackhole", additionally relay to another peer
< sipa>
jnewbery: an alternative approach would be still sending addr messages to everyone, but treat some subset as non-relaying (and thus not counting towards the 1 or 2 relay slots)
< jnewbery>
sipa: ah. Got it. Thanks
< sipa>
jnewbery: which would less risky for the network, but in my opinion weakly exploitable
< jnewbery>
'for the network' seems vague
< sipa>
if we're confident this won't break anything, the current approach has my preference
< amiti>
that is also my preference :)
< jnewbery>
it'd be less risky for peers that want to receive addrs but don't ask for addrs, or am I missing some transitive behaviour?
< sipa>
jnewbery: software that doesn't getaddr or send addrs, but still relies on receiving addresses
< sipa>
jnewbery: i don't expect such software to exist, but it's also hard to be certain
< jnewbery>
sipa: yep, that's my understanding
< amiti>
I don't see much indication we will break things. I'll check bitcoinj and hope to hear back from bitcore, but beyond that I don't think there's much else I can do from my end
< ariard>
at least ml + libraries inquiry let's build confidence, do we have other methods to improve such opinion?
< sipa>
no, there is only so much we can do
< jnewbery>
Great. Anything else on that, or shall we move to next topic?
< amiti>
just to conclude -
< amiti>
I'll continue moving forward. if anyone has outstanding concerns, please let me know :)
< amiti>
thanks!
< jnewbery>
amiti: great. Thank you!
< jnewbery>
#topic Moving forward with asmap (gleb)
< core-meetingbot>
topic: Moving forward with asmap (gleb)
< gleb>
We (me and sipa) want to move asmap forward and the main question is how to enable it by default. So far one priority is to help the maintainer to keep track of the BGP topology state updates.
< gleb>
Basically, the maintainer would have to re-generate the compressed BGP topology map (asmap) for distribution and make sure it’s valid.
< gleb>
There’s also testing of the existing tools and code in the Core, feel free to help:
< gleb>
Once these tools are ready and stable, we will be able to enable it by default I think. Let me know if you have any thoughts or suggestions for other TODO to make progress here, otherwise I’m done.
< ariard>
Who is maintainer here ? bitcoin core or asmap tooling one?
< gleb>
Bitcoin Core maintainers, every core release probably should get a new asmap file
< gleb>
To maintain the best p2p robustness of the nodes.
< jeremyrubin>
hi
< sipa>
one critical component i think is tooling to produce human-readable diffs between asmap files
< sipa>
because they can't be deterministically produced
< gleb>
Yeah, everyone should be able to check the diff between the two easily.
< ariard>
so it's about finishing asmap-rs as a functional bitcoin-asmap ?
< gleb>
I think sipa still doesn't like rust, so we might end up using smething different...
< gleb>
But basically yes, improving the tools.
< ariard>
i think language choice is ultimately decided by who is maintaining the tool :p
< sipa>
i certainly don't mind having good tooling in another language than one i'm familiar with, if it"s maintained
< gleb>
I think I can commit to maintaining asmap-rs, but then, should we also translate sipa/asmap (compression part) into it?
< gleb>
No need to answer now, I'll think about it after the meeting.
< ariard>
gleb: nah you can link *.c/*.cpp in rust, we can talk about it in rust-bitcoin if you wanna
< gleb>
alright, i'll check how nasty that is :)
< jnewbery>
ariard: I don't think that's the problem. The question seems to be whether we should add some dependency on maintaining a rust tool to our release process.
< sipa>
the only thing we neef reusable or usable from within Bitcoin Core is decoding/querying support, and we have that
< sipa>
sure, it'd be nice if some tool shipped with core and possibly built from shared sources could do encoding too and other things, but i don't think that's a critical requirement
< ariard>
jnewbery: yes as i'm planning to have rust dependency for altnet, if you think that's a real issue to have dependency in rust, let's have a discussion during main meeting?
< ariard>
i think it was a subject a year ago
< sipa>
those things just need to be available and usable
< jnewbery>
ok, anything else on this topic, or move on?
< gleb>
i think we can move on
< sipa>
yeah
< jnewbery>
#topic irc meetings on better L2s onchain support (ariard)
< core-meetingbot>
topic: irc meetings on better L2s onchain support (ariard)
< ariard>
hi!
< ariard>
it has been a recurring topic among LN devs how to improve second-layer protocol layer by the base layer
< glozow>
hi
< ariard>
as current tx-relay and fee-bumping aren't really accurate
< ariard>
we have the idea last year to do a share meeting between ln/core dev in 2021, but it doesn't seem it's going to be a thing even this year
< ariard>
so instead, i'm working on setting up a bunch of irc meeting to talk about stuff like dust, full-rbf, package relay, standardness, coordinated security disclosures
< ariard>
and will do an announcement on the ml latter this week about process
< ariard>
feel free to contribute if you're interested by those topics :)
< gleb>
ariard: i think to motivate people to come, you (or any coordinator) should be really clear on how this is going to be useful, what are the possible useful outcomes, and why this stuff is blocker for L2 protocols.
< sipa>
i think it would be useful if this was more concrete
< ariard>
gleb: yes how this is going to be useful is described in threats/ performance/ section of new repo, possible useful outcomes are changes like full-rbf or package-relay
< ariard>
but sure we'll make this really clear in ml post
< glozow>
i'd be interested in seeing some simulations of attacks
< sipa>
people (ariard in particular) oftrn brings up issues of unreliability or certain lack of guarantees offered by the p2p protocol and its current implementations, but it's hard to discuss thst in general as there simply can't be any guarantees really, and other layers need to be aware of that... bit that doesn't mean we can't have useful discussions about specific features or so
< ariard>
glozow: yes we can try them on signet or mainet, main issue is having a realistic mempool, with sudden spikes
< sipa>
so it would be much more interesting to me at least to discuss specific features or proposals for the p2p protocol
< ariard>
sipa: i know this non-reliability point would be the starter point for such irc meetings
< sipa>
rather than "fee bumping is insufficient"
< ariard>
like there is quite a divide among L1 and L2 devs, and afaik matt or rusty I'm leaning toward more reliability expectations
< ariard>
sipa: ultimately if we release something like package relay we have a question on the L2-side, is how much stability we can expect of such mechanism
< sipa>
ariard: yeah the vbyte thing wasn't done as well as it could have been
< sipa>
ariard: you can't expect transactions to be relayed, period
< sipa>
they're likely to be, and we can discuss what will work in non-adverserial settings likely
< ariard>
sipa: i agree, the best you can hope is an economic compatible tx-relay policy widely deployed on the network like bip125
< sipa>
i'm afraid that economic compatibility is very hard without something like partial blocks
< sipa>
because network bandwidth costs are ultimately in contradiction with always relaying the economically optimal final state
< ariard>
sipa: by stability I didn't mean "every-full-node on the network must support it" more Core devs are not going to deprecate future or introduce api change break without some release process
< ariard>
sipa: i don't know about partial blocks?
< sipa>
oh, certainly
< glozow>
er, what does economic compatible tx relay mean?
< sipa>
glozow: say a tx is bumped by 1 satoshi in fee
< ariard>
glozow: let's define better as incentive-compatible, apply this policy will increase your mempool feerate
< sipa>
it won't get relayed by bitcoin core, because it's below the marginal feerate (the cost of relaying over the network is considered larger than what it's paying extra
< jnewbery>
ariard: I don't think that's even it. incentive-compatible would mean that this policy increases the total fee of the top block's worth of transactions in your mempool
< sipa>
glozow: but it is economically still better for miners to get that transaction; miner want it, but the network has no incentive to relay it
< sipa>
that's a conflict, and the only general solution for it i know of is partial blocks
< ariard>
jnewbery: i think accepting higher-feerate replacement transaction increase the odds to mine a higher fee block in the future?
< amiti>
what is the goal from today's discussion?
< sipa>
where miners broadcast partial solutions to PoW over the network (say at 1/10th the difficulty) to prove to the network "there is likely a significant portion of PoW working on this block"
< sipa>
that would provide a natural incentive to switch mempools to the contents of such a blocm
< glozow>
sipa: i see, thank you
< jnewbery>
ariard: that's not incentive compatible for a miner. They only care about the contents of the next block.
< ariard>
amiti: getting the feedbacks of folks here if they would like to participate to such meetings, once we have a clear scope :)
< glozow>
oh cool, similar to like mining pool partial solutions for reward shares
< jnewbery>
ariard: when are you planning to do this irc meeting?
< glozow>
like broadcasting "this is the block i'm working on" before finding the solution
< sipa>
glozow: indeed
< ariard>
jnewbery: depends of your miner model? even if they loss the race to mine next block, they are still willingly to optimize fee of following blocks
< jnewbery>
any final topics before we wrap up?
< ariard>
jnewbery: end of may/june
< jnewbery>
ariard: thanks!
< ariard>
i'm done, thanks for your feedbacks :)
< sipa>
glozow: and partial PoW means a natural rate limit for such partial blovks
< glozow>
ariard: I'm interested in such a meeting if you're able to coordinate a time
< glozow>
apart from that, I'll keep an eye on the docs in your repo, and am interested in turning some of them into functional tests or simulations for a more concrete measure of the attacks
< ariard>
glozow: coool let me get back to you to do simulation of attacks!
< amiti>
I'd be happy to participate if there was a clear scope, agenda & goals. I agree with sipa that its hard to make much progress in a purely abstract conversation.
< amiti>
(around p2p guarantees)
< darosior>
ariard: (re-mentioning here) happy to participate too
< ariard>
amiti: that's the reason of braindumping in a repo to avoid abstract conversation (and working on attacks simulation)
< amiti>
cool!
< jnewbery>
seems like that's all. Thanks everyone!