📅 Original date posted:2015-10-22
📝 Original message:On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:
> This link contains an RFC for a new type of Bitcoin address called a
> "payment code"
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.
Luke
Luke Dashjr [ARCHIVE] /
npub1tf…rfq0n
2023-06-07 17:43:48
in reply to nevent1q…sk74
Author Public Key
npub1tfk373zg9dnmtvxnpnq7s2dkdgj37rwfj3yrwld7830qltmv8qps8rfq0nPublished at
2023-06-07 17:43:48Event JSON
{
"id": "aed93216ea4eeb4c9349f8d31cc800c39a1beb27db61f8ef212abda25f43d350",
"pubkey": "5a6d1f44482b67b5b0d30cc1e829b66a251f0dc99448377dbe3c5e0faf6c3803",
"created_at": 1686159828,
"kind": 1,
"tags": [
[
"e",
"9bb6828e62e331ddd988f31d853a7e825173c1f158082e0c7c1ae01342918390",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2015-10-22\n📝 Original message:On Friday, April 24, 2015 8:00:46 PM Justus Ranvier wrote:\n\u003e This link contains an RFC for a new type of Bitcoin address called a\n\u003e \"payment code\"\n\nSorry for the late review. I'm concerned with the \"notification address\" \nrequirement, which entails address reuse and blockchain spam. Since it entails \naddress reuse, the recipient is forced to either leave them unspent forever \n(bloating the UTXO set), or spend it which potentially compromises the private \nkey, and (combined with the payment code) possibly as much as the entire \nwallet.\n\nInstead, I suggest making it a single zero-value OP_RETURN output with two \npushes: 1) a hash of the recipient's payment code, and 2) the encrypted \npayment code. This can be searched with standard bloom filters, or indexed \nwith whatever other optimised algorithms are desired. At the same time, it \nnever uses any space in the UTXO set, and never needs to be \nspent/mixed/dusted.\n\nLuke",
"sig": "86a1ebb0fcc2b6dd41b61afad494a99bd1d06e5376038c7a8db5ea4a040665f039b4d014380353b90fc8ec3932c08ac1f180c50907efeaf91a3dc2aefc2991e0"
}