📅 Original date posted:2015-10-22
📝 Original message:On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:
> 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.
No, they just need to improve their software, and only to support receiving
with payment codes (not sending to them). BIPs should in general not be
designed around current software, especially in this case where there is no
benefit to doing so (since it requires software upgrades anyway).
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:43:49
in reply to nevent1q…xekf
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:43:49Event JSON
{
"id": "802abba10374bc1d9a0e4ac782d104ec2f9d34eef5034715c1a81b14eb91f6d9",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159829,
"kind": 1,
"tags": [
[
"e",
"9bb6828e62e331ddd988f31d853a7e825173c1f158082e0c7c1ae01342918390",
"",
"root"
],
[
"e",
"84b582dd6a6b5761f39593c2a3d43a95edc867d3996f4e27350773fb2e6e31a2",
"",
"reply"
],
[
"p",
"b2b39b6f2c86908d3da9f500193abd5757b21cac328f838800a48c4d557c10dd"
]
],
"content": "📅 Original date posted:2015-10-22\n📝 Original message:On Thursday, October 22, 2015 2:55:14 PM Justus Ranvier wrote:\n\u003e On 22/10/15 00:53, Luke Dashjr wrote:\n\u003e \u003e Sorry for the late review. I'm concerned with the \"notification address\"\n\u003e \u003e requirement, which entails address reuse and blockchain spam. Since it\n\u003e \u003e entails address reuse, the recipient is forced to either leave them\n\u003e \u003e unspent forever (bloating the UTXO set), or spend it which potentially\n\u003e \u003e compromises the private key, and (combined with the payment code)\n\u003e \u003e possibly as much as the entire wallet.\n\u003e \u003e \n\u003e \u003e Instead, I suggest making it a single zero-value OP_RETURN output with\n\u003e \u003e two pushes: 1) a hash of the recipient's payment code, and 2) the\n\u003e \u003e encrypted payment code. This can be searched with standard bloom\n\u003e \u003e filters, or indexed with whatever other optimised algorithms are\n\u003e \u003e desired. At the same time, it never uses any space in the UTXO set, and\n\u003e \u003e never needs to be\n\u003e \u003e spent/mixed/dusted.\n\u003e \n\u003e The notification transaction portion is my least-favorite portion of the\n\u003e spec, but I don't see any alternatives that provide an unambiguous\n\u003e improvement, including your suggestion.\n\u003e \n\u003e One of the most highly-weighted goals of this proposal is to be usable\n\u003e on as many mobile/light wallets as possible.\n\u003e \n\u003e I know for sure that all existing platforms for balance querying index\n\u003e by address. Support for bloom filters or other querying methods is less\n\u003e comprehensive, meaning the set of wallets that can support payment codes\n\u003e would be smaller.\n\nNo, they just need to improve their software, and only to support receiving \nwith payment codes (not sending to them). BIPs should in general not be \ndesigned around current software, especially in this case where there is no \nbenefit to doing so (since it requires software upgrades anyway).\n\nLuke",
"sig": "87a425eb2c0e7ed8664dd5d708c4a2fd910b8b001c98b450a71e86de4924789bb6a9b79bcad940f8e43c8379dad8fd843d859cd6860ceee883bdae7217a7360d"
}