View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0008082 | Taler | libeufin-nexus | public | 2024-01-12 18:31 | 2024-03-07 20:49 |
| Reporter | Antoine A | Assigned To | Antoine A | ||
| Priority | immediate | Severity | block | Reproducibility | N/A |
| Status | closed | Resolution | fixed | ||
| Target Version | 0.9.4 | Fixed in Version | 0.9.4 | ||
| Summary | 0008082: Make payment bouncing deterministic | ||||
| Description | When libeufin-nexus bounces an incoming payment, it issues a message with an outgoing payment with a random bank ID and a subject mentioning the bounced payment. When rebuilding the database from scratch, there is no way of knowing whether a malformed incoming payment has already been bounced and we risk bouncing the same payment multiple times. In addition, it should be easy for auditors to establish a link between an outgoing payment and a bounced incoming payment. | ||||
| Additional Information | The solution is to generate a deterministic bank ID from the bank ID of the bounced payment. As libeufin-bank and libeufin-nexus are linked using SQL triggers to perform conversion logic, it must be possible to generate the ID entirely in postgres SQL. The bank ID can be a maximum of 35 characters long and we are not sure that this field is case sensitive as the standard does not clearly specify this. Our solution is to perform a SHA-256 hash of the bank ID, encode it using base64, then truncate it to 35 characters and finally capitalise the result. | ||||
| Tags | No tags attached. | ||||
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2024-01-12 18:31 | Antoine A | New Issue | |
| 2024-01-12 18:31 | Antoine A | Status | new => assigned |
| 2024-01-12 18:31 | Antoine A | Assigned To | => Antoine A |
| 2024-01-15 15:19 | Antoine A | Status | assigned => resolved |
| 2024-01-15 15:19 | Antoine A | Resolution | open => fixed |
| 2024-02-10 23:31 | Christian Grothoff | Fixed in Version | => 0.9.4 |
| 2024-03-07 20:49 | Christian Grothoff | Status | resolved => closed |
