Small spike: Investigate sending vouchers with the boost http request

[geoknee]

Right now the nitro client is fully responsible for communicating a voucher to other participants. However it would be nice if we could just submit the payment for data right along with the request.

We would just need to include the amount and the signature.

This would mean updating go-nitro to expose an API method to receive a voucher.

[geoknee]

This is probably the neatest way to associate payments with retrieval requests.

Other solutions will require more book keeping to prevent payments being redeemed multiple times.

I think the nicest API would be to have a pushVoucher or pushMessage API which returns a payment amount.

This would be a non-idempotent method, so that pushing a voucher a second (or third etc) time results in a payment amount of zero.

We use replace-by-incentive vouchers. So:

pushVoucher({c,10})
=> payment amount = 10
pushVoucher({c,20})
=> payment amount = 10
pushVoucher({c,20})
=> payment amount = 0

This makes it pretty easy for a retrieval provider to:

• accept a voucher as http request params
• push it into their nitro node
• inspect the returned amount to see if it covers the request.

If it doesn't cover the request, what happens? Obviously the request is not serviced. But the retrieval provider has now been paid some amount which won't count towards any future requests. That's something we either need to be comfortable with (can we fall back on the micropayments idea and not worry about it?), or solve somehow.

Clearly the nitro.Pay method needs to now return the voucher over the API on the client side of the interaction.

[geoknee]

Via #1385