Bitcoin Forum
February 20, 2019, 08:43:43 AM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3]  All
  Print  
Author Topic: [NXT] API 2 Brainstorming  (Read 4916 times)
ferment
Full Member
***
Offline Offline

Activity: 168
Merit: 100


IDEX - LIVE Real-time DEX


View Profile
January 10, 2014, 04:00:55 PM
 #41

I put generateBlock and a placeholder for a call to determine when an account could try to generate a block.

C-f-B?

Shouldn't we leave block forging for clients? Coz it's the same as signing transactions, u have to use ur secret key.

Yes, that's the purpose of generateBlock, but we also need an API for determining when a client can generate blocks like the response that is used to update the timer in the current client. Basically, an API that encapsulates the TF logic to suggest when a client can attempt to generate a block.


Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
hiksush2
Newbie
*
Offline Offline

Activity: 12
Merit: 0


View Profile
January 12, 2014, 04:28:48 AM
 #42

For High-level:

getAllAccounts() - possibly with filtering parameters and sort/limit

I'm not sure what the Account object provides currently, but these would be useful:

getBalance()
getTotalTransferAmounts() - returns total amount of NXT transferred.  filter by in/out
getTransactions() - filter by activity type (in/out/alias creation/etc.)
getTimeFirstActivity() - filter by activity type (in/out/alias creation/etc.)
getTimeLastActivity() - filter by activity type (in/out/alias creation/etc.)
getBlocksGenerated() - correct term?
getFeeEarned() - correct term?
getAliases()
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 12, 2014, 08:59:31 PM
 #43

Is it possible to have an api that searches for incoming account transactions with a specific description?  (payment with attached description)

This would be good to verify payments.. Sort of like the system with bank transfers can have a message attached to it.
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 13, 2014, 09:23:17 AM
 #44

API call to get peers that have public bot access enabled.
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1000


Ian Knowles - CIYAM Lead Developer


View Profile WWW
January 13, 2014, 09:33:48 AM
 #45

An API call to get the AM size limit (currently 1000) would be helpful (in order to chop up data and send it in max. size chunks efficient).

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 13, 2014, 10:29:31 AM
 #46

Enable jsonp so that javascript can call peer via bot access like so: (to get around same origin policy)

?...&callback=myCallback

Can also implement CORS: http://enable-cors.org/server.html
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 13, 2014, 10:33:25 AM
 #47

add server date to getState as well as lastBlockDate.
oliviern
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
January 16, 2014, 09:28:27 AM
 #48

Hello,

I have two main api addons to ask, because I'm faced with a few limitations in my mobile app :

- forged blocks statistics for a given account :
I've been said I have to crawl blocks to know who has computed each, and sum the coins for each account number (I may be wrong...). If it sounds possible, a api call giving forging stats for a nxt account would be relevant

- tokens to replace the passphrase into api calls :
To send money, one has to send his own passphrase through http. This is truly not secured, because communications can be listened, and modified 'reliable' nodes can store passphrases using a api proxy for example... I'd rather have a solution to use api without any passphrase. To do so, one may imagine the following services :

     getAppToken(application_name, application_secretkey) : returns a token (token_app), used to identify application provider. this token can be given publicly to the users who want to give the app access to their accounts

     allowApp(token_app,account_passphrase, array of allowed functions) : returns a token (token_account_app), which certifies that the account owner allows the app to access to a list of api calls (send money, send message, ...)

The token_account_app is sent by the user to the app owner, who can use it to sign secured API calls, with his own application_secretkey. The called node has to verify the matching between application_secretkey, token_account_app, and allowed api services. The application_secretkey allows to certify it is called from the application owner. (this is close to app_ID+app_secretkey used into google,fb,twitter apis for example).

Doing so, the user does not have anymore to send his passphrase to send money, for example. He can also call a disallowApp(token_app,account_passphrase), which returns the same token_account_app, but remove all allowed functions. Doing so, the application can not call anymore any API functions. The allowed functions list could be stored into the blockchain, or even locally on the application dedicated node (ie the user allows a specified node to do API calls).

I've tried to keep it simple, and this is certainly not perfect. This is a very first proposal, in order to talk about with nxt teams. Maybe we could also use aliases to identify applications, or even hack the messages process to validate transactions... Whatever solution is used, I do think it is relevant not to send user's passphrase into the api calls made from external services.

Feedbacks welcome. Thanks,

Olivier

PS : another subject... Wouldn't it be possible to imagine an API call made to check a nxt node code has not been modified (in order to hack accounts for example) ? I know... this function could be modified by the node owner, to return the good checksum... so, this should be made externally, by a external peer. For example, the API service returns the server local main files, calling an external peer hashing service (hashing algorithm being secret, and peer dependent). If it matches, one can say the node uses not modified files. To hack this, one should have to modify hashing algorithm on all peers, which sounds quite difficult. The tested node could also send fake files, but maybe there is a solution to hash running code (and not local files) ?... don't know... this is just a thought.
ferment
Full Member
***
Offline Offline

Activity: 168
Merit: 100


IDEX - LIVE Real-time DEX


View Profile
January 16, 2014, 01:23:48 PM
 #49


- forged blocks statistics for a given account :
I've been said I have to crawl blocks to know who has computed each, and sum the coins for each account number (I may be wrong...). If it sounds possible, a api call giving forging stats for a nxt account would be relevant

Try getAccountBlockIds in current API.

oliviern
Newbie
*
Offline Offline

Activity: 17
Merit: 0


View Profile
January 17, 2014, 12:45:12 PM
 #50

Can't wait either... Smiley
ferment
Full Member
***
Offline Offline

Activity: 168
Merit: 100


IDEX - LIVE Real-time DEX


View Profile
January 17, 2014, 04:06:40 PM
 #51


I'd rather have a solution to use api without any passphrase.

The best way to do this is to have the client do all of the signing and transmit transaction data to the server. No secret phrases would ever leave the client.

wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 17, 2014, 05:08:22 PM
 #52

Ability to set timestampend so that it returns transactions BEFORE the timestamp. Good for pagination.

As well as a way to set a limit.
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 22, 2014, 02:12:06 PM
 #53

Ability to get transactions where sender = x and recipient = Y. Especially useful for Arbitrary messaging instead of having to loop through potentially thousands of transactions.
l8orre
Legendary
*
Online Online

Activity: 1040
Merit: 1002


View Profile
January 23, 2014, 09:04:59 AM
 #54


Ability to get all assets owned by an account. CFB already mentioned including a call for this.
l8orre
Legendary
*
Online Online

Activity: 1040
Merit: 1002


View Profile
January 23, 2014, 09:30:46 AM
Last edit: January 23, 2014, 08:14:31 PM by l8orre
 #55

Ability to get transactions where sender = x and recipient = Y. Especially useful for Arbitrary messaging instead of having to loop through potentially thousands of transactions.

Do I understand correctly that atm it is neccessary to query ALL transactions and then filter the list in the client? yup. looks like it. I am actually catching up here...
l8orre
Legendary
*
Online Online

Activity: 1040
Merit: 1002


View Profile
January 24, 2014, 01:36:02 PM
 #56


heyhey, I made some experiments - my raspi needs TWO SECONDS to answer a query - while the testnet has a replytime of ~150ms

My concern is the following: when you have to resolve a chain of queries, like when going from block ->transactions -> transaction detail  -- 2 seconds per query does become a factor - you get to resolve 10 or 20 queries, get stuck for 20 to 40 seconds ?!?!?! Think about fast messaging ?!

BaiMangal
Member
**
Offline Offline

Activity: 109
Merit: 10


View Profile
January 24, 2014, 03:53:04 PM
 #57


Ability to get all assets owned by an account. CFB already mentioned including a call for this.

yeah this one is important!
wesleyh
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
February 08, 2014, 09:17:20 PM
 #58

Account statistics; number of messages / aliases / assets owned, number of transactions done, number of forged blocks, forged block fees, creation date of account, etc..
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!