BIP47, ugly duckling - New day crypto

One of the main disasters of the Bitcoin protocol is the reuse of addresses.Transparency and distributionTo avoid the problems associated with it, it is recommended to use a new empty address [...]

"He's too big," they all said, andthe Indian rooster, who seemed to have been born with spurs and considered himself an emperor, pouted like a ship with all sails raised, and went straight at him with eyes red with great fury. The poor duck did not know whether to stop or go: he was bitter because all the ducks of the yard despised him.

One of the major disasters of the Bitcoin protocol isaddress reuse. The transparency and distribution of the network makes this practice dangerous for user privacy. To avoid the problems associated with this, it is recommended to use a new empty address to receive each new payment, which can be difficult in some cases.

This compromise is as old as Nakamoto's whitepaper itself. Already in it, Satoshi warned about the risks of address reuse:

"As an added security measure, a new key pair should be used for each transaction so that they are not associated with a common owner."

There are many solutions for gettingmultiple payments without address reuse, each with its own trade-offs and drawbacks. One of them is BIP47, a proposal to implement reusable payment codes in Bitcoin developed by Justus Ranvier and published back in 2015. The goal is to allow multiple transactions with the same user without address reuse.

Initially this offer was very coldadopted by part of the community, and was never added to Bitcoin Core. Until now, some programs prefer to implement it on their own. So, Samourai Wallet has developed its own implementation of BIP47: PayNym. Today, this implementation is apparently available in Samourai Wallet for smartphones and Sparrow Wallet for PC.

Over time, Samourai began to develop newfeatures directly related to PayNym. To date, they offer a whole ecosystem of tools to optimize user privacy based on PayNym and BIP47.

In this article, I will explain in detail the principlesBIP47 and PayNym, the mechanisms of operation of these protocols and some practical applications that follow from them. I will only talk about the first version of BIP47 here, the one currently used for PayNym, but versions 2, 3 and 4 work in much the same way.

The only significant difference is innotification transactions. v1 uses a simple address with OP_RETURN for notification, v2 uses a multisig script (bloom-multisig) with OP_RETURN, and v3 and v4 just uses a multisig script (cfilter-multisig). Therefore, the mechanisms described in this article, including cryptographic methods, are applicable to all four versions. Today, the PayNym implementations in Samourai and Sparrow Wallet use the first version of BIP47.

Navigation:

Address reuse problem →
How BIP47 and PayNym work →
How-to: Using PayNym →
- Building a BIP47 transaction in Samourai Wallet →
- Building a BIP47 transaction in Sparrow Wallet →
How BIP47 Works →
- Reusable payment code →
- Cryptographic method: Elliptic-Curve Diffie-Hellman (ECDH) →
- Notification transaction →
- Building a Notification Transaction →
- Receive notification transaction →
- BIP47 payment transaction →
- Receive a BIP47 payment and receive a private key →
- BIP47 payment refund →
Derivative Use Cases for PayNym →
My opinion on BIP47 →

Address reuse problem

The receiving address is used to receive incomingbitcoin transactions. It is generated from the public key by hashing and applying a certain format to it. This allows for each incoming payment to create a new disbursement condition by changing its owner.

In addition, you have probably already heard from experienced andinformed bitcoiners that receiving addresses are for one-time use, and therefore a new address must be generated for each new incoming payment. Okay, but why is that?

Basically, a direct threat to your fundsreuse of addresses does not incur. Using elliptic cryptography allows you to prove to the network that you own the private key without revealing the key itself. So you can block multiple UTXOs on the same address and spend them at different times. This will not give anyone access to your funds, unless you disclose your private key associated with this address. But reusing addresses creates a privacy problem.

As mentioned above, transparency andThe distribution of the Bitcoin network implies that any user with access to a network node can observe all transactions of the payment system. As a result, he can also see address balances. Satoshi Nakamoto mentioned the ability to generate new key pairs - and hence new addresses - for each new payment that enters the wallet. The goal is to have additional protection—a kind of firewall—in case a user's identity is associated with one of their key pairs.

Today, with the development of specialized inblockchain analysis of companies and the spread of KYC practices in the crypto market, generating new empty addresses for each new transaction is no longer an additional security measure, but a mandatory measure for anyone who is at least minimally worried about their own privacy.

The desire for privacy is not a comfort or fantasy of a bitcoiner maximalist. This setting directly affects your personal security and the security of your funds. Here's a very specific example:

Bob buys bitcoins little by little through regularperiods of time to smooth out the entry price (dollar cost averaging). It systematically sends purchased funds to the same receiving address. Buys 0.01 BTC every week and sends them to the same address. After two years, Bob had accumulated a full BTC in this address.
The bakery around the corner accepts payment in BTC.Satisfied with the opportunity to conveniently spend BTC on daily needs, Bob goes to buy a bun for Satoshi. For payment, he uses satoshi from the same bitcoin address. The baker now knows that Bob owns the bitcoins. A large wallet balance (and the baker can look at it in a click or two) can make people jealous, and Bob risks being physically attacked.

Address reuse allows an observer to establish an undeniable link between your various UTXOs, and sometimes that means between your identity and your entire Bitcoin wallet balance.

It is for this reason that mostBitcoin wallets automatically generate a new receiving address whenever you click the «Receive» button. Therefore, for a simple user of a non-custodial wallet, the need to use new empty addresses often does not cause much inconvenience. However, for an online business, exchange, or fundraising campaign, this limitation can quickly become unmanageable.

For such organizations, there are many solutions, each with its own advantages and disadvantages, but today and as we will see below, BIP47 really stands out from the rest.

The problem of address reuse inBitcoin should not be underestimated. As you can see from the graph below from oxt.me, the total share of address reuse by Bitcoin users is currently ~50%:

Most of these cases of repeateduse falls on the exchanges, which are guided by considerations of simplicity and efficiency. And today BIP47 is the best solution to stop this phenomenon on the exchanges. The transition of exchange wallets to this standard would significantly reduce the overall level of address reuse, without creating great difficulties for these network entities. Measuring the overall indicator across the network in this case is completely appropriate. Indeed, address reuse is a problem not only for its owner, but also for everyone who sends transactions to this address. The loss of privacy in Bitcoin acts like a virus, spreading from user to user. Tracking a common metric for all network transactions allows us to understand the magnitude of the phenomenon.

How BIP47 and PayNym work

The purpose of BIP47 is to offerusers an easy way to receive a large number of payments without reusing addresses. The principle of its operation is based on the use of a reusable payment code.

The protocol allows multiple payments to be sent to one reusable payment code without the need for the recipient to transmit a new empty address for each new transaction.

The user can freely publish such a payment code on social networks or on a website without the risk of losing privacy, unlike a classic bitcoin address or public key.

To make an exchange for both usersyou need to have a bitcoin wallet that supports BIP47, such as PayNym in Samurai or Sparrow Wallet. Linking the payment codes of two users will allow you to establish a secret channel between them. To do this, the sender will need to complete a notification transaction on the Bitcoin blockchain; I will talk about this in more detail later.

Linking billing codes of two userscreates a shared secret that allows the generation of a large number of unique BTC receiving addresses (2^32 to be exact). Thus, in reality, a payment from BIP47 is sent not to a payment code, but to quite a classic-looking address generated from the payment codes of the protagonists.

That is, the payment code works as a virtual identifier obtained from the seed value of the wallet. In the HD wallet derivation structure, the payment code is at depth 3, at the wallet account level.

Its derivation target is marked as 47′ (0x8000002F), from BIP47. The derivation path for a reusable payment code would, for example, be like this:

m/47'/0'/0'/

And for an example of what the billing code itself looks like, here's mine:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

It can also be encoded into a QR code for easier communication:

As for PayNym-bots - pictures with robots,found on crypto twitter are just visual representations of your payment code generated by Samourai Wallet. They are created using a hash function, which makes each such image unique. This is what mine looks like, with ID:

+throbbingpond8B1

These «bots» have no real technical application. They only facilitate interaction between users, creating a virtual visual identity.

For the user, the BIP47 payment process through PayNym looks very simple. Let's say Alice wants to send several payments to Bob:

Bob gives her his QR code in any way ordirectly reusable payment code. He can post it publicly on his website, social networks or send it in private messages.
Alice opens the Samurai or Sparrow wallet and scans or pastes Bob's payment code.
Alice enables Bob's PayNym tracking by clicking «Follow». This operation is not recorded on the blockchain and is completely free.
Alice establishes a connection between her PayNymand Bob's PayNym by clicking «Connect». This transaction is performed on-chain and Alice must pay a transaction fee as well as Samourai's fixed fee of 15,000 satoshi for providing the service. This step is called a «notification transaction».
After confirming the transaction notification Alicecan create a BIP47 payment transaction to Bob. At the same time, his wallet will automatically generate a new empty receiving address, for which only Bob has the private key.

Notification transaction, i.e.Establishing a connection between your PayNym and the recipient's PayNym is a mandatory preliminary step for making BIP47 payments. On the other hand, once this is done, the sender will be able to make multiple (2^32) payments to the recipient without having to worry about address reuse and without the need for a repeated notification transaction.

As you can see, there are two separate operations,allowing you to establish a connection between PayNym users: Follow and Connect. The connection operation («Connect») corresponds to a BIP47 notification transaction, which is a simple Bitcoin transaction with certain information passed in the OP_RETURN output. It helps establish an encrypted connection between two users to subsequently create a shared secret needed to generate new empty addresses for receiving BTC.

On the other hand, the operation of enabling tracking(«Follow» or «Link») allows you to establish a connection between users in Soroban, a Tor-based encrypted communication protocol specifically developed by the Samourai teams.

In summary:

Simple tracking («follow») PayNymanother user absolutely free. This helps establish an encrypted off-chain connection, in particular for using collaborative (Stowaway or StonewallX2) transaction tools in Samourai. This operation is specific to PayNym and is not described in BIP47.
Establishing a connection between two PayNyms −paid operation. This implies the execution of a notification transaction that initiates such a connection. Its cost consists of the service fee, the usual network transaction fee and 546 satoshi sent to the recipient's address to notify the opening of the payment tunnel. This operation is described in BIP47. After it is completed, the sender can make many confidential BIP47 payments to the recipient's reusable billing code.

To establish a full connection between two PayNyms, the sender first needs to «follow» Recipient's PayNym.

Instructions: Using PayNym

After getting acquainted with the theory, let's walk togetherfor practical use. The idea behind the instructions below is to link my PayNym in Sparrow Wallet to my other PayNym in Samourai Wallet. In the first tutorial, I show you how to make a transaction using a reusable payment code from Samourai to Sparrow Wallet, in the second one, everything is the same, but from Sparrow to Samourai.

I ran this entire demo on a testnet, these are not real bitcoins.

Building a BIP47 transaction in Samourai Wallet

To get started, you'll obviously need the Samourai Wallet app. It can be installed from the Google Play Store or directly from the APK file available on the official Samourai website.

After initializing your wallet, if you have not already done so, generate your PayNym by clicking on the (+) in the lower right corner and selecting «PayNym».

The first step to making BIP47 payments is to receive our payee's reusable billing code. Then we can follow it, and then establish a connection:

After confirming the notification transaction, II will be able to confidentially send many transactions to my recipient. Each transaction will automatically be sent to a new empty address, the keys to which the recipient has. The latter does not need to take any action, everything is calculated on my side.

Here is how to make a BIP47 transaction in Samourai Wallet:

Building a BIP47 transaction in Sparrow Wallet

To do this, obviously, you will need to install the Sparrow app. It is only available for PC. You can download it from the official site.

Do not forget to check the developer's signature and the integrity of the downloaded software before installation.

Create a wallet and request your PayNym by clicking on «Show PayNym» in the «Tool» menu top panel:

Next you will need to bind(«Follow») your PayNym to the recipient's PayNym and establish a connection between them. To do this, enter the reusable payment code in the «Find Contact» window, follow it, then complete the notification transaction by clicking «Link Contact»:

After confirming the notification transaction, it will be possible to send payments to the payee's reusable billing code. Here's how to do it:

Now that we have seen the practical use of PayNym, let's take a look at how these mechanisms work and what cryptographic methods they use.

How BIP47 Works

Reusable payment code

As mentioned above, in the second part of thisarticles, the reusable payment code is at a depth of 3 HD wallet. It can be compared to xpub in some ways - both in terms of location and structure, and in terms of its role.

An 80-bit payment code consists of the following parts:

Byte 0: version. If we use the first version of BIP47, this byte will be 0x01.
Byte 1: bit field. This space is reserved for additional guidance in case of specific use. With a simple use of PayNym, this byte will be 0x00.
Byte 2: parityy. This byte can be either 0x02 or 0x03 depending on whether the ordinate value of our public key is even or even.
Bytes 3–34: meaningx. These bytes point to the abscissa of our public key. Concatenationxand parityygives us a compressed public key.
Bytes 35-66: string code. This place is reserved for the string code associated with the public key mentioned above.
Bytes 67-79: padding. This space is reserved for possible future developments. In version 1 it is simply padded with zeros up to 80 bytes, the size of the output's OP_RETURN data.

This is the hexadecimal representation of my reusable billing code shown in the previous part:

0x010002A0716529BAE6B36C518AA52F9C828282D90774747F0DCD4D9A39A97C370C390D842F364086362F412E2B0C7E7e7FC6E3287646A

Then we need to add the prefix byte «P» so that we can immediately determine that we are dealing with a payment code. This byte is 0x47.

0x47010002A0716529BAE6B36C518A52F9C8282D8D907474747F0DCD4D9A39E9C5F370C390C390D842F3640863622F412E2E2E364ARA

Finally, we calculate the checksum of thispayment code using HASH256, that is, we get a double hash using the SHA256 function. We extract the first four bytes of the resulting condensate and concatenate them to the end.

0x47010002a0716529bae6b36c5c9aa518a52f9c828b46ad8d907747f0d09dcd4d9a39e97c3c5f37c470c390d842f364086362f6122f412e2b0c7e7fc6e32287e364a7a36a00000000000000000000000000567080c4

The payment code is ready, it remains only to convert it to Base58:

PM8TJSBiQmNQDwTogMAbyqJe2PE2kQXjtgh88MRTxsrnHC8zpEtJ8j7Aj628oUFk8X6P5rJ7P5qDudE4Hwq9JXSRzGcZJbdJAjM9oVQ1UKU5j2nr7VR5

It can be seen that this construction strongly resembles the extended public key structure of the xpub type.

In this process to obtain the payment code weused a compressed public key and a string code. These two elements are the result of deterministic and hierarchical derivation from the wallet seed along the following path: m/47’/0’/0’/.

Specifically, to get the public key and chainreusable billing code code, we calculate the main private key from the seed value, and then get the child pair with an index of 47 + 2^31 (strong derivation). We then get the child pairs twice at index 2^31 (strong derivation).

Cryptographic method: Elliptic-Curve Diffie-Hellman (ECDH)

The cryptographic method used at the heart of BIP47 is ECDH (Elliptic-Curve Diffie-Hellman= Diffie–Hellman key exchange on elliptic curves). It is a variation of the classic Diffie–Hellman key exchange protocol.

The Diffie–Hellman protocol in its first versionwas introduced in 1976 and allows two people, exchanging information over an insecure communication channel, to securely determine a shared secret based on two pairs of keys (public and private).

This shared secret (red key) can then beused for other tasks. Basically this shared secret can be used to encrypt and decrypt messages on an insecure network:

For a successful exchange, the Diffie-Hellman protocol uses modular arithmetic to calculate the shared secret. In an accessible form, the scheme of its work can be described as follows:

Alice and Bob decide on a common color, in this case yellow. The color is known to everyone, this is open data.
Alice chooses her secret color, in this case red. The secret color is mixed with the common color to make orange.
Bob chooses his secret color, in this case navy blue. The secret color is mixed with the common color to form blue.
Alice and Bob can exchange the received colors: orange and blue. This exchange can take place on an insecure network that can be observed by intruders.
Alice mixes the blue she received from Bob with her secret color (red). Gets brown.
Bob mixes the orange color he received from Alice with his secret color (dark blue). Gets the same brown color.

In this simplified visual diagram, brownrepresents the secret that Alice and Bob shared with each other. Well, in this example, we need to imagine that it is impossible for an attacker to separate the orange and blue colors in order to determine the secret colors of Alice and Bob.

Now let's imagine how it works onreally. At first glance, the Diffie-Hellman algorithm seems difficult to understand. In fact, the principle of its work is almost childish. Before describing this mechanism in detail, let me remind you of two mathematical concepts that we will need for this (and are also used in many other cryptographic methods).

Prime number:a natural number that is divisible without remainder by only two divisors: 1 and itself. For example, the number 7 is prime because it is only divisible by 1 and 7 (itself). And the number 8 is not prime, because it is divisible without a remainder by 1, 2, 4 and 8. That is, it has not two, but four integer positive divisors.
«Modulus», or remainder of division(denoted as «mod» or «%»): a mathematical operation on two integers that returns the remainder of the Euclidean division of the first number by the second. For example, 16 mod 5 is equal to 1.

The Diffie–Hellman key exchange between Alice and Bob proceeds as follows:

Alice and Bob define two common numbers: p and g.p is a prime number. The larger this number p, the more reliable the Diffie-Hellman protection will be. g is the primitive root of p. These two numbers can be transmitted over an insecure network and are the yellow equivalents in the simplified diagram above. The p and g values of Alice and Bob must be the same.
After choosing the parameters, Alice and Bob determinerandom secret number. The random number received by Alice, we will call a and it is equivalent to the color red, and the random number received by Bob is b, it is equivalent to dark blue. These two numbers must remain secret.
Instead of directly exchanging these numbers a and b, each side will calculate A (capital) and B (capital). For example:

# A is equal to g to the power of a modulo p:A = g^a % p# B equals g to the power of b modulo p:B = g^b % p

Already these numbers A (equivalent to orange) and B (equivalent to blue) will be exchanged between the parties. The exchange can be carried out openly over an insecure network.
Alice, who now knows B, will calculate the value of z as follows:

# z is equal to B to the power of a modulo p:z = B^a % p

Let me remind you thatB = g^b % p. So we have:

z = B^a % p  z = (g^b)^a % p# In accordance with the rules for calculating degrees:(x^n)^m = x^nm# So we have:z = g^ba % p

Bob, who now knows the value of A, will also calculate the value of z as follows:

# z is equal to A of degree b modulo p:z = A^b % p# So we have:z = (g^a)^b % p  z = g^ab % p  z = g^ba % p

Alice and Bob find exactly the samez value. This number represents their shared secret, i.e. the equivalent of brown in the previous popular scheme. They can use this shared secret to encrypt a message between them on an insecure network.

An attacker who learned the meaningsp,g,AAndB, will not be able to calculatea,borz. This would require a calculationthe reverse of exponentiation. This value cannot be obtained except by a simple enumeration of the options, since we are working with a final field. This is equivalent to calculating the discrete logarithm, i.e. inverse exponent in a finite cyclic group.

Thus, if you choose large enough valuesa,bAndp, then the implementation of the Diffie–Hellman protocol will be secure. As a rule, with parameters of 2048 bits (600-digit number in decimal system), checking all possibilities foraAndbconsidered a chimerical task. Today, with numbers of this order, this algorithm is considered safe.

It is at this level that the main disadvantage lies.Diffie-Hellman protocol: for the algorithm to be safe, it must use large numbers. Therefore, today we prefer to use ECDH, a variant of the Diffie-Hellman algorithm that uses an algebraic curve in the calculations, in this case an elliptic one. This allows you to work with much smaller numbers while maintaining an equivalent level of security, and therefore reduce the resources required for computing and storage.

The general principle of the algorithm remains the same.But instead of using a random number a and A computed from it via modular exponentiation, we will use a pair of keys generated on an elliptic curve. And instead of relying on the distributivity of the exponentiation operator, we will use the group law of elliptic curves, or rather, the associativity of this law.

Roughly speaking, the private key is a random numberfrom 1 to n-1 (where n is the order of the curve), and the public key is the single point on the curve, determined by the private key by adding and doubling the points from the generating point, so:

K = k G

WhereK- public key,kis the private key, andG— generating point.

One of the properties of this key pair is that it is very easy to defineK, knowingkAndG, but today it is impossible to determinek, knowingKAndG: This is a one-way function.

In other words, one can easily calculate the openkey by knowing the private key, but it is not possible to compute the private key from the public key. This security, again, is based on the impossibility of calculating the discrete logarithm.

Therefore, we will use this property to adapt our Diffe–Hellman algorithm. Then the principle of operation of ECDH will look like this:

Alice and Bob jointly agree on a cryptographically secure elliptic curve and its parameters. This information is public.
Alice generates a random numberka, which will be her private key. This private key must remain secret. It determines the public keyKaby adding and doubling points selected on an elliptic curve.

Ka = ka G

Bob also generates a random number that will be his private keykb. And calculates the public key associated with itkb.

Kb = kb G

Alice and Bob exchange their public keysKaAndkbon an unsecured public network.
Alice computes a point (x,y) on the curve using your private keykafrom Bob's public keykb.

(x,y) = ka Kb

Bob computes a point (x,y) on the curve using your private keykbfrom Alice's public keyKa.

(x,y) = kb Ka

Alice and Bob end up with the same point on the elliptic curve. The common secret will be the abscissaxthis point.

They get the same shared secret because:

(x,y) = ka Kb = ka kb G = kb ka G = kb Ka

Potential intruder watchingan insecure public network, can only obtain the public keys of Alice and Bob, as well as the parameters of the selected curve. As I explained above, it is currently impossible to calculate private keys from these two pieces of information, so an attacker cannot gain access to the secret.

ECDH is an algorithm that allows the exchangekeys. It is often used to define a protocol along with other cryptographic methods. For example, ECDH is used at the heart of Transport Layer Security (TLS), the encryption and authentication protocol used at the transport layer of the Internet. TLS uses ECDHE, a variant of ECDH in which the keys are ephemeral, for key exchange to provide persistent confidentiality. In addition to ECDHE, TLS also uses an authentication algorithm like ECDSA, an encryption algorithm like AES, and a hash function like SHA256.

TLS defines, in particular, the letter «s»in the name «https», as well as the state of the small padlock that you see at the beginning of the search bar of your Internet browser, which signal to you that your Internet connection to this site is encrypted. So you are using ECDH and reading this article as you seem to be using it on a daily basis without even realizing it.

Notification transaction

As we already found out in the previous part, ECDH -it is a variant of the Diffie–Hellman exchange protocol using key pairs defined on an elliptic curve. It's good that key pairs meet this standard, because we have our bitcoin wallets!

So the idea is to usekey pairs of hierarchical deterministic bitcoin wallets of two stakeholders to create shared and ephemeral secrets between them. Within BIP47, we use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

The first time ECDHE is used in BIP47 fortransfer of the payment code from the sender to the recipient. This is the same notification transaction. Indeed, BIP47 requires each of the two parties (sender and payee) to know the other party's billing code. This will be needed to obtain ephemeral public keys and, accordingly, new empty receiving addresses.

Before this exchange, the sender logically already knowspayment code of the recipient: it could be published on the website or somewhere in social networks. But the recipient does not necessarily know the sender's billing code. It must be transferred to the recipient, otherwise he will not be able to calculate his ephemeral keys, and therefore, get access to the bitcoins sent to him. You can send the sender's payment code to it off-chain, using any other communication system, but this will create a problem if the wallet is restored from the seed value.

Indeed, as I mentioned, BIP47 addressescannot be obtained from the recipient's seed (otherwise one of its xpubs could be used directly), they are the result of a calculation based on two billing codes: the recipient and the sender. Therefore, if the recipient loses his wallet and tries to recover it from the seed, he will definitely need to have all the payment codes of the people who sent him bitcoins via BIP47.

So BIP47 could easily be used andwithout this notification transaction, but then each user would have to keep a backup copy of the payment codes of their peers. And this will remain a non-viable option until an easy and reliable way to perform, store and update such backups is found. So, in the current state of things, doing a notification transaction is almost mandatory.

In addition to storing payment codes, the notification transaction, as the name suggests, also serves to inform the recipient that a payment tunnel has been opened.

Before proceeding to explain the technicalOn the side of how the notification transaction works, I want to talk a little about the BIP47 privacy model. The use of BIP47 further justifies the necessary preparations with the execution of this initial transaction and the creation of a payment tunnel.

By itself, the payment code does not bear the risk of lossprivacy. Unlike the classical Bitcoin address model, which, according to the author's intention, breaks the relationship between the user's identity and transactions, including the preservation of the anonymity of public keys, a payment code can be directly associated with the identity of its owner. Obviously, this is not a prerequisite, but the presence of this connection does not bear any damage to the confidentiality of user transactions.

The payment code cannot be calculated from the addresses used to receive BIP47 payments. Instead, the addresses are obtained by applying the ECDHE with the child keys of the billing codes of both parties.

Therefore, the payment code itself does not carrya direct risk of loss of confidentiality, since only the address of the notification can be calculated from it. Some information can be extracted from this address, but it is usually impossible to find out who you are transacting with.

That is why it is so important to maintain this strictseparation between user payment codes. From this point of view, the initial stage of code transfer is a critical moment for ensuring the confidentiality of payments and at the same time mandatory for the correct functioning of the protocol. If one of the two billing codes can be made public (for example, on a website), then the second code, that is, the sender's billing code, should not be associated with the first.

Let's say I want to set up regular donations to a peaceful protest movement in Canada with BIP47:

Protest organizers posted the payment code on their website or social media.
It is clear that this code is associated with movement.
I receive this payment code from an open source.
Before I can send them a donation,I need to make sure they know my billing code, which is also linked to my identity since I posted it on my social media and used it to receive payments.

How can I give them my payment code?If I send it through the usual means of communication, it could be leaked and I risk being on the radar of the regulatory authorities as a scoundrel supporting peaceful protest movements.

The notification transaction is not the only one, of course.a possible solution for confidential transmission of the sender's billing code to the recipient, but at the moment it does an excellent job of this task, applying several layers of security.

In the diagram below, red lines indicate information flows that should be disrupted, and black arrows indicate undeniable connections that an outside observer can make.

In fact, for the classical modelBecause of Bitcoin privacy, it is often difficult to completely interrupt the flow of information between a key pair and a user, especially when transactions are made remotely. For example, in the case of a fundraising campaign, the recipient would have to disclose their address or public key somewhere on the site or on social media. Native use of BIP47 - that is, with a notification transaction - solves this problem thanks to ECDHE and the level of encryption, which we will look at later.

It is obvious that at the level of ephemeral openkeys obtained by combining two payment codes, the classic Bitcoin privacy model is still respected. These two models are interdependent. Here I just want to emphasize that, unlike using a classic public key to receive bitcoins, when linking a payment code to an individual, there is no loss of confidentiality, since the information connection «Bob makes a transaction with Alice» is violated at another moment. The payment code is used to generate the addresses, but based solely on on-chain data, the BIP47 payment transaction cannot be linked to the payment codes used to construct it.

Building a Notification Transaction

Now let's take a closer look at how it worksthis transaction notification. Let's say Alice wants to send money to Bob using BIP47. In my example, Alice will be the sender and Bob will be the receiver. Bob has posted his payment code on the site, so Alice already knows it.

1. Alice computes a shared secret with ECDH:

The algorithm chooses a pair of keys in itsHD-wallet, which is located on another branch of his payment code. Be careful: this pair should not be easily associated with either the address of the notification or the identity of Alice (see the previous part).
Alice chooses a private key for this pair. Let's denote it by the letter «a» (lowercase).

Alice receives the public key associated with the addressBob's notifications. This key is the first child received after Bob's payment code (index 0). Let's call it the public key «B» (capital). And the private key associated with this public key will be called «b» (lowercase). «B» is determined by adding and doubling points on an elliptic curve from «G» (generator point) to «b» (private key).

B = b G

Alice calculates the secret point «S» (capital) on an elliptic curve by adding and doubling using your private key «a» from Bob's public key «B».

S = a B

Alice calculates the blinding factor«f», with which it will encrypt your payment code. To do this, the algorithm determines a pseudorandom number using the HMAC-SHA512 function. The second input to this function is a value that only Bob can find: (x), which is the abscissa of the previously calculated secret point. The first input is (o), which is the UTXO used as the input of this transaction (outpoint).

f = HMAC-SHA512(o, x)

2. Alice converts her personal billing code to base 2 (binary).

3.This blinding factor is used as a key to perform symmetric encryption of its payment code. The encryption algorithm is simply XOR. The operation performed is comparable to the Vernam cipher (it is also called a «one-time pad»):

First, Alice divides her blindness factor into two parts: the first 32 bytes are called «f1», the second 32 bytes are called «f2». So we have:

f = f1 || f2

Alice calculates separately the encryptedthe abscissa (x’) of the public key (x) of your payment code, and the encrypted (c’) of your string code (c). «f1» and «f2» are used as encryption keys respectively. The XOR (or exclusive) operation is used:

x' = x XOR f1  c' = c XOR f2

Alice replaces the actual values of the abscissa of the public key (x) and string code (c) in her payment code with the encrypted values (x’) and (c’).

Before continuing the technical description of ournotification transactions, let's briefly dwell on this XOR operation. XOR is a bit-level logical operator based on boolean algebra. Of the two operands in bits, it returns 1 if the bits of the same rank are different, and 0 if the bits of the same rank are equal. This is how the XOR truth table looks like according to the values of operands D and E:

For instance:

0110 XOR 1110 = 1000

Or:

010011 XOR 110110 = 100101

With ECDH using XOR as a layerencryption is especially logical. First, thanks to this operator, encryption is symmetrical. This allows the recipient to decrypt the payment code using the same key that was used to encrypt it. The encryption and decryption key is calculated from the shared secret using ECDH.

This symmetry is possible due to the commutativity and associativity properties of the XOR operator:

# Other properties:  -&gt; D ⊕ D = 0  -&gt; D ⊕ 0 = D# Commutative:D ⊕ E = E ⊕ D# Associativity:D ⊕ (E ⊕ Z) = (D ⊕ E) ⊕ Z = D ⊕ E ⊕ Z# Symmetry:If: D ⊕ E = L  Then: D ⊕ L = D ⊕ (D ⊕ E) = D ⊕ D ⊕ E = 0 ⊕ E = E-&gt; D ⊕ L = E

This encryption method is very similar to the Vernam cipher(«one-time pad»), the only encryption algorithm known today that has unconditional (i.e. absolute) security. For a Vernam cipher to have this property, the encryption key must be completely random, be the same size as the message, and be used only once. In the encryption method used here for BIP47, the key is indeed the same size as the message, the blinding factor is the same size as the concatenation of the abscissa of the public key with the chain code of the reusable payment code. This encryption key is used only once. On the other hand, this key is not completely random since it is obtained from HMAC. This is a pseudo-random value. So it's not a Vernam cipher, but the method comes close.

Let's get back to building our notification transaction:

4.So, Alice currently has her own payment code with an encrypted payload. She will create and broadcast a transaction with her public key «A» at the input, output to Bob's notification address, and output OP_RETURN, consisting of her payment code with an encrypted payload. This is a notification transaction.

OP_RETURN is an opcode, i.e.script that allows you to mark the output of a bitcoin transaction as invalid. Today, it is used to propagate or record information on the Bitcoin blockchain. It can store up to 80 bytes of data, which is written to the blockchain and therefore visible to all other users.

As we saw in the previous part, the Diffie protocol– Hellman is used to create a shared secret between two users communicating over an insecure network and potentially under surveillance by attackers. In BIP47, ECDH is used to communicate over the Bitcoin network, which is inherently transparent and can be observed by anyone who is interested, including many potential attackers. The shared secret, calculated through Elliptic Curve Diffie-Hellman key exchange, is then used to encrypt the transmitted secret information: the sender's (Alice's) billing code.

Here is a diagram from BIP47 illustrating this process:

If we compare this scheme with my description, then:

«Wallet Priv-Key» on Alice's side matchesa.
«Child Pub-Key 0» on Bob's side matchesB.
«Notification Shared Secret» correspondsf.
«Masked Payment Code» corresponds to a hidden payment code, i.e. with encrypted payload:x’Andc’.
«Notification Transaction» is a transaction that contains OP_RETURN.

And to summarize the steps for performing a notification transaction that we have just covered:

Alice receives Bob's billing code and notification address.
Alice selects her own UTXO on her HD wallet with the corresponding key pair.
It calculates a secret point on an elliptic curve using ECDH.
This secret point is used by Alice to calculate the HMAC, which is the glare factor.
She uses this blinding factor to encrypt the payload of her personal billing code.
She uses the OP_RETURN output of the transaction to pass the hidden payment code to Bob.

To understand in more detail how it works,including the use of OP_RETURN, let's look at the actual notification transaction. I made such a transaction on the test network, you can go to it at this link.

TXID:

0e2e4695a3c49272ef631426a9fd2dae6ec3a469e3a39a3db51aa476cd09de2e

We can see that this transaction has one input and 4 outputs:

The first output is OP_RETURN which contains my hidden billing code.
The second output with 546 satoshi points to my recipient's notification address.
The third output with 15,000 satoshi contains the service fee, since I used Samourai Wallet to create this transaction.
The fourth output of two million satoshi is change, that is, the remainder of the face value of my input, returned to my other address.

Of greatest interest is obviously exit 0 with OP_RETURN. Let's look at it in more detail:

Here we see the exit script in hexadecimal format:

6A4C50010002B13B29111719409D704ECC69FA315A6CB20FDD6EE39874667703D67B164927B0E88F89F2533B5D7ED481A3BEA7E953B56B481A7E953B56B481A7E953BEAR

This script has several parts:

6a4c50010002b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d800000000000000000000000000# Opcodes:6a4c50# Metadata of my billing code in its purest form:010002# Encrypted abscissa of the public key of my payment code:b13b2911719409d704ecc69f74fa315a6cb20fdd6ee39bc9874667703d67b164# Encrypted chain code of my payment code:927b0e88f89f3f8b963549eab2533b5d7ed481a3bea7e953b546b4e91b6f50d8# Fill up to 80 bytes:000000000000000000000000000

Opcodes include 0x6a, which stands for OP_RETURN, 0x4c, which stands for OP_PUSHDATA1, and 0x50, which stands for OP_RESERVED.

Then comes the payment code with the encrypted payload.

Here is my cleartext payment code used in this transaction:

# With base 58:PM8TJQCyt6ovbozreUCBrfKqmSVmTzJ5vjqse58LnBzKFFZTwny3KfCDdwTqAEYVasn11tTMPc2FJsFygFd3YzsHvwNXLEQNADgxeGnMK8Ugmin62TZU    # С основанием 16 (HEX):  4701000277507c9c17a89cfca2d3af554745d6c2db0e7f6b2721a3941a504933103cc42add94881210d6e752a9abc8a9fa0070e85184993c4f643f1121dd807dd556d1dc000000000000000000000000008604e4db

If we compare my payment code (in clear text) with OP_RETURN, we will see that HRP and checksum are not transmitted. This is normal, because this information is for people.

And we can also find out the version (0x01), bitwisefield (0x00) and parity of the public key (0x02). And at the end of the payment code, there are just empty bytes (0x00), filling the remaining volume up to 80 bytes. All this metadata is transmitted in clear (unencrypted) form.

Finally, you can see that the abscissa of the public key and the string code have been encrypted. This is the payment code payload.

Receiving transaction notification

Now that Alice sent the notification transaction to Bob, let's see how Bob interprets it.

Let me remind you that Bob must have access to the paymentAlice code. Without this information, as we will see in the next part, he will not be able to deduce the key pairs generated by Alice and therefore will not be able to access his bitcoins obtained using BIP47. At the moment, Alice's payment code payload is encrypted. Let's now see how Bob deciphers it.

1. Bob monitors transactions that create outputs with his notification address.

2. Having found such a transaction, Bob analyzes it for the presence of an OP_RETURN output that complies with the BIP47 standard.

3. If the first byte of the OP_RETURN payload is 0x01, Bob starts looking for a possible secret sent from ECDH:

Bob chooses the transaction's entry public key, that is, the public key «A» Alice:

A = a G

Bob selects the private key «b» associated with his notification address:

Bob calculates the secret point «S»(ECDH shared secret) on an elliptic curve by adding and doubling the points using your private key «b» to the public key «A» Alice:

S = b A

Bob determines the glare factor«f», which will decrypt Alice's payment code payload. Just as Alice calculated it earlier, Bob will find «f» by applying HMAC-SHA512 to the (x) abscissa value of the secret point «S» and to (o) UTXO consumed as input of this notification transaction:

f = HMAC-SHA512(o, x)

4.Bob interprets the OP_RETURN data in the notification transaction as a payment code. It will easily decipher the payload of this potential payment code thanks to its blinding factor «f»:

Bob shares the blinding factor «f» into two parts: the first 32 bytes «f» will be «f1», and the second 32 bytes will be «f2».
Bob decrypts the value of the encrypted abscissa (x’) of the public key from Alice's payment code:

x = x' XOR f1

Bob decrypts the meaning of the encrypted string code (c’) of Alice's payment code:

c = c' XOR f2

5.Bob checks if the public key value of Alice's payment code is in the secp256k1 group. If it does, it interprets it as a valid billing code. Otherwise, it ignores this transaction.

Now that Bob knows Alice's payment code, she can send him up to 2^32 payments without having to repeat the same notification transaction.

Why does it work?How can Bob determine the same dazzle factor as Alice and therefore decipher his billing code? Let's take a closer look at the operation of ECDH in the process just described.

First of all, we are dealing with a symmetricalencryption. This means that the encryption key and the decryption key are the same value. In the notification transaction, this key is the blinding factor (f = f1 || f2). Therefore, Alice and Bob must obtain the same value of f without passing it directly, since an attacker can steal it and decrypt the secret information.

This glare factor is obtained byapplying the HMAC-SHA512 hash algorithm to two values: the abscissa of the secret point and the UTXO consumed as transaction input. To decrypt Alice's payment code payload, Bob needs these two pieces of information.

As for the login UTXO, Bob can get it simply from the on-chain transaction data of the notification. For the secret point, Bob will have to use ECDH.

As shown in the part about Diffie algorithm −Hellman, simply by exchanging their respective public keys and applying their private keys to each of their partner's public keys, Alice and Bob can determine exactly the same secret point on the elliptic curve. The notification transaction is based on this mechanism:

# Bob's key pair:  B = b G# Alice key pair:A = a G# For secret point S (x,y):S = a B = a b G = b a G = b A

Now that Bob knows Alice's payment code, he can determine her BIP47 payments to himself and calculate the private keys that block the bitcoins received in these transactions.

If we compare this scheme with my description, then:

«Wallet Pub-Key» on Alice's side matchesA.
«Child Priv-Key 0» on Bob's side matchesb.
«Notification Shared Secret» correspondsf.
«Masked Payment Code» corresponds to Alice's hidden payment code, i.e. with encrypted payload:x’Andc’.
«Notification Transaction» is a transaction that contains OP_RETURN.

And to summarize the steps for performing a notification transaction that we have just covered:

Bob tracks transactions with output to his notification address.
When it finds such a transaction, it retrieves the information contained in OP_RETURN.
Bob selects a public key from the input of the transaction and computes a secret point using ECDH.
It uses this secret point to calculate the HMAC, which is the dazzle factor.
It uses this blindness factor to decrypt the payload of Alice's payment code contained in OP_RETURN.

BIP47 payment transaction

Now let's take a look at the BIP47 payment process together. Let me briefly remind you of the current state of affairs:

Alice knows Bob's payment code: it was just published somewhere on the site.
Bob knows Alice's payment code thanks to the notification transaction.
Alice will now make the first payment to Bob. In the same way, she can make many more payments.

Before proceeding to explain this process, I think it's important to recall what index we're working with now:

We describe the payment code derivation path as follows: m/47’/0’/0’/.

The next depth distributes the indices in this way:

The first regular (non-enhanced) child pair is used to generate the notification address that we talked about in the previous part: m/47’/0’/0/0/.
Regular child key pairs are used in ECDH to generate BIP47 payment receiving addresses, as we will see in this part: m/47’/0’/0’/ 0 to 2,147,483,647/ .
Strengthened child key pairs are ephemeral payment codes: m/47’/0’/0’/ from 0′ up to 2 147 483 647’/.

Every time Alice wants to send a payment to Bob, she gets a new unique empty address, again thanks to the ECDH protocol:

Alice chooses the first private key obtained from her personal reusable billing code:

Alice chooses the first unused public key obtained from Bob's payment code. We'll call this public key «B». It is associated with a private key «b», known only to Bob.

B = b G

Alice calculates the secret point «S» on an elliptic curve by adding and doubling points using your private key «a» from Bob's public key «B».

S = a B

From this secret point Alice will calculate(tiny) shared secret «S». To do this, she selects the abscissa from the secret point «S» with the name «Sx» and passes this value to the sha256 hash function.

s = SHA256(Sx)

Alice uses this shared secret «S»to calculate the Bitcoin payment receiving address. First she checks that «S» is actually contained in the SECP256K1 curve sequence. If it is not, it increments Bob's public key index to obtain a different shared secret.
The second step is to calculate the public key«K0», adding points «B» on the elliptic curve. and «S g». In other words, Alice sums up the public key obtained from the payment code «B» Bob, with another point, calculated on the elliptic curve by adding and doubling points with a shared secret «s» from the generating point «G» curve SECP256K1. This new point represents the public key, and we'll call it «K0»:

K0 = B + s G

With this public key «K0» Alice can obtain a new empty receive address using a standard method (e.g. SegWit v0 or bech32).

Having received this receiving address belonging to Bob«K0», Alice can build a classic Bitcoin transaction by selecting a UTXO from another branch of her HD wallet and spending it on «K0» Bob's address.

If we compare this diagram from BIP47 with what I described earlier, then:

«Child Priv-Key» on Alice's side matchesa.
«Child Pub-Key 0» on Bob's side matchesB.
«Payment Secret 0» correspondss.
«Payment Pub-Key 0» correspondsK0.

And to summarize the steps for sending a BIP47 payment that we just covered:

Alice selects the first child private key obtained from her personal billing code:
It uses ECDH to calculate the secret point on the elliptic curve from the first unused child public key obtained from Bob's billing code.
She uses this secret point to calculate the shared secret using SHA256.
She uses this shared secret to calculate a new secret point on the elliptic curve.
She adds this new secret point to Bob's public key.
Gets a new ephemeral public key for which only Bob has the corresponding private key.
Alice can send a classic transaction to Bob with an ephemeral derived receive address.

If she wants to make a second payment, sherepeats all the same actions, but selects the second public key obtained from Bob's payment code, that is, the next unused key. Then she will receive Bob's second receive address «K1».

This can be repeated up to 2^32 times and get up to 2^32 new empty receive addresses owned by Bob.

From the point of view of an outside observer, it is theoretically impossible to distinguish a BIP47 payment from a regular bitcoin transaction. Here is an example of a BIP47 payment transaction on the testnet:

https://blockstream.info/testnet/tx/94b2e59510f2e1fa78411634c98a77bbb638e28fb2da00c9f359cd5fc8f87254

TXID:

94b2e59510f2e1fa78411634c98a77bbb638e28fb2da00c9f359cd5fc8f87254

It looks like a normal transaction with input consumed, output with 210,000 Satoshi payment and change:

Receive a BIP47 payment and receive a private key

So, Alice made her first BIP47 payment onan automatically generated new empty address owned by Bob. Now let's take a look at how Bob gets this payment together. We will also see why Alice does not have access to the private key of the address she just generated and how Bob finds that key to spend the bitcoins received in such a transaction.

When Bob receives a transaction from Alicenotifications, he receives the public key «K0» even before his BIP47 correspondent sent the payment. Therefore, it keeps track of any payments to the associated address. In fact, it will immediately calculate several addresses, which it will observe (K0, K1, K2, K3 …). Here's how he gets this public key «K0»:

Bob chooses the first child private key,obtained from his payment code. Let's call this private key «b». It is associated with the public key «B», with which Alice performed her calculations in the previous step:

Bob chooses Alice's first public key,obtained from her payment code. Let's call this key «A». It is associated with the private key «a», with which Alice performed her calculations and known only to Alice. Bob can carry out this process because he knows Alice's payment code, which was passed to him with the notification transaction.

A = a G

Bob calculates the secret point «S» byadding and doubling points on an elliptic curve using your private key «b» to the public key «A» Alice. Here we see the use of ECDH, which guarantees us that this point «S» for Bob and for Alice will be the same.

S = b A

Just like Alice did, Bob allocatesthe abscissa of this point «S». I called this value «Sx». It passes this value to the SHA256 function to find the shared secret «s» (lowercase).

s = SHA256(Sx)

Just like Alice, Bob calculates the point«s·G» on an elliptic curve. He adds this secret point to his public key «B». It then receives a new point on the elliptic curve, which it interprets as the public key «K0»:

K0 = B + s G

Once Bob has this public key «K0», he can get the corresponding private key to spend his bitcoins. Only he can generate this number.

Bob adds his child private key«b», obtained from his personal payment code. The meaning of «b» only he can get it. Then he adds «b» to the shared secret «s» to get k0, the private key of K0:

k0 = b + s

Thanks to the elliptic curve group law, Bob gets exactly the private key that matches the public key used by Alice. So we have:

K0 = k0 G

If we compare this diagram from BIP47 with what I described earlier, then:

«Child Priv-Key 0» on Bob's side matchesb.
«Child Pub-Key 0» on Alice's side matchesA.
«Payment Secret 0» correspondss.
«Payment Pub-Key 0» correspondsK0.
«Payment Priv-Key 0» correspondsk0.

And to summarize the steps to receive a BIP47 payment and calculate the corresponding private key:

Bob selects the first child private key obtained from his personal billing code.
It computes a secret point on an elliptic curve using ECDH from the first child public key derived from Alice's chain code.
She uses this secret point to calculate the shared secret using SHA256.
He uses this shared secret to calculate a new secret point on the elliptic curve.
It adds this new secret point to its own public key.
Gets the new ephemeral public key to which Alice will send her first payment.
Bob calculates the private key associated with this ephemeral public key by adding his child private key derived from the billing code and the shared secret.

Since Alice cannot obtain «b», Bob's private key, she cannot determine k0, the private key associated with Bob's BIP47 receiving address.

Schematically, the calculation of the shared secret «S» can be represented as follows:

Having found the shared secret using ECDH, Alice and Bob calculate the public key of the BIP47 payment «K0», and Bob also calculates the corresponding private key «k0»:

BIP47 payment refund

Because Bob knows the reusable billing codeAlice, he already has all the information he needs to send her chargebacks. He will not have to contact Alice again to find out some additional information. He just needs to notify her with a notification transaction, specifically so she can recover her BIP47 addresses from the seed, and then he too can send up to 2^32 payments to Alice.

Bob will be able to send payments to Alice in the same way that she sent payments to him. The roles are reversed:

Now you know all the principles of this excellent payment solution, which is BIP47.

Derivative use cases for PayNym

The result of implementing this BIP47 in the walletSamourai Wallet became PayNym, identifiers calculated from users' payment codes. Today, their usefulness goes far beyond the application of BIP47.

Samourai development teams graduallybuild an entire ecosystem of tools and services based on PayNym users. Among them, obviously, there are all the spending tools that allow optimizing user privacy by adding entropy to the transaction, and therefore the possibility of plausible deniability.

Using Soroban (encrypted communication networkbased on Tor) together with PayNym allowed to significantly optimize the user experience when creating collaborative, joint transactions, while maintaining a good level of security. Because of this, Stowaway (PayJoin) and StonewallX2 transactions can be easily executed without the manual execution of numerous unsigned transaction exchanges required to create this type of collaborative transaction.

Unlike BIP47, to use thesetools, it is simple enough to link PayNym(s) via following, since these collaborative transactions do not require a notification transaction to be performed. There is no need to establish a connection between them.

In addition to these collaborative transactions, teamsSamourai are involved in the development of the authentication protocol associated with PayNym, Auth47. This tool is already working and allows, for example, to log in using PayNym on sites that accept this authentication method. In the future, I think that in addition to this internet authentication capability, Auth47 will become part of a larger project around the BIP47/PayNym/Samourai Wallet ecosystem. Perhaps this protocol will be used to further optimize the user experience of Samourai Wallet, especially with regard to spending tools.

My opinion on BIP47

Obviously, the main disadvantage of BIP47 isnotification transaction. This is an additional action, which is also accompanied by network (per Bitcoin transaction) and service fees, which can be irritating for some users. On the other hand, the argument about «spam» Bitcoin's blockchain is completely unacceptable. Anyone paying a transaction fee should be able to record it on the ledger, regardless of the purpose of the transaction. To argue otherwise is to argue in favor of censorship.

It is possible that others will be found in the future,less expensive solutions for transferring the sender's payment code to the recipient and storing it securely. But so far, the notification transaction remains the least compromise solution.

And given the advantages of BIP47, this disadvantagedoesn't even seem that important. Of all the existing proposals for solving the problem of address reuse, this is, in my opinion, the best solution.

As mentioned above, the source of mostreuse addresses are exchanges. BIP47 is the only sensible solution that really addresses this problem at its very source. Any proposal to reduce address reuse should take this into account and tailor the solution to the root cause of the problem.

From the user's point of view, despite the rathercomplex mechanism of operation, the payment process with BIP47 looks rather childish. Therefore, reusable payment codes can be accepted quite easily even by novice users.

In terms of privacy, BIP47is of great interest. As I have already explained when talking about notification transactions, billing codes do not reveal any information about derived ephemeral addresses. Thus, they allow interrupting the flow of information between a bitcoin transaction and the recipient's ID, as opposed to the traditional use of the recipient's address.

And most importantly, the implementation of BIP47 in the form of PayNymis already working. They have been available in Samourai Wallet since 2016, and in Sparrow Wallet since the beginning of this year. This is not some research experiment, but a practical solution, tested yesterday and fully functional today.

I hope that in the future these payment codes will be accepted by the ecosystem participants, they will be supported in more wallets and they will be distributed among bitcoiners.

Any really positive decision forUser privacy needs to be discussed, advocated, and promoted to prevent Bitcoin from becoming a playground for centralized players and a tool for government surveillance.

“He thought about how he was insulted everywhere andpursued, and now he heard everyone talking about him as the most beautiful of all these beautiful birds! And the elderberry itself bowed its branches towards him and the sun shed such a warm and gracious light! Then his feathers fluffed up, his slender neck rose, and he exclaimed with all his heart: “How could I dream of such happiness when I was just an ugly duckling!”

BitNews disclaim responsibility for anyinvestment recommendations that may be contained in this article. All the opinions expressed express exclusively the personal opinions of the author and the respondents. Any actions related to investments and trading on crypto markets involve the risk of losing the invested funds. Based on the data provided, you make investment decisions in a balanced, responsible manner and at your own risk.