Integrated Address
Integrated addresses are ideal for accepting Beldex in an automated fashion - like in online stores and exchanges.
Beldex integrated address embeds a payment ID. This allows you to learn for what you are being paid.
Please note these are Beldex technical payment IDs and must not be confused with business identifiers like order number or invoice number.
The transaction to integrated address will not reveal the payment ID publicly. Payment ID in a transaction will be encrypted with a shared secret (one-time random key known only to sender and recipient). Only the recipient will be able to match the transaction against payment ID.
Beldex integrated address obsoletes the former practice of using full 32-bytes payment ID in a transaction extra field (where it was not encrypted).
Data structure (src):
Index | Size in bytes | Description |
0 | 1 | |
1 | 32 | public spend key |
33 | 32 | public view key |
65 | 8 | compact payment ID - 8 bytes randomly generated by the recipient; note that it does not need encryption in the address itself but it is hidden in a transaction paying to integrated address to prevent linking payment with the address by external observers |
73 | 4 | checksum (Keccak-f[1600] hash of the previous 73 bytes, trimmed to first 4 bytes) |
It totals to 77 bytes. The bytes are then encoded (src) in Beldex specific Base58 format, resulting in a 106 chars long string. Example integrated address:
4LhSDqBZdjLQWajr4pBcFkdjL8oGY7MDvfJkKfrQVaokfDMxU6bDVb6h8tsD1jpKpSXbbB1p8RxPbA7fmjvLGjicKLBdQvDMbHA7TWVCUQ
Integrated addresses vs subaddresses
Both types allow you to learn for what you are being paid.
Individuals should prefer subaddresses to receive payments. This is to improve privacy in certain scenarios. See article on subaddresses for details.
Businesses accepting payments in an automated way should prefer integrated addresses. The rationale is as follows:
Scenario where subaddresses improve privacy is not applicable to businesses b/c businesses have the same identity over time. Consequently, subaddresses provide no benefits over integrated addresses.
No private key is necessary to generate integrated address. This provides a strong security advantage because services that generate integrated addresses need no access to wallet. In contrast, to generate a subaddress, one needs a private view key.
No shared counter is necessary to generate integrated address. This allows individual services to independently generate integrated addresses w/o synchronizing on a common sequence. In contrast, subaddresses are generated sequentially, and so the sequence (the counter or index) is a coupling point between the wallet and all services that need to generate the address. Back to integrated addresses, note that embedded payment IDs are 64-bit. This means the space is large enough that one can simply generate them randomly and reliably assume uniqueness.
In very specific scenarios, preparation effort to monitor a very huge number of subaddresses, could became an issue. See this reddit thread for details.
Caveats
There are some caveats:
Single transaction cannot pay to multiple integrated addresses.
As individual running a wallet you should generally prefer subaddresses. However, if you happen to use integrated addresses, you should allow Beldex software to generate integrated addresses for you (instead of forcing your own payment IDs).
Reference
question on StackExchange
Last updated