Tool to "compile" and create spending condition tx — Part 1

[troggy]

Bounty

⚠️Bounty has EXPIRED. If you want to work on this issue, chime in into comments first ⚠️

This issue takes #5 couple of steps further.

Currently, it is a big deal to create a spending condition transaction. First, you need to create an address, which is fairly easy still requires some boilerplate. Second, when you are about to create a spending condition tx you need to a) know which inputs and outputs to supply b) write more boilerplate like including LEAP input with script and encoded msgData. As a user you will need to study the spencon code to effectively execute it, which makes adoption harder.

Proposal is to create a tool to generate a helper object for each spencon. This helper can be then dropped in a client app and used to simplify making spending condition tx.

Scope

• create a tool like this:
  Input:

  • path to a contract json file made by Truffle compiler or contract json itself
  • list of parameters for placeholder substitution. Placeholders are expected to be deterministic: 0x1111...111, 0x2222...222 and so on.

  Output:
  A <contract>.js file exporting an object (SpenCon object) with:

  • spencon script
  • spencon address
  • contract code (solidity or link to ipfs)
  • function to generate a base for spending condition tx: input with fee, script and encoded msgData

• allow to run the tool from command line

• allow to use the tool programmatically in javascript code (allow require)

• publish the tool in npm (leapc 😃)

• add an instruction to docs.leapdao.org

Deliverables

• command line tool published on npm
• updated documentation

Gain for the project

• foster network adoption by providing easier developer experience

Publicly visible delivery

• updated docs.leapdao.org
• maybe tweet?

Roles

bounty gardener: @troggy / 10%
bounty worker: name / share
bounty reviewer: name / share

Funded by

Dev Circle

[MaxStalker]

Since we are on it, would be pretty cool to do something about conditional outputs.
I had this case in my game, where output would be defined by your inputs and msgData. So you would need to create spending condition, then check it, adjust outputs and gas price, check it again. And only after that you can submit it. Not kewl :\

[troggy]

@MaxStalker yeah, this will be a Part 2 for the tool.

Something like this:

1. Create spencon tx barebones (e.g. only gas input and output, script an msgData) with the SpenCon object generated by the tool before
2. Provide the rest of the inputs
3. SpenCon object will run the tx against checkSpendingCondition on the node getting all the outputs (@vrde uses similar approach in PlanetA)
4. SpenCon object verifies that all the required outputs are in place: e.g. for each NST/NFT input it is expected to see corresponding output to owner
5. SpenCon object submits the tx

Schematically:

const tx = await AirSpencon.create(paramsArr, plasmaClient);
// ... tx here has one LEAP input (selected by the tool using `plasmaClient`) with script and msgData created from `paramsArr` and maybe one LEAP output with change (if needed)

// user adds the rest of the inputs here
tx.inputs.push(...)

await AirSpencon.checkAndSend(tx, privKey); // emulate, add all the outputs, sign and send

[pinkiebell]

Nice, I appreciate the tooling work here.

I'm forming a new spending condition design in my head that still uses the underlying UTXO model for 'state changes' but otherwise works like on the ethereum root chain. I'm going to sketch something up soon, so stay tuned.

In the meantime, 💯 for the tooling work here. ✊

[johannbarbie]

deterministic: 0x1111...111, 0x2222...222 and so on.

this is kind of difficult. replacements can go wrong if the byte before the address is also 0x11 or 0x22. hence, the template needs to be a pattern.

[johannbarbie]

Funded by ?

EF-grant!

[troggy]

this is kind of difficult. replacements can go wrong if the byte before the address is also 0x11 or 0x22. hence, the template needs to be a pattern.

good point. Now I see why the placeholders were always so weird :)

[troggy]

How about using the same pattern then for the first 19 bytes and put the placeholder index in the last byte?

[johannbarbie]

another very rough idea was to have library contracts for the different environments, containing the constants, which then can be imported. but that would require recompiling contracts when deploying from testnet to mainnet.

[troggy]

requesting to upsize this one to M because on a second glance it looks underfunded esp. for proper review (I anticipate a long review here)

[troggy]

upsized optimistically. Let me know in case of objections