aitorjs has quit [Remote host closed the connection]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] hebasto opened pull request #22814: build: Add ability to build qt in depends with -stdlib=libc++ (master...210827-libc++) https://github.com/bitcoin/bitcoin/pull/22814
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake closed pull request #21144: test: convert feature_bip68_sequence.py to use MiniWallet (master...test-feature-bip68-sequence-without-wallet) https://github.com/bitcoin/bitcoin/pull/21144
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
klementtan has joined #bitcoin-core-dev
common has quit [Ping timeout: 240 seconds]
common has joined #bitcoin-core-dev
muhblockchain has quit [Ping timeout: 250 seconds]
muhblockchain has joined #bitcoin-core-dev
grettke has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
grettke has joined #bitcoin-core-dev
grettke has quit [Client Quit]
grettke has joined #bitcoin-core-dev
dermoth_ has joined #bitcoin-core-dev
dermoth has quit [Killed (NickServ (GHOST command used by dermoth_))]
dermoth_ is now known as dermoth
cmirror has quit [Remote host closed the connection]
cmirror has joined #bitcoin-core-dev
AaronvanW has quit [Quit: Leaving...]
common has quit [Remote host closed the connection]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
gribble has quit [Remote host closed the connection]
jarolrod has quit [Ping timeout: 250 seconds]
jarolrod has joined #bitcoin-core-dev
gribble has joined #bitcoin-core-dev
raj has joined #bitcoin-core-dev
<michaelfolkson>
ariard__: I think #22665 would benefit from your input. You've Concept ACKed #22698 but I and presumably others don't know if you'd also be happy with #22665
<gribble>
https://github.com/bitcoin/bitcoin/issues/22698 | Implement RBF inherited signaling and fix getmempoolentry returned bip125-replaceable status by mjdietzx · Pull Request #22698 · bitcoin/bitcoin · GitHub
earnestly has joined #bitcoin-core-dev
<michaelfolkson>
ariard__: I agree on BIP vs code being case by case. If BIP logic is stronger we should go with BIP. If code logic is stronger we should go with code. I don't think we should blindly go with code because code automatically overrules BIP
bitdex has quit [Remote host closed the connection]
bitdex has joined #bitcoin-core-dev
<laanwj>
"code overrules documentation" is a necessity for consensus code which is very hard to change, for policy it's less clear cut, though it still takes long to propagate changes
bitdex has quit [Remote host closed the connection]
vysn has joined #bitcoin-core-dev
bitdex has joined #bitcoin-core-dev
<michaelfolkson>
laanwj: Agreed on consensus code. I wouldn't describe a BIP as (Core) documentation though. I would describe it as a standard.
<michaelfolkson>
If the code and the Core documentation don't match you would just update the documentation. But presumably BIPs have got buy in from alternative implementations and today Lightning implementations etc
<michaelfolkson>
So you might still update the BIP or create a new BIP if the code logic is superior (or too difficult to change) to the BIP logic. But it isn't just a Core issue
<michaelfolkson>
That's my view anyway :)
<laanwj>
sure, but there are no other mempool policy implementations in wide use, arguably a document that describes that is actually running in the wild has some use, apart from any function as standard
<laanwj>
there's a lot of inertia involved in trying to change the implementation, if something gets merged it will take a long time before that version is widely spread on the network to be behavior other software can rely on, so in the meantime... it might as well be a new BIP
Ananta-shesha has joined #bitcoin-core-dev
<laanwj>
e.g. most straightforward would be to create a new diff-BIP that documents core's behavior and state that we implement that
<laanwj>
then consider if we want to really implement BIP125 instead
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Henrik has joined #bitcoin-core-dev
lkqwejhhgasdjhgn has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
Yihen has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
vysn has quit [Quit: WeeChat 3.2]
Henrik has joined #bitcoin-core-dev
goatpig has quit [Quit: Konversation terminated!]
JackH has joined #bitcoin-core-dev
Henrik has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
prayank has joined #bitcoin-core-dev
goatpig has joined #bitcoin-core-dev
prayank has quit [Read error: Connection reset by peer]
Ananta-shesha is now known as ArcticVaultETMar
ArcticVaultETMar is now known as ArcticVauETMarsH
ArcticVauETMarsH is now known as ArcticVauMarsHel
ArcticVauMarsHel is now known as ArcticVauMarsHPJ
prayank has joined #bitcoin-core-dev
ArcticVauMarsHPJ is now known as ArctVaultMarsHMP
ArctVaultMarsHMP is now known as ArctVaulMarsHMPJ
vnogueir- has joined #bitcoin-core-dev
vnogueira has quit [Ping timeout: 276 seconds]
suraj has joined #bitcoin-core-dev
prayank has quit [Ping timeout: 250 seconds]
Guyver2 has joined #bitcoin-core-dev
<ariard__>
michaelfolkson: Happy to review #22665, if you review a PR in LDK, next release should be productionish one and I'm late on few reviews there :)
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitdex has quit [Quit: = ""]
common has quit [Ping timeout: 240 seconds]
Talkless has quit [Quit: Konversation terminated!]
lkqwejhhgasdjhgn has quit [Quit: Konversation terminated!]
raj_ has joined #bitcoin-core-dev
raj has quit [Ping timeout: 248 seconds]
<michaelfolkson>
ariard__: Haha I'll have a scratch around. Didn't know a major LDK release was on the horizon, don't let me distract you :)
common has joined #bitcoin-core-dev
prayank has joined #bitcoin-core-dev
<yanmaani>
What is Bitcoin Core's policy on refactors that are beneficial to downstream projects, but not directly useful for Bitcoin?
<yanmaani>
Specifically, adding an additional SignTranaction(tx, sighash) method in CWallet, which works like the current SignTransaction(tx) method with fetching coins, but doesn't assume SIGHASH_DEFAULT.
<prayank>
#proposedwalletmeetingtopic
<prayank>
Not sure if this hashtag did anything
<michaelfolkson>
You put the topic directly after the hashtag prayank
<prayank>
lol okay
<prayank>
#dontusewalletacrosschains
b10c has joined #bitcoin-core-dev
<michaelfolkson>
#proposedwalletmeetingtopic and then your topic :)
<michaelfolkson>
e.g. #proposedwalletmeetingtopic Don't use wallet across chains
<prayank>
#proposedwalletmeetingtopic wallet files should not be reused across chains
<yanmaani>
Are they now?
<prayank>
Yes
<yanmaani>
What, across testnet and mainnet?
<sipa>
what?
<prayank>
Testnet wallet works in mainnet
<yanmaani>
Yeah, but they're not reused, are they?
<sipa>
they're in separate data directories
<yanmaani>
i.e. bitcoin generates a new wallet if I go into testnet; I'd have to manually move my wallet to get it to reuse them
<sipa>
ok, so they aren't reused, but it's not detected when you accidentally load the wrong one
<sipa>
?
<prayank>
Yes
<michaelfolkson>
yanmaani: Someone with more experience can answer your question but I'm almost certain they will say it is case by case basis. If it isn't harmful to Core, has benefits to downstream projects and can get sufficient review to warrant it being merged there's no reason why it can't get merged
<sipa>
if it's only beneficial to downstream project, the getting sufficient review part may be hard
<yanmaani>
sipa: It's on the order of 2-10 lines, so it's not a massive chunk of code
<sipa>
best way would be to tr
<sipa>
y
<michaelfolkson>
I don't know what "not directly useful for Bitcoin" means. I'm assuming you mean not directly useful for Bitcoin Core users there
<yanmaani>
michaelfolkson: nice
<sipa>
that'll reach for more people than asking it here now
<sipa>
*far
<yanmaani>
michaelfolkson: yes, it would be dead code
<yanmaani>
sipa: On the ML or github?
<sipa>
yanmaani: open a PR
<sipa>
there is no bitcoin core development ML
<yanmaani>
sipa: thanks
<sipa>
if it's dead code, i would NACK it
<sipa>
unless there is a prospected need for it
<yanmaani>
sipa: there's a need for it in downstream projects, but from the pov of bitcoin, it would be dead code.
<sipa>
yanmaani: bitcoin core's reviewers won't care about that
<sipa>
i suspect
<sipa>
(and i wouldn't)
jarthur has joined #bitcoin-core-dev
<yanmaani>
sipa: e.g. wouldn't want it?
<sipa>
no
<prayank>
michaelfolkson: Thanks for helping with the hashtag. So do we have any meeting today to discuss wallet issues? Wanted to confirm else this IRC app disconnects in between when I do other things and not looking at my phone
<michaelfolkson>
prayank: I'm not sure what you are asking. As I said meeting at 19:00 UTC, in about 90 minutes
<prayank>
Sorry I thought it's at 17:00. Will join later. Thanks.
prayank has quit [Quit: irc thread exit]
aitorjs has joined #bitcoin-core-dev
vysn has joined #bitcoin-core-dev
Chris_Stewart_5 has quit [Ping timeout: 240 seconds]
<S3RK>
#proposedwalletmeetingtopic automatically adding record to adress book to prevent #19856
<S3RK>
I remember there was a proposal to check best block record and compare genesis blocks
<sipa>
that seems to be what 18554 is doing
<achow101>
comparing bestblock only works if it is in the mainchain. If it's a stale block, and the wallet is loaded on a node that doesn't have it, it won't work
<prayank>
Yes it does something with blocks which doesn't look the right approach or maybe we need to add more things in if statement
<sipa>
prayank: if you tested that PR, and found it isn't doing what it is claimed, you should leave that as a review on the PR
<S3RK>
yes. So there is a problem with miscategorizing self-to-self transactions as change
<S3RK>
this leads to them missing from listtransactions
<S3RK>
it affects cases when restoring wallets with missing metadata
<S3RK>
or having same wallet loaded in parallel in two nodes
<S3RK>
I created a prototype to fix that by automatically adding such addresses to address book
<S3RK>
but I'm not sure that's a way to go
<achow101>
send to self should already be in the address book because the address had to be requested
<S3RK>
yes, but no in the cases I described
<achow101>
the situations this bug occurs in are restored wallets and having another node loaded with the same wallet
<S3RK>
even we discard the case with the same wallet loaded in two places
<S3RK>
the case with restored wallet seems like a bug
<S3RK>
I don't see many downsides to add such addresses automatically to the address book
<S3RK>
or should I say any downsides
<achow101>
IMO it's not a bug. I think if you are restoring a wallet, you can expect that some metadata will be missing, e.g. whether something is or is not change
<S3RK>
whether it's a bug or not is secondary. It's a poor ux and we can reasonably fix that
<achow101>
I don't mind if it isn't very invasive
<S3RK>
I can't think of any downsides, but I may be missing something
<achow101>
the only downside is if we want to change back to using a single key chain rather than a split for receive and change
<achow101>
since afaict, you need the split in order to correctly determine whether an output is send to self or change
<S3RK>
not exaclty, even without descriptors you can get it from keypool records
<achow101>
only for legacy wallets
<S3RK>
agree, one chain makes it much more complicated or even impossible
<achow101>
in any case, if you open a PR, we can discuss further there
<S3RK>
ok. I wasn't sure if it makes sense to invest more time. Will open a PR
vasild has quit [Ping timeout: 276 seconds]
<achow101>
any other topics to discuss?
<S3RK>
I have a question
vasild has joined #bitcoin-core-dev
<S3RK>
do you have any updates on the upgrading wallets to tr descriptors?
<achow101>
No, I thought it might be something we should discuss at coredev
<S3RK>
thumbs up
<michaelfolkson>
+1
<michaelfolkson>
Latest Twitch streams have been on multipath descriptors
Guest67 has quit [Quit: Leaving]
<S3RK>
there is a gist with topic ideas for coredev
<achow101>
I'll comment on it (don't post that here)
<achow101>
anything else?
<michaelfolkson>
It hasn't clicked with me why multipath descriptors are important but I didn't do sufficient reading
<michaelfolkson>
So let me do that first
<michaelfolkson>
No nothing from me
<S3RK>
one more small thing
<S3RK>
I'm reviewing #22067
<gribble>
https://github.com/bitcoin/bitcoin/issues/22067 | Test and document a basic M-of-N multisig using descriptor wallets and PSBTs by mjdietzx · Pull Request #22067 · bitcoin/bitcoin · GitHub
<S3RK>
and I wonder why can't we use one wallet for this multisig setup
<achow101>
I think it's to demonstrate the use of combinepsbt
<achow101>
and generally the passing around of PSBTs
<S3RK>
no, I mean each participant have two wallets
<S3RK>
one to signer and one watch-only multisig
<S3RK>
can't we have both descriptors in one wallet?
<achow101>
oh, pure watchonly can't be imported into a wallet with private keys
<S3RK>
yes, but you can replace your xpub with xprv
vnogueira has quit [Remote host closed the connection]
<achow101>
sure
<achow101>
that's something you can ask in the pr
<S3RK>
will do. Just checking if I'm missing something obvious