bip-0044: scan just external chains

prusnak commented at 3:32 pm on May 21, 2014: contributor

prusnak commented at 5:57 pm on June 11, 2014: contributor

bump

luke-jr commented at 6:01 pm on June 11, 2014: member

Why shouldn’t they be allowed? You can’t really control the order your own transactions get confirmed.

prusnak commented at 6:04 pm on June 11, 2014: contributor

This is a specification. You are free to do whatever you want, but then you are not compliant to this specification.

luke-jr commented at 6:05 pm on June 11, 2014: member

I suggest not requiring unreasonable things in this specification.

prusnak commented at 6:09 pm on June 11, 2014: contributor

As a wallet implementer you are perfectly in control how you work with internal (change) chains.

sipa commented at 6:13 pm on June 11, 2014: member

You’re not in control of the order in which different transactions that create independent change confirm.

It’s reasonable to expect that the gaps in an internal chain will be much less common than in external chains, though.

wozz commented at 6:17 pm on June 11, 2014: contributor

Unless you reuse change addresses until there is a certain number of confirmations on the last change address. Electrum does that currently, which I assume is by design.

luke-jr commented at 6:18 pm on June 11, 2014: member

@wozz Addresses should never be used more than once. That behaviour is a bug.

wozz commented at 6:22 pm on June 11, 2014: contributor

Restoring from seed gets a lot more complicated if you create new addresses without waiting for confirmations. It’s a tradeoff between reusing addresses and restoring a chain from a seed.

If you get to the gap limit in your change chain, should the wallet prevent you from creating new transactions until one of the current transactions confirms?

bip-0044: scan just external chains ba1cca2225

prusnak commented at 6:25 pm on June 11, 2014: contributor

Rephrased the wording.

luke-jr commented at 6:29 pm on June 11, 2014: member

@wozz No, it should just continue making addresses beyond the gap limit, or perhaps start another internal chain. If this makes trouble restoring from seed, then a user option to extend the gap limit is advisable.

laanwj commented at 6:30 pm on June 11, 2014: member

NACK. Having to reuse addresses to avoid gaps is a terrible solution.

prusnak commented at 6:33 pm on June 11, 2014: contributor

Please review the commit, not some random conversation of people that have nothing to do with the request.

laanwj commented at 6:43 pm on June 11, 2014: member

OK it seems you completely changed the commit from what the pull title says.

Surely, you still need to scan the internal chain. The requirement that keys there receive coins only ‘from’ addresses in the external chain (which is debatable, what about spending from multisig addresses?) could help optimize the scan, but it doesn’t avoid it.

prusnak renamed this:
~~bip-0044: don't allow gaps in internal chains~~
bip-0044: scan just external chains
on Jun 11, 2014

prusnak commented at 6:58 pm on June 11, 2014: contributor

If you are going to send change from a multisig transaction to an internal change without ever touching the external chain then you are on your own. The worst thing that can happen to you is that you use change address twice by accident. It’s not wise to force all BIP-0044 implementers to scan two chains instead of one just because of this hypothetical case.

prusnak commented at 11:36 pm on June 15, 2014: contributor

I just realized that your case is not even hypothetical. There is no way a BIP44 compatible wallet would end up with coins on an internal chain without touching the external one. So please let this one in …

laanwj commented at 3:38 pm on June 16, 2014: member

Well, I won’t argue anymore, it’s your BIP.

laanwj referenced this in commit 91f026a40f on Jun 16, 2014

laanwj merged this on Jun 16, 2014

laanwj closed this on Jun 16, 2014

prusnak commented at 3:49 pm on June 16, 2014: contributor

Thank you!

janmoller commented at 8:02 am on June 24, 2014: none

There is no way a BIP44 compatible wallet would end up with coins on an internal chain without touching the external one.

But there is.

You have a wallet with one unspent output (1) on your external chain.
You send a fraction of your coins to some external address and end up with one unspent output (2) on your internal chain.
You do a second spending with a fraction of your coins and end up with a new unspent output (3), also on the internal chain

The last transaction you sent did not touch your external chain. If you don’t scan the internal chain you won’t find unspent output number 3 when scanning the wallet from scratch.

prusnak commented at 8:37 am on June 24, 2014: contributor

@janmoller if you have UTXO on external chain then you already “touched it”, no? The sentence just specifies the account discovery, not the discovery of UTXOs on chains .

janmoller commented at 9:11 am on June 24, 2014: none

@prusnak the thing is that you can have a very long chain of transactions send from your internal chain by continuously doing step 3 as described above. How will you discover those addresses on your internal chain by scanning the external chain only?

prusnak commented at 9:14 am on June 24, 2014: contributor

@janmoller: i’ll repeat, this is just about the account discovery i.e. if account should be considered as “unused” or “used”. if it’s “used” than both chains are properly examined using gap limit. just for discovery purposes only the external chain is checked.

If you think this idea could be rephrased in a better way in the spec I would love you to draft such change.

janmoller commented at 9:30 am on June 24, 2014: none

@prusnak very well. I was under the impression that the Account Discovery section was about figuring out which address ranges were in use. If the Account Discovery section is only for figuring out whether an account is used or not, then I suggest removing the Address Gap Limit sub section and just mention that the first 20 addresses should be scanned.

For completeness it would be great if the BIP then had another section that described how to do address range discovery of external and internal chains. There the Address Gap Limit section would come to its right.

prusnak commented at 9:39 am on June 24, 2014: contributor

@janmoller Feel free to submit a pull request and I will review it. I would love to see someone rewriting our ideas in a less confusing way instead of just dismissing the idea as a whole without trying to understand it first like we’ve all seen above.

jachiang referenced this in commit 9424700d78 on Sep 16, 2019

real-or-random referenced this in commit 9965880f6c on Feb 23, 2023

bip-0044: scan just external chains #66