public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

From: El_Hoy <eloyesp@gmail•com>
To: Bitcoin DEV <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] RFC for a BIP32 recurrent address derivation scheme
Date: Thu, 22 Sep 2022 00:06:50 -0300	[thread overview]
Message-ID: <CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 2123 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2762 bytes --]

next             reply	other threads:[~2022-09-22  3:07 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-22  3:06 El_Hoy [this message]
2022-09-29 22:41 ` Ruben Somsen
2022-10-04 19:08   ` El_Hoy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAPapNH28iCxEcTOKt3YC+zuZzxbM=AudbbYByjS3aUZAgFHUag@mail.gmail.com' \
    --to=eloyesp@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox