[Bug]: Not always using unique onchain receive address

[catch-21]

Describe the bug

My wallet has not always been using a new unique address for each onchain receive. The latest transaction I took is f23b28ed8e8d4faf942e37824994818163cf4aa7017ea6592d4e3e88fd36d461 and that is to address bc1qqraqjlu9wgxsm8fsf4n8anhyzlkfap0f7eefca, which currently has 11 transactions over the past 3 months. When I go to receive again the same address is suggested.

This was once also the case for bc1q7t9a52ygc8yucya7zm0ypyu4ys3sgay9pq2ecc

Reproduce

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Screenshots / Recording

Operating system

Android 13 TKQ1.221114.001

Bitkit version

v128

Log output

No response

[limpbrains]

Do you still have this issue? It might be fixed in #2210

[pwltr]

Looks like the onchain wallet is not refreshed somewhere:

1. Create new wallet
2. Receive onchain tx
3. Open Receive again, check address

Simulator.Screen.Recording.-.iPhone.15.-.2024-10-02.at.12.23.11.mp4

Then if you pull to refresh you'll get a new address.

[catch-21]

I haven't seen this recently with receive address, but we have seen change address reuse in testing session.
I hope that those are both the same cause that Phil suggested.

[JeanlChristophe]

@catch-21 can you test it again in order to see if Ivan need to spend time on it, please?

[pwltr]

Can easily reproduce this with a new wallet:

1. Create new wallet
2. Receive onchain tx (don't mine block)
3. Open Receive again, check address
4. Also observe no activity

Simulator.Screen.Recording.-.iPhone.15.-.2024-11-07.at.15.40.21.mp4

Feels like this should be handled in beignet but fixed here in Bitkit for now.

[catch-21]

Tested on 1.0.7 (139) 3b9a833 and (141) 97851ff using regtest wallet
My wallet still appears to have got stuck reusing the same address. Note that none of these transactions in the video have confirmed.

Screen-2024-12-03-100206.mp4

... although, after tx confirm the address persists still:

Screen-2024-12-03-101012.mp4

In case it is in any way useful: bitkit_ldk_logs_1733221273874.zip

[pwltr]

I tried to reproduce this by receiving roughly 50 transactions. I got a unique address everytime. I didn't have to use pull-to-refresh. Tested on 041b824

Here's the list of addresses:

// iOS - fresh wallet
bcrt1qyh78pmm7mqa044hnudz9cqj6rdfw398hhhaxkf
bcrt1q9gsdspwcj60kmaqerd4uxqszpk4ashcupxr6rn
bcrt1qkyrtty29gle5e8v749g7y90mygq7al9y9nr62z
bcrt1q20kkwd0uzd7v6j45nky7fleq3gtl7l3vtmr9tt
bcrt1qufzze77usrgkqfcphd45wggak03l93nuks039d
bcrt1qlh7060rnqmcx6fjx2p9eshef0ppdmwa92tr4qn
bcrt1qtx5ea9dw6fnzzvdy84z3fltu2zu7vm4365gwkz
bcrt1qcp2jmh3hy68sjyrw3jgqzhk7csruf896sl7fej
bcrt1q7sd39xgz3g3hxwf9w06gucj83gltwz8xt96whh
bcrt1q6a8au9umn7lg6mpagccr80h9t64g9947xa3r6h
bcrt1q8nqy87m9rd0d2t4y9wkeq9d2dclvdfv67xz08j
bcrt1q805jd3n25ap6xvdu442vd45444pv5w5t2m6f0c
bcrt1qe5m502cqcgr3fclhshsuz5lk6a9m5ptnv48lwh
bcrt1qgeqxy5yuu4nk6vcrya4vvwqudxfhfwfq60854x
bcrt1qv5neuqxjvm4qn4pdegu9se09hf7fgtz3crs2ln
bcrt1q7dm6d930u5gnal06jddcgnce8fknv7n794qapf
bcrt1qt4xpktkccdy8n239sfu6lkm6se8lhpe5ey3n6j
bcrt1qsa7v8qltqyejv42ay278zpjwyc7fdftaju9ckx
bcrt1qefumwclk5a7cyze55kjqjl4hgnrtj5sp2pr7n2
bcrt1q3t0588tq4mk86m69pcxnw3zysa7wf0x6xstp50
// restart
bcrt1qwfcxkf57hwcyj3xlej4ssfhzlvcxc2hn2vq9ch
bcrt1qftqkuf9qm5e70lfren5ycdnvlt8f8xpxur0g4h
bcrt1qhkpytujzz4ukfz2fg2sf9k7eumr0rsyjhtgr4w
bcrt1qejxtmg2ec70qz7szkk3pxew555agkv5426kthl
bcrt1q7vl8quet9hl7akc4vvavkmrac8z6j6smhd5jwz
// mine & restart
bcrt1qhppc0r9asdpy2j978rzrdw8rx4v2pfx08uk56g
bcrt1qy7asyn9quz5gqdrn0yrczcu20tnsc550cdx6vy
bcrt1qxenun8m2wzqlwsn85fq4s0efrhuu5k2s85lvy2
bcrt1qqgda2kpjv0pmdpd3jrvkahlpldf3ar7d5g80u0
bcrt1qmmex6jv8pp2xzkewz772d5u3tnlrnslhdew3w9
// wipe & restore on iOS
bcrt1qltw7v28wptrpkenfylfvw8qkdp8m9mjcuussc4
bcrt1qd64f99d4xnfrkkm3renprgq0mqtxpzrp24hlz3
bcrt1qfkr8hq6nj5s3y0peamnja5rfge4gq6x9e2mzjm
bcrt1qvrmtz2h4rh99mxc5npm6qvl784jtvmhvdk7qfp
bcrt1qn6nvz28756rcm4mrqhwp3nes8w8vpa2ya4j80a
bcrt1qnvnfcdl6uymfpg2xz6p7xsutvqy7lz09l4u9fr
bcrt1q9424aw08xvd6juf8rpntdf5ydqq469c7j29xfg
bcrt1qtcq44sccwvzkrqch3y5jy9z6hyt5snld7vp7yv
bcrt1q39sfx0f7jgmjzfaqj8gmn2fl3wya7h4732jcyl
bcrt1qgmks9ajvrk7x00f2rgh3vlyg8ytsyn9xcrt7jt
// mine & restart
bcrt1qh4qv0hz0u8pgkp389d4ktk8etzqd8asmm42ns5
bcrt1q9zxcpmsr6z9rwa4s9mw2mcu6u5v3n6cxduyehg
bcrt1qpucku0sx3u8sm4lf4uu4rhse394z6xgmqnkpfm
bcrt1qamau98xeade8l0c5a86zegx596h7fw7mjvs5kl
// wipe & restore on Android
bcrt1qfhwh4j4r0ndyu9qn0m5sjfl4yaqlft3847xp3r
bcrt1q3amnf6ad6tgze50w58wanggt6stcx4cw0qrrmh
bcrt1q9ktrc2rs9e66s6sqwe03esc0vp9gkuldpdzntd
bcrt1qtwuzlfnpdtt548tx87jcpra8sdlwjuh7n4mpud
// mine & restart
bcrt1qemhs4qm2p369njq3amxw8l2f6nm6rpm87k79fj
bcrt1q2ezq6x8qmzr6lgk394lhd3aj7dd6nlwpazlxp2
bcrt1q83vjma0085s7l8qqu8sm487twd4alglpsle4l6
bcrt1qcljs4dhjs93utu2pd9sdhut46zghqqgw9n8rcj

[limpbrains]

Looks like it is hard to reproduce on the regtest, might be easier on the mainnet

[catch-21]

I experienced this again today on mainnet. Steps:

1. Sent 500_000 from non-bitkit wallet to bitkit wallet, received to address bc1q2je4wd4mgquyztdurqal6mu03sqh0sw3srq4am, see tx 75cc03d854378cd81fb8dca09b862191a72405a71ec5745324f8419d49618fb0
2. Perform manual channel setup sending 325_436 to lightning node, see tx 1fece6742c84cd1ae06894911870540907726249217e60a281201b4790d2460c
3. Close all lightning channels (one pre-existing with 1_500 spending balance and the manually created one). The pre-existing channel used the same address as in step 1 to return the 1_500, see tx
   4049b0f3b7696d1d4fb7a6b392e62c32d10106c72f60a1531df07b03e5016cf5

[catch-21]

Again today on mainnet with address bc1q5em7x9uf0qw88pwzn49cghfqxak9utd05fhv5u

Similar to above, I closed a channel and it returned funds to an address that had already been used to return funds from spending balance the day before.

[limpbrains]

Thing with closing channels is expected because you have to provide an address for channel refunds at the opening

[catch-21]

Thing with closing channels is expected because you have to provide an address for channel refunds at the opening

Sure. Maybe a dedicated derivation path to isolate those, a separate account? I would say extend the fourth level used for change but that would break BIP-44.