functionland / sugarfunge-node

The SugarFunge blockchain powers the SugarFunge Protocol. A protocol for creating privately-owned economies without the complexity of building and maintaining their own blockchain infrastructure. Empowering businesses with digital and physical assets with minting, crafting and trading mechanics.
Other
0 stars 1 forks source link

Remove seed in requests and sign the request on client #4

Closed ehsan6sha closed 8 months ago

ehsan6sha commented 1 year ago

currently a seed is passed as an input parameter to methods, which exposes the seed of user if it is executed on another machine. We need to be able to execute a method on any machine

is there any way that we can avoid putting the seed in the request body somehow? I am not sure how, but right now since we need to put the seed in the request body, it means the request can only be executed on one's own blox. Here is the scenario that it helps if we can avoid putting hte seed: 1- Let's assume a user who does not have a blox. He purchases some tokens from exchange and need his files to be backed up on blox owners 2- Right now to send the backup request he needs to call "upload manifest" which requires the seed as parameter in the body The user himself, does not have a running API endpoint, and we cannot send the request to another blox to be executed as it includes the user's seed and if blox owner checks the request he sees other person's seed. If we don't send it to another blox to be executed, how can we talk to blockchain API from a mobile app? I do not think the rust code right now can run on an Adnroid or iOS device and I am not sure if it is the best approach to run it on android or iOS. another approach is if there is possibility of just running the API on Android or iOS and it interprets and safely sends the request to nodes in the network. Any thoughts here? In summary the question is, how someone without a blox(node), can safely sends requests to the network without revealing his seed for calls that need the seed? (edited) 6 replies

rozgo 7 days ago Yes. This requires some changes to the API so the request body can be built on client. And the request is send with transaction already signed, so the API can process the rest of the call.

rozgo 7 days ago We will add this to the API :white_check_mark: 1

ehsan shariati 7 days ago can this be the priority please? As we want to start integration work with blockchain asap

rozgo 7 days ago Yes, this aligns with our own goals. We can accelerate this. :white_check_mark: 1

ehsan shariati 7 days ago in the solution you proposed, we are considering blocking replay attacks ,... ? so that a bad actor for example cannot replay a transaction request over and over?

rozgo 6 days ago Each transaction requires: last transaction num + 1, thus requiring to sign every transaction with a consecutive id. Making it impossible to reuse/replay a transaction

ehsan6sha commented 8 months ago

for calls that require seed we use polkadot apis directly