mirrors/bitcoin-bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-01-18 13:26:08 +01:00
Code Issues Projects Releases Wiki Activity

Leaner notifications

Browse Source
This commit is contained in:
Alfred Hodler 2022-08-01 12:15:46 +00:00
parent 7330484680
commit 50e707bd8c
No known key found for this signature in database
GPG Key ID: 8DECE1168AD6CFE3
1 changed files with 6 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
bip-alfredhodler-privatepayments.mediawiki
View File

@ -106,11 +106,11 @@ While payment codes use 2-byte bitflag arrays, notifications use ordinal values
===Notifications===
Notifications are performed by publishing transactions that contain a 44-byte <code>OP_RETURN</code> output. The value of the <code>OP_RETURN</code> is constructed using the following formula:
Notifications are performed by publishing transactions that contain a 40-byte <code>OP_RETURN</code> output. The value of the <code>OP_RETURN</code> is constructed using the following formula:
''search_key | notification_code | N<sub>x</sub> | address_type''
* ''search_key'' equals "BIP999" and is a static ASCII-encoded string (6 bytes)
* ''search_key'' equals "PP" and is a static ASCII-encoded string (2 bytes)
* ''notification_code'' is ''H(n<sub>x</sub> * P)[0..4]'' (4 bytes)
* ''N<sub>x</sub>'' is the unique public key a sender is using for a particular recipient (33 bytes)
* ''address_type'' is the '''ordinal''' value of a single address type that a sender wants to send to (1 byte). This must be selected from the recepient's accepted address types.
@ -124,7 +124,7 @@ When Alice wants to notify Bob that he will receive future payments from her, sh
# Selects any UTXO in her wallet, preferably not associated with her.
# Sends a transaction including an <code>OP_RETURN</code> output whose value is set to the constructed payload.
When Bob notices an <code>OP_RETURN</code> starting with the search key, he performs the following procedure:
When Bob notices a 40-byte <code>OP_RETURN</code> starting with ''search key'', he performs the following procedure:
# Breaks down the payload into its four constituent parts.
# Discards the ''search_key'' (item #0).
@ -142,6 +142,8 @@ Since ''notification_code'' is a 4-byte truncation of the full value, Bob has a
There is a scanning requirement on the recipient side in that the recipient must have access to full blocks in order to be able to search them for OP_RETURN outputs containing notifications. For more information on how light clients can get around this limitation and still use the standard, see Appendix B.
Recipients that do not want to decode raw block data can quickly search for notifications in a block by looking for the following byte array: <code>[106, 40, 80, 80]</code>. The first two bytes represent ''OP_RETURN'' and ''OP_PUSHBYTES_40'', followed by the ASCII value of ''search_key''.
===Transacting===
Alice initializes counter ''c'' which is unique to Bob and increments with each transaction. ''c'' is a 64-bit integer and must be inputted into a hasher as a big-endian encoded array of 8 bytes.
@ -208,7 +210,7 @@ When Bob wants to spend from such addresses, he calculates his private keys in t
'''Address type commitment:''' 1 (segwit)
'''Notification output script:''' OP_RETURN OP_PUSHBYTES_44 424950393939fbe8d683039d138aaf5bc2e27a9740541576eceb90a5f20b4799dbfda48e5c7ca24050575301
'''Notification output script:''' OP_RETURN OP_PUSHBYTES_40 5050fbe8d683039d138aaf5bc2e27a9740541576eceb90a5f20b4799dbfda48e5c7ca24050575301
===Alice sending to Bob===