<bitcoin-git>
bitcoin/master f6eadaa Kristaps Kaupe: Use same Python executable for subprocesses as for all-lint.py
<bitcoin-git>
bitcoin/master 4bb840a MarcoFalke: Merge bitcoin/bitcoin#26802: test: Use same Python executable for subproce...
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #26802: test: Use same Python executable for subprocesses as for `all-lint.py` (master...all-lint-python-executable) https://github.com/bitcoin/bitcoin/pull/26802
<lisper29>
bitcoind's (24.0.1) listreceivedbyaddress always returns an empty array for a watch-only wallet when it's of type descriptor (not legacy). Anyone know if that's expected behaviour, or a potential bug? (This problem doesn't occur with a legacy watch-only wallet, only a descriptor watch-only wallet.) Helpful people in #bitcoin suggested I ask in here. Thanks in advance.
<achow101>
lisper29: sounds like a bug, but I can't replicate it
<achow101>
what parameters are you giving it?
<lisper29>
Awesome, thanks achow101. In that case, I'd better re-run my experiment more carefully. (I did observe that listsince block did work so I could use that as a workaround, or just use a legacy wallet.)
Guest969 has joined #bitcoin-core-dev
gnaf has quit [Quit: Konversation terminated!]
darosior has quit [Read error: Connection reset by peer]
<lisper29>
achow101: Sorry, I should have listed this query/response. I've updated the bottom of my note. $ bcli.sh -rpcwallet=w2 listreceivedbyaddress 1 true true "" true => []
darosior has quit [Ping timeout: 260 seconds]
<achow101>
lisper29: thanks, I do replicate the issue now
<achow101>
will investigate
darosior has joined #bitcoin-core-dev
<lisper29>
achow101: That's super to hear. Thanks for trying all this out with me. And thanks fanquake.
<achow101>
lisper29: if you do getaddressinfo for the address in the watchonly wallet, do you see "ischange": true
<lisper29>
achow101: yes, it's set to true.
<achow101>
so the problem is that the wallet thinks the address(es) is change because there is no address book entry. There's no address book entry because you haven't done anything that would give it an address book entry, like use getnewaddress (which adds an entry for the returned address) or use setlabel
<achow101>
and listreceived doesn't show txs for change
<lisper29>
Right, I see
<achow101>
I think you could work around this by setting a label to all of the addresses.
<achow101>
This generally falls under the umbrella of "our change detection sucks"
<lisper29>
ha
<lisper29>
I notice that importdescriptors' help says label is disabled for ranged descriptor. I did try setting the next_index value to something high (900), to see if that would make bitcoind notice, but it didn't. I'll now try your getnewaddress trick on the watch-only wallet.
<achow101>
I think this is the kind of issue that you won't see fixed for a while. can you open an issue on github so we can track it over the long term?
jon_atack has quit [Quit: WeeChat 3.7.1]
<achow101>
we might be able to have a workaround with having next_index add address book entries for everything in the range below that index, but that's not implemented yet
<lisper29>
Here's something that works. If I import descriptors with the active=true flag, then ischange is shown as false and listreceivedbyaddress works. (No need for getnewaddress, or more specifically getnewaddress requires active=true, which is what actually solves the problem.)
Guest969 has quit [Ping timeout: 260 seconds]
<achow101>
hmm, I didn't expect just importing as active to make a difference
jonatack has joined #bitcoin-core-dev
<achow101>
oh, I guess it does when rescanning. if it's active, we can infer whether the address is change when we rescan.
<bitcoin-git>
[bitcoin] glozow merged pull request #26603: doc: CalculateSequenceLocks: prevHeights entries are set to 0, not removed (master...docs-fix-CalculateSequenceLocks) https://github.com/bitcoin/bitcoin/pull/26603
jon_atack has quit [Ping timeout: 265 seconds]
jon_atack has joined #bitcoin-core-dev
sipsorcery has quit [Ping timeout: 260 seconds]
dermoth has joined #bitcoin-core-dev
b_101_ has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
b_101 has quit [Ping timeout: 260 seconds]
b_101 has joined #bitcoin-core-dev
b_101_ has quit [Ping timeout: 264 seconds]
gnaf has quit [Quit: Konversation terminated!]
vasild has quit [Ping timeout: 255 seconds]
vasild has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
Talkless has quit [Quit: Konversation terminated!]
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Client Quit]
<jamesob>
If I'm consuming a PUSHDATA value in EvalScript, let's say a hash, it's encoded in little-endian, right? So that means if I want to cast it to uint256, I'd have to reverse the bytearray?
<sipa>
Script elements are byte arrays. It has no concept of numbers.
<sipa>
The opcode takes the bytes from the script, and creates a stack element with those bytes, in the order they were specified.
<jamesob>
Ah okay, of course. Thanks
<sipa>
If you want to show those bytes in a human readable-way, because you happen to know they represent a hash (something script doesn't know or care about), then you'll indeed want to reverse them
<sipa>
But that's just a human representation issue