<bytes1440000>
I have left some comments in PR. One last thing that I observed and want to share since people have accused me of a few things because I have asked some question related to PR being stalled for months:
<michaelfolkson>
bytes1440000: Indeed. It appears we have a Brink problem. We've lost Core as an open source project
bitdex has quit [Remote host closed the connection]
<michaelfolkson>
Not sure what is going on there. If anyone has any insight my DMs are open
<michaelfolkson>
If I had to guess there is a small group of people including a founder of Brink, a couple of maintainers and maybe others who think they can make decisions as a small private group and not tell anyone else about the rationales for those decisions
<michaelfolkson>
But just speculating, it is very strange
brunoerg has joined #bitcoin-core-dev
<michaelfolkson>
Longer term we might have to think about how we route around this small group. We can't continue like this if we want Bitcoin Core to stay open source
<bitcoin-git>
bitcoin/master 9d47e7b Pieter Wuille: Squashed 'src/secp256k1/' changes from 44c2452fd3..21ffe4b22a
<bitcoin-git>
bitcoin/master 4462cb0 Pieter Wuille: Adapt to libsecp256k1 API changes
<bitcoin-git>
bitcoin/master 3d8a6ae Pieter Wuille: Update secp256k1 subtree to upstream libsecp256k1 version 0.2.0
<bitcoin-git>
[bitcoin] fanquake merged pull request #26691: Update secp256k1 subtree to libsecp256k1 version 0.2.0 (master...secp256k1) https://github.com/bitcoin/bitcoin/pull/26691
brunoerg has quit [Ping timeout: 264 seconds]
kexkey has quit [Ping timeout: 272 seconds]
kexkey has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
AmunRa has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 246 seconds]
dviola has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
Guyver2_ has joined #bitcoin-core-dev
Guyver2 has quit [Ping timeout: 268 seconds]
jonatack3 has joined #bitcoin-core-dev
jonatack2 has quit [Read error: Connection reset by peer]
brunoerg has quit [Ping timeout: 260 seconds]
Guest25 has joined #bitcoin-core-dev
Guest25 has quit [Client Quit]
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<jnewbery>
bytes1440000: I haven't been involved in day-to-day Bitcoin Core development for over a year. The only reason I commented on #25923 was that I was tagged by vasild with the comment "a bug is a bug, even if it was done on purpose.". My response was to correct several mistakes made by both vasild and jonatack in their comments on that PR.
<gribble>
https://github.com/bitcoin/bitcoin/issues/25923 | p2p: always provide CNodeStateStats and getpeerinfo/netinfo/gui updates by jonatack · Pull Request #25923 · bitcoin/bitcoin · GitHub
<jnewbery>
The PR description has been changed 15 times(!) by jonatack, so it's difficult to see what I'm responding to. Earlier descriptions referred to "regressions" and "API stability".
<jnewbery>
I stand by my statement in that PR: "Both the PR description and @vasild's comment make it sound like this was some nefarious intentional API break, or some egregious bug. It's neither."
<jnewbery>
It's not aggression to defend myself from an accusation that I'd introduced a bug, much less from one that I'd introduced a break intentionally. It's also not aggression to correct mistakes on a PR - that's literally what review is for.
<jnewbery>
As for whether I think vasild should become a maintainer: I haven't commented on that PR because I no longer contribute regularly to the project, so my opinion carries little weight. I also haven't been keeping track of his more recent contributions to the project.
<jnewbery>
michaelfolkson: I haven't been involved with Brink or Bitcoin Core for over a year, and yet I continue to get tagged in PRs and irc with accusations that I've deliberately broken code, been "aggressive" or am involved in some shady cabal that controls Bitcoin Core.
<jnewbery>
It's striking that neither of the two people making the accusations or pushing for vasild to become maintainer have made *any* meaningful contributions to Bitcoin Core. And yet they make incessent demands on contributors' and maintainers' time and attention and then demand justification when they don't get that attention.
<jnewbery>
Incidentally, I do agree with you that some of the processes around Bitcoin Core are broken at the moment. There are a small number of developers doing very important and very good work (including people that you regularly attack), but sadly that good work is often drowned out by interminable PRs and irc discussions about politics instead of code.
brunoerg has quit [Ping timeout: 264 seconds]
andrewtoth_ has quit [Remote host closed the connection]
andrewtoth_ has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<michaelfolkson>
jnewbery: Indeed my friend. Some of us have to spend months on the stuff no one else wants to do. Like chasing maintainers for not doing their jobs and trying to get community consensus on soft fork activation mechanisms
<michaelfolkson>
Only to see people like you trash those efforts at the last minute with weird compromises
<jnewbery>
michaelfolkson: you don't "have to" do anything. And I'd wager most people here would find this project a lot more pleasant if you chose not to.
<michaelfolkson>
Well yeah pleasant is having two maintainers blocking whatever they like without a rationale and soft forks that are ready not get activated
<michaelfolkson>
Or perhaps you'd like to venture that Luke and my efforts were pointless
<vasild>
fwiw I mentioned you (jnewbery) on 25923 to double check whether my comment was correct. It turned out it was not and you corrected/clarified some things. Thanks for that. I think all is good. I did not mean to accuse or blame you in any way.
brunoerg has quit [Ping timeout: 248 seconds]
<michaelfolkson>
jnewbery as benevolent dictator could have chosen the weird compromise we ended up with and saved Luke and me a lot of hassle
<michaelfolkson>
Or you could have NACKed Jeremy's CTV PR and saved me huge amounts of time in 2022
<michaelfolkson>
People leave the rubbish for people like me and Luke to clear up and then abuse us
<michaelfolkson>
Then they have the cheek to call us "unpleasant". Lol
midnight has quit [Ping timeout: 272 seconds]
cold has quit [Ping timeout: 260 seconds]
midnight has joined #bitcoin-core-dev
cold has joined #bitcoin-core-dev
<jnewbery>
I have no idea what you're talking about with a compromise or CTV. And I doubt anyone else in this channel is interested in this conversation.
andrewtoth_ has quit [Remote host closed the connection]
<michaelfolkson>
No one ever is interested in the rubbish. That's why it is left to people like me and Luke to deal with it
andrewtoth_ has joined #bitcoin-core-dev
sds has joined #bitcoin-core-dev
sds has quit [Client Quit]
brunoerg has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] ajtowns opened pull request #26887: RPC: make RPCResult::MatchesType return useful errors (master...202301-rpc-matchestype) https://github.com/bitcoin/bitcoin/pull/26887
<bitcoin-git>
bitcoin/master eea73d4 fanquake: test: skip sqlite3 tests if it isn't available
<bitcoin-git>
bitcoin/master 3283403 MarcoFalke: Merge bitcoin/bitcoin#26882: test: skip sqlite3 tests if it isn't available
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26882: test: skip sqlite3 tests if it isn't available (master...func_tests_check_import_sqlite) https://github.com/bitcoin/bitcoin/pull/26882
weylin_ has quit [Remote host closed the connection]
w0xlt_ has quit [Excess Flood]
w0xlt_ has joined #bitcoin-core-dev
w0xlt_ has quit [Excess Flood]
w0xlt_ has joined #bitcoin-core-dev
weylin_ has joined #bitcoin-core-dev
ghost43 has quit [Remote host closed the connection]
ghost43 has joined #bitcoin-core-dev
w0xlt_ has quit []
w0xlt has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
<bitcoin-git>
[bitcoin] vasild opened pull request #26888: net: simplify the call to vProcessMsg.splice() (master...simplify_vProcessMsg_splice) https://github.com/bitcoin/bitcoin/pull/26888
Guyver2__ has joined #bitcoin-core-dev
Guyver2__ has left #bitcoin-core-dev [#bitcoin-core-dev]
bytes1440000 has joined #bitcoin-core-dev
Guyver2_ has quit [Ping timeout: 260 seconds]
<bytes1440000>
jnewbery: I agree, I reviewed and tested less PRs. Will do more in 2023. Not sure what you mean by demand. Asking the maintainers about dysfunction and PR being stalled? Maybe 4 months wasn't enough time
bytes1440000 has left #bitcoin-core-dev [#bitcoin-core-dev]
halosghost has joined #bitcoin-core-dev
MrFrancis has joined #bitcoin-core-dev
FrancisMr has joined #bitcoin-core-dev
FranMr has joined #bitcoin-core-dev
MrFrancis has quit [Ping timeout: 255 seconds]
FrancisMr has quit [Ping timeout: 255 seconds]
AmunRa has joined #bitcoin-core-dev
FranMr has quit [Ping timeout: 260 seconds]
TallTim_ has joined #bitcoin-core-dev
TallTim has quit [Ping timeout: 260 seconds]
weylin_ has quit [Remote host closed the connection]
<bitcoin-git>
[bitcoin] furszy opened pull request #26889: wallet: set keypool size instead of access global args manager from spkm (master...2022_spkm_keypool_size) https://github.com/bitcoin/bitcoin/pull/26889
weylin_ has joined #bitcoin-core-dev
<instagibbs>
michaelfolkson, just leave if that's what you believe. You've made your views known, now move on.
<theStack>
instagibbs: heh, that would indeed be very interesting. IIUC, we can still create P2PK outputs with hybrid pubkeys, but spending them is invalid (since SCRIPT_VERIFY_DERSIG)?!
<theStack>
_aj_: thanks, that is a fun historic read
<instagibbs>
you mean SCRIPT_VERIFY_STRICTENC?
<theStack>
instagibbs: oh yeah indeed, sorry
Guest39 has joined #bitcoin-core-dev
<instagibbs>
kind of odd to allow creation and not redemption
<_aj_>
we allow that for unknown segwit versions
<instagibbs>
for a consensus-defined output type*
Guest39 has quit [Client Quit]
<_aj_>
seems like sipa's txs got reorged out, if they were even ever broadcast (that was about a year before regtest was created)
<sipa>
Oh wow, hybrid keys.
<sipa>
I had almost forgotten about those.
<instagibbs>
1-of-3 bare multisig with the same public key in compressed, uncompressed, and hybrid
<instagibbs>
Just In Case
<sipa>
haha
<michaelfolkson>
instagibbs: Where do you suggest I leave to?
<instagibbs>
somewhere you don't feel abused, life is too short
<michaelfolkson>
Any alternative cryptocurrency you recommend?
<instagibbs>
Not an invitation for more off topic convo, "move on"
<michaelfolkson>
Oh it is a "move on and shut up". Ok gotcha, charming
<bitcoin-git>
bitcoin/master 0f883df fanquake: build: fix configuring with only bitcoin-util
<bitcoin-git>
bitcoin/master 8915e4d fanquake: Merge bitcoin/bitcoin#26824: build: fix configuring with only bitcoin-util
<bitcoin-git>
[bitcoin] fanquake closed pull request #26824: build: fix configuring with only bitcoin-util (master...fix_bitcoin_util_configure) https://github.com/bitcoin/bitcoin/pull/26824
ShohamChakrabort has quit [Quit: You have been kicked for being idle]
dviola has joined #bitcoin-core-dev
<halosghost>
I'm struggling to even find information on what a hybrid key is
<halosghost>
anyone happen to have a handy link lying around? ☺ (I saw _aj_'s link to sipa's mail mentioning what the actual layout is, but I don't understand what it's for or what makes it hybrid)
<sipa>
It's a public key encoding specified in SEC1 (the same series of documents that secp256k1 came from).
<sipa>
It defines:
<sipa>
0x00 for infinity (not used, as infinity is not a valid public key)
<sipa>
0x02 or 0x03 + X coordinate, compressed key with the prefix indicating the Y sign
jonatack3 has quit [Read error: Connection reset by peer]
jonatack3 has joined #bitcoin-core-dev
<sipa>
0x04 + X coordinate + Y coordinate, the uncompressed encodin
<sipa>
and 0x06 or 0x07 + X coordinate + Y coordinate, with the prefix repeating the Y sign, the hybrid encoding
<sipa>
it's truly dumb
brunoerg has quit [Remote host closed the connection]
<halosghost>
oh, I see
<sipa>
Actually, now that I look up the spec, it does not mention the hybrid encoding, only infinity, compressed, and uncompressed.
<instagibbs>
OpenSSL supported it, so Bitcoin supports it
<halosghost>
so, what you meant in the mailer (that you can just treat them as if they had the prefix 0x04) is that the sign preservation is redundant because the full Y coordinate is stored anyway
<sipa>
It may just have been an OpenSSL invention.
<halosghost>
that makes sense
<halosghost>
and yeah… that sounds a bit like something OpenSSL might do ☺
<halosghost>
sipa: thanks for the clarification!
<sipa>
halosghost: Unfortunately, no, you cannot just treat them as having 0x04 instead, because if the parity in the prefix mismatches the actual Y coordinate that follows, the encoding is invalid.
<halosghost>
mm, sure
<halosghost>
additional failure cases!
<halosghost>
fun ☺
<sipa>
Oh, you were just repeating what decade-ago-sipa claimed. I guess he was being inaccurate.
<instagibbs>
6 year ago sipa claims its in ANSI standard
brunoerg has quit [Ping timeout: 248 seconds]
<sipa>
Oh wow, 6-years-ago-sipa was a lot smarter than 10-year-ago-sipa or current-sipa.
MrFrancis has quit [Ping timeout: 246 seconds]
<instagibbs>
sipa officially over the hill
<halosghost>
hah
TallTim_ is now known as TallTim
<sipa>
haha
<sipa>
ANSI X9.62-1998 says: "NOTE— The hybrid form contains information of both compressed and uncompressed forms. It allows an implementation to
<sipa>
convert to either compressed form or to uncompressed form."
<sipa>
LOL
<halosghost>
…
<halosghost>
right… because neither the compressed nor uncompressed forms allow you to convert to the other…
<halosghost>
I assume they meant “trivially convert” or something
<halosghost>
but that's quite a choice
<sipa>
At least going from compressed to uncompressed involves a square root.
<sipa>
But going from uncompressed to compressed is just as hard as from hybrid to compressed.
<halosghost>
I'm pretty comfortable saying that was a BadIdea™
<halosghost>
but then, I'm not responsible for ANSI standards
<halosghost>
☺
salvatoshi has quit [Ping timeout: 272 seconds]
Corissa has joined #bitcoin-core-dev
Corissa has quit [Client Quit]
hardtotell has quit [Quit: pz]
hardtotell has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
as2333 has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
<sipa>
Heh, it appears SEC1 does include some comstraints that curves need to satisfy... and some of them secp256k1 doesn't actually satisfy.
<sipa>
No clue where these constraints come from, TBH.
<sipa>
They seem unrelated to security.
brunoerg has joined #bitcoin-core-dev
AmunRa has quit [Remote host closed the connection]
AmunRa has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 246 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
vasild has quit [Remote host closed the connection]
vasild has joined #bitcoin-core-dev
AmunRa has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
AmunRa has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
AmunRa has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 256 seconds]
AmunRa has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<ariard>
achow101: clear NACK on my side on a CoC, just for all the legal implications to have a formal disciplinary authority around the project...
<ariard>
but we can discuss it more during next meeting
brunoerg has quit [Ping timeout: 260 seconds]
MrFrancis has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
dviola has quit [Quit: WeeChat 3.7.1]
<ariard>
sghost> that makes sense
<ariard>
mistake
brunoerg has quit [Ping timeout: 248 seconds]
<achow101>
ariard: what sort of legal implications? if there are any, would they not apply to the ad-hoc way we do disciplinary actions now? (when they are occasionally done)
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 265 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
<provoostenator>
The current document uses phrases like "leaders" and "officially representing the community in public spaces" which seems a bit off for this project, but that wording could be tweaked.
<achow101>
Welcome to the bi-weekly wallet meeting
<sipa>
hi
<achow101>
There are no pre-proposed wallet meeting topics
<achow101>
does anyone have anything to discuss?
<furszy>
hi
<Murch1>
furszy is doing great work, nothing else :p
<furszy>
<3
<Murch1>
Kinda curious how we are getting non-zero waste scores for coin selection algorithms when the feerate, LTFRE, and cost-of-change are 0
<Murch1>
May be a bug
<Murch1>
but I guess furszy and I will be looking a bit more into that
<achow101>
Murch1: in a test?
<Murch1>
Aye
<achow101>
excess
<furszy>
yeah
<Murch1>
#26720
<gribble>
https://github.com/bitcoin/bitcoin/issues/26720 | wallet: coin selection, dont return results that exceed the max allowed weight by furszy · Pull Request #26720 · bitcoin/bitcoin · GitHub
<achow101>
that's the only other term in that equation
<Murch1>
Excess only appears in transactions without change
<achow101>
I'll put that on my todo list
<furszy>
as there is no change, the waste is merely calculated by waste = selected_effective_value - target;
<Murch1>
it's 0 for transactions with change
<Murch1>
See GetSelectionWaste(…)
<Murch1>
Clarification, there is a change output, but the cost_of_change is set to 0 for the test.
<Murch1>
furszy: If that were so, that would be a bug
<furszy>
the test is only running the selection process, it's not creating a tx
<furszy>
not sure what you think that there is a change output
<achow101>
Murch1: it's probably excess. IIRC we assume cost_of_change == 0 means changeless solution which means include excess
<Murch1>
so both Knapsack and SRD should have a waste score of 0 throughout the test
<achow101>
Murch1: ignoring the fact of whether or not change is produced, we determine whether to use excess depending on the value of cost_of_change. If it happens to be 0, then we include excess
<Murch1>
but furszy reports they do not
<Murch1>
ergo Bug
<Murch1>
achow101: ooooooooh.
<Murch1>
Gah.
<Murch1>
That is TERRIBLE
<Murch1>
but okay, I see why I'm wrong
<Murch1>
thanks
<achow101>
well it works in normal usage :)
<Murch1>
IMO, the issue here is that we are setting a bunch of values that are never 0 to 0 in a test that is supposed to test how the function works when everything is not 0
<achow101>
but yes, it might make sense to change that
<Murch1>
Yes, let's please not set everything to zero when that is completely unnatural and never occurs in operation
<Murch1>
Sure, we might have tests to see that it would continue working, but it just baffles me that we are testing coin selection but make it behave completely different
<achow101>
right, a lot of the tests pre-date the more recent coin selection things and so in that conversion, it was convenient to use a default value of 0 because then they wouldn't implode
<Murch1>
I guess I had a topic after all :p
<Murch1>
Okay, how about we just don't do that
<achow101>
however I think our coin selection decisions are stable enough at this point we should go through the tests and actually update them and evaluate whether they still make sense
<Murch1>
Also, tbh, the trigger of adding excess when cost_of_change is 0, is kinda bad
<Murch1>
it should be whether or not there is change
<achow101>
note: I am not volunteering to do this but will gladly review
<Murch1>
Yeah, that's alright
<Murch1>
Also, furszy: my apologies, I was wrong and you were right all along!
<Murch1>
haha
<achow101>
glad I could resolve that without having to actually read any code :)
<Murch1>
I bet
<furszy>
hehe, i tried to explain what achow101 said in a line in 4 long comments in the PR :p
<furszy>
should have used the "excess" wording
<Murch1>
Yeah, in theory it should work, but in practice…
<Murch1>
Nah, sorry, that was my fault, I did not realize that setting cost_of_change = 0 actually makes everything evaluate as if it were changeless solutions 🤦♂️
<achow101>
anything else to discuss?
<Murch1>
BIP47 is terrible
<Murch1>
No discussion necessary, though
<Murch1>
:p
<Murch1>
err, no
<Murch1>
Also, are we defaulting to P2TR change yet? ^^
<Murch1>
At least when sending to P2PKH for wallets that don't have a legacy descriptor?
<achow101>
I think we might want to avoid changing that since it ends up being a dead giveaway of what our change is
<Murch1>
I mean, we already match the recipient output when we have a descriptor for that type
<achow101>
if you do not have a descriptor for legacy, and have a bech32m descriptor, we will use a bech32m as change
<Murch1>
noice
<achow101>
so I think the answer is that we already do what you suggest
<Murch1>
It's just a few stragglers of minor relevance such as Binance, Coinbase, Bitfinex, Bitso, Crypto.com, Fireblocks, Gemini, Luno, and Paxful that have not implemented support yet
<achow101>
it's only the biggest exchange, nbd
brunoerg has joined #bitcoin-core-dev
<Murch1>
😄
<achow101>
I guess choosing the address type to use is really easy to do now so maybe it doesn't matter as much?
<Murch1>
If we announce that we are switching the default address type early and loudly enough, they might also just finally do the ~2 line code change
w0xlt has quit [Excess Flood]
w0xlt has joined #bitcoin-core-dev
<Murch1>
But yeah, for real, maybe v26 is more realistic
w0xlt has quit [Client Quit]
w0xlt has joined #bitcoin-core-dev
<achow101>
any other topics?
<Murch1>
We should do a wallet offsite
<Murch1>
just wallet devs hanging out for a few days
<Murch1>
preferably in the winter on an island where it's warm
brunoerg has quit [Ping timeout: 246 seconds]
<Murch1>
I hear the Caribbean is nice this time of the year
<achow101>
perhaps
<achow101>
I don't know if there's a whole lot to talk about that we can't do during a coredev event?
<Murch1>
🤷
<Murch1>
I think you are only catching part of the point :p
<ariard>
achow101: legal responsibility of the moderation team for contributors code and statements on the repository, or in fact any related venue
<ariard>
it could apply to the ad-hoc actions already taken...formalizing make things worse from a legal reasoning standpoint as you function on decision criterias
<ariard>
and here you have to consider not only your local juridiction -- but also the ones of anyone to whom you might take actions
<ariard>
as of today, according to foss standards, contributors are only responsible of their own acts
<ariard>
at the very least I would advice to take opinoins from lawyers on the case, the annoying thing we're evolving in an environement where the legal responsibilites of cryptocurrencies dev are in plain discussion
AmunRa has quit [Remote host closed the connection]
MrFrancis has joined #bitcoin-core-dev
Talkless has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]