Skip to content
Mark Pfennig edited this page Aug 30, 2014 · 5 revisions

Things to Clone or Adapt:

Thoughts which need fleshed out

  • Option to run on Random Port instead of Static.
  • x509 certificate based authentication for http+tls api
  • focus on https+tls (https) api
  • modular extensible design, focus on light fast daemon where apps interface through api
  • web based management interface, needs tight security, consider apps as agents with their own auth details
  • ui easy to access like webmail, hooks in to the api of whichever node is specified
  • bitcoin's old ip transactions is an abstract request payment address api which could be updated and run with urls
  • one time addresses can be proven by provider signing it with a key they are known to own
  • need neat api call to show chain download progress, block xxx of yyy
  • maybe x509 certificates can be used to provide rsa encryption for messages, so messages are optional and require no processing weight to clients, but can be access if available and supported.
  • signing one time use addresses is important, prevents against mitm attacks on payments
  • messages relating to transactions can be detached and sent by different communication methods, a hash of them can be put in transaction as proof of their validity
  • worry over reliance on dns for dnsseeds, there should be another way
  • bitcoin design was based on everybody running a node, block time had to account for huge network latency, with increase in spv clients and api clients it can rationally be decreased
  • existing services are important, but new services can be created to accept bitmark, file hosting is always important
  • faucets which deliver free coins that can be used to purchase real services drives adoption, ensure rate limiting by ip address subnets
  • api integrations are important, adding bitmark support should be as easy adding a wordpress plugin
  • uri scheme for sending payments which can invoke specified client is important
  • look at transaction notifications api, perhaps push instead of listtransactions/getbyaccount, perhaps transactions since x
  • check if javascript apps can post to localhost, could be nice for detached clients
  • institutional momentum is to stick to the last decision made, so bitmark should be secure before targetting existing service providers, if they deny it first time they will probably keep denying
  • api documentation should include example code for well known language(s), important to have before pushing adoption
  • people should not need complicated tooling to fix stuck transactions and errors, there should be an easy way to do it automatically
  • ensure json-rpc over http is http compliant
  • does caching need covered, in daemon, or as a layer above, perhaps a wrapping application that caches json responses and acts as a middle man
  • simplicity first, the network only needs to prevent against double spends, if it does that, and people can interface easily, it works.
  • discuss starting with a fixed reasonable transaction fee
  • make block chain downloads available at each checkpoint?