Skip to content

BIP-352: add test vector for edge case - input key intermediate sum zero #2142

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
jonatack merged 2 commits into from
Apr 17, 2026
Merged

BIP-352: add test vector for edge case - input key intermediate sum zero #2142

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
c2ac36f
BIP-352: add test vector for edge case - input key intermediate sum zero
macgyver13 Apr 13, 2026
00957af
BIP-352: update changelog and correct typo
macgyver13 Apr 16, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion bip-0352.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -95,7 +95,7 @@ Bob must calculate the same ''input_hash'' when scanning.

''' Using all inputs '''

In our simplified example we have been referring to Alice's transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the silent payments protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 33 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 33 bytes per transaction in a trustless manner, see [[#appendix-a-light-client-support|Appendix A: Light Client Support]] for more details.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name=""all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind Diffie–Hellman] to prevent the other participants from learning who Alice is paying. Note it is currently not recommended to use this protocol for CoinJoins due to a lack of a formal security proof.</ref>.
In our simplified example we have been referring to Alice's transactions as having only one input ''A'', but in reality a Bitcoin transaction can have many inputs. Instead of requiring Alice to pick a particular input and requiring Bob to check each input separately, we can instead require Alice to perform the tweak with the sum of the input public keys<ref name="other_inputs">'''What about inputs without public keys?''' Inputs without public keys can still be spent in the transaction but are simply ignored in the silent payments protocol.</ref>. This significantly reduces Bob's scanning requirement, makes light client support more feasible<ref name="using_all_inputs">'''How does using all inputs help light clients?''' If Alice uses a random input for the tweak, Bob necessarily has to have access to and check all transaction inputs, which requires performing an ECC multiplication per input. If instead Alice performs the tweak with the sum of the input public keys, Bob only needs the summed 33 byte public key per transaction and only does one ECC multiplication per transaction. Bob can then use BIP158 block filters to determine if any of the outputs exist in a block and thus avoids downloading transactions which don't belong to him. It is still an open question as to how Bob can source the 33 bytes per transaction in a trustless manner, see [[#appendix-a-light-client-support|Appendix A: Light Client Support]] for more details.</ref>, and protects Alice's privacy in collaborative transaction protocols such as CoinJoin<ref name="all_inputs_and_coinjoin">'''Why does using all inputs matter for CoinJoin?''' If Alice uses a random input to create the output for Bob, this necessarily reveals to Bob which input Alice has control of. If Alice is paying Bob as part of a CoinJoin, this would reveal which input belongs to her, degrading the anonymity set of the CoinJoin and giving Bob more information about Alice. If instead all inputs are used, Bob has no way of knowing which input(s) belong to Alice. This comes at the cost of increased complexity as the CoinJoin participants now need to coordinate to create the silent payment output and would need to use [https://gist.github.com/RubenSomsen/be7a4760dd4596d06963d67baf140406 Blind Diffie–Hellman] to prevent the other participants from learning who Alice is paying. Note it is currently not recommended to use this protocol for CoinJoins due to a lack of a formal security proof.</ref>.

Alice performs the tweak with the sum of her input private keys in the following manner:

Expand Down Expand Up @@ -503,6 +503,8 @@ The <code>MAJOR</code> version is incremented if changes to the BIP are introduc
The <code>MINOR</code> version is incremented whenever the inputs or the output of an algorithm changes in a backward-compatible way or new backward-compatible functionality is added.
The <code>PATCH</code> version is incremented for other changes that are noteworthy (bug fixes, test vectors, important clarifications, etc.).

* '''1.1.1''' (2026-04-16):
** Add test vector "Input keys intermediate sum is zero but final sum is non-zero"
* '''1.1.0''' (2026-03-02):
** Introduce per-group recipient limit ''K<sub>max</sub>'' to mitigate quadratic scanning behavior for adversarial transactions.<ref name="why_limit_k"></ref>
* '''1.0.2''' (2025-07-25):
Expand Down
134 changes: 134 additions & 0 deletions bip-0352/send_and_receive_test_vectors.json
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3186,6 +3186,140 @@
}
]
},
{
"comment": "Input keys intermediate sum is zero but final sum is non-zero",
"sending": [
{
"given": {
"vin": [
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 0,
"scriptSig": "",
"txinwitness": "0247304402203e5537fa8c876b3475e7efe4f1474b0f48b7a6e4169179db5de9bb5b55ad1bd10220200e06f8f4d29dbc48bbcdf90df3278e798ce6cbf3c9fbf90427599fde147867012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792"
}
},
"private_key": "a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb"
},
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 1,
"scriptSig": "",
"txinwitness": "0247304402207fdad0faf46edc54f5a5c67d33b2fa8d3f1fdc869381fd96e659f9e0c470ab1e022044f0d973339618b18667cef9a6251817f7f431f7f2b252a8cb760ccb40e7d823012103557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149860538b5575962776ed0814ae222c7d60c72d7b"
}
},
"private_key": "592095f44bb766d5cfe20bda71f9575ed2df6b9fb9addc7e5fdffe0923841456"
},
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 2,
"scriptSig": "",
"txinwitness": "0247304402203e5537fa8c876b3475e7efe4f1474b0f48b7a6e4169179db5de9bb5b55ad1bd10220200e06f8f4d29dbc48bbcdf90df3278e798ce6cbf3c9fbf90427599fde147867012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792"
}
},
"private_key": "a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb"
}
],
"recipients": [
{
"address": "sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv",
"scan_pub_key": "0220bcfac5b99e04ad1a06ddfb016ee13582609d60b6291e98d01a9bc9a16c96d4",
"spend_pub_key": "025cc9856d6f8375350e123978daac200c260cb5b5ae83106cab90484dcd8fcf36"
}
]
},
"expected": {
"outputs": [
[
"7e88a7536c90770be4d2693a84ed03abe3fdcc5a29f96ec3433effec3b0c2194"
]
],
"shared_secrets": [
"037dc4e5904ab4770dbdbb628860b54265fdbb7810b8afdf9f582fedaabfdebef0"
],
"input_private_key_sum": "a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb",
"input_pub_keys": [
"02557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"03557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"02557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975"
]
}
}
],
"receiving": [
{
"given": {
"vin": [
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 0,
"scriptSig": "",
"txinwitness": "0247304402203e5537fa8c876b3475e7efe4f1474b0f48b7a6e4169179db5de9bb5b55ad1bd10220200e06f8f4d29dbc48bbcdf90df3278e798ce6cbf3c9fbf90427599fde147867012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792"
}
}
},
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 1,
"scriptSig": "",
"txinwitness": "0247304402207fdad0faf46edc54f5a5c67d33b2fa8d3f1fdc869381fd96e659f9e0c470ab1e022044f0d973339618b18667cef9a6251817f7f431f7f2b252a8cb760ccb40e7d823012103557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149860538b5575962776ed0814ae222c7d60c72d7b"
}
}
},
{
"txid": "3a286147b25e16ae80aff406f2673c6e565418c40f45c071245cdebc8a94174e",
"vout": 2,
"scriptSig": "",
"txinwitness": "0247304402203e5537fa8c876b3475e7efe4f1474b0f48b7a6e4169179db5de9bb5b55ad1bd10220200e06f8f4d29dbc48bbcdf90df3278e798ce6cbf3c9fbf90427599fde147867012102557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975",
"prevout": {
"scriptPubKey": {
"hex": "00149d9e24f9fab4e35bf1a6df4b46cb533296ac0792"
}
}
}
],
"outputs": [
"7e88a7536c90770be4d2693a84ed03abe3fdcc5a29f96ec3433effec3b0c2194"
],
"key_material": {
"spend_priv_key": "9d6ad855ce3417ef84e836892e5a56392bfba05fa5d97ccea30e266f540e08b3",
"scan_priv_key": "0f694e068028a717f8af6b9411f9a133dd3565258714cc226594b34db90c1f2c"
},
"labels": []
},
"expected": {
"addresses": [
"sp1qqgste7k9hx0qftg6qmwlkqtwuy6cycyavzmzj85c6qdfhjdpdjtdgqjuexzk6murw56suy3e0rd2cgqvycxttddwsvgxe2usfpxumr70xc9pkqwv"
],
"outputs": [
{
"priv_key_tweak": "3d5b7a284108f93b9fe78f2c300d2ca9ef3b4e0cd0de673fc72990f2a4f417b9",
"pub_key": "7e88a7536c90770be4d2693a84ed03abe3fdcc5a29f96ec3433effec3b0c2194",
"signature": "f8d5222f1a682215c40ab677f2104606f2a0e6c5cb1a2d248d970fb61d4eadb31702353e6b41ea5a9b24817efa0eaf535552eeee8a794b662c3cf303b6c86672"
}
],
"tweak": "039c68bacb7efbf2175d781822f460afc4839a5798fabb055b50d939231bf57bb6",
"shared_secret": "037dc4e5904ab4770dbdbb628860b54265fdbb7810b8afdf9f582fedaabfdebef0",
"input_pub_key_sum": "02557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975"
}
}
]
},
{
"comment": "Maximum per-group recipient limit K_max is exceeded (2324 matches): sending fails, receiver doesn't scan beyond limit",
"sending": [
Expand Down