Simplifying buying

[bedeho]

Background

This proposal is a deep fix to the issue of having the user construct the contract transaction in javascript. We have been discussing moving this into the addon, or the wrapper, to hide some of it from the end user, but at the deepest level, there is a redundancy which this proposal tries to look at the lowest level where it exists.

---

When trying to start downloading, using the extension::request::StartDownloading, the user of the extension has the following pieces of non-trivial information

• protocol_session::PeerToStartDownloadInformationMap<libtorrent::tcp::endpoint> peerToStartDownloadInformationMap: what peers to use, and corresponding setup information
• Coin::Transaction contractTx: a fully signed contract transaction

Importantly, the extension knows everything it needs to know to construct contractTx on it own, it only requires some means of financing it.

Problem

Requiring user to construct contractTx leaks lots of details about the payment channel into user code, which both makes it more complicated, to manage, test and change. It really should be avoidable to have the user to this redundant work, and instead give the extension the minimal amount of information.

Solutions

Replace contractTx in the extension::request::StartDownloading request with

struct Financing {
  std::vector<Coin::TxIn>> inputs;
  boost::option<Coin::TxOut> possible_change;
}

@brief Gets financing for given outputs and total fee rate constraint.
@param outputs ordered set of outputs, to be financed
@param fee minimum satoshies per Kb constraint required on final transaction
@return financing of the given outputs with given fee constraint
typedef std::function<Financing(const std::vector<Coin::TxOut> & outputs,int64_t fee)> Financier;

which is called by the extension to construct the final contract transaction.

Two approaches

There are two approaches to implementing a Financier instance.

• have it make a direct call with whatever manages the UTXO set in the application, for example a wallet or UTXO manager. This introduces the potentially difficult problem of synchronizing the libtorrent thread with user thread(s).

• preallocate the UTXO set, and capture it in the Financier, and use it to sign when called.

The second option is better, as it avoids any need for synchronization, however, the ability to do so requires a sufficiently flexible signing infrastructure in the application.

Example: joystream-node-cpp

The first approach would require synchronizing with the nodejs thread, which is possible, but non-trivial.

The second approach would require altering the start_download binding in the addon to take some sort of utxo representation. This representation could be converted into an Coin::UnspentOutputSet instance, and capture this inside the Financier. This will require fixing the representation to a predetermined set of UTXO types, e.g. only p2sh, or p2pkh. So a user of the js wrapper would do something like

// p2pkh utxo
var utxo_1 = {
outpoint: ...
sk: ...
value: ...
};

plugin.start_download(..., [utxo_1]);

[mnaamani]

I agree with the need to hide the paymentchannel details from the application layer, and the second approach to your proposed solution is arguably better than the first.

Although there is additional complexity introduced by having a UTXO manager, it does eliminate the construction of the transaction at the application layer, and any need to make calls into the wallet from the plugin to sign/fund a transaction.

The start_download will need to provide the serialized transaction in the callback so the application can broadcast it? Or if it's available in the "DownloadStarted" event payload, the application can get the transaction from there I suppose.

The details of payment channels can creep up again when pre-allocating the utxos however: when selecting the total funds required to make a utxo set which will be captured by the financier it needs to account for the fee that is based on the estimated size of the contract Tx.

Another approach is possible, by not having to pre-allocate utxos. Add a new plugin function

plugin.prepare_contract(PeerToStartDownloadInformationMap, function callback(contracTx, feeRate){

})

which submits a new plugin request "PrepareContract" that will create a partial contract transaction (containing commitment outputs, no inputs, no change output).

The application can then fund and sign the contract with a given feeRate, and make a subsequent call to plugin.start_downloading, passing in the signed transaction and the same peerToStartDownloadInformationMap.

This solves the need to know details about how to construct the transaction in javascript, but still has to be aware of the fact that a contract needs to be prepared.

[bedeho]

Continuation from our Slack discussion

GOAL: minimize buying complexity for user of javascript developer, and perhaps also extension-cpp

FIX 1: Plugin builds contract, signs using callback c++ callback (which captures nodejs utxo state)

extension-cpp

• Introduce financier
• Change StartDownload request to drop contract, introduce financier.
• Change StartDownload request hanler to call financier, and build contract internally. The plugin will construct a contract with as many of the peers
  as reflected, while exlucluding those that no longer match (gone, or changed terms). We could add another parameter where the plugin commits to not even try, unless a given number of requested peers are available.

joystream-node-cpp

• export seller_output_size binding, which gives static size of a given seller output in contract
• introduce decoding for a UTXO set, which can include mix of p2sh & p2kh utxo
• update start_downloading such that
  • such a set is provided instead of contractTx
  • the financier constructed, to be passed to the plugin, captures
    a decoded utxo set, and uses it to construct and sign a contract for the plugin, using Coin::* types, and on the libtorrent thread.

joystream-node-npm

• torrent_plugin.start_downloading is updated to only send utxo, no contractTx

user/utility code

• given set of sellers to buy from, allocate utxo by combination of
  • seller prices
  • fee constraints
  • number of pieces in torrent size
  • seller_output_size

FIX 2: Native addon builds contract, signs using js callback

extension-cpp

• nothing

joystream-node-cpp

• modify peers map binding to be able to have payorSk, so that addon can builds contract
• update plugin.start_downloading
  • remove contractTx param
  • add transaction signing callback signer(tx, min_fee_rate) param,
    where tx is an unsigned transaction, and fee_rate is the minimum fee rate on the signed transaction.
  • it constructs tx, using modified peers map, and the paychan contract builder.
  • it constructs min_fee_rate, by using the peers map.
  • if signer throws, then start_downloading passes that on to user, e.g. due to insufficient funds.

joystream-node-npm

• small changes

FIX 3: Javascript wrapper builds contract, and signs using js callback

extension-cpp

• nothing

joystream-node-cpp

• nothing

joystream-node-npm

• similar to joystream-node-cpp

FIX 4: Plugin does it all

• we go back to the plugin starting buying itself,
  and picking its own peers, and only requesting a signature
  through a callback, which needs to be synchronized.
  If it fails, due to insufficient funds, then the plugin sends an alert