Ruben Somsen [ARCHIVE] on Nostr: 📅 Original date posted:2022-09-29 📝 Original message:Hi Eloy, Nice idea. Note I ...
📅 Original date posted:2022-09-29
📝 Original message:Hi Eloy,
Nice idea.
Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
I agree with your general assessment that this is a scheme that seems like
an improvement over the status quo. Note that both BIP47 and Silent
Payments don't require any interaction with the sender, while this scheme
requires one-time interaction (e.g. this wouldn't be suitable for one-time
donations). I think this would mostly be a convenience feature that
improves the regular interactive payment flow (interact once, instead of
repeatedly asking for addresses with each payment).
>master / purpose' / coin_type' / contact' / index
Despite your explanation, it's still not fully clear to me how "contact" is
defined, but I assume it's just a counter? Just in case, note that you
can't let Bob define it for Carol, as then you can't deterministically
recover your payments without also backing up how it's defined (the seed
alone won't be enough).
The gap limit also needs to be kept in mind. If we allow each xpub to have
its own gap limit, you potentially get an exponential blowup (gaps in the
xpub * gaps in the addresses generated from the xpubs). It may be OK to
define a low default gap limit for these xpubs, since there should be no
reason to expect the same sender to leave any gaps, though this may depend
on how the xpubs are used (e.g. it may also be used to derive addresses for
others) so it's probably important to be explicit about this.
Cheers,
Ruben
On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is a known issue on bitcoin, that is that every transaction requires
> a new address to prevent address reuse, making it uncomfortable to make
> recurring payments, as every payment requires a new off-chain interaction.
> A scheme is already mentioned on the [on the BIP32 itself][1], but it
> cannot be implemented as is.
>
> Here I propose a scheme that follows the structure described on [BIP44]
> that should make it possible to send recurring payments using a single
> offline interaction.
>
> The proposed scheme is:
>
> master / purpose' / coin_type' / contact' / index
>
> Where the definitions of all the levels follow BIP44, except for `contact`
> that is described below.
>
> Example usage: Bob wants to make recurring payments to Carol, so he asks
> her for a _contact address_, that is, an extended public key.
>
> Bob can use that public key to generate multiple derived addresses to make
> multiple recurring payments to Carol, the contact address is stored
> off-chain, anyone inspecting the chain will just see normal transactions
> on-chain.
>
> ## Considerations
>
> [BIP47] tries to solve the same issue, but the solution is more complex
> and involves more on-chain transactions that involve data, this
> implementation simpler and requires less work to implement.
>
> Also, the derivation path might need some adjustments for different
> address types on bitcoin.
>
> Finally, this only works in a single direction and does not make it
> possible for Carol to send anything to Bob, as it would require Bob sending
> her a contact address.
>
> ## Advantages
>
> A positive side effect of using this, is that Bob can choose to send
> payments to Carol using multiple outputs, giving him more privacy.
>
> Also, those payments can be easily labeled by the receiving wallet, as
> they are received.
>
> Regards.
>
> ### References
>
> [1]:
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
> [BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
> "Reusable Payment Codes for Hierarchical Deterministic Wallets"
> [BIP43]:
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
>
> --- Eloy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220930/d73e6790/attachment-0001.html>;
📝 Original message:Hi Eloy,
Nice idea.
Note I thought about and succinctly described a similar scheme here (which
in turn was derived from work by Kixunil):
https://gist.github.com/RubenSomsen/c43b79517e7cb701ebf77eec6dbb46b8#xpub-sharing
I agree with your general assessment that this is a scheme that seems like
an improvement over the status quo. Note that both BIP47 and Silent
Payments don't require any interaction with the sender, while this scheme
requires one-time interaction (e.g. this wouldn't be suitable for one-time
donations). I think this would mostly be a convenience feature that
improves the regular interactive payment flow (interact once, instead of
repeatedly asking for addresses with each payment).
>master / purpose' / coin_type' / contact' / index
Despite your explanation, it's still not fully clear to me how "contact" is
defined, but I assume it's just a counter? Just in case, note that you
can't let Bob define it for Carol, as then you can't deterministically
recover your payments without also backing up how it's defined (the seed
alone won't be enough).
The gap limit also needs to be kept in mind. If we allow each xpub to have
its own gap limit, you potentially get an exponential blowup (gaps in the
xpub * gaps in the addresses generated from the xpubs). It may be OK to
define a low default gap limit for these xpubs, since there should be no
reason to expect the same sender to leave any gaps, though this may depend
on how the xpubs are used (e.g. it may also be used to derive addresses for
others) so it's probably important to be explicit about this.
Cheers,
Ruben
On Thu, Sep 22, 2022 at 5:18 PM El_Hoy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is a known issue on bitcoin, that is that every transaction requires
> a new address to prevent address reuse, making it uncomfortable to make
> recurring payments, as every payment requires a new off-chain interaction.
> A scheme is already mentioned on the [on the BIP32 itself][1], but it
> cannot be implemented as is.
>
> Here I propose a scheme that follows the structure described on [BIP44]
> that should make it possible to send recurring payments using a single
> offline interaction.
>
> The proposed scheme is:
>
> master / purpose' / coin_type' / contact' / index
>
> Where the definitions of all the levels follow BIP44, except for `contact`
> that is described below.
>
> Example usage: Bob wants to make recurring payments to Carol, so he asks
> her for a _contact address_, that is, an extended public key.
>
> Bob can use that public key to generate multiple derived addresses to make
> multiple recurring payments to Carol, the contact address is stored
> off-chain, anyone inspecting the chain will just see normal transactions
> on-chain.
>
> ## Considerations
>
> [BIP47] tries to solve the same issue, but the solution is more complex
> and involves more on-chain transactions that involve data, this
> implementation simpler and requires less work to implement.
>
> Also, the derivation path might need some adjustments for different
> address types on bitcoin.
>
> Finally, this only works in a single direction and does not make it
> possible for Carol to send anything to Bob, as it would require Bob sending
> her a contact address.
>
> ## Advantages
>
> A positive side effect of using this, is that Bob can choose to send
> payments to Carol using multiple outputs, giving him more privacy.
>
> Also, those payments can be easily labeled by the receiving wallet, as
> they are received.
>
> Regards.
>
> ### References
>
> [1]:
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#recurrent-business-to-business-transactions-nmih0
> [BIP47]: https://github.com/bitcoin/bips/blob/master/bip-0047.mediawiki
> "Reusable Payment Codes for Hierarchical Deterministic Wallets"
> [BIP43]:
> https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki#Purpose
>
> --- Eloy
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220930/d73e6790/attachment-0001.html>;