Page History

1min

• George working to integrate iroha and Quilt.
• Lurii Vinogradov
• Kincaid, Neil, Noah, Ian, David: Working on ILP in Java and JS.

• Iroha is a private permissioned blockchain.
• Iroha is in C++; Good permission model; lightweight, easy to deploy; use on mobile.
• No smart contract - 
• Many Private networks all running same code. Intended for private enterprise blockchains (20-30 projects).
• CBDC in Cambodia (Bakank)
• Looking to connect/bridge different Iroha networks.
• Focused on financial transactions.

• Kincaid
  • Sender wallet presents some max-amount that will leave your account.
  • StreamSender needs to enforce that this max is the most that leaves the account.
  • Question: Does the lower-level sender need knowledge around how much its delivering?
  • JS StreamController interface: break sender up into as many little state machines as possible (max packets; liquidity congestion; setting the amount and tracking amount paid; pacing).
• Neil
  • Durability is aimed at knowing the state of any given stream payment. 
  • We could go back and retry. Or we could just do another payment.
  • How do we get a fixed amount in receiver's units where things like FX/slippage could be unknown until the sender gets it.
• What should STREAMSender do if the FX rate goes against the sender and the payment cannot be completed?
  • Kincaid: FX rates are that big of a deal because they don't fluctuate that frequently.
  • Could happen but is unlikely.
  • Bigger issue is sending packets that fail due to rounding errors, ultimately failing the payment.
  • Accurately probing an FX rate is pretty hard because different-sized packets have different rounding errors. Some packets divide nicely but others don't.
• Ideas
  • Fixed-exchange rate path guarantees could be an interesting solution here.
  • Many mini-state machines to control for each thing independently (e.g., amount delivered should be distinct from time).
  • Try to complete a payment, but plan on failure.
• Kincaid
  • Majority of incomplete payments are caused by unimplemented features or bugs in implementations.
  • Very tiny fraction of payments are caused by network errors or intermediary manipulation.
• Create a "guidance doc" for state machines and approaches to building a STREAM sender.
  • Notes on error-cases, better explanation.
  • Discussion around each "mini state machine"
• Kincaid
  • Opinion on best-practices is evolving.