View Issue Details

IDProjectCategoryView StatusLast Update
0004692Talerdeployment and operationspublic2019-12-20 19:12
ReporterFlorian Dold Assigned ToMarcello Stanisci  
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status closedResolutionfixed 
Product Versiongit (master) 
Target Version0.6Fixed in Version0.6 
Summary0004692: probing scripts to test wire config of exchange/bank is missing
DescriptionFor 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.
TagsNo tags attached.


Florian Dold

2016-09-28 14:13

manager   ~0011190

Last edited: 2016-09-28 23:39

Accidentally marked as fixed, I wanted to close another bug. This still need to be implemented!

Marcello Stanisci

2017-03-08 17:17

viewer   ~0011912

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.

Marcello Stanisci

2018-12-13 13:36

viewer   ~0013407

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?

Marcello Stanisci

2019-01-29 17:43

viewer   ~0013512

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.

Christian Grothoff

2019-02-03 10:07

manager   ~0013566

"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").

Marcello Stanisci

2019-02-10 18:26

viewer   ~0013644

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!

Christian Grothoff

2019-02-10 18:54

manager   ~0013645

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

Marcello Stanisci

2019-02-12 19:05

viewer   ~0013689

As of commit c93c62e8, there is a usable version of
the taler-wire tool.

Issue History

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