š
Original date posted:2015-10-22
š Original message:On 22/10/15 00:53, Luke Dashjr wrote:
> Sorry for the late review. I'm concerned with the "notification address"
> requirement, which entails address reuse and blockchain spam. Since it entails
> address reuse, the recipient is forced to either leave them unspent forever
> (bloating the UTXO set), or spend it which potentially compromises the private
> key, and (combined with the payment code) possibly as much as the entire
> wallet.
>
> Instead, I suggest making it a single zero-value OP_RETURN output with two
> pushes: 1) a hash of the recipient's payment code, and 2) the encrypted
> payment code. This can be searched with standard bloom filters, or indexed
> with whatever other optimised algorithms are desired. At the same time, it
> never uses any space in the UTXO set, and never needs to be
> spent/mixed/dusted.
The notification transaction portion is my least-favorite portion of the
spec, but I don't see any alternatives that provide an unambiguous
improvement, including your suggestion.
One of the most highly-weighted goals of this proposal is to be usable
on as many mobile/light wallets as possible.
I know for sure that all existing platforms for balance querying index
by address. Support for bloom filters or other querying methods is less
comprehensive, meaning the set of wallets that can support payment codes
would be smaller.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0xEAD9E623.asc
Type: application/pgp-keys
Size: 18442 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.bin>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.sig>;
Justus Ranvier [ARCHIVE] /
npub1k2ā¦9qd6m
2023-06-07 17:43:49
in reply to nevent1qā¦l25e
Author Public Key
npub1k2eekmevs6gg60df75qpjw4a2atmy89vx28c8zqq5jxy64tuzrws39qd6mPublished at
2023-06-07 17:43:49Event JSON
{
"id": "84b582dd6a6b5761f39593c2a3d43a95edc867d3996f4e27350773fb2e6e31a2",
"pubkey": "b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd",
"created_at": 1686159829,
"kind": 1,
"tags": [
[
"e",
"9bb6828e62e331ddd988f31d853a7e825173c1f158082e0c7c1ae01342918390",
"",
"root"
],
[
"e",
"aed93216ea4eeb4c9349f8d31cc800c39a1beb27db61f8ef212abda25f43d350",
"",
"reply"
],
[
"p",
"5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803"
]
],
"content": "š
Original date posted:2015-10-22\nš Original message:On 22/10/15 00:53, Luke Dashjr wrote:\n\u003e Sorry for the late review. I'm concerned with the \"notification address\" \n\u003e requirement, which entails address reuse and blockchain spam. Since it entails \n\u003e address reuse, the recipient is forced to either leave them unspent forever \n\u003e (bloating the UTXO set), or spend it which potentially compromises the private \n\u003e key, and (combined with the payment code) possibly as much as the entire \n\u003e wallet.\n\u003e \n\u003e Instead, I suggest making it a single zero-value OP_RETURN output with two \n\u003e pushes: 1) a hash of the recipient's payment code, and 2) the encrypted \n\u003e payment code. This can be searched with standard bloom filters, or indexed \n\u003e with whatever other optimised algorithms are desired. At the same time, it \n\u003e never uses any space in the UTXO set, and never needs to be \n\u003e spent/mixed/dusted.\n\nThe notification transaction portion is my least-favorite portion of the\nspec, but I don't see any alternatives that provide an unambiguous\nimprovement, including your suggestion.\n\nOne of the most highly-weighted goals of this proposal is to be usable\non as many mobile/light wallets as possible.\n\nI know for sure that all existing platforms for balance querying index\nby address. Support for bloom filters or other querying methods is less\ncomprehensive, meaning the set of wallets that can support payment codes\nwould be smaller.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: 0xEAD9E623.asc\nType: application/pgp-keys\nSize: 18442 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.bin\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 801 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/915cb984/attachment.sig\u003e",
"sig": "f59e6e45dc1258cd95cce5a5c2e465a26e8c66fa2ed3240c2562572fc61758d1848a72d7c16c9dad4f41599b682f71da134680b623e3eed6b1d4a868219aa485"
}