bigchaindb / bigchaindb/bigchaindb-driver
Allow for multiple inputs/outputs in prepare_transaction and fulfill_transaction
- Dominant language
- Python
- Stars
- 106
- Forks
- 99
- PR merge metrics
- No merged PRs in 30d
Description
Currently it is the following:
```
In [14]: cid = 0
In [15]: condition = creation_tx['transaction']['conditions'][cid]
In [16]: transfer_input = {
....: 'fulfillment': condition['condition']['details'],
....: 'input': {
....: 'cid': cid,
....: 'txid': creation_tx['id'],
....: },
....: 'owners_before': condition['owners_after'],
....: }
....:
In [17]: prepared_transfer_tx = bdb.transactions.prepare(
....: operation='TRANSFER',
....: asset=creation_tx['transaction']['asset'],
....: inputs=transfer_input,
....: owners_after=bob.verifying_key,
....: )
....:
```
while it could be simply:
```prepared_transfer_tx = bdb.transactions.prepare_transfer(input_tx, output_id, owners_after, metadata) ```
Notice that the operation, transfer_input, asset are all derived from the input_tx (full transaction, not only the tx_id). The complex transfer_input object is legacy of the common code, but can easily be abstracted away in the driver until the common code is fixed
Contributor guide
Research direction
Start at the bdb.transactions.prepare entry point and trace the transaction-building flow around the proposed prepare_transfer API. Compare how prepare_transfer and fulfill_transaction should derive inputs, outputs, the operation, and asset from a full input transaction; done means both APIs support multiple inputs and outputs without requiring callers to build the legacy transfer_input structure.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100