The jellyfishsdk from birthdayresearch

@defichain/testcontainers should automatically update itself when there is an release

What would you like to be added:

Automatically create a pull request to jellyfish/packages/testcontainers with the update docker version.

Why is this needed:

Manually creating PR is tiresome, this pipeline should be automated.
PR will be automatically tested, reviewer can just approve and merge them in and get immediate CI checks.

refactor `jellyfish-address` implementation to be lighter

#189 (review)

What would you like to be added:

Refactoring of jellyfish-address code/logic to be lighter, currently, it's too complex. Dangerous technical debt.

Why is this needed:

@@           Coverage Diff            @@
##             main     #189    +/-   ##
========================================
  Coverage   96.21%   96.22%            
========================================
  Files          66       74     +8     
  Lines        1718     1958   +240     
  Branches      235      264    +29     
========================================
+ Hits         1653     1884   +231     
- Misses         65       74     +9

I would expect around <15 code logical branches for jellyfish-address but there were +29 which is 10% more than the current combined mono repo code base.

#237 has only +7 for comparison and it has a much more complex implementation design. Clearly, there is much to optimize, the more code there is, the more there is to maintain. Less is more.

bigint platform compatibility problem

What would you like to be added:

Not to use readBigUInt64LE and bigint as it's not support in many platform.

JavaScript hierarchical deterministic wallet for DeFiChain ecosystem

What would you like to be added:

Ability to create hierarchical deterministic wallet with JavaScript/TypeScript that can be used for the DeFiChain ecosystem.

Likely to follow the principles behind bip32 & bip39 but not yet decided.

Why is this needed:

To reduce the complexity of private key and wallet management for the developers of DeFiChain ecosystem.

documentation front matter

What would you like to be improved:

Improve front matter of the documentation website. This include:

Logo & branding matters
SEO meta
Out links
Deployed Netlify (OSS Plan)
Domain: jellyfish.defichain.io?

Why is this needed:

Currently the documentation website is populated with basic relevant docs of jellyfish development. But not much attention is paid to the "front matter" of the docs website.

documentation website continuous deployment

What would you like to be added:

Continuously deploy docs website that are merged into main
Continuously integrate docs website with preview at each pull request

Service provider like Netlify, Vercel & AWS Amplify can be used.

Why is this needed:

Make docs website a no-op process for jellyfish development
Bring visibility to documentation website at each pull request
+ all the benefits of shift level automations

DeFi Blockchain RPC Implementations

This tracks all the RPC methods and categories being implemented in jellyfish-api-core. Will list all the methods here, and strike out those that are not applicable.

Feel free to update this and tag yourself if you want to work on a feature. You will need to reference DeFiCh/ain code base, https://github.com/DeFiCh/ain/tree/master/src/rpc to be exact.

This is purely for documenting all features of DeFi Blockchain. 
Everything that is required has already been completed.

`src/rpc`

`blockchain.cpp`

`mining.ccp`

`misc.cpp`

`net.cpp`

`rawtransaction.cpp`

`server.cpp` - COMPLETED

getrpcinfo #330
~~help~~
~~stop~~
uptime #340

`src/spv`

`spv_rpc.cpp`

`src/wallet`

`rpcwallet.cpp`

`src/masternode`

`mn_rpc.cpp` - COMPLETED

setgov #456
getgov #456

`rpc_accounts.cpp` - COMPLETED

`rpc_masternodes.cpp` - COMPLETED

`rpc_poolpair.cpp` - COMPLETED

`rpc_tokens.cpp` - COMPLETED

@defichain/jellyfish-address to include fromAddress(string) and toAddress(script.hex) + refactor

Blocked by #187
To refactor #139 after merged

What would you like to be added:

We need a utility for DeFi Blockchain address for easy address interfacing for DeFi JS ecosystem.

export type Network = 'mainnet' | 'testnet' | 'regtest'

export const DeFiAddress {
  from(address: string): {hex: string, network: Network}, // return hex with prefix stripped
  to(hex: string, network: Network): string, // return address with network prefix
}

At the same time, we should refactor all address related code into @defichain/jellyfish-address. Putting it into package/jellyfish-address and importing jellyfish-crypto and jellyfish-network as dependencies.

documentation sandbox environment with ocean

What would you like to be added:

Allow sandbox environment in the documentation website.

Possibly using a testnet or mainnet via ocean.defichain.com https://github.com/DeFiCh/ocean/issues/1
Also a codesandbox env?

Why is this needed:

Lower the complexity to start building dApps
Allow developer to try and understand what it each method does in a safe environment

strict json precision parsing

What would you like to be added:

Its not critical but also a note.
Currently the precision is loose on
while:

parse (obj, type): any
parse({ foo: { bar: 123 }, bar: 123 }, { bar: 'bignumber' }

result:

{ foo: { bar: { BigNumber }}, bar: { BigNumber }}

expected:

{ foo: { bar: 123 }, bar: { BigNumber }}

note:
Two issues will be facing while implement the strict precision

ApiClient.call's resp object structure - { result, error, id }
Ideally for rpc call is only passing the relevant precision mapping object

// better
getBlock(...args) {
  return await this.client.call(m, [], { number: 'bignumber' })
}

// Not so friendly
getBlock(...args) {
  return await this.client.call(m, [], { result: { number: 'bignumber' }})
}

Nested object will not be able to get parsed
Currently in order to remove the loose precision is to replace the precision by empty object {}

// remap.ts ln: 108-110
case MappingAction.DEEPLY_UNKNOWN:
  -- remapLosslessObj(losslessObj[k], precision)
  ++ remapLosslessObj(losslessObj[k], {})
  break

this causes the nested object cannot be parsed due to empty precision.

Why is this needed:

technically {foo: { bar: 123 }} !== { bar: 123 }
for note

But its also convince-able to remain the loose precision

Rare case in real scenario

parse({foo: {bar: 123}, bar: 123}}, {bar: 123})

assume bar is a crypto amount, so why not parsing both??

Its doable for but its required extra struct specification

parse({foo: {bar: 123}, bar: 123}}, { foo: {bar: 'number'}, bar: 'bignumber' })
// foo.bar remains number
// bar is converted to bignumber

DeFi CustomTx scripting

This tracks all the DeFi scripting (AKA CustomTx) that is to be implemented in jellyfish-transaction.

packages/jellyfish-transaction/src/script/defi/*

All CustomTX has a starting signature of DfTx in utf8 or 0x44665478. It is as it is, don't need to convert from BE to LE.

They are structured as a

VarUInt + [OP_RETURN + DfTx + TYPES[CxTxType] + ...]
VarUInt + 6a + 44665478 + Type + ...

CustomTx

It's a char, UTF8 -> HEX

Implementation core with error handling and protocol adapter

What would you like to be added:

jellyfish-core implementation must be:

modern with near zero dependencies to mitigate risk
support interceptors implementation but not implemented on day one
error handling at core, Promise.reject()
ability to adapt to any protocol when introduced, ws, https etc while being simple to use

/triage accepted
/area core

`@defichain/testing` `sendtokenstoaddress` utility method

What would you like to be added:

Currently in @defichain/testing only accountToAccount is supported. That function requires manual selection of tokens to send for testing. We need sendtokenstoaddress for testing for a better/easier setup process.

additional test in `jellyfish-api-core` to ensure DFI can only be sent as UTXO

What would you like to be added:

A test within jellyfish-api-core to ensure that DFI can only be sent to others in the form of UTXO.
expect().toThrow()

Why is this needed:

Additional regression capability for api-core.

rename jellyfish-* to transport-* or api-*

What would you like to be added:

Rename jellyfish-* to transport-* or api-*. or protocol-*

jellyfish-core to transport-core or api-core
jellyfish-jsonrpc to transport-jsonrpc or api-jsonrpc

Why is this needed:

While working on the wallet-core RFC for #25 jellyfish name should be reserved for the project as it bundles related project for a single distribution. Renaming jellyfish-core to api-core or such will reduce the confusion of what jellyfish does.

/triage accepted
/area core jsonrpc
/priority important-soon

dependabot giving wrong deps update

What happened:

Invalid PR such as #148 and #147 are created. Although the version updates state in the PR title are valid, but the PR created to update the version and wrong.

What you expected to happen:

packages/*/package.json & package-lock.json should be created to update just that deps. Min of 2 files and at least 2 LOC to change. There might be lack of support for NPM7 workspaces, hence we might need to individually indicate each package.json in .github/dependabot.yml

This is an example of a correct PR that should be created by dependabot: https://github.com/DeFiCh/oss-governance-bot/pull/71/files

@defichain/jellyfish-crypto to include bs58check capability

What would you like to be added:

Currently, only bech32 is supported in jellyfish-crypto, we need to add base58check encode/decoding support in
@defichain/jellyfish-crypto. This is for address type: p2sh, p2pkh.

The implementation should follow the design pattern of https://github.com/DeFiCh/jellyfish/blob/main/packages/jellyfish-crypto/src/bech32.ts

Test fixtures/data should be taken directly from running testcontainers. https://github.com/bitcoinjs/bs58check can be used for the implementation. Our network prefix are here: https://github.com/DeFiCh/jellyfish/blob/main/packages/jellyfish-network/src/index.ts

Why is this needed:

Although for the light wallet implementation we don't intend to support receiving via non-bech32 address, we still need to support sending. We also need this for DeFi whale and DeFi explorer.

error installing via npm 'No matching version found for @defichain/jellyfish-core@^0.0.3.'

What happened:

npm i @defichain/jellyfish --save --include=dev

npm ERR! code ETARGET
npm ERR! notarget No matching version found for @defichain/jellyfish-core@^0.0.3.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

What you expected to happen:

Successful installation

How to reproduce it (as minimally and precisely as possible):

npm i @defichain/jellyfish --save --include=dev

`DeFiCh/ain:1.7.x` DeFi CustomTx (DfTx)

enum class CustomTxType : uint8_t
{
  AppointOracle         = 'o',
  RemoveOracleAppoint   = 'h',
  UpdateOracleAppoint   = 't',
  SetOracleData         = 'y',
}

in

packages/jellyfish-transaction/src/script/defi/*

All CustomTX has a starting signature of DfTx in utf8 or 0x44665478. It is as it is, don't need to convert from BE to LE.

They are structured as a

VarUInt + [OP_RETURN + DfTx + TYPES[CxTxType] + ...]
VarUInt + 6a + 44665478 + Type + ...

Refer to #108 for a detailed implementation guide

browser/jellyfish.umd.js to be exported as global mode

Moved out of scope from #17 due to waiting for upstream fixes and implementation.

What would you like to be added:

import jellyfish from 'jellyfish.ts'
window.jellyfish = jellyfish

Why is this needed:

To allow browser users to do this:

<script src="https://unpkg.com/@defichain/jellyfish@latest/dist/jellyfish.umd.js"/>
<script>
  var client = new jellyfish.Client('http://ocean.defichain.com')
  client.mining.getMintingInfo().then(info => {
    console.log(info)
  })
</script>

Replace examples that uses `getMintingInfo` with `getMiningInfo`

#229 getMintingInfo is used as an example in some places, let me know if this PR should replace the examples as well

What would you like to be added:

Following the deprecation of getMintingInfo, getMiningInfo is added to support multiple masternode support from within one defid instance. We need to update all documentation that uses getMintingInfo as an example to use getMiningInfo.

refactor/rename by adding `_TX` for `DEFI_OP_*`

What would you like to be added:

https://github.com/DeFiCh/jellyfish/blob/7f906b1779c89f2cf39a2eaf66d8cc12cbcd54f8/packages/jellyfish-transaction/src/script/mapping.ts#L95-L126

Inconsistency in naming convention noticed by @monstrobishi in jellyfish-transaction/script/mapping.ts.
To refactor as it is best to follow the original naming convention.

Correct

OP_DEFI_TX_TOKEN_MINT
OP_DEFI_TX_POOL_REMOVE_LIQUIDITY

Wrong

DEFI_OP_UTXOS_TO_ACCOUNT
DEFI_OP_ACCOUNT_TO_UTXOS

multi-platform matrix CI testing for edge and regression

What would you like to be added:

Currently, the CI only test on linux platform. We should test on windows and mac to guarantee edge and regression don't show up.

                                       --> CI Build & Test (Windows)
CI Build & Test with Coverage (Linux) |
                                       --> CI Build & Test (MacOS)

@defichain/testing for modular testing fixtures setup

What would you like to be added:

In the process of dogfooding this library and building up and out the DeFi ecosystem, we have to write tons of tests. The test that is written is pretty much consistent with a minor variable difference to test an aspect. They are not fixed hence your typically fixture paradigm is not effective. But rather we need a testing module (e.g. @defichain/testing) with utilities to set up the testing conditions.

As this library is written in jellyfish and to prevent circular dependant, jellyfish components should not use @defichain/testing components for testing. This is for projects that are external to jellyfish, DeFi whale for an example.

Example of a 'fixture' to setup a condition:

async function createSignedTxnHex (
  aAmount: number,
  bAmount: number,
  a: EllipticPair = Elliptic.fromPrivKey(Buffer.alloc(32, Math.random().toString(), 'ascii')),
  b: EllipticPair = Elliptic.fromPrivKey(Buffer.alloc(32, Math.random().toString(), 'ascii'))
): Promise<string> {
  const aBech32 = Bech32.fromPubKey(await a.publicKey(), RegTest.bech32.hrp as HRP)
  const bBech32 = Bech32.fromPubKey(await b.publicKey(), RegTest.bech32.hrp as HRP)

  const { txid, vout } = await container.fundAddress(aBech32, aAmount)
  const inputs = [{ txid: txid, vout: vout }]

  const unsigned = await client.rawtx.createRawTransaction(inputs, {
    [bBech32]: new BigNumber(bAmount)
  })
  const signed = await client.rawtx.signRawTransactionWithKey(unsigned, [
    WIF.encode(RegTest.wifPrefix, await a.privateKey())
  ])
  return signed.hex
}

@defichain/testcontainers spv testing

What would you like to be added:

Currently, RegTestContainer offers a variety of testing functions and boilerplate to ease testing. E.g. container.generate(1) and container.waitForCoinBaseMaturity(). We need to add spv testing functionality into RegTestContainer as well.

spv_fundaddress as container.spv.fundAddress()
spv_setlastheight as container.spv.setLastHeight()

class RegTestContainer {
  readyonly spv = new Spv(this)
}

jellyfish-transaction tests should be run against testcontainers for compatibility

What would you like to be added:

Additional testing against testcontainers for jellyfish-transaction for better compatibility. This can be done on a RegTestContainer without masternode configured for a quick round of tests. __testcontainers__ directory can be used to separate the tests that require testcontainers to be up.

Why is this needed:

This provide additional guarantee the txn generated by jellyfish-transaction will all always in compliance with DeFi Blockchain.

Extended testing on TestNet & MainNet?

What would you like to be added:

Run extended end to end test on testnet and mainnet for extra quality.
Honestly seems highly redundant, but note worthy.

packages/*/
├── __tests__/**.test.ts            <- fast tests, spins up regtest chain
├── __tests_testnet__/**.test.ts    <- slow tests, spins up test chain
└── __tests_mainnet__/**.test.ts    <- slow tests, spins up main chain

Why is this not a good idea?

It takes forever to sync main/test net, GitHub Actions are time scoped
It takes considerably longer to run the tests, this will hold up our GitHub Actions concurrency
Longer cycle time to push changes into main if we need to wait for main/net test cases to complete
No significant test coverage compared to regtest

@defichain/testcontainers multi node testing

What would you like to be added:

Ability to setup and run multiple nodes in @defichain/testcontainers for distributed decentralized mocking.

Why is this needed:

For scenario that require testing transaction send from another node.

Documentations

What would you like to be added:

Documentation to be implemented along side with code in the docs/ directory. Docs to be deployed automatically on merged.

Why is this needed:

Allow feature to be released together with documentation on release.
Sharing the same concern, easy for community to contribute

@defichain/testcontainers should be less flaky

What would you like to be added:

Implement measures to make the test less flaky.

Why is this needed:

Spending too much time manually re-triggering the tests as they are too flaky.

DeFi 'super-node' upstream proxying service

What would you like to be added:

An API gateway/proxy service for DeFiChain jellyfish users.

Why is this needed:

Currently, the JSON-RPC channel in DeFiCh/ain is password protected by default. Important and intentional by design. However, this makes it difficult to setup password-less service for public to uplink to. It does not make sense to implement API gateway/proxy features in C++. This will also offload the networking layer to a purpose built provider. (👀 NGINX & Related)

We need:

Whitelist based service/system for super-node hosting to on/off certain RPCs?
A build of DeFiCh/ain without wallet features
HTTPS & HTTP2 capable gateway for TLS termination
Cloud Native - docker capable setup

We should:

Use infrastructure as code for deployment
Open source the setup for anyone that wants to run it
Use solution with high memory/networking pressure capability over fully featured solutions.

txid in jellyfish is using LE order, we might want to use BE for consistency

What would you like to be added:

Change txid in jellyfish-transaction when encoded as a string to be formatted as BE order.

defid uses LE
DeFi Whale uses defid through jellyfish-api-core hence BE
DeFi Whale Indexer also uses BE since it's same as above
Only jellyfish-transaction uses LE when stored at REST.

We should change to BE for consistency.

jellyfish-api-whale & jellyfish-wallet-whale

What would you like to be added:

DeFi whale is a stateless stateless indexer for DeFi Blockchain. jellyfish-api-whale is hence the typed api client for interacting with jellyfish-api-whale. This will be developed together with the DeFi whale project.

Why is this needed:

DeFi Whale has entered into project inception phase.
WhaleWalletAccount implements the WalletAccount from jellyfish-wallet; a stateless account service for DeFi.

This is required for WhaleWalletAccount.

IEEE-754 conscious design, json-bigint, bignumbers & native number

What would you like to be added:

Built-in JSON/Object parser must parse number as bignumber, and development of library must take a beginner friendly stance of interoperability with big-number and number.

https://www.npmjs.com/package/json-bigint

Why is this needed:

While most developers are aware of the IEEE 754 double standards, JSON specification does not say anything about number precision. Jellyfish implementation must be accommodating to various developer experience while preventing number precision mistake at large.

THIS IS VERY IMPORTANT FOR THE LIBRARY TO BE ACCOMMODATING TO VARIOUS DEVELOPER EXPERIENCE.

> parseFloat("0.000008") * 10
0.00007999999999999999

/area core
/triage accepted
/priority important-soon

dumb revive json-rpc value type

What would you like to be added:

"smart revive" blockchain amount as bignumber, the rest numeric remains as number.

Why is this needed:

strict type and better view for user

seperate jellyfish-transaction segwit parts into jellyfish-signature

What would you like to be added:

Spin off tx_segwit.ts and tx_signature.ts that is part of jellyfish-transaction into a separate package called jellyfish-signature or jellyfish-transaction-signature.

Why is this needed:

To remove "@defichain/jellyfish-crypto" dependencies out of jellyfish-transaction for lite applications that want to just use jellyfish-transaction as it further depends on this dependencies. This will eventually make it easier to bundle jellyfish-transaction into jellyfish, as jellyfish-transaction only has smart-buffer as a dependency.

"@defichain/jellyfish-crypto" dependencies:

"bech32": "^2.0.0",
"bip66": "^1.1.5",
"create-hash": "^1.2.0",
"tiny-secp256k1": "^1.1.6",
"wif": "^2.0.6"

`jellyfish-wallet-ledger`

What would you like to be added:

#25 jellyfish-wallet implementation should support ledger hardware wallet.

Docker setup for dev, integration and staging environment

What would you like to be added:

Ability for the test env to automatically spin up defi/defichain:latest for testing without any manual setup.

This can be implemented directly into https://github.com/DeFiCh/ain/tree/master/.github as a workflow to build docker images ready for use without command override. Command interface is not friendly for automation, preference of convention over configuration.

Why is this needed:

Allow upstream services of DeFiChain Blockchain [this project included] to utilize conventional defaults when running integration automation, tdd, testing and such. Allowing projects to have the ability to setup fully-featured test env for their various needs.

jellyfish-wallet-mnemonic to support encrypt and decrypt

What would you like to be added:

jellyfish-wallet-mnemonic with encrypt and decrypt function extended above 24 word.
24 word must unlock the wallet, this just encrypt the 24 words on rest.

Why is this needed:

The 24 words mnemonic seed should serve as a cold storage of your HD seed.
However the 24 words should not sit in your device (phone/browser/desktop) unencrypted as rest.
Encryption can be done with biometric authentication provided by device, jellyfish-wallet-mnemonic just need to provide the interface to do it.

Reference example: https://github.com/bitcoin/bips/blob/master/bip-0038.mediawiki

`DeFiCh/ain:1.7.x` RPCs implementation

Similar to #48 This tracks all the RPC methods and categories being implemented in jellyfish-api-core. Please tag update this if you want to work on a feature.

~~As a final docker build is not produced please use the latest 1.7.x docker build for your testcontainers, #184 for more information.~~

`src/masternodes/`

`rpc_icxorderbook.cpp`

`rpc_oracles.cpp`

appointoracle @jingyi2811 #336
removeoracle @jingyi2811 #339
updateoracle @jingyi2811 #341
setoracledata @jingyi2811 #346
getoracledata @jingyi2811 #347
listoracles @jingyi2811 #345
listlatestrawprices @jingyi2811 #352
getprice @jingyi2811 #355
listprices @jingyi2811 #356

`src/spv`

`spv_rpc.cpp`

address validation for p2sh, p2pkh, p2wpkh, p2wsh

What would you like to be added:

jellyfish-network or jellyfish-wallet should implement a validator and guess what kind of address this is.

Why is this needed:

For client/wallet app this provides an utility to present the type of address user are sending their crypto assets to.

DeFi OP_CODES implementation mapping

This tracks all the OP_CODES class and their categories to be implemented in jellyfish-transaction. DeFi blockchain custom transaction will be tracked in another issue.

packages/jellyfish-transaction/src/script/*

`data.ts`

0x01-0x4b @fuxingloh #106
OP_PUSHDATA1 @fuxingloh #106
OP_PUSHDATA2 @fuxingloh #106
OP_PUSHDATA4 @fuxingloh #106

`constants.ts`

`control.ts`

`stack.ts`

`splice.ts`

OP_CAT = 0x7e, @jingyi2811 #510
OP_SUBSTR = 0x7f, @jingyi2811 #510
OP_LEFT = 0x80, @jingyi2811 #510
OP_RIGHT = 0x81, @jingyi2811 #510
OP_SIZE = 0x82, @jingyi2811 #510

`bitwise.ts`

OP_INVERT = 0x83 @surangap #422
OP_AND = 0x84 @surangap #422
OP_OR = 0x85 @surangap #422
OP_XOR = 0x86 @surangap #422
OP_EQUAL @fuxingloh #106
OP_EQUALVERIFY @fuxingloh #106
OP_RESERVED1 = 0x89 @surangap #422
OP_RESERVED2 = 0x8a @surangap #422

`arithmetic.ts`

`crypto.ts`

`expansion.ts`

`invalid.ts`

OP_INVALIDOPCODE = 0xff @Jouzo #440

jellyfish-wallet signing callback interface

What would you like to be added:

A callback interface for jellyfish-wallet transaction signing. When a user were to perform any signing action, it triggers a callback to the signing interface. This allow presentation of information to user before they sign the transaction.

const signingInterface = {
  unsigned(buffer: Buffer, tx: Transaction): Promise<void> {
    console.log('show client')
  },
  signed(buffer: Buffer, tx: TransactionSegWit): Promise<void> {
    console.log('show client')
  }
}

const provider = new WalletHdNodeProvider(signingInterface)

Why is this needed:

To provide the user/client the information of what they are actually signing.

Write once run everywhere; for browser, node and RN

What would you like to be added:

Jellyfish implementation must be platform agonistic and support all possible use case.

<script src="jellyfish.js"> for browser with bundling
Electron
Node 10+ CJS and ESM
Reactive Native

Why is this needed:

To support the developer ecosystem, jellyfish implementation must plug and play for all platform.

/area core
/triage accepted

WalletAccount stateless stateful interfaces

What would you like to be added:

Interfaces in WalletAccount for

stateless features:

getUtxoBalance
listUtxo
listTransaction
listTokenBalance
getTokenBalance

stateful features

sendUtxo
sendToken
addLiquidity
removeLiquidity
swap
fromUtxoToAccount
fromAccountToUtxo

jellyfish-transaction p2wpkh should check elliptic pair before signing transaction

What would you like to be added:

jellyfish-transaction should validate that it can actually spend the transaction with the given elliptic pair before signing transaction.

Only for p2wpkh as it is the only one that is implemented.

Why is this needed:

Currently jellyfish-transaction will sign any transaction regardless of what prevout is given to it.
It should check it can actually spend the given transaction by, taking the prevout and HASH160 it.

Create getpeerinfo rpc

A bit steep to this.
Requires Docker networking layer knowledge in order to proceed.

subpath exports for large packages

What would you like to be added:

Available in NPM >v12.7.0

Custom subpaths can be defined along with the main entry point by treating the main entry point as the "." subpath:

{
  "main": "./dist/index.js",
  "exports": {
    ".": "./dist/index.js",
    "./submodule": "./dist/bech32.js"
  }
}

This allow loading a sub path

import submodule from '@defichain/jellyfish-crypto/bech32';
// Loads ./node_modules/@defichain/jellyfish-crypto/dist/bech32.js

Why is this needed:

As the modules and packages grows, it is becoming increasingly complex to manage imports and exports. Bundling all exports into one index.js file for small modules make senses but for large more complex modules it is harder to effectively manage conflicts. E.g. jellyfish-api-core, hence it is wise to implement subpath exports vs named exports for larger packages.

transaction builder

What would you like to be added:

A new package called jellyfish-transaction, this package will use a builder-like mechanism to facilitate the creation of transaction. Basic P2SH, P2PKH, P2WSH and P2WPKH are expected. All custom transaction should be implemented as well. They don't need to be implemented in 1 pr but should allow easy iterative implementing.

static const std::vector<unsigned char> DfTxMarker = {'D', 'f', 'T', 'x'};  // 44665478

enum class CustomTxType : unsigned char
{
    None = 0,
    // masternodes:
    CreateMasternode    = 'C',
    ResignMasternode    = 'R',
    // custom tokens:
    CreateToken         = 'T',
    MintToken           = 'M',
    UpdateToken         = 'N', // previous type, only DAT flag triggers
    UpdateTokenAny      = 'n', // new type of token's update with any flags/fields possible
    // dex orders - just not to overlap in future
//    CreateOrder         = 'O',
//    DestroyOrder        = 'E',
//    MatchOrders         = 'A',
    //poolpair
    CreatePoolPair      = 'p',
    UpdatePoolPair      = 'u',
    PoolSwap            = 's',
    AddPoolLiquidity    = 'l',
    RemovePoolLiquidity = 'r',
    // accounts
    UtxosToAccount     = 'U',
    AccountToUtxos     = 'b',
    AccountToAccount   = 'B',
    AnyAccountsToAccounts  = 'a',
    //set governance variable
    SetGovVariable       = 'G',
    // Auto auth TX
    AutoAuthPrep       = 'A',
};

Signature signing should be supported as well. SIGHASH_ALL should be implemented first and the rest if required in another PR.

Signature.SIGHASH_ALL = 0x01;
Signature.SIGHASH_NONE = 0x02;
Signature.SIGHASH_SINGLE = 0x03;
Signature.SIGHASH_ANYONECANPAY = 0x80;

Why is this needed:

In light wallet implementation, you need to be able to create transaction without relying on a node. This package will facilitate that.

Promise based client

What would you like to be added:

Jellyfish to return Promise<BlockInfo> instead of using callback.

Why is this needed:

To prevent "callback hell" problem where code get nested and messy, making it harder to understand. As async/await is very mature, it brings better quality of life to development.

/area core
/triage accepted

birthdayresearch / jellyfishsdk Goto Github PK

jellyfishsdk's People

Stargazers

Watchers

Forkers

jellyfishsdk's Issues

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

What would you like to be added:

What would you like to be added:

Why is this needed:

What would you like to be improved:

Why is this needed:

What would you like to be added:

Why is this needed:

src/rpc

blockchain.cpp

mining.ccp

misc.cpp

net.cpp

rawtransaction.cpp

server.cpp - COMPLETED

src/spv

spv_rpc.cpp

src/wallet

rpcwallet.cpp

src/masternode

mn_rpc.cpp - COMPLETED

rpc_accounts.cpp - COMPLETED

rpc_masternodes.cpp - COMPLETED

rpc_poolpair.cpp - COMPLETED

rpc_tokens.cpp - COMPLETED

What would you like to be added:

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

CustomTx

What would you like to be added:

What would you like to be added:

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

What happened:

What you expected to happen:

What would you like to be added:

Why is this needed:

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

What would you like to be added:

Why is this needed:

What would you like to be added:

What would you like to be added:

Correct

Wrong

What would you like to be added:

What would you like to be added:

Example of a 'fixture' to setup a condition:

What would you like to be added:

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this not a good idea?

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

What would you like to be added:

Why is this needed:

We need:

We should:

What would you like to be added:

What would you like to be added:

Why is this needed:

`src/rpc`

`blockchain.cpp`

`mining.ccp`

`misc.cpp`

`net.cpp`

`rawtransaction.cpp`

`server.cpp` - COMPLETED

`src/spv`

`spv_rpc.cpp`

`src/wallet`

`rpcwallet.cpp`

`src/masternode`

`mn_rpc.cpp` - COMPLETED

`rpc_accounts.cpp` - COMPLETED

`rpc_masternodes.cpp` - COMPLETED

`rpc_poolpair.cpp` - COMPLETED

`rpc_tokens.cpp` - COMPLETED

`src/masternodes/`

`rpc_icxorderbook.cpp`

`rpc_oracles.cpp`

`src/spv`

`spv_rpc.cpp`

`data.ts`

`constants.ts`

`control.ts`

`stack.ts`

`splice.ts`

`bitwise.ts`

`arithmetic.ts`

`crypto.ts`

`expansion.ts`

`invalid.ts`