Add silentpayments (BIP352) module #1471
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,296 @@ | ||
| #ifndef SECP256K1_SILENTPAYMENTS_H | ||
| #define SECP256K1_SILENTPAYMENTS_H | ||
|
|
||
| #include "secp256k1.h" | ||
| #include "secp256k1_extrakeys.h" | ||
|
|
||
| #ifdef __cplusplus | ||
| extern "C" { | ||
| #endif | ||
|
|
||
| /* This module provides an implementation for the ECC related parts of | ||
| * Silent Payments, as specified in BIP352. This particularly involves | ||
| * the creation of input tweak data by summing up private or public keys | ||
| * and the derivation of a shared secret using Elliptic Curve Diffie-Hellman. | ||
| * Combined are either: | ||
| * - spender's private keys and receiver's public key (a * B, sender side) | ||
| * - spender's public keys and receiver's private key (A * b, receiver side) | ||
| * With this result, the necessary key material for ultimately creating/scanning | ||
| * or spending Silent Payment outputs can be determined. | ||
| * | ||
| * Note that this module is _not_ a full implementation of BIP352, as it | ||
| * inherently doesn't deal with higher-level concepts like addresses, output | ||
| * script types or transactions. The intent is to provide cryptographical | ||
| * helpers for low-level calculations that are most error-prone to custom | ||
| * implementations (e.g. enforcing the right y-parity for key material, ECDH | ||
| * calculation etc.). For any wallet software already using libsecp256k1, this | ||
| * API should provide all the functions needed for a Silent Payments | ||
| * implementation without the need for any further manual elliptic-curve | ||
| * operations. | ||
| */ | ||
|
|
||
| /** Create Silent Payment tweak data from input private keys. | ||
| * | ||
| * Given a list of n private keys a_1...a_n (one for each silent payment | ||
| * eligible input to spend) and a serialized outpoint_smallest, compute | ||
| * the corresponding input private keys tweak data: | ||
| * | ||
| * a_sum = a_1 + a_2 + ... + a_n | ||
| * input_hash = hash(outpoint_smallest || (a_sum * G)) | ||
| * | ||
| * If necessary, the private keys are negated to enforce the right y-parity. | ||
| * For that reason, the private keys have to be passed in via two different parameter | ||
| * pairs, depending on whether they were used for creating taproot outputs or not. | ||
| * The resulting data is needed to create a shared secret for the sender side. | ||
| * | ||
| * Returns: 1 if shared secret creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: a_sum: pointer to the resulting 32-byte private key sum | ||
| * input_hash: pointer to the resulting 32-byte input hash | ||
| * In: plain_seckeys: pointer to an array of pointers to 32-byte private keys | ||
| * of non-taproot inputs (can be NULL if no private keys of | ||
| * non-taproot inputs are used) | ||
| * n_plain_seckeys: the number of sender's non-taproot input private keys | ||
| * taproot_seckeys: pointer to an array of pointers to 32-byte private keys | ||
| * of taproot inputs (can be NULL if no private keys of | ||
| * taproot inputs are used) | ||
| * n_taproot_seckeys: the number of sender's taproot input private keys | ||
| * outpoint_smallest36: serialized smallest outpoint | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_private_tweak_data( | ||
| const secp256k1_context *ctx, | ||
| unsigned char *a_sum, | ||
| unsigned char *input_hash, | ||
| const unsigned char * const *plain_seckeys, | ||
| size_t n_plain_seckeys, | ||
| const unsigned char * const *taproot_seckeys, | ||
| size_t n_taproot_seckeys, | ||
| const unsigned char *outpoint_smallest36 | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(8); | ||
|
|
||
| /** Create Silent Payment tweak data from input public keys. | ||
| * | ||
| * Given a list of n public keys A_1...A_n (one for each silent payment | ||
| * eligible input to spend) and a serialized outpoint_smallest, compute | ||
| * the corresponding input public keys tweak data: | ||
| * | ||
| * A_sum = A_1 + A_2 + ... + A_n | ||
| * input_hash = hash(outpoint_lowest || A_sum) | ||
| * | ||
| * The public keys have to be passed in via two different parameter pairs, | ||
| * one for regular and one for x-only public keys, in order to avoid the need | ||
| * of users converting to a common pubkey format before calling this function. | ||
| * The resulting data is needed to create a shared secret for the receiver's side. | ||
| * | ||
| * Returns: 1 if tweak data creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: A_sum: pointer to the resulting public keys sum | ||
| * input_hash: pointer to the resulting 32-byte input hash | ||
| * In: plain_pubkeys: pointer to an array of pointers to non-taproot | ||
| * public keys (can be NULL if no non-taproot inputs are used) | ||
| * n_plain_pubkeys: the number of non-taproot input public keys | ||
| * xonly_pubkeys: pointer to an array of pointers to taproot x-only | ||
| * public keys (can be NULL if no taproot inputs are used) | ||
| * n_xonly_pubkeys: the number of taproot input public keys | ||
| * outpoint_smallest36: serialized smallest outpoint | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_public_tweak_data( | ||
|
There was a problem hiding this comment. in 2290e80: This function covers a very important use case: preparing public transaction input data so that it can be served to a light client (a light client in this scenario is any client that does not have access to the blockchain but does have access to their However, if used by a full node client, this function would cause the receiver to do two ECC multiplications:
In d725050 the sender only does one ECC multiplication by first doing the less expensive scalar multiplication of What if we had a single function that is used by both the sender and receiver, e.g. Just brainstorming, open to other suggestions! Also might be prematurely optimizing but from what I understand ECC Multiplication is expensive, so keeping it to one for both sender and receiver seems worth it even at this stage. There was a problem hiding this comment. Good point! I assumed that full node clients using silent payments would usually also be interested in the public tweak data to maintain a tweak index (like e.g. bitcoin/bitcoin#28241), both for the purpose of serving the data to light clients and for faster silent payment rescans, but didn't consider that this might not be the case for all full nodes.
Seems reasonable, though currently we don't expose
Agree that we should avoid these extra multiplications if possible. There was a problem hiding this comment.
Yeah, what I suggested is pretty half baked! I'll also give this a more thorough think and share my thoughts. Happy to keep the discussion here (easier to reference things concretely), or we can move it to the linked issue if you prefer. There was a problem hiding this comment.
No strong preference for issue or PR as discussion platform either, it's fine to keep it here for me as well! I still haven't come up with something concrete yet, but am planning to study BIP327 and it's secp256k1 module PR (#1479), as it might give some ideas, both regarding interface and concrete implementation. Haven't looked deeper, but I see that a dedicated caching data type is introduced there to avoid recomputations, maybe something like that could be useful for a BIP352 interface too. There was a problem hiding this comment. One easy possibility to avoid the extra point multiplication on the receiver side for full node clients:
In that function, the shared secret would then be calculated via That would be a straightforward change. The only thing needed then for light clients (or nodes that want to create a silent payments tweak index) is an additional routine to calculate Just some ideas and mostly thinking out loud, happy to receive further input. There was a problem hiding this comment.
This is how I did it in #28122 and this seemed to work well. This would also allow us to simplify things a bit and use a single routine for shared secret creation for both sender and receiver: where For the receiver, yes, I think we would need the two routines you mentioned:
These could also be the same routine since they are essentially doing the same thing ( There was a problem hiding this comment.
Consolidating the API to a single shared secret creation function for both directions would be nice indeed. One drawback could be though that it is likely more confusing for the user and it's a bit easier to use it wrong; since the paramters can't be named exactly after what is expected anymore (e.g. Even the shared secret creation for light clients (passing
Those two calculations are different in the sense that the shared secret creation one does a full ECDH including the call of the ECDH hash function, while the other one is just a normal point multiplication (less critical, as there is no secret key material involved, IIUC). So I think a dedicated routine for creating There was a problem hiding this comment.
True, but as you said, I think we can address this with good documentation. Another for using the same routine for both sender and receiver is we ensure that sender and receiver will arrive at the same shared secret (provided they give correct inputs), since they are using the same routine. If we use separate routines, there is a small chance of introducing a bug in one of the routines that would cause the sender and receiver to arrive at different shared secrets despite giving the correct inputs.
Also not a bad idea! I'd say we can go with this for now and always revert to multiple routines if there are objections.
Good point, I forgot about that. I think the main difference here is that ECDH is done in constant time whereas point multiplication is not. Regardless, you're correct that these should remain separate routines and I agree we should just return the 33 byte serialized pubkey for the routine creating the light client/index data. There was a problem hiding this comment. in "silentpayments: add public tweak data creation routine" (98f5ba4): Similarly (see previous comment), we could rename this function to something like
There was a problem hiding this comment.
Nice idea, I think that interface would indeed be easier for users. The drawback I see here is that if a wallet scans for multiple silent payments addresses (ones that differ in the scan pubkey part), it is more costly, as the intermediate results of Can we live with that? Would that be common or is it much more likely that the scan keypair is constant and a user would only work with labels on the same scan pubkey anyway? Not sure what the typical usecase would be here in the future, interested about your thoughts about that. Without having numbers, I could imagine that summing up pubkeys is insignifcant compared to the point multiplication in the ECDH step, but it's still a bit ugly that for scanning There was a problem hiding this comment. That's a great point, scanning the same transaction for multiple receivers will be a likely use case, so probably better to keep it as is. There was a problem hiding this comment. Also worth pointing out this is an unbounded problem (unlike the sending case): I could be scanning for 30M scan keys for a single transaction. In this case, we would want to avoid recalculating There was a problem hiding this comment.
True! Do you think it's worth it to still introduce a |
||
| const secp256k1_context *ctx, | ||
| secp256k1_pubkey *A_sum, | ||
| unsigned char *input_hash, | ||
| const secp256k1_pubkey * const *plain_pubkeys, | ||
| size_t n_plain_pubkeys, | ||
| const secp256k1_xonly_pubkey * const *xonly_pubkeys, | ||
| size_t n_xonly_pubkeys, | ||
| const unsigned char *outpoint_smallest36 | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(8); | ||
|
|
||
| /** Create Silent Payment tweaked public key from public tweak data. | ||
| * | ||
| * Given public tweak data (public keys sum and input hash), calculate the | ||
| * corresponding tweaked public key: | ||
| * | ||
| * A_tweaked = input_hash * A_sum | ||
| * | ||
| * The resulting data is useful for light clients and silent payment indexes. | ||
| * | ||
| * Returns: 1 if tweaked public key creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: A_tweaked: pointer to the resulting tweaked public key | ||
| * In: A_sum: pointer to the public keys sum | ||
| * input_hash: pointer to the 32-byte input hash | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_tweaked_pubkey( | ||
|
There was a problem hiding this comment. in " silentpayments: add tweaked pubkey creation routine (for light clients / sp index)" (842e5bf): If we end up using the |
||
| const secp256k1_context *ctx, | ||
| secp256k1_pubkey *A_tweaked, | ||
| const secp256k1_pubkey *A_sum, | ||
| const unsigned char *input_hash | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4); | ||
|
|
||
| /** Create Silent Payment shared secret. | ||
| * | ||
| * Given a public component Pub, a private component sec and an input_hash, | ||
| * calculate the corresponding shared secret using ECDH: | ||
| * | ||
| * shared_secret = (sec * input_hash) * Pub | ||
| * | ||
| * What the components should be set to depends on the role of the caller. | ||
| * For the sender side, the public component is set the recipient's scan public key | ||
| * B_scan, and the private component is set to the input's private keys sum: | ||
| * | ||
| * shared_secret = (a_sum * input_hash) * B_scan [Sender] | ||
| * | ||
| * For the receiver side, the public component is set to the input's public keys sum, | ||
| * and the private component is set to the receiver's scan private key: | ||
| * | ||
| * shared_secret = (b_scan * input_hash) * A_sum [Receiver, Full node scenario] | ||
| * | ||
| * In the "light client" scenario for receivers, the public component is already | ||
| * tweaked with the input hash: A_tweaked = input_hash * A_sum | ||
| * In this case, the input_hash parameter should be set to NULL, to signal that | ||
| * no further tweaking should be done before the ECDH: | ||
| * | ||
| * shared_secret = b_scan * A_tweaked [Receiver, Light client scenario] | ||
| * | ||
| * The resulting shared secret is needed as input for creating silent payments | ||
| * outputs belonging to the same receiver scan public key. | ||
| * | ||
| * Returns: 1 if shared secret creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: shared_secret33: pointer to the resulting 33-byte shared secret | ||
| * In: public_component: pointer to the public component | ||
| * private_component: pointer to 32-byte private component | ||
| * input_hash: pointer to 32-byte input hash (can be NULL if the | ||
| * public component is already tweaked with the input hash) | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_shared_secret( | ||
|
There was a problem hiding this comment. in "silentpayments: add shared secret creation routine (aB == Ab)" (b0e3796): Building off the last couple suggestions, this function is now exclusively for light clients and there is no ambiguity about the arguments:
we can also drop the |
||
| const secp256k1_context *ctx, | ||
| unsigned char *shared_secret33, | ||
| const secp256k1_pubkey *public_component, | ||
| const unsigned char *secret_component, | ||
| const unsigned char *input_hash | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4); | ||
|
|
||
| /** Create Silent Payment label tweak and label. | ||
| * | ||
| * Given a recipient's scan private key b_scan and a label integer m, calculate | ||
| * the corresponding label tweak and label: | ||
| * | ||
| * label_tweak = hash(b_scan || m) | ||
| * label = label_tweak * G | ||
| * | ||
| * Returns: 1 if label tweak and label creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: label_tweak: pointer to the resulting label tweak | ||
| * In: receiver_scan_seckey: pointer to the receiver's scan private key | ||
| * m: label integer (0 is used for change outputs) | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_label_tweak( | ||
| const secp256k1_context *ctx, | ||
| secp256k1_pubkey *label, | ||
theStack marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| unsigned char *label_tweak32, | ||
| const unsigned char *receiver_scan_seckey, | ||
| unsigned int m | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4); | ||
|
|
||
| /** Create Silent Payment labelled spend public key. | ||
| * | ||
| * Given a recipient's spend public key B_spend and a label, calculate | ||
| * the corresponding serialized labelled spend public key: | ||
| * | ||
| * B_m = B_spend + label | ||
| * | ||
| * The result is used by the receiver to create a Silent Payment address, consisting | ||
| * of the serialized and concatenated scan public key and (labelled) spend public key each. | ||
| * | ||
| * Returns: 1 if labelled spend public key creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: l_addr_spend_pubkey33: pointer to the resulting labelled spend public key | ||
| * In: receiver_spend_pubkey: pointer to the receiver's spend pubkey | ||
| * label: pointer to the the receiver's label | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_create_address_spend_pubkey( | ||
| const secp256k1_context *ctx, | ||
| unsigned char *l_addr_spend_pubkey33, | ||
| const secp256k1_pubkey *receiver_spend_pubkey, | ||
| const secp256k1_pubkey *label | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4); | ||
|
|
||
| /** Create Silent Payment output public key (for sender). | ||
| * | ||
| * Given a shared_secret, a recipient's spend public key B_spend, and | ||
| * an output counter k, calculate the corresponding output public key: | ||
| * | ||
| * P_output_xonly = B_spend + hash(shared_secret || ser_32(k)) * G | ||
| * | ||
| * Returns: 1 if output creation was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: P_output_xonly: pointer to the resulting output x-only pubkey | ||
| * In: shared_secret33: shared secret, derived from either sender's | ||
| * or receiver's perspective with routines from above | ||
|
Comment on lines
+229
to
+230
There was a problem hiding this comment. Only from the sender's perspective since only the sender calls this (as per the first sentence in the doc), right? There was a problem hiding this comment. I removed |
||
| * receiver_spend_pubkey: pointer to the receiver's spend pubkey | ||
| * k: output counter (usually set to 0, should be increased for | ||
| * every additional output to the same recipient) | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_sender_create_output_pubkey( | ||
| const secp256k1_context *ctx, | ||
| secp256k1_xonly_pubkey *P_output_xonly, | ||
| const unsigned char *shared_secret33, | ||
| const secp256k1_pubkey *receiver_spend_pubkey, | ||
|
There was a problem hiding this comment. in "silentpayments: implement output pubkey creation (for sender)" (8460be5): I think the sender will always be getting the receiver spend key externally, so we could just have this be There was a problem hiding this comment.
SGTM, I'm all for minimizing necessary conversions at the caller-side. One slight drawback might be that the routine has now one more reason to fail (if the passed byte-string is not representing a valid public key), but I think that's acceptable. |
||
| unsigned int k | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(4); | ||
|
|
||
| typedef struct { | ||
| secp256k1_pubkey label; | ||
| secp256k1_pubkey label_negated; | ||
| } secp256k1_silentpayments_label_data; | ||
|
|
||
| /** Scan for Silent Payment transaction output (for receiver). | ||
| * | ||
| * Given a shared_secret, a recipient's spend public key B_spend, | ||
| * an output counter k, and a scanned tx's output x-only public key tx_output, | ||
| * calculate the corresponding scanning data: | ||
| * | ||
| * t_k = hash(shared_secret || ser_32(k)) | ||
| * P_output = B_spend + t_k * G [not returned] | ||
|
Comment on lines
+248
to
+255
There was a problem hiding this comment. In the course of writing benchmarks, I just noticed that this scanning API is flawed from a performance perspective, as we currently recalculate |
||
| * if P_output == tx_output | ||
| * direct_match = 1 | ||
| * else | ||
| * label1 = tx_output - P_output | ||
| * label2 = -tx_output - P_output | ||
| * direct_match = 0 | ||
| * | ||
| * The resulting data is needed for the receiver to efficiently scan for labels | ||
| * in silent payments eligible outputs. | ||
| * | ||
| * Returns: 1 if output scanning was successful. 0 if an error occured. | ||
| * Args: ctx: pointer to a context object | ||
| * Out: direct_match: pointer to the resulting boolean indicating whether | ||
| * the calculated output pubkey matches the scanned one | ||
| * t_k: pointer to the resulting tweak t_k | ||
| * label_data: pointer to the resulting label structure, containing the | ||
| * two label candidates, only set if direct_match == 0 | ||
| * (can be NULL if the data is not needed) | ||
| * In: shared_secret33: shared secret, derived from either sender's | ||
| * or receiver's perspective with routines from above | ||
| * receiver_spend_pubkey: pointer to the receiver's spend pubkey | ||
| * k: output counter (usually set to 0, should be increased for | ||
| * every additional output to the same recipient) | ||
| * tx_output: pointer to the scanned tx's output x-only public key | ||
| */ | ||
| SECP256K1_API SECP256K1_WARN_UNUSED_RESULT int secp256k1_silentpayments_receiver_scan_output( | ||
| const secp256k1_context *ctx, | ||
| int *direct_match, | ||
| unsigned char *t_k, | ||
| secp256k1_silentpayments_label_data *label_data, | ||
| const unsigned char *shared_secret33, | ||
| const secp256k1_pubkey *receiver_spend_pubkey, | ||
| unsigned int k, | ||
| const secp256k1_xonly_pubkey *tx_output | ||
| ) SECP256K1_ARG_NONNULL(1) SECP256K1_ARG_NONNULL(2) SECP256K1_ARG_NONNULL(3) SECP256K1_ARG_NONNULL(5) SECP256K1_ARG_NONNULL(6) SECP256K1_ARG_NONNULL(8); | ||
|
|
||
| #ifdef __cplusplus | ||
| } | ||
| #endif | ||
|
|
||
| #endif /* SECP256K1_SILENTPAYMENTS_H */ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,2 @@ | ||
| include_HEADERS += include/secp256k1_silentpayments.h | ||
| noinst_HEADERS += src/modules/silentpayments/main_impl.h | ||
theStack marked this conversation as resolved.
Show resolved
Hide resolved
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
in "silentpayments: add private tweak data creation routine" (81d1303):
Thinking about this more, is there a usecase where the sender might need
a_sumand not need the shared secret? If not, seems like it would be better to have the API accept private keys as an input and return the final shared secret. Otherwise, callers need to be really careful witha_sumas it could be a single private key.What about renaming this function to something like
secp256k1_silentpayments_create_shared_secret_from_private_dataand it returnsunsigned char shared_secret33. This way, we can pass pointers to the privkey data and get back the shared secret without needing to worry about handling a potentially dangerousa_sumin between.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The only
a_sum/input_hashreuse scenario I could think of is one where the sender wants to create a transaction with more than one silent payments recipient (and with that, different scan pubkeys, i.e. the same recipient with different labels but same scan pubkey wouldn't count as "different" in that sense). Given that sending is an infrequent scenario and calculating a_sum and input_hash are comparably cheap operations, that's probably not a big deal though. The receiving/scanning part is potentially more of a problem, see comment below.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great point. This could be a fairly common usecase (e.g. an exchange processing withdrawals to$n$ silent payment addresses), but it is still a bounded problem in that you can't send to more than $N$ silent payment addresses in a single transaction, where $N$ is the number of outputs you can fit in a single block.
I'm leaning toward making this so the caller doesn't need to handle intermediary secret data. The other option is we expose both routines in the API?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oops, I missed this comment last week. I agree that a
secp256k1_silentpayments_create_shared_secret_from_private_dataroutine would be useful for the reasons you mentioned (i.e. avoid having to handle intermediate secret key data), will add one in a bit. I tend to think that exposing both routines still makes sense, in cases where performance for sending to multiple receivers is really a concern? Will keep the current one around for discussion, if it's not considered useful it can still be removed later.