boltwall integration

[bucko13]

This PR removes redis tracking of invoices related to hash submissions and instead uses boltwall to manage endpoint authorization.

New endpoints include:

• GET /boltwall/node to get information about the node that will be paid (useful for establishing better connection to facilitate payment)
• POST /boltwall/hodl to create a new hodl invoice. No body is necessary as a middleware will check for or create (if none is found) a paymentHash and attach it to the req.body such that boltwall can generate a new invoice from it
• GET /invoice If an invoice has been generated in association with the request (determined by macaroons attached as cookies) this will get information about the invoice.

More comments about the code and new functionality will be included inline in the PR.

This PR also includes:

• some additional configs in the docker-compose to enable boltwall's ln-service connection as well as the ability to test against a simnet node running locally (this needs to be made more flexible, open to suggestions!)
• A middleware that creates a unique sessionID associated with new or expired requests. This is used to manage inflight invoices.

TESTING DIRECTIONS

1. Make sure you have boltbox available locally
2. run make simnet to start up a local simnet network
3. Get alice's adminMacaroon, cert, and socket info. The first two should be in a local credentials.json file generated by the script. The socket info should be alice:10001
4. Add the following env vars to your .env file

   LND_SOCKET=alice:10001
   LND_TLS_CERT=[alices tls cert]
   LND_MACAROON=[alice's admin macaroon]
   CAVEAT_KEY=[random string used as a password to sign macaroon caveats]
   # used to sign, verify, and decrypt sessions
   SESSION_SECRET=[randomly generated 32 byte hex string. Can be left out and generated automatically, but session cookies can't be persisted between server restarts if skipped]

   (Note: if you want to test against a running testnet node you can replace the relevant connection information above. Please note, that this must be a different node than the one you will be paying from for testing)

5. To get the services up and running first run docker-compose up -d from the chainpoint-core directory.
6. Once everything is started, you can stop the api container docker-compose stop api and then restart it with the logs (useful for testing) with docker-compose up --build api
7. The update with nodemon and the mapped volumes mean that if you make a change (or just save) the server.js or any file in the endpoints directory, it will get picked up in the container and the server restarted. Useful for testing, but open to feedback on this.

Other tools helpful for testing I recommend testing with postman (so you can easily parse and add headers) and the LSAT Playground. The LSAT playground will allow you to drop in the challenges to generate an LSAT token from it when making your requests.

TESTING ENDPOINTS I find it easiest to use Postman for this, but whatever works for you is obviously fine

1. First try to GET /localhost/boltwall/node to see your node's information
2. Next try and POST localhost/hash without any payment processing (include a proper hash in the request body). You should get a 402 error.
3. Retrieve the LSAT from the WWW-Authenticate header. This will include an invoice.
4. Use the playground to decode the challenge and get the LSAT token (which is just the macaroon).
5. Add the token to your request headers under the Authorization header.
6. Without paying anything, try and submit a hash again. You should get a response that says the invoice is unpaid and give you the invoice information
7. If your simnet started up correctly, you can head on over to localhost:5000 and log in to RTL (password should be `foobar)
8. make sure you're on bob or carol's dashboard (check top left of the dashboard) since alice is getting paid. Go to payments > send and enter your payment information and click "Send Payment". This will hang since it's a hodl invoice.
9. Try and POST localhost/hash again. Now it should go through and the RTL dashboard should show the invoice as confirmed (no more hanging)
10. Try and submit again, you'll get a 402 response again.
11. Rinse and repeat!

[bucko13]

Some areas where I'd like feedback:

• Do the responses make sense to you? Do they meet your expectations for the API?
• docker-compose updates to support this type of testing/development setup. Probably don't want to keep the local files mapped (but maybe it's fine?). Are we ok with nodemon dependency or better to take it out?

[jacohend]

Given that this is the middleware route, do we need any production-oriented changes to swarm-compose.yaml?

[bucko13]

Given that this is the middleware route, do we need any production-oriented changes to swarm-compose.yaml?

I'm less familiar with swarm and how it handles env vars, but for production, I think only the env vars for telling boltwall how to connect with your node are required.

[jacohend]

@bucko13 We provide HOT_WALLET_PASS, HOT_WALLET_ADDRESS, LND_SOCKET, and the mounted lnd volume for connecting the API to LND. The first two are via docker secrets, so they aren't explicit parameters (only visible to the internal container process).

[bucko13]

Boltwall needs a few more (you can see them in the updated docker-compose, also mentioned in the testing directions here). Let me know if/where I need to add them for swarm to work.

[jacohend]

Can boltwall ingest the lnd files for auth purposes? I think we'd rather use the mounted volume for LND_MACAROON and LND_TLS_CERT, if that's possible. For CAVEAT_KEY and SESSION_SECRET, we can add these to docker secrets as long as we generate them during the init script.

[bucko13]

It cannot at the moment but it's an update I plan to make. I think it would still be good to support raw credentials though as it allows a core operator to connect to an existing and/or remote node rather than have to spin one up as part of the same "package".

I realize that all of that is still needed anyway because of the anchoring requirements, but it seems like it might be worthwhile to aim for as much separation/flexibility as possible where we can. Even just with this setup it can allow an operator to receive payments to a node separate from their anchoring wallet. In most cases this may not be desirable since you have to manually top up the anchoring wallet, but I could see use cases for it, e.g. privacy or providing liquidity to other routing nodes you might be running).

[bucko13]

The paths would probably still need to be passed in environment variables anyway though as that is how boltwall handles its ln-service initialization. I think that would be good anyway as in the api service it seems to currently be hardcoded while the socket connection is in an env var, whereas all three are needed for connection so seems like it would make sense to parameterize all of them in env vars/secrets.

[jasonbukowski]

It would be nice if this would optionally accept a winston logger object so that the output generated from the boltwall endpoints matches that of the rest of the application.

[bucko13]

Yes I totally agree. Now that boltwall is more of an “official” project of ours, spending some time on a little cleanup I think is definitely something I’d like to do. I’ve been doing a bit of this in parallel with this PR as they’ve come up (some necessary to get things to work). I will add this to the list!

[bucko13]

To that point actually, any other suggestions for the api that would be worthwhile upgrades, this would be a good opportunity to play around with boltwall and find out.

LSAT and logging will be two big ones. I’m also curious about the error messaging and how those are formatted and communicated.

[jasonbukowski]

There is one particular error that I saw that I feel should be caught and logged as information, not an error. This occurs when you attempt to retrieve an invoice when there is already a currently outstanding unpaid invoice.

There was a problem creating hodl invoice: [ 503, 'UnexpectedAddHodlInvoiceError', { err: Error: 2 UNKNOWN: invoice with payment hash already exists at Object.exports.createStatusError (/home/node/app/node_modules/ln-service/node_modules/grpc/src/common.js:91:15) at Object.onReceiveStatus (/home/node/app/node_modules/ln-service/node_modules/grpc/src/client_interceptors.js:1204:28) at InterceptingListener._callNext (/home/node/app/node_modules/ln-service/node_modules/grpc/src/client_interceptors.js:568:42) at InterceptingListener.onReceiveStatus (/home/node/app/node_modules/ln-service/node_modules/grpc/src/client_interceptors.js:618:8) at callback (/home/node/app/node_modules/ln-service/node_modules/grpc/src/client_interceptors.js:845:24) { code: 2, metadata: [Metadata], details: 'invoice with payment hash already exists' } } ]

I think that should be caught and output something like this (assuming the use of winston) -> 2019-11-08T17:02:50.903Z [info] : Invoice with payment hash already exists : 73566c3bfc76f751352805c3dee254254096279976a522398a7ddb34982e8f57

An error occurred with that specific boltwall operation, but the API remains unfazed... its not bringing down the service. We should just log info like that I think.

[bucko13]

Pausing work on this until boltwall has been updated for LSAT support. Will patch once boltwall API has been upgraded.

[bucko13]

Fixed problem with lsat-js being unable to handle simnet invoices so this should be possible to test against running simnet nodes as in the PR description and verifying/parsing in the lsat playground.

[bucko13]

@jacohend and @jasonbukowski - with regards to code that is no longer necessary, I wanted to confirm/clarify that the following should be removed:

• node-lnd-mon-service/* (whole directory)
• reference tolnd-mon service in docker-compose.yml
• Dockerfile.lnd-mon
• lnd-mon service in swarm yaml
• References to lnd-mon in README
• 'gcr.io/chainpoint-registry/$REPO_NAME/node-lnd-mon-service:$COMMIT_SHA'in cloud-build.yml
• lnd-mon env parsing in parseEnv.js

Are there any other services or code that can be done away with?