[c-lightning] Feature: run scripts on incoming transactions

[Rusty Russell]

Hi Corné,

        This is an interesting area: currently we hit the database to
validate transactions, and if it commits OK, we mark it paid.  It would
be nice to cut the API at that point, so instead of asking/telling the
DB, we could ask/tell something else.

        One can imagine a JIT inventory management system in future,
where we want to fail payment because we're out of widgets, for example.
Or maybe you want to drive other things directly from the payment,
rather than polling as one does now.

        I think the best solution is a new cmdline option which creates
a new socket: an "approver" connects to this, and it sends JSONRPC msgs
for each incoming payment, and you respond.  Your "fire off
corresponding script" could be a simple helper program.  We could even
use this same API for our current payment DB, though it seems overkill.

        Yes, if the approver blocks, the daemon blocks.  We can get more
sophisticated later (failing payments as if they were malformed if we
start timing out), but there's little else we can do.

Cheers!
Rusty.

Corné Plooy <corne at bitonic.nl> writes:
> Hi,
>
>
> I'm working on an experimental feature for C-Lightning where a custom
> (Sphinx) message in an incoming transaction can trigger the execution of
> a script. The script can receive information about the transaction
> (hash, time-out, amount, message data etc.), do anything it wants, and
> reply to lightningd whether this incoming transaction should be accepted
> or canceled. The incoming transaction does not have to correspond to an
> invoice created in this Lightning node: it can also be that a
> higher-level application needs to forward the payment to some other
> party, in an application-specific way, to gain access to the preimage.
>
>
> The (unfinished) code is available at:
>
>
> https://github.com/bitonic-cjp/lightning/tree/application_connection
>
>
> By its very nature, the code involves some API changes. So far, the
> design is roughly as follows:
>
> * The 'sendpay' command allows optional extra attributes 'realm' and
> 'data' in individual route steps. These override the normal realm value
> (0) and data (channel ID, amount, time-out) that would otherwise be put
> into the routing data given to a node.
>
> * If an incoming transaction contains a realm number that would
> otherwise not be supported (currently, realm 0 is the only one defined
> by the RFC and supported by C-Lightning), lightningd tries to execute a
> script "handle_realm_<realmnumber>" in the Lightning directory. It
> receives information about the transaction on STDIN (format: TBD), and
> sends a single number back on STDOUT indicating whether the transaction
> should be accepted or rejected.
>
> * Currently, if such a script hangs, lightningd hangs. I'm not
> completely happy with this, but what would be the alternatives? Not have
> the script send any data back? Asynchronous communication with the
> script? You potentially have a "process leak" problem: an attacker may
> crash a machine by triggering huge numbers of parallel script
> executions. For now, this problem does not exist, and "don't make buggy
> scripts" is an obvious solution to stop lightningd from hanging.
>
> * Extra RPC commands will be added to allow applications to give a
> transaction preimage to lightningd (inherently safe) and to indicate
> that a certain payment will be canceled (unsafe - the application needs
> to ensure that any outgoing goods/services/assets are stopped, before
> canceling the incoming funds).
>
>
> The reason for this e-mail:
>
> * I want you to be aware of this project
>
> * I'd like to have some "early" feed-back on the API design
>
> As a consequence of me being open to feedback, the API is subject to
> change; don't depend on it yet!! In fact, currently, it's all designed
> in a very ad-hoc manner; I'll have a critical look at it myself, as soon
> as I have a prototype with a tested full feature set.
>
>
> regards,
>
> CJP
>
>
>
> -- 
> c-lightning mailing list
> c-lightning at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/c-lightning