|
@@ -0,0 +1,122 @@
|
|
|
+<pre>
|
|
|
+ PIP: PIP-0027
|
|
|
+ Title: E-PASA: Layer-2 Addresses
|
|
|
+ Type: Frontend
|
|
|
+ Impact: None
|
|
|
+ Author: Herman Schoenfeld <[email protected]>
|
|
|
+ Comments-URI: https://discord.gg/sJqcgtD (channel #pip-0027)
|
|
|
+ Status: Draft
|
|
|
+ Created: 2019-02-11
|
|
|
+</pre>
|
|
|
+
|
|
|
+## Summary
|
|
|
+
|
|
|
+This PIP proposes a backwards compatible addressing scheme to facilitate Layer-2 addresses as well as improve current Layer-1 payments and general usage.
|
|
|
+
|
|
|
+## Motivation
|
|
|
+
|
|
|
+PascalCoin current allows users to send/receive operations between accounts using their account numbers (PASA) as a reference. These account numbers are typically post-fixed with a checksum to avoid data entry errors.
|
|
|
+
|
|
|
+This proposal extends this specification to allow the embedding of a payload to an address. This allows a recipient to specify the payload the sender must enter when sending an operation. This is useful in many current use-cases such as a merchant specifying the payload code in the buyers transaction so that he can recognize it. Also, for exchanges to specify the payload for users to deposit. By using these addresses, a single PASA can be represented in many forms.
|
|
|
+
|
|
|
+Most importantly, Layer-2 applications require this as an addressing scheme for Layer-2 applications. As a result, this PIP proposes a formal specification for these addresses.
|
|
|
+
|
|
|
+## Specification
|
|
|
+
|
|
|
+Layer-2 addresses will be herein referred to as Extended PASA, or E-PASA for short.
|
|
|
+
|
|
|
+### Extended PASA format (E-PASA)
|
|
|
+
|
|
|
+An Extended PASA is defined by the below EBNF grammar:
|
|
|
+
|
|
|
+ EPASA = PASA [ExtensionSpec]
|
|
|
+ PASA = Integer-Checksum
|
|
|
+ Checksum = Integer
|
|
|
+ ExtensionSpec = "[" Payload "]" [PayloadChecksum]
|
|
|
+ Payload = PayloadType EncryptionType "-" PayloadContent
|
|
|
+ PayloadType = "H" | "B" | "A"
|
|
|
+ EncryptionType = "N" | "S" | "R" | "P" Password
|
|
|
+ Password = "!"" ASCII-String "!"
|
|
|
+ PayloadContent = HexPayload | Base58Payload | ASCIIPayload
|
|
|
+ PayloadChecksum = ":" Integer
|
|
|
+ HexPayload = "0" "x" HEXADECIMAL-String
|
|
|
+ Base58Payload = BASE58-String
|
|
|
+ ASCIIPayload = "'" ASCII-String "'"
|
|
|
+
|
|
|
+The above rules are explained as follows:
|
|
|
+
|
|
|
+| Rule | Explanation |
|
|
|
+| --------------: | :------------------------------------------------------------------------------------------------------- |
|
|
|
+| EPASA | This is a layer-2 address, fully backwards compatible as Layer-1 address |
|
|
|
+| PASA | This is the standard layer-1 address of an account |
|
|
|
+| Checksum | This is the standard layer-1 address checksum |
|
|
|
+| ExtensionSpec | The specification of the extended PASA portion (payload, how to encrypt, etc) |
|
|
|
+| Payload | The fully qualified payload |
|
|
|
+| PayloadType | The format the payload will be specified in (H = Hex, B = Base58, A = ASCII) |
|
|
|
+| EncryptionType | The type of encryption used on the payload (N = None, S = Senders Key, R = Recipients Key, P = password) |
|
|
|
+| Password | The password used for AES256 encrypted payloads |
|
|
|
+| PayloadContent | The actual payload data, specified it it's correct form |
|
|
|
+| PayloadChecksum | An optional 32bit MurMur3 hash of the Payload |
|
|
|
+| HexPayload | A hexadecimal-encoded string used when specifying a payload in hexadecimal, prefixed with 0x |
|
|
|
+| Base58Payload | A base58 encoded string used when specifying a payload in base58 |
|
|
|
+| ASCIIPayload | An ASCII-encoded string used when specifying a payload in ASCII |
|
|
|
+
|
|
|
+#### Payload Checksumming
|
|
|
+
|
|
|
+In order to avoid data entry errors, the payload portion is **optionally** checksummed. The payload checksum is calculated as follows:
|
|
|
+
|
|
|
+```
|
|
|
+ PayloadChecksum = Format-As-4-Digit-Number( MurMur3( Payload.ToString ) MOD 10000 )
|
|
|
+```
|
|
|
+
|
|
|
+The MurMur3 used here is the 32bit version. The hash digest is **Payload** portion of the E-PASA inASCII form (i.e. the text between square brackets). The Checksum by convention is padded to 4 digits and it's range constrained to 0000 - 9999.
|
|
|
+
|
|
|
+## Examples
|
|
|
+
|
|
|
+### Example 1
|
|
|
+
|
|
|
+```
|
|
|
+123456-77[HN0x12ab3f]
|
|
|
+```
|
|
|
+
|
|
|
+- Address is '123456-77'
|
|
|
+- Payload is the hexadecimal string 0x12ab3f
|
|
|
+- Payload is not encrypted (public)
|
|
|
+- No payload checksum included
|
|
|
+
|
|
|
+**Note**
|
|
|
+ - To encrypt using senders key, address would be ```123456-77[HS0x12ab3f]```.
|
|
|
+ - To encrypt using recipients key, address would be ```123456-77[HR0x12ab3f]```.
|
|
|
+ - To encrypt using password "Alpha$", address would be ```123456-77[HP!Alpha$!0x12ab3f]```.
|
|
|
+ - To add a checksum, address would be ```123456-77[HN0x12ab3f]:9876```
|
|
|
+
|
|
|
+
|
|
|
+### Example 2:
|
|
|
+
|
|
|
+```
|
|
|
+77-44[AN'[email protected]']:1234
|
|
|
+```
|
|
|
+
|
|
|
+- Layer-1 address is '77-44'
|
|
|
+- Payload is the ASCII string "[email protected]"
|
|
|
+- Payload is not encrypted (public)
|
|
|
+- Payload checksum is "1234"
|
|
|
+
|
|
|
+**NOTE**
|
|
|
+- By using recipients key, ```77-44[AR'[email protected]']:5678``` exchanges could use such addresses to accept users deposits easily, via a single address per user.
|
|
|
+
|
|
|
+## Rationale
|
|
|
+
|
|
|
+The design approach was to remain backwards compatible in order to allow existing JSON API's to simply accept E-PASA addresses and which automatically fill out the payload fields.
|
|
|
+
|
|
|
+## Backwards Compatibility
|
|
|
+
|
|
|
+This PIP is backwards compatible and does not requier a hard-fork activation, only an implementation change.
|
|
|
+
|
|
|
+## Reference Implementation
|
|
|
+
|
|
|
+WIP
|
|
|
+
|
|
|
+## Links
|
|
|
+
|
|
|
+None
|