View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0004692 | Taler | deployment and operations | public | 2016-09-28 13:53 | 2019-12-20 19:12 |
| Reporter | Florian Dold | Assigned To | Marcello Stanisci | ||
| Priority | normal | Severity | feature | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Product Version | git (master) | ||||
| Target Version | 0.6 | Fixed in Version | 0.6 | ||
| Summary | 0004692: probing scripts to test wire config of exchange/bank is missing | ||||
| Description | For every wire transfer method that supports this, we should have a script that triggers a test transfer to see if bank and exchange can communicate with each other. | ||||
| Tags | No tags attached. | ||||
|
|
Accidentally marked as fixed, I wanted to close another bug. This still need to be implemented! |
|
|
We need dummy deposits for this. We have two ways for that: 0) taler-exchange-aggregate gets some "--fake" option where it performs dummy wire transfers to the bank. 1) the merchant does dummy deposits to the exchange. Option 0) seems more reasonable. |
|
|
mmhh, we really need this? After the company running the exchange signs up at some bank, then it MUST be the case they can communicate.. no? |
|
|
Moreover, banks give their PAYTO URI, and exchanges do know if they speak that method or not. Then, there might exist methods which do not have test transfers - like taler-bank for example - so if we really want to implement this check-script, I propose we issue a 1 cent transfer from exchange to whatever other account to see if it works. |
|
|
"script" might be the wrong word here. What I'm looking for is basically a simple command-line tool to test the basic plugin functionality, and as the plugins are in C, that will naturally itself be a C program. That program should simply parse the configuration (as usual, GNUNET_PROGRAM_run() will do), then load the specified wire plugin(s) (probably which one should be specified on the command-line, as the exchange may load multiple wire plugins, but the tool should only use one), and execute one of two specified actions: 1) show transactions (with a command-line option giving the "since when" in say our base32 encoding, and we should output the binary serial numbers uniquely identifying transactions to the terminal in the same format as well). So this tests that we can see incoming transactions (both plugin logic as well as credentials!) 2) execute transaction (with command-line options specifying the amount and a payto://-URL), testing again that the plugin logic to do transactions is correct, as well as that the credentials are configured correctly. We should then expand the exchange operator manual to include testing the wire plugin setup with the new tool (I would call it "taler-wire"). |
|
|
On 1): could you elaborate more on the "since when" option given in our base32 encoding? Do you mean the "/Date(x)/" format by chance? And then, why the serial numbers should be displayed in _binary_ form? Thanks! |
|
|
The "since_when" cannot be a timestamp, as it doesn't uniquely identify a record (time is inadequate for that). If you look at taler_wire_plugin.h, we identify the offset in the transaction history using a "void *row_off" of "row_off_size" bytes. For example for Blockchains, this could be a block ID (instead of a time). For banks, it might be a 128-bit UUID, a 64-bit record ID or whatever. We should not make any assumptions about the format. Hence the tool should output the rowid as base32, and accept range queries using the same format. (Oh, and I've used "serial numbers" interchangeably with "since_when" and "row_id" here, I mean the same thing in all cases, which is the "row_off" or "start_off" pointers in the taler_wire_plugin.h |
|
|
As of commit c93c62e8, there is a usable version of the taler-wire tool. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2016-09-28 13:53 | Florian Dold | New Issue | |
| 2016-09-28 14:13 | Florian Dold | Note Added: 0011190 | |
| 2016-09-28 14:13 | Florian Dold | Status | new => resolved |
| 2016-09-28 14:13 | Florian Dold | Resolution | open => fixed |
| 2016-09-28 14:13 | Florian Dold | Assigned To | => Florian Dold |
| 2016-09-28 23:30 | Christian Grothoff | Fixed in Version | => 0.1 |
| 2016-09-28 23:39 | Florian Dold | Note Edited: 0011190 | |
| 2016-09-28 23:40 | Florian Dold | Status | resolved => new |
| 2016-09-28 23:40 | Florian Dold | Status | new => assigned |
| 2016-09-28 23:40 | Florian Dold | Fixed in Version | 0.1 => |
| 2016-09-29 01:40 | Florian Dold | Assigned To | Florian Dold => Marcello Stanisci |
| 2016-12-07 14:19 | Marcello Stanisci | Target Version | => 0.5 |
| 2017-03-06 00:26 | Christian Grothoff | Severity | minor => feature |
| 2017-03-08 17:17 | Marcello Stanisci | Note Added: 0011912 | |
| 2017-04-09 00:16 | Christian Grothoff | Product Version | => git (master) |
| 2017-04-09 00:16 | Christian Grothoff | Target Version | 0.5 => 0.7.1 |
| 2018-12-13 13:36 | Marcello Stanisci | Note Added: 0013407 | |
| 2019-01-29 17:43 | Marcello Stanisci | Note Added: 0013512 | |
| 2019-02-03 10:07 | Christian Grothoff | Note Added: 0013566 | |
| 2019-02-10 18:26 | Marcello Stanisci | Note Added: 0013644 | |
| 2019-02-10 18:54 | Christian Grothoff | Note Added: 0013645 | |
| 2019-02-12 19:05 | Marcello Stanisci | Note Added: 0013689 | |
| 2019-02-12 19:05 | Marcello Stanisci | Status | assigned => resolved |
| 2019-02-12 23:17 | Christian Grothoff | Fixed in Version | => 0.6 |
| 2019-02-12 23:17 | Christian Grothoff | Target Version | 0.7.1 => 0.6 |
| 2019-12-20 19:12 | Christian Grothoff | Status | resolved => closed |
