Bitcoin is one of the most significant breakthroughs of the entire digital age in terms of transferring value between one person and another. It does not require intermediaries. It is secured by a decentralized quorum of miners and validated by each network participant who so wishes in order to guarantee the validity of individual payments. The system architecture is designed to allow anyone from anywhere on the planet to receive money from anyone else, no matter where they are. Crowdfunding, charity, funding anything you want becomes instantly possible without needing anyone’s permission, without dealing with gatekeepers, without any bureaucracy. It’s a brilliant idea in theory, but in reality, it suffers from a huge flaw: privacy.
As a push-based payment system (no one is allowed to “pull” payments from you, you must explicitly authorize them yourself and “push” them to other people), Bitcoin requires the sender has the information needed to define the destination for the money they send. This requires the receiver to tell the sender their bitcoin address in some way. In the case of trying to raise funds from the general public, this has massive implications in terms of privacy or the need to maintain a constant interactive presence online. Anyone is quite capable of just posting a single bitcoin address somewhere online, and from then on, anyone who wants to send money to that person can just do it, but there’s no confidentiality to fundraise in this way. Just take that address and look it up on the blockchain, and you can not only see how much money that person has been sent, but you can see the fingerprint on the blockchain of everyone who has sent them money . The person trying to raise funds and anyone who has donated to them have no privacy; everything is completely open and correlated for the whole world to see.
The only alternative to address reuse in the form of publicly displaying a single static address requires running a server that stays online all the time so people can request a new, unused address whenever someone again wants to donate money. While it doesn’t seem like a problem to have something online all the time in the digital age, it does come at a cost and complexity, especially if someone is trying to run it themselves at home. on its own hardware. And what about people who only have a mobile device? It’s nearly impossible these days with current operating system features to optimize battery usage for something to run in the background all day, and even if you can it will drain the battery.
Enter BIP47 by Justus Ranvier. The purpose of this proposal is to allow someone to be able to post enough information publicly to be able to receive funds from anyone who wants it, without that public information being enough to (1) track how much money the person who posted it received and (2) reveal to the public any information about who sent funds to the person requesting them. The basic idea is to take this publicly released information (or payment code) and from there combine their own payment code to generate a new set of addresses for which the recipient can build the private keys. This new set of addresses is specific to the relationship between a single sender and receiver, each time a new sender uses this protocol to send money to a receiver, it will generate a new set of unique addresses for the of them.
At a high level, the general flow follows as such: the person who wishes to receive money generates a new extended public key from their HD wallet in a new derivation path and publishes it publicly. This new public key functions as their “payment code”. From there, someone wanting to send him money will take this new payment code, and he will have all the information necessary to generate new addresses to send money to. The problem, however, is that the sender must communicate their own payment code information to the receiver, otherwise they will not be able to generate the private key needed to actually spend the funds sent to them. This requires a special “notification transaction”.
Suppose Alice wants to transact with Bob using payment codes. Alice selects a UTXO to send to Bob’s notification address, from there she takes the private key associated with that UTXO and the public key associated with Bob’s notification address. She multiplies them to create a blinding secret key. With this, she can encrypt her payment code and encode them in an OP_RETURN output. This means that Bob, taking the private key from his notification address and the public key from Alice’s spent entry, is the only person who can decrypt and read this information. This works because multiplying Alice’s private key with Bob’s public key produces the same value as multiplying Bob’s private key with Alice’s public key.
Alice and Bob can now derive a new set of addresses that only the two of them are aware of, and Alice can now send any amount of transactions to Bob using a new address each time without any outside observers being aware of the link between them. There is a second variation where, instead of sending output to Bob’s notify transaction, Alice creates a modify output to herself using a 1 of 2 multisig where one key is her modify address and the second is Bob’s payment code identifier. A third variant uses a 1 of 3 multisig output to encode the necessary information instead of OP_RETURN. Other than that, things work the same way.
The only downside to BIP47 is the need to use block space to send a special transaction notifying a recipient that they are going to receive money before spending it. This turns out to be very inefficient for use cases where someone is only trying to send a single payment. There is also a risk of actively infringing privacy if the UTXO used for the notification transaction is connected to the UTXOs used to make payments to someone’s BIP47 addresses. Care must be taken to provide isolation between these two things so as not to create correlations that could be tracked on-chain and the associated ownership of UTXOs resulting from different payouts.
Silent Payments is Ruben Somsen’s latest idea. It effectively solves the same problem as BIP47 without the need for a notification transaction with the trade-off of having to analyze more transactions to detect payments made to the recipient. The idea is basically the same: you publish public information, and from there, a sender is able to construct a new address that only the recipient can reconstruct. The difference is in the implementation details.
The recipient publishes a “silent” public key in an accessible place, then the sender takes it and modifies this public key using the private key of an entry that he is going to spend to make a payment to the recipient. This is done by multiplying the sender’s private key with the recipient’s silent public key and then adding that silent public key again. This results in a new address, which the recipient can retrieve by multiplying their private key by the sender’s public key and adding their silent public key. It’s so simple.
The big downside here is that supporting thin clients is very difficult, as the receiver has to parse every transaction in every block and calculate their key-adjusted input combinations to see if it matches an output in a transaction. For a fullnode user, this is not an unbearable increase in validation costs, but for lightweight wallets without their own fullnode, it becomes very costly. This could be further optimized by simply scanning the UTXO set. Blockstream’s Jonas Nick ran a benchmark test on an Intel i7, and he found that it took about three and a half hours to parse the whole thing and run the calculations to verify the addresses. This did not include the time it took to find the transaction that created each UTXO to find the input public keys needed to perform this calculation. This has not yet been evaluated or tested, so cost and time remain an open question.
Another optimization that could be done is to use each entry of the send transaction’s public key as part of the setting, which would reduce the cost of scanning to see if you received money by not forcing you not to digitize each individual entry in a transaction. and run the calculation individually. It would, however, increase the complexity of doing so with CoinJoin transactions, as it would require all other participants to actively participate in key adjustments. This would also disclose to them what output you are paying for in the naive implementation. However, this would prevent the recipient from learning which input was used to pay them, and by cryptographically obfuscating the information shared with other CoinJoin participants, it would prevent them from learning which output the silent payment is, thus mitigating any problems. confidentiality.
It is also possible to add a scan and spend key in the derivation process so that the recipient can have an online key which is all that is needed to detect incoming payments, while retaining the necessary key to spend the coins he received offline and in cold storage. This would change the derivation by multiplying the sender’s input private key with the scanning key, then adding the key needed for the spend. This would allow for greater security in receiving payments, leaving only your privacy at risk if the recipient’s device is compromised.
One last important thing to consider is the potential for address reuse on the sender side. In the basic implementation, if a sender has multiple UTXOs with the same public key, reusing those to be sent to the same person with silent payment would result in the same silent address and constitute address reuse. This could be avoided by including the TXID and Entry Index of the transaction entry used in the schema, which could be precomputed before being sent to thin clients so as not to create additional computational load on them.
Overall, the idea is a substantial improvement over BIP47 in every way except the higher validation costs for the recipient to track down funds sent to them. It retains the deterministic recovery property, ensures non-linkage between different payments sent to the recipient, and removes the need for a notification transaction before payments are made. Again, Somsen came up with a very solid idea for a protocol that could be implemented to improve Bitcoin’s utility.
This is a guest post from Shinobi. The opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.