search

bitpay / wallet

Bitpay Wallet (formerly Copay) is a secure Bitcoin and other crypto currencies wallet platform for both desktop and mobile devices.
http://bitpay.com/wallet
MIT License
3.8k stars 1.74k forks source link

Address derivation look ahead window #4603

Open Derrick- opened 8 years ago

Derrick- commented 8 years ago

It appears that the current functionality of balance calculation does not look ahead at all. BIP44 specifies (or recommends) that the HD wallet look ahead 20 addresses. https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit

Currently Copay does support manual forward scanning, however this feature is buried very deeply in the "Wallet Info" screen under Advanced Settings -> Wallet Info: "Scan for funds"

The use case, in addition to being compliant with BIP44 specification of 20, is for using the wallet xpub in 3rd party apps which will generate addresses, such as for storefront payment plug-ins.

I do not consider this functionality an Advanced Feature (https://github.com/bitpay/copay/issues/4600#issuecomment-233226285), as I can see new bitcoin users which do online sales being anxious to begin accepting bitcoin payments or donations if they have such a storefront or other application.

Related: From https://github.com/bitpay/copay/issues/2865#issuecomment-109580338

"The only problem is that currently I don't think the wallet does any look ahead, and it only watches an address as soon as it is displayed on someone's Copay screen."

The look ahead scanning does take some time, and if the user had to wait for this it might be detrimental to the initial experience, so i would recommend doing this in the background after the wallet is created.

matiu commented 8 years ago

It is not clear to me that BIP44 specifies any look ahead. The link you mention: https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit seems to be related to "Account discovery", a one time process.

Derrick- commented 8 years ago

Yes, looking again I do see that it is under the recovery heading, I guess this isn't a compliance issue technically.

However, it seems logical to assume any wallet which provides an xpub should expect that addresses might be generated from that key, as such the look ahead of 20 still seems applicable as it is essentially the same case as recovery.

If it is thought that the overhead of scanning those 20 addresses might be a problem for all users, perhaps the wallet would only be put in such a forward scanning mode if the xpub is viewed or copied by the user.

matiu commented 8 years ago

Thanks on the follow up. I see the use case, I think we discuss it some time ago, no sure if a 20 address gap is necessary in this case, maybe a 2-3 look ahead window should be enough, to allow the a seed to be used at the same time in different wallets... what you think?

I am renaming the ticket time, according to this discussion. Please rename it again if find it inaccurate.

Derrick- commented 8 years ago

For my use cases 10+ would be more reliable. I really think 20 would be best because it seems to be in line with what other wallets do (Electrum is 20 and Trezor is 25). However I can see reducing the number if it significantly impacts performance.

One of my actual in-production use cases: I am using xpubs to generate payment screens for customers who sign up for (openbazaar hosting) services, a fully automated process. It has been common that users get as far as the payment screen and then do not pay (wasting those addresses). The goal here is to be able to receive these funds directly to a Copay multisig account.

Another is: BEWP, a bitcoin enabled Wi-Fi portal (https://bitcoinstarter.com/projects/bewp-bitcoin-enabled-wifi-portal/), with which we would like to promote Copay as the recommended wallet.

Although my particular use cases might be less common, I can still see how web storefronts have the potential to have a few skipped addresses; i.e., checkouts that never get paid. I don't think 2 or 3 would be enough in those more common cases either.

dabura667 commented 8 years ago

imo, Copay should look all the way up to 20 empty addresses after the higest index address with any tx history.

Some wallets look at 20 cummulative empty addresses, but I think that promotes address reuse in those merchant use cases.

pooleja commented 8 years ago

I would propose that this look ahead window should be configurable (with PopChest we would have hundreds of views in a row without paying)

paintballpanda commented 8 years ago

Another request for a 20 address window please.

I am using a Trezor in combination with Copay on mobile. I never send funds from Copay but use it as a watch-only wallet, using the xpub of the Trezor wallet to be able to monitor the wallet's balance.

Whenever I send from the Trezor using Electrum, and then try to get an updated balance on Copay on mobile, I always have to rescan all addresses in order to see what the balance is.

Also another use case is where I am receiving payments to an xpub and in order for Copay to see it I have to manually forward scan the addresses.

Would be great if Copay had an option to automatically do this on startup.

jodyrb commented 8 years ago

Same request here... thank you!

dabura667 commented 8 years ago

I got around this with my trezor by just tapping generate new address many many times on first boot.

The cost to reward ratio is very high for this feature, as anyone having this problem cluld just generate the addresses with a few taps of the button.

assaf-meiry commented 6 years ago

hi, whats the status on that issue? is there a way to force the client full scan for known addresses? or change window size ? thanks in advance, a