<phantomcircuit>
sipa: all the wallets have a GetScriptPubKeys method, so at least in theory there's no reason not to support all of them
<phantomcircuit>
but yeah i get it, i'll see if achow101 has an opinion :)
<achow101>
phantomcircuit: multisig as in bare multisig or any multisigs?
<phantomcircuit>
achow101: as in i would only be able to find things that are in LegacyScriptPubKeyMan::GetScriptPubKeys()
<phantomcircuit>
which if i understand correctly puts me in the same position as someone who migrates from legacy to descriptor anyways
<achow101>
ah, that's fine
<phantomcircuit>
i can see what sipa is saying though, since im not able to support more than what descriptor wallets can do i should just support migrated wallets only
<achow101>
GetScriptPubKeys() should exactly match everything that IsMine() does, so it shouldn't miss anything
<achow101>
one of the issues with the rescanning is that each new tx found can add entries to the keypool, so figuring out what was added in order to update the spk set might be harder with legacy wallets
<phantomcircuit>
achow101: ironically it's much easier with true legacy wallets that dont have hd keys
<phantomcircuit>
im not sure you're right about GetScriptPubKeys matching IsMine 1:1
as2333 has quit [Changing host]
as2333 has joined #bitcoin-core-dev
<achow101>
it's supposed to... if it doesn't, that's a bug
<phantomcircuit>
achow101: i dont think it can, since there's an exponential blow up in the solver
<phantomcircuit>
achow101: bare n-of-m multisig where the legacy wallet has all the keys will be IsMine, but we cannot possibly generate all of those scriptpubkeys
<achow101>
not since a while now
<achow101>
you need to import bare multisigs explicitly for them to be detected
<phantomcircuit>
ah i see // Never treat bare multisig outputs as ours (they can still be made watchonly-though)
<phantomcircuit>
ok yeah then it's possible
<phantomcircuit>
sipa: lol you're the one who made bare multisig !IsMine :)
<sipa>
I just remember it was nontrivial to generate the set of all scriptPubKeys!
<sipa>
If the code for that exists now, so much the better.
<phantomcircuit>
sipa: iirc i tried to do it before the change to bare multisigs and decided it was literally impossible, because of the bare multisig support
weylin_ has joined #bitcoin-core-dev
weylin__ has joined #bitcoin-core-dev
dviola has joined #bitcoin-core-dev
weylin_ has quit [Ping timeout: 256 seconds]
andrew_m_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
b_101 has joined #bitcoin-core-dev
b_101 has quit [Client Quit]
andrew_m_ has joined #bitcoin-core-dev
<sipa>
yeah without that you have n^3 combinations
andrew_mo_ has quit [Ping timeout: 268 seconds]
b_101 has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
MrFrancis has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 272 seconds]
AmishNick has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_m_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 256 seconds]
dviola has quit [Ping timeout: 252 seconds]
AmunRa has quit [Remote host closed the connection]
test_ has joined #bitcoin-core-dev
_flood has quit [Ping timeout: 246 seconds]
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
MrFrancis has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has quit [Ping timeout: 256 seconds]
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_m_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew___ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
andrew_m_ has quit [Ping timeout: 272 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew___ has quit [Ping timeout: 260 seconds]
andrew_m_ has joined #bitcoin-core-dev
Randolf has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_m_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 272 seconds]
andrew_m_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 272 seconds]
andrew_mo_ has joined #bitcoin-core-dev
hsmiths has quit [Quit: hsmiths]
hsmiths has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
Randolf has quit [Quit: Leaving]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
cmirror has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
jarthur has quit [Quit: jarthur]
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
as2333 has quit [Quit: as2333]
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 256 seconds]
weylin__ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
andrew_m_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
andrew_m_ has quit [Ping timeout: 268 seconds]
andrew_mo_ has joined #bitcoin-core-dev
Guyver2 has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 272 seconds]
AmunRa has joined #bitcoin-core-dev
weylin_ has joined #bitcoin-core-dev
___nick___ has joined #bitcoin-core-dev
weylin_ has quit [Ping timeout: 246 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
AmunRa has quit [Ping timeout: 255 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 252 seconds]
<phantomcircuit>
sipa: does FastRange64 change the sort order?
<MacroFake>
At a first glance it doesn't look possible without a complete re-write
<bitcoin-git>
[bitcoin] fanquake opened pull request #26919: scripted-diff: use RPCArg::Optional::OMITTED over OMITTED_NAMED_ARG (master...remove_omitted_named_arg) https://github.com/bitcoin/bitcoin/pull/26919
AmunRa has quit [Remote host closed the connection]
weylin_ has joined #bitcoin-core-dev
Guyver2__ has joined #bitcoin-core-dev
AmunRa has joined #bitcoin-core-dev
greypw2546002 has quit [Read error: Connection reset by peer]
<bitcoin-git>
bitcoin/master dff7ed5 James O'Beirne: test: add an easy way to run linters locally
<bitcoin-git>
bitcoin/master 250598a MarcoFalke: Merge bitcoin/bitcoin#26906: test: add an easy way to run linters locally
<bitcoin-git>
bitcoin/master b68e5a7 James O'Beirne: lint: specify the right commit range when running locally
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26906: test: add an easy way to run linters locally (master...2023-01-lint-container) https://github.com/bitcoin/bitcoin/pull/26906
andrew_mo_ has quit [Ping timeout: 265 seconds]
brunoerg_ has joined #bitcoin-core-dev
brunoerg_ has quit [Remote host closed the connection]
brunoerg_ has joined #bitcoin-core-dev
brunoerg has quit [Read error: Permission denied]
andrew_mo_ has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 268 seconds]
MrFrancis has quit [Ping timeout: 252 seconds]
andrew_mo_ has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #26924: refactor: Add missing includes to fix gcc-13 compile error (master...2301-iwyu-gcc-13-📔) https://github.com/bitcoin/bitcoin/pull/26924
andrew_mo_ has quit [Ping timeout: 256 seconds]
weylin_ has quit [Remote host closed the connection]
<achow101>
There are two preproposed meeting topics: code of conduct (achow101), libsecp256k1 release schedule (sipa). Any other topics to add to the list for today?
<achow101>
I viewed the new one as a more free form where anyone could add whatever they wanted
<lightlike>
oh, ok
<achow101>
maybe _aj_ had a different usage in mind when he brought up the idea?
<_aj_>
just added the missing ones from high prio to pr statuses
andrew_mo_ has quit [Ping timeout: 252 seconds]
<achow101>
#opic code of conduct (achow101)
<achow101>
#topic code of conduct (achow101)
<core-meetingbot>
topic: code of conduct (achow101)
andrew_mo_ has joined #bitcoin-core-dev
<achow101>
I wanted to get some thoughts on whether a code of conduct (not necessarily the one proposed in #26890) is something that people think we should have in this project
<ariard>
achow101: have you get feedback on how a code of conduct could be opposed legal binding to contributors ?
<instagibbs>
from you ariard I think :P
<_aj_>
instagibbs: (achow101 was going to get lawyer-ish feedback, i think)
<achow101>
ariard: not yet. ajonas is helping me with finding some lawyers to look at it
andrew_mo_ has quit [Ping timeout: 252 seconds]
<achow101>
should have something next week I think?
<ariard>
well i checked the french law on the legal binding of internet code of conduct...and it turns out you have cases where they have been recognized legal binding
<ariard>
in matters of civil law and spamming-only -- though still it means code of conduct have been included in the law norm hierarchy which isn't good ihmo
<MacroFake>
No opinion on that, but I think we can just continue as before with (temporary) bans. No one seems to have complained about how things were done in the past. And the only change of the CoC.md would be that there are warnings for less severe violations, so maybe just do that in the future without the md file?
<ariard>
achow101: the hard thing you will need probably lawyer opinions...from well all the juridctions where we have contributors :/
<instagibbs>
MacroFake, I don't think temp bans are happening fast enough, just my humble opionion ofc
<achow101>
MacroFake: we've taken actions on the obvious stuff like spam and threats of violence, but there are some behaviors that I think warrant action but are less obvious and potentialy more contentious, so a CoC would help us set the line for those
<achow101>
more contentious in that taking action can be contested if it isn't written down as something that we don't think is appriopriate conduct
<_aj_>
it can be contested anyway; as long as the people doing the moderating (and most normal contributors) are in agreement, it's fine?
<kanzure>
i agree with some of the comments advising high levels of caution before deciding to implement a code of conduct programme
<achow101>
_aj_: how would we do that though? Have a topic in the meeting of "proposal to ban X"?
<sipa>
I have little opinion, fwiw. I do see some of the problems that may merit different moderation and policies; I don't know whether a CoC is the right way to address those, but also don't oppose it.
<kanzure>
is your concern about a ban of a contributor looking like a unilateral action which might be subject to backlash/headaches that you would like to be personally protected from
<MacroFake>
achow101: The people that can ban (+ maybe some maintainers ) could discuss a warning/ban?
<achow101>
kanzure: yes
<_aj_>
achow101: have the moderators moderate things quickly; have a signal group for the moderators to get quick feedback; be prepared to undo things if you go too far
andrew_mo_ has joined #bitcoin-core-dev
kmartin has quit [Ping timeout: 260 seconds]
<_aj_>
achow101: maybe have a wiki page where you document what people should(n't) be doing if reasonable people seem to be getting confused
<kanzure>
well, you can't be everything to everyone, and it's naturally okay for some people to just not want to work together
<achow101>
_aj_: I guess so
<achow101>
in terms of who can moderate, right now it's basically just the maintainers, github does have Moderator position though
andrew_mo_ has quit [Ping timeout: 272 seconds]
andrew_mo_ has joined #bitcoin-core-dev
<achow101>
if anyone wants that permission, we could have a discussion about it like we do for maintainership?
<sipa>
In the libsecp256k1 meeting monday we decided to aim for a roughly every-3-months release schedule, every second one of which synchronized with the bitcoin core releases (~1 month before feature freeze).
<sipa>
So the next one would be early march.
<achow101>
sipa: will the versioning be sane?
<sipa>
semantic versioning
<sipa>
we releases 0.2.0 in december, in case you missed it
<achow101>
is the idea that we would do a subtree update just before feature freeze every release?
<sipa>
or at least, have the opportunity to do so
<sipa>
yeah
andrew_mo_ has quit [Ping timeout: 256 seconds]
<sipa>
so far libsecp256k1 pulls have mostly been "enough useful stuff has accumulated"
<sipa>
but now we also have a changelog etc, so it should be easier to reason about that
<achow101>
doing it on a regular schedule seems reasonable
<sipa>
yeah, we considered doing it more feature based ("there is enough useful stuff"), but having regular releases may be beneficial for contributions too
<sipa>
but on the other hand, the overhead of a release is so low that we don't need to go to once-every-6-months either
<sipa>
not that much to discuss, just wanted to announce it here, and if people have comments/opinions, feel free to reach out
<_aj_>
sounds great
<achow101>
cool
<sipa>
for now we'll just see how it goes
<MacroFake>
Will previous releases receive bugfixes?
<MacroFake>
If yes, then you may underestimate the overhead, as it scales with the number of supported previous releases
<sipa>
MacroFake: Yes, that's the plan. Though we have little experience with bugs... *humblebrag*
<_aj_>
i'm sure you could do a call for contributors if you want more experience with bugs?
<sipa>
There is one open question I now think of, which is how to deal with Bitcoin Core PRs that depend on new features (specifically, #23432 currently).
Talkless has quit [Quit: Konversation terminated!]
Guest6969 has joined #bitcoin-core-dev
Guest6969 has quit [Client Quit]
scg has joined #bitcoin-core-dev
jonatack has joined #bitcoin-core-dev
<scg>
gm! why does bitcoind creates a PSBTv0 if I specify locktime ?? I can see that it set PSBT_GLOBAL_FALLBACK_LOCKTIME on psbt but kept version of psbt 0. In BIP174 I read that v0 psbts require exclusion of PSBT_GLOBAL_FALLBACK_LOCKTIME. What am I missing ?
<scg>
bitcoind v24.0
<instagibbs>
24.0 whoudl only make v0, but shouldn't include PSBT_GLOBAL_FALLBACK_LOCKTIME afaik
<sipa>
support for PSBTv2 isn't even merged in master
<sipa>
and I don't see PSBT_GLOBAL_FALLBACK_LOCKTIME or anything related to psbt-locktime in the code.
<instagibbs>
only mention i found was in the python test suite
<scg>
let me check - maybe parsing it with HWI populated that field
<scg>
meh - yes it was HWI, which sets it in `PSBT.setup_from_tx` from CTransaction (Fills in the PSBTv2 fields for this PSBT given a transaction)
weylin__ has quit [Remote host closed the connection]
<bitcoin-git>
bitcoin/master 8e3fc99 Russell O'Connor: Do not use CScript for tapleaf scripts until the tapleaf version is known
<bitcoin-git>
bitcoin/master 58da161 Andrew Chow: Merge bitcoin/bitcoin#25877: refactor: Do not use CScript for tapleaf scri...
<bitcoin-git>
bitcoin/master dee8943 Russell O'Connor: Abstract out ComputeTapbranchHash
<bitcoin-git>
[bitcoin] achow101 merged pull request #25877: refactor: Do not use CScript for tapleaf scripts until the tapleaf version is known (master...202208_tapleaf_script) https://github.com/bitcoin/bitcoin/pull/25877
b_101_ has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
andrew_mo_ has quit [Remote host closed the connection]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 272 seconds]
andrew_mo_ has joined #bitcoin-core-dev
andrew_mo_ has quit [Ping timeout: 260 seconds]
andrew_mo_ has joined #bitcoin-core-dev
halosghost has quit [Quit: WeeChat 3.8]
weylin_ has joined #bitcoin-core-dev
weylin_ has quit [Remote host closed the connection]