From f1c188faa55adb84ea0972dd451f319355c2860c Mon Sep 17 00:00:00 2001 From: josibake Date: Tue, 6 Jun 2023 15:10:48 +0200 Subject: [PATCH] add backward compatibility blurb --- bip-0000.mediawiki | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/bip-0000.mediawiki b/bip-0000.mediawiki index 29aab525b1..c6a55d66d4 100644 --- a/bip-0000.mediawiki +++ b/bip-0000.mediawiki @@ -276,6 +276,10 @@ Since each silent payment output address is derived independently, regular backu If using a seed phrase only style backup, the user can recover the wallet’s unspent outputs from the UTXO set (by only scanning transactions with at least one unspent taproot output) and can recover the full wallet history by scanning the blockchain, starting from the wallet birthday. If a wallet uses labels, this information SHOULD be included in the backup. If the user does not know whether or not labels were used, they can precompute a large number of labels based on a safe upper bound (e.g 100k labels) to use when re-scanning. +== Backward Compatibility == + +Silent payments introduces a new address format and protocol for sending and as such is not compatible with older wallet software or wallets which have not implemented the silent payments protocol. + == Appendix A: Light Client Support == This section proposes a few ideas for how light clients could be supported in ways that preserve bandwidth and privacy. While this is out of scope for the current BIP, it is included to movitate further research into this topic. In this context, a light client refers to any bitcoin wallet client which does not process blocks and does not have a direct connection to a node which does process blocks (e.g a full node). Based on this definition, clients that directly connect to a personal electrum server or a bitcoin node are not light clients.