React Native Zcash SDK Interface

rn-zcash-sdk.ts

class KeyTool {
  static deriveViewKey (seedBytesHex: string): string
  static deriveSpendingKey: (seedBytesHex: string): string
}
class AddressTool {
  static deriveShieldedAddress (viewingKey: string): string
  static deriveTransparentAddress (viewingKey: string): string
  static isValidShieldedAddress (address: string): boolean
  static isValidTransparentAddress (address: string): boolean
}
interface InitializerConfig {
  host: string
  port: number
  fullViewingKey: string
  // alias: ??
  birthdayHeight: number
}
interface WalletBalance {
  shieldedAvailable: string
  shieldedTotal: string
  transparentAvailable: string
  transparentTotal: string
}
interface InitializerCallbacks {
  onError: (e: Error): void
  onTransactionsChanged: (): void
  onBalanceChanged: (walletBalance: WalletBalance): void
}
interface SpendInfo {
  zatoshi: string
  toAddress: string
  memo: string
  fromAccountIndex: number
  spendingKey?: string
}

interface ZcashTransaction {
  txId: string
  fee: string
  value: string 
  direction: 'inbound' | 'outbound'
  toAddress: string
  memo?: string
  minedHeight: number // 0 for unconfirmed
  blockTime: number // UNIX timestamp
}
type PendingTransaction = ZcashTransaction & {
  accountIndex: number
  expiryHeight: number
  cancelled: number
  submitAttemps: number
  errorMessage?: string
  errorCode?: number
  createTime: number
}

interface TransactionQuery {
  offset?: number
  limit?: number
  startDate?: number
  endDate?: number
}
class Synchronizer {
  static init (initializerConfig: InitializerConfig): void
  setCallbackHandlers (callbacks: InitializerCallbacks): void
  getLatestHeight (): number
  getProgress (): number // 0-1
  // getStatus (): ??
  getBalance (): WalletBalance
  estimateFee (spendInfo: SpendInfo): string
  sendToAddress (spendInfo: SpendInfo): void
  start (): void
  stop (): void
  getPendingTransactions (): PendingTransactions[]
  getConfirmedTransactions (query: TransactionQuery): ZcashTransaction[]
}

@paullinator I have a number of questions here, but one thing that strikes me right away is that the paginated interface for transaction retrieval seems fragile with respect to race conditions. If you retrieve a page of results, and then some additional syncing happens in the background, the page boundaries might change as additional transactions involving your wallet are discovered. Do you have a suggestion of how you would want the API provider to address this, as a user of the API?

oh I recall this gist. I think most of it was actually implemented. The paginated was partially but never used.

@nuttycom Databases deal with page boundaries all the time. Blockchains are even easier. Since the starting point of the query is fixed at a certain date (or blockheight), the number of transactions at each page, and which transactions are in each page should stay constant. Other than due to a reorg, there shouldn't be any possibility of a page ever returning different transactions given a specific starting date/height.

However, due to the possiblity of reorgs, it would be recommended that SDK users have a rollback number of blocks to query when it gets a notification of new balances or transaction updates. ie.

Let's assume the api uses blockheight instead of date for simplicity
App has ROLLBACK_BLOCKS = 20
Current block is 500000
App requests transactions from date 0 at start. it gets say 10 transactions at various heights. It considers itself synced up to block 500000
App gets notification of new transactions, it then queries the sdk from blockheight 499980 which would get all updates for any transactions that may have been changed/reorged since the last update.