many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
/******************************************************************************
|
|
|
|
|
* Copyright © 2014-2016 The SuperNET Developers. *
|
|
|
|
|
* *
|
|
|
|
|
* See the AUTHORS, DEVELOPER-AGREEMENT and LICENSE files at *
|
|
|
|
|
* the top-level directory of this distribution for the individual copyright *
|
|
|
|
|
* holder information and the developer policies on copyright and licensing. *
|
|
|
|
|
* *
|
|
|
|
|
* Unless otherwise agreed in a custom licensing agreement, no part of the *
|
|
|
|
|
* SuperNET software, including this file may be copied, modified, propagated *
|
|
|
|
|
* or distributed except according to the terms contained in the LICENSE file *
|
|
|
|
|
* *
|
|
|
|
|
* Removal or modification of this copyright notice is prohibited. *
|
|
|
|
|
* *
|
|
|
|
|
******************************************************************************/
|
|
|
|
|
|
|
|
|
|
#ifndef INCLUDE_PAX_H
|
|
|
|
|
#define INCLUDE_PAX_H
|
|
|
|
|
|
|
|
|
|
#define PEGGY_GENESIS "6aef504158ec0014fee05dc20a0006048ed63e523f6d1062feb23622da928cf23ddcc3b53f23566bc6cab5ebd77cfbf8f0bccb34bff73c55d742dd232994bfbffe1cbab7119ab3d653a256b02d5b6f56c05b8817799f0d242f48c26d35c992ebfff14acdefbe253345d394e84d975334cd55f7d6cbad5a7bd9425b1d5db44944d40be5304b7b62ba0dbc20d3323d2b35f05f654bc95a5a2fdb5a30e46c6fd33b5ea078255f7cad9fd0dbd2fa5031ada4474cbba7b2ee64ef35df06bf3fd3eef6cd3f48339f3c0e080158a92862bbf20bc6702018effbaee525502eb463c74f7ca0dff4ae7cb55ee55ef7cb1c915e655649"
|
|
|
|
|
|
|
|
|
|
#include "iguana777.h"
|
|
|
|
|
// CfB "the rule is simple = others can know the redemption day only AFTER the price for that day is set in stone."
|
|
|
|
|
#define PEGGY_NUMCOEFFS 539
|
|
|
|
|
#define ACCTS777_MAXRAMKVS 8
|
|
|
|
|
#define BTCDADDRSIZE 36
|
|
|
|
|
|
|
|
|
|
#define HASH_SIZE 32
|
|
|
|
|
#define PEGGY_MINUTE 60
|
|
|
|
|
#define PEGGY_HOURTICKS (PEGGY_MINUTE * 60)
|
|
|
|
|
#define PEGGY_DAYTICKS (24 * PEGGY_HOURTICKS)
|
|
|
|
|
#define MAX_TIMEFRAME (24 * 3600 * 365)
|
|
|
|
|
#define MAX_PEGGYDAYS (365)
|
|
|
|
|
#define PEGGY_MINEXTRADAYS 3
|
|
|
|
|
|
|
|
|
|
#define PEGGY_MAXPRICEDPEGS 64
|
|
|
|
|
#define PEGGY_MAXPAIREDPEGS 4096
|
|
|
|
|
#define PEGGY_MAXPEGS (PEGGY_MAXPRICEDPEGS + PEGGY_MAXPAIREDPEGS)
|
|
|
|
|
|
|
|
|
|
#define PEGGY_MAXVOTERS 4096
|
|
|
|
|
#define PEGGY_MARGINMAX 100
|
|
|
|
|
#define PEGGY_MIXRANGE 7777
|
|
|
|
|
#define PEGGY_MARGINLOCKDAYS 30
|
|
|
|
|
#define PEGGY_MARGINGAPDAYS 7
|
|
|
|
|
|
|
|
|
|
#define PEGGY_RATE_777 2052
|
|
|
|
|
|
|
|
|
|
#define OP_RETURN_OPCODE 0x6a
|
|
|
|
|
#define OPRETURNS_CONTEXTS 2
|
|
|
|
|
|
|
|
|
|
#define MAX_OPRETURNSIZE 4096
|
|
|
|
|
#define PEGGY_MAXLOCKDAYS 180
|
|
|
|
|
#define PEGGY_PASTSTAMP 3600
|
|
|
|
|
#define PEGGY_FUTURESTAMP 60
|
|
|
|
|
|
|
|
|
|
#define PEGGY_RSTATUS_REDEEMED 0
|
|
|
|
|
#define PEGGY_RSTATUS_AUTOPURGED 1
|
|
|
|
|
#define PEGGY_RSTATUS_MARGINCALL 2
|
|
|
|
|
|
|
|
|
|
#define PEGGY_FLAGS_HASFUNDING 1
|
|
|
|
|
#define PEGGY_FLAGS_PEGGYBASE 2
|
|
|
|
|
|
|
|
|
|
#define PEGGY_ADDRBTCD 0
|
|
|
|
|
#define PEGGY_ADDRCREATE 1
|
|
|
|
|
#define PEGGY_ADDRNXT 2
|
|
|
|
|
#define PEGGY_ADDRUNIT 3
|
|
|
|
|
#define PEGGY_ADDRPUBKEY 4
|
|
|
|
|
#define PEGGY_ADDR777 5
|
|
|
|
|
#define PEGGY_ADDRFUNDING 6
|
|
|
|
|
|
|
|
|
|
#define USD 0
|
|
|
|
|
#define EUR 1
|
|
|
|
|
#define JPY 2
|
|
|
|
|
#define GBP 3
|
|
|
|
|
#define AUD 4
|
|
|
|
|
#define CAD 5
|
|
|
|
|
#define CHF 6
|
|
|
|
|
#define NZD 7
|
|
|
|
|
#define CNY 8
|
|
|
|
|
#define RUB 9
|
|
|
|
|
|
|
|
|
|
#define NZDUSD 0
|
|
|
|
|
#define NZDCHF 1
|
|
|
|
|
#define NZDCAD 2
|
|
|
|
|
#define NZDJPY 3
|
|
|
|
|
#define GBPNZD 4
|
|
|
|
|
#define EURNZD 5
|
|
|
|
|
#define AUDNZD 6
|
|
|
|
|
#define CADJPY 7
|
|
|
|
|
#define CADCHF 8
|
|
|
|
|
#define USDCAD 9
|
|
|
|
|
#define EURCAD 10
|
|
|
|
|
#define GBPCAD 11
|
|
|
|
|
#define AUDCAD 12
|
|
|
|
|
#define USDCHF 13
|
|
|
|
|
#define CHFJPY 14
|
|
|
|
|
#define EURCHF 15
|
|
|
|
|
#define GBPCHF 16
|
|
|
|
|
#define AUDCHF 17
|
|
|
|
|
#define EURUSD 18
|
|
|
|
|
#define EURAUD 19
|
|
|
|
|
#define EURJPY 20
|
|
|
|
|
#define EURGBP 21
|
|
|
|
|
#define GBPUSD 22
|
|
|
|
|
#define GBPJPY 23
|
|
|
|
|
#define GBPAUD 24
|
|
|
|
|
#define USDJPY 25
|
|
|
|
|
#define AUDJPY 26
|
|
|
|
|
#define AUDUSD 27
|
|
|
|
|
|
|
|
|
|
#define USDNUM 28
|
|
|
|
|
#define EURNUM 29
|
|
|
|
|
#define JPYNUM 30
|
|
|
|
|
#define GBPNUM 31
|
|
|
|
|
#define AUDNUM 32
|
|
|
|
|
#define CADNUM 33
|
|
|
|
|
#define CHFNUM 34
|
|
|
|
|
#define NZDNUM 35
|
|
|
|
|
|
|
|
|
|
#define NUM_CONTRACTS 28
|
|
|
|
|
#define NUM_CURRENCIES 8
|
|
|
|
|
#define NUM_COMBINED (NUM_CONTRACTS + NUM_CURRENCIES)
|
|
|
|
|
#define MAX_SPLINES 64
|
|
|
|
|
#define MAX_LOOKAHEAD 48
|
|
|
|
|
|
|
|
|
|
#define MAX_EXCHANGES 64
|
|
|
|
|
#define MAX_CURRENCIES 32
|
|
|
|
|
|
|
|
|
|
#define PRICE_RESOLUTION_ROOT ((int64_t)3163)
|
|
|
|
|
#define PRICE_RESOLUTION (PRICE_RESOLUTION_ROOT * PRICE_RESOLUTION_ROOT) // 10004569
|
|
|
|
|
#define PRICE_RESOLUTION2 (PRICE_RESOLUTION * PRICE_RESOLUTION) // 100091400875761
|
|
|
|
|
#define PRICE_RESOLUTION_MAXPVAL ((int64_t)3037000500u) // 303.5613528178975 vs 64 bits: 4294967295 429.30058206405493,
|
|
|
|
|
#define PRICE_RESOLUTION_MAXUNITS ((int16_t)((int64_t)0x7fffffffffffffffLLu / (SATOSHIDEN * PRICE_RESOLUTION))) // 9219
|
|
|
|
|
#define SCALED_PRICE(val,scale) (((scale) * (val)) / PRICE_RESOLUTION)
|
|
|
|
|
#define Pval(r) ((double)(r)->Pval / PRICE_RESOLUTION) // for display only!
|
|
|
|
|
#define PERCENTAGE(perc) (((perc) * PRICE_RESOLUTION) / 100)
|
|
|
|
|
|
|
|
|
|
struct price_resolution { int64_t Pval; };
|
|
|
|
|
struct peggy_lock { int16_t peg,denom; uint16_t minlockdays,maxlockdays,clonesmear,mixrange,redemptiongapdays; uint8_t extralockdays,margin; };
|
|
|
|
|
|
|
|
|
|
struct peggy_newunit { bits256 sha256; struct peggy_lock newlock; };
|
|
|
|
|
struct peggy_univaddr { uint8_t addrtype,rmd160[20]; char coin[7]; };
|
|
|
|
|
union peggy_addr { struct peggy_univaddr coinaddr; struct peggy_newunit newunit; bits256 sha256; bits384 SaMbits; uint64_t nxt64bits; };
|
|
|
|
|
struct peggy_input { uint8_t type,chainlen; union peggy_addr src; uint64_t amount; };
|
|
|
|
|
struct peggy_output { uint8_t type,vin; union peggy_addr dest; uint32_t ratio; };
|
|
|
|
|
|
|
|
|
|
struct peggy_txprices { uint16_t num,maxlockdays; uint32_t timestamp; uint32_t feed[256]; };
|
|
|
|
|
struct peggy_txbet { struct price_resolution prediction; char peg[15],binary; };
|
|
|
|
|
struct peggy_txmicropay { bits256 claimhash,refundhash; uint32_t expiration; uint8_t chainlen,vin,vout; };
|
|
|
|
|
struct peggy_time { uint32_t blocknum,blocktimestamp; };
|
|
|
|
|
struct peggy_units { int64_t num,numoppo; };
|
|
|
|
|
struct peggy_margin { int64_t deposits,margindeposits,marginvalue; };
|
|
|
|
|
struct peggy_description { char name[32],base[16],rel[16]; uint64_t basebits,relbits,assetbits; int16_t id,baseid,relid; int8_t hasprice,enabled; };
|
|
|
|
|
struct peggy_pool { struct peggy_margin funds; struct peggy_units liability; uint64_t quorum,decisionthreshold,mainunitsize,mainbits; };
|
|
|
|
|
//struct peggy_limits { int64_t scales[MAX_TIMEFRAMES],maxsupply,maxnetbalance; uint32_t timeframes[MAX_TIMEFRAMES],numtimeframes; };
|
|
|
|
|
|
|
|
|
|
#define PEGGY_MAXSIGS 16
|
|
|
|
|
#define PEGGY_MAXINPUTS 15
|
|
|
|
|
#define PEGGY_MAXOUTPUTS 16
|
|
|
|
|
|
|
|
|
|
#define PEGGY_TXNORMAL 0
|
|
|
|
|
#define PEGGY_TXBET 1
|
|
|
|
|
#define PEGGY_TXPRICES 2
|
|
|
|
|
#define PEGGY_TXTUNE 3
|
|
|
|
|
#define PEGGY_TXMICROPAY 4
|
|
|
|
|
union peggy_bytes8 { uint8_t bytes[8]; uint64_t val; };
|
|
|
|
|
struct peggy_txtune { char type,peg[15]; uint64_t val; union peggy_bytes8 B; };
|
|
|
|
|
|
|
|
|
|
union peggy_txtype
|
|
|
|
|
{
|
|
|
|
|
struct peggy_txprices price; struct peggy_txbet bets[64]; struct peggy_txtune tune[64];
|
|
|
|
|
struct peggy_txmicropay micropays[16];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct PAX_sig { bits256 sigbits,pubkey; uint64_t signer64bits; uint32_t timestamp,allocsize; };
|
|
|
|
|
|
|
|
|
|
struct peggy_tx
|
|
|
|
|
{
|
|
|
|
|
uint16_t datalen; uint8_t numinputs,numoutputs,txtype,flags,msglen,numdetails; uint32_t timestamp,activation,expiration;
|
|
|
|
|
struct peggy_input inputs[PEGGY_MAXINPUTS],funding; struct peggy_output outputs[PEGGY_MAXOUTPUTS];
|
|
|
|
|
union peggy_txtype details; char hexstr[512];
|
|
|
|
|
uint8_t data[4096];
|
|
|
|
|
struct PAX_sig sigs[PEGGY_MAXSIGS];
|
|
|
|
|
//uint64_t required;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct peggy_unit
|
|
|
|
|
{
|
|
|
|
|
int64_t estimated_interest,costbasis,amount,marginamount; uint32_t timestamp; int16_t dailyrate; uint8_t baseid,relid;
|
|
|
|
|
struct peggy_lock lock; bits256 lockhash;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct peggy
|
|
|
|
|
{
|
|
|
|
|
struct peggy_description name; struct peggy_pool pool; struct peggy_lock lockparms; int64_t maxsupply,maxnetbalance;
|
|
|
|
|
struct price_resolution spread,mindenomination,genesisprice,price,dayprice; uint32_t day,genesistime,maxdailyrate,unitincr,peggymils;
|
|
|
|
|
uint32_t dayprices[MAX_PEGGYDAYS],*baseprices,*relprices; int32_t RTminute;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct peggy_pricedpeg
|
|
|
|
|
{
|
|
|
|
|
struct peggy PEG;
|
|
|
|
|
uint32_t prices[MAX_PEGGYDAYS * 1440]; // In main currency units
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
union peggy_pair { struct peggy PEG; struct peggy_pricedpeg pricedPEG; };
|
|
|
|
|
|
|
|
|
|
struct peggy_bet { struct price_resolution prediction; uint64_t distbet,dirbet,payout,shares,dist; uint32_t timestamp,minutes; };
|
|
|
|
|
struct peggy_vote { int32_t pval,tolerance; };//struct price_resolution price,tolerance; uint64_t nxt64bits,weight; };
|
|
|
|
|
struct peggy_entry
|
|
|
|
|
{
|
|
|
|
|
int64_t total,costbasis,satoshis,royalty,fee,estimated_interest,interest_unlocked,interestpaid,supplydiff,denomination;
|
|
|
|
|
int16_t dailyrate,baseid,relid,polarity;
|
|
|
|
|
struct peggy_units supply; struct price_resolution price,oppoprice;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct peggy_balances { struct peggy_margin funds; int64_t privatebetfees,crypto777_royalty,APRfund,APRfund_reserved; };
|
|
|
|
|
|
|
|
|
|
struct PAX_data
|
|
|
|
|
{
|
|
|
|
|
uint32_t ttimestamps[128]; double tbids[128],tasks[128];
|
|
|
|
|
uint32_t ftimestamps[128]; double fbids[128],fasks[128];
|
|
|
|
|
uint32_t itimestamps[128]; double ibids[128],iasks[128];
|
|
|
|
|
char edate[128]; double ecbmatrix[32][32],dailyprices[MAX_CURRENCIES * MAX_CURRENCIES],metals[4];
|
|
|
|
|
int32_t ecbdatenum,ecbyear,ecbmonth,ecbday; double RTmatrix[32][32],RTprices[128],RTmetals[4];
|
|
|
|
|
double btcusd,btcdbtc,cryptos[8];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct PAX_spline { char name[64]; int32_t splineid,lasti,basenum,num,firstx,dispincr,spline32[MAX_SPLINES][4]; uint32_t utc32[MAX_SPLINES]; int64_t spline64[MAX_SPLINES][4]; double dSplines[MAX_SPLINES][4],pricevals[MAX_SPLINES+MAX_LOOKAHEAD],lastutc,lastval,aveslopeabs; };
|
|
|
|
|
|
|
|
|
|
struct peggy_info
|
|
|
|
|
{
|
|
|
|
|
char maincurrency[16]; uint64_t basebits[256],mainbits,mainunitsize,quorum,decisionthreshold; int64_t hwmbalance,worstbalance,maxdrawdown;
|
|
|
|
|
struct price_resolution default_spread; struct peggy_lock default_lockparms;
|
|
|
|
|
struct peggy_balances bank,basereserves[256];
|
|
|
|
|
int32_t default_dailyrate,interesttenths,posboost,negpenalty,feediv,feemult;
|
|
|
|
|
int32_t numpegs,numpairedpegs,numpricedpegs,numopreturns,numvoters;
|
|
|
|
|
struct accts777_info *accts;
|
|
|
|
|
struct PAX_data data,tmp; double cryptovols[2][9][2],btcusd,btcdbtc,cnyusd;
|
many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
char path[512],*genesis; uint32_t genesistime,BTCD_price0,lastupdate;
|
|
|
|
|
struct PAX_spline splines[128];
|
|
|
|
|
struct peggy_vote votes[PEGGY_MAXPRICEDPEGS][PEGGY_MAXVOTERS];
|
|
|
|
|
struct peggy *contracts[PEGGY_MAXPEGS];
|
|
|
|
|
struct peggy pairedpegs[PEGGY_MAXPRICEDPEGS + PEGGY_MAXPAIREDPEGS];
|
|
|
|
|
struct peggy_pricedpeg pricedpegs[PEGGY_MAXPRICEDPEGS];
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct txinds777_hdr { int64_t num,nextpos; uint32_t blocknum,timestamp,firstblocknum,lastblocknum; struct sha256_vstate state; bits256 sha256; };
|
|
|
|
|
struct txinds777_info
|
|
|
|
|
{
|
|
|
|
|
struct txinds777_hdr H;
|
|
|
|
|
FILE *txlogfp,*indexfp,*fp; char path[512],name[64]; int64_t curitem,*blockitems;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
int64_t txind777_bundle(struct txinds777_info *txinds,uint32_t blocknum,uint32_t timestamp,int64_t *bundle,int32_t numtx);
|
|
|
|
|
int64_t txind777_create(struct txinds777_info *txinds,uint32_t blocknum,uint32_t timestamp,void *txdata,uint16_t len);
|
|
|
|
|
int32_t txind777_txbuf(uint8_t *txbuf,int32_t len,uint64_t val,int32_t size);
|
|
|
|
|
int32_t txinds777_flush(struct txinds777_info *txinds,uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
struct txinds777_info *txinds777_init(char *path,char *name);
|
|
|
|
|
int64_t txinds777_seek(struct txinds777_info *txinds,uint32_t blocknum);
|
|
|
|
|
void *txinds777_read(int32_t *lenp,uint8_t *buf,struct txinds777_info *txinds);
|
|
|
|
|
void txinds777_purge(struct txinds777_info *txinds);
|
|
|
|
|
|
|
|
|
|
struct ramkv777_item { UT_hash_handle hh; uint16_t valuesize,tbd; uint32_t rawind; uint8_t keyvalue[]; };
|
|
|
|
|
|
|
|
|
|
struct ramkv777
|
|
|
|
|
{
|
|
|
|
|
char name[63],threadsafe;
|
|
|
|
|
portable_mutex_t mutex;
|
|
|
|
|
struct ramkv777_item *table;
|
|
|
|
|
void **list; int32_t listsize,listmax;
|
|
|
|
|
struct sha256_vstate state; bits256 sha256;
|
|
|
|
|
int32_t numkeys,keysize,dispflag; uint8_t kvind;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define ramkv777_itemsize(kv,valuesize) (sizeof(struct ramkv777_item) + (kv)->keysize + valuesize)
|
|
|
|
|
#define ramkv777_itemkey(item) (item)->keyvalue
|
|
|
|
|
#define ramkv777_itemvalue(kv,item) (&(item)->keyvalue[(kv)->keysize])
|
|
|
|
|
|
|
|
|
|
struct ramkv777_item *ramkv777_itemptr(struct ramkv777 *kv,void *value);
|
|
|
|
|
int32_t ramkv777_clone(struct ramkv777 *clone,struct ramkv777 *kv);
|
|
|
|
|
void ramkv777_free(struct ramkv777 *kv);
|
|
|
|
|
|
|
|
|
|
int32_t ramkv777_delete(struct ramkv777 *kv,void *key);
|
|
|
|
|
void *ramkv777_write(struct ramkv777 *kv,void *key,void *value,int32_t valuesize);
|
|
|
|
|
void *ramkv777_read(int32_t *valuesizep,struct ramkv777 *kv,void *key);
|
|
|
|
|
void *ramkv777_iterate(struct ramkv777 *kv,void *args,void *(*iterator)(struct ramkv777 *kv,void *args,void *key,void *value,int32_t valuesize));
|
|
|
|
|
struct ramkv777 *ramkv777_init(int32_t kvind,char *name,int32_t keysize,int32_t threadsafe);
|
|
|
|
|
|
|
|
|
|
struct acct777 { uint32_t firstblocknum,firsttimestamp; int64_t balance; };
|
|
|
|
|
|
|
|
|
|
struct accts777_info
|
|
|
|
|
{
|
|
|
|
|
queue_t PaymentsQ;
|
|
|
|
|
uint64_t balance;
|
|
|
|
|
struct peggy_unit *units;
|
|
|
|
|
int32_t numunits; uint8_t numkvs;
|
|
|
|
|
struct ramkv777 *bets,*pricefeeds,*hashaddrs,*coinaddrs,*SaMaddrs,*nxtaddrs,*addrkvs[16];
|
|
|
|
|
bits256 peggyhash;
|
|
|
|
|
struct txinds777_info *txinds;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct accts777_info *accts777_init(char *dirname,struct txinds777_info *txinds);
|
|
|
|
|
|
|
|
|
|
#define YAHOO_METALS "XAU", "XAG", "XPT", "XPD"
|
|
|
|
|
extern char *peggy_bases[64],CURRENCIES[][8];
|
|
|
|
|
extern int32_t MINDENOMS[],Peggy_inds[],dailyrates[];
|
|
|
|
|
|
|
|
|
|
struct price_resolution peggy_scaleprice(struct price_resolution price,int64_t peggymils);
|
|
|
|
|
char *peggy_tx(char *jsonstr);
|
|
|
|
|
void _crypto_update(struct peggy_info *PEGS,double cryptovols[2][9][2],struct PAX_data *dp,int32_t selector,int32_t peggyflag);
|
many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
int32_t PAX_idle(struct peggy_info *PEGS,int32_t peggyflag,int32_t idlegap);
|
|
|
|
|
int32_t PAX_genspline(struct PAX_spline *spline,int32_t splineid,char *name,uint32_t *utc32,double *splinevals,int32_t maxsplines,double *refvals);
|
|
|
|
|
int32_t PAX_contractnum(char *base,char *rel);
|
|
|
|
|
int32_t PAX_basenum(char *base);
|
|
|
|
|
int32_t PAX_ispair(char *base,char *rel,char *contract);
|
|
|
|
|
struct peggy_info *PAX_init();
|
many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
uint32_t peggy_mils(int32_t i);
|
|
|
|
|
void calc_smooth_code(int32_t smoothwidth,int32_t _maxprimes);
|
|
|
|
|
struct peggy *peggy_find(struct peggy_entry *entry,struct peggy_info *PEGS,char *name,int32_t polarity);
|
|
|
|
|
struct price_resolution peggy_priceconsensus(struct peggy_info *PEGS,struct peggy_time T,uint64_t seed,int16_t pricedpeg,struct peggy_vote *votes,uint32_t numvotes,struct peggy_bet *bets,uint32_t numbets);
|
|
|
|
|
struct price_resolution peggy_price(struct peggy *PEG,int32_t minute);
|
|
|
|
|
struct price_resolution peggy_shortprice(struct peggy *PEG,struct price_resolution price);
|
|
|
|
|
void peggy_delete(struct accts777_info *accts,struct peggy_unit *U,int32_t reason);
|
|
|
|
|
int32_t peggy_setprice(struct peggy *PEG,struct price_resolution price,int32_t minute);
|
|
|
|
|
int32_t peggy_pegstr(char *buf,struct peggy_info *PEGS,char *name);
|
|
|
|
|
struct acct777 *accts777_find(int32_t *valuesizep,struct accts777_info *accts,union peggy_addr *addr,int32_t type);
|
|
|
|
|
struct acct777 *accts777_create(struct accts777_info *accts,union peggy_addr *addr,int32_t type,uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
int64_t acct777_balance(struct accts777_info *accts,uint32_t blocknum,uint32_t blocktimestamp,union peggy_addr *addr,int32_t type);
|
|
|
|
|
uint64_t peggy_redeem(struct peggy_info *PEGS,struct peggy_time T,int32_t readonly,char *name,int32_t polarity,uint64_t nxt64bits,bits256 pubkey,uint16_t lockdays,uint8_t chainlen);
|
|
|
|
|
#define accts777_getaddrkv(accts,type) ((accts != 0) ? (accts)->addrkvs[type] : 0)
|
|
|
|
|
uint64_t peggy_poolmainunits(struct peggy_entry *entry,int32_t dir,int32_t polarity,struct price_resolution price,struct price_resolution oppoprice,struct price_resolution spread,uint64_t poolincr,int16_t denomunits);
|
|
|
|
|
int32_t acct777_pay(struct accts777_info *accts,struct acct777 *srcacct,struct acct777 *acct,int64_t value,uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
struct peggy *peggy_findpeg(struct peggy_entry *entry,struct peggy_info *PEGS,int32_t peg);
|
|
|
|
|
void peggy_thanks_you(struct peggy_info *PEGS,int64_t tip);
|
|
|
|
|
uint64_t peggy_createunit(struct peggy_info *PEGS,struct peggy_time T,struct peggy_unit *readU,uint64_t seed,char *name,uint64_t nxt64bits,bits256 lockhash,struct peggy_lock *lock,uint64_t amount,uint64_t marginamount);
|
|
|
|
|
int32_t peggy_swap(struct accts777_info *accts,uint64_t signerA,uint64_t signerB,bits256 hashA,bits256 hashB);
|
|
|
|
|
int32_t peggy_aprpercs(int64_t dailyrate);
|
|
|
|
|
int64_t peggy_lockrate(struct peggy_entry *entry,struct peggy_info *PEGS,struct peggy *PEG,uint64_t satoshis,uint16_t numdays);
|
|
|
|
|
char *peggy_emitprices(int32_t *nonzp,struct peggy_info *PEGS,uint32_t blocktimestamp,int32_t maxlockdays);
|
|
|
|
|
int64_t peggy_compound(int32_t dispflag,int64_t satoshis,int64_t dailyrate,int32_t n);
|
|
|
|
|
|
|
|
|
|
#define MAX_OPRETURNSIZE 4096
|
|
|
|
|
struct opreturn_payment { struct queueitem DL; uint64_t value; char coinaddr[BTCDADDRSIZE]; };
|
|
|
|
|
struct opreturn_entry { struct opreturn_payment vout; uint32_t timestamp,blocknum; uint16_t isstaked,txind,v,datalen; uint8_t data[MAX_OPRETURNSIZE]; };
|
|
|
|
|
|
|
|
|
|
int64_t peggy_process(void *context,int32_t flags,void *fundedcoinaddr,uint64_t fundedvalue,uint8_t *data,int32_t datalen,uint32_t currentblocknum,uint32_t blocktimestamp,uint32_t stakedblock);
|
|
|
|
|
int32_t opreturns_gotnewblock(uint32_t blocknum,uint32_t blocktimestamp,char *opreturns[],int32_t numopreturns,char *peggybase_opreturnstr);
|
|
|
|
|
char *opreturns_stakinginfo(char opreturnstr[8192],uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
|
|
|
|
|
int32_t opreturns_process(int32_t flags,uint32_t currentblocknum,uint32_t blocknum,uint32_t blocktimestamp,struct opreturn_entry *list,int32_t num,uint8_t *peggyopreturn,int32_t peggylen);
|
|
|
|
|
int32_t opreturns_queue_payment(queue_t *PaymentsQ,uint32_t blocktimestamp,char *coinaddr,int64_t value);
|
|
|
|
|
int32_t opreturns_init(uint32_t blocknum,uint32_t blocktimestamp,char *path);
|
|
|
|
|
void *opreturns_context(char *name,int32_t context);
|
|
|
|
|
long hdecode_varint(uint64_t *valp,uint8_t *ptr,long offset,long mappedsize);
|
|
|
|
|
|
|
|
|
|
uint64_t conv_acctstr(char *acctstr);
|
|
|
|
|
int32_t serdes777_deserialize(int32_t *signedcountp,struct peggy_tx *Ptx,uint32_t blocktimestamp,uint8_t *data,int32_t totallen);
|
|
|
|
|
int32_t serdes777_serialize(struct peggy_tx *Ptx,uint32_t blocktimestamp,bits256 privkey,uint32_t timestamp);
|
|
|
|
|
int32_t peggy_univ2addr(char *coinaddr,struct peggy_univaddr *ua);
|
|
|
|
|
int32_t peggy_addr2univ(struct peggy_univaddr *ua,char *coinaddr,char *coin);
|
|
|
|
|
uint64_t PAX_validate(struct PAX_sig *sig,uint32_t timestamp,uint8_t *data,int32_t datalen);
|
|
|
|
|
uint64_t PAX_signtx(struct PAX_sig *sig,bits256 privkey,uint32_t timestamp,uint8_t *data,int32_t datalen);
|
|
|
|
|
|
|
|
|
|
int64_t peggy_process(void *context,int32_t flags,void *fundedcoinaddr,uint64_t fundedvalue,uint8_t *data,int32_t datalen,uint32_t currentblocknum,uint32_t blocktimestamp,uint32_t stakedblock);
|
|
|
|
|
int32_t peggy_emit(void *context,uint8_t opreturndata[MAX_OPRETURNSIZE],struct opreturn_payment *payments,int32_t max,uint32_t currentblocknum,uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
int32_t peggy_flush(void *context,uint32_t currentblocknum,uint32_t blocknum,uint32_t blocktimestamp);
|
|
|
|
|
int32_t peggy_init_contexts(struct txinds777_info *opreturns,uint32_t blocknum,uint32_t blocktimestamp,char *path,void *globals[OPRETURNS_CONTEXTS],int32_t lookbacks[OPRETURNS_CONTEXTS],int32_t maxcontexts);
|
|
|
|
|
uint32_t peggy_clone(char *path,void *dest,void *src);
|
|
|
|
|
void *peggy_replay(char *path,struct txinds777_info *opreturns,void *_PEGS,uint32_t blocknum,char *opreturnstr,uint8_t *data,int32_t datalen);
|
|
|
|
|
uint32_t peggy_currentblock(void *globals);
|
|
|
|
|
struct peggy_info *peggy_init(int32_t maxdays,char *maincurrency,uint64_t maincurrencyunitsize,uint64_t quorum,uint64_t decisionthreshold,struct price_resolution spread,uint32_t dailyrate,int32_t interesttenths,int32_t posboost,int32_t negpenalty,int32_t feediv,int32_t feemult,uint32_t firsttimestamp,uint32_t BTCD_price0);
|
many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
|
|
|
|
|
struct peggy_unit *peggy_match(struct accts777_info *accts,int32_t peg,uint64_t nxt64bits,bits256 lockhash,uint16_t lockdays);
|
|
|
|
|
int32_t peggy_addunit(struct accts777_info *accts,struct peggy_unit *U,bits256 lockhash);
|
|
|
|
|
FILE *myfopen(char *fname,char *mode);
|
|
|
|
|
int32_t myfclose(FILE *fp);
|
|
|
|
|
void peggy_priceinits(struct peggy_info *PEGS,uint32_t firsttimestamp,uint32_t *allprices);
|
|
|
|
|
double PAX_aveprice(struct supernet_info *myinfo,char *base);
|
many changes
blockexplorer tab: needs to allow to input height, blockhash or txid.
also please display images/BTC_blocks.jpg below the text as a w800 x
h400 bitmap, which is active using the mouse api
for coin management, below the active coins have a form that arbitrary
json can be input with an add button to the right that will call
"addcoin" API. this way I can test adding new coins dynamically. dont
worry if it doesnt work, just as long as it submits the json to the C
code. I am pretty sure I need to do some debugging of this
peers management is not working for me at all. maybe it is due to bad
internet. On initialization you need to read in the
confs/BTCD_peers.txt from the native filesystem and save it into the
chrome app filesystem. same thing for confs/BTCD_hdrs.txt. But this is
only to be done if there isnt already such a file inside chrome. if
there is, only do it upon a button invoked by the user. the reason is
that the pexe is updating this file with the latest. Maybe it is nice
to have an "extract" button that will copy out from the chrome storage
into the native filesystem. There is also the manifest issue about
localstorage vs chrome.localstorage. not sure what is needed to be
done, but certainly a priority to get it so everything works as a
chrome app. I know before it was making ramchain files inside the
chrome filesystem, so it is probably things the GUI is doing. maybe in
the settings tab, which has obsolete stuff that can be removed.
anyway, the issue about files existing in the native filesystem ->
chrome and optionally extracting them is an issue for the confs files
and .html template files used to autogenerate the port7778, maybe other
files are affected. i think we need a way to have a list of hardcoded
files that are just copied into chrome on startup if they dont exist
already (or if possible copy over if the native version is bigger?) and
buttons to extract them
for debug tab:
THREE_STRINGS(SuperNET,encryptjson,passphrase,permanentfile,anything);
TWO_STRINGS(SuperNET,decryptjson,passphrase,permanentfile);
at the top of page a way to put in passphrase and optional
permanentfile along with arbitrary json. The standard form template has
no easy way to describe to pass in everything as it is oriented to
specific fields. but the encryptjson API saves all the fields, so the
arbitrary json from the form needs to be combined at the same level as
the "agent", "method", etc. I know, not the best, but internally it
makes it easier. so
{"agent":"SuperNET","method":"encryptjson","passphrase":"<passphrase>","
permanentfile":"<filename>","fromform":"valuefromform","fromform2":"valu
efromform2",...rest of form at top level}
then this will save it into a file with crazy number (it is a hash like
txid) but given the same passphrase and filename, it will regenerate
this hash so you dont actually have to store it, but it helps during
debugging.
for the filename, we must warn quite strongly to the user that if the
file is ever lost or even changed in any way that the data will not be
recoverable. also best to not allow the user to specify a file that
does not exist. I think at this point chrome app version gets a bit
tricky. we could simply push the native file into the chrome storage,
but then an attacker who gets access to the computer could just get a
list of these files and it really wont be much protection. So that
means if a filename is specified, it needs to be copied into the chrome
space, then immediately deleted... ok, this seems like not a good
approach. let us make it so that the permanentfile option is not
available from the chrome app, but only if the native version is
running. that way we sidestep the issue of the pexe not having access
to the specified file.
Speaking of native vs pexe, on the startup page we should have a radio
button that allows the user to select which the GUI will talk to. It
should default based on a self test to the more likely value, but it is
possible that the user wants to use the native version, even if the
pexe is running.
another thing to have on the startup page is a simple login:
THREE_STRINGS(SuperNET,login,passphrase,permanentfile,handle);
ZERO_ARGS(SuperNET,logout);
ZERO_ARGS(SuperNET,activehandle);
the handle is a human readable name that is associated with the
passphrase/permanentfile. There can only be one active account (though
it will be possible to associate different accounts with tradebots).
use the activehandle API to find out who is logged in and the
associated addresses and pubkeys
The above is not yet tested so if it doesnt work, dont fret, just let
me know. Once set the handle can be displayed in various places to let
the user know which account is logged in. The standard 12 dictionary
word passphrases should be used, but any string can be sent in as the
password
for Pangea:
INT_AND_ARRAY(pangea,host,minplayers,params);
ZERO_ARGS(pangea,lobby);
HASH_AND_STRING(pangea,join,tablehash,handle);
HASH_AND_INT(pangea,buyin,tablehash,numchips);
HASH_ARG(pangea,start,tablehash); // by host only
HASH_ARG(pangea,status,tablehash);
HASH_ARG(pangea,call,tablehash);
HASH_ARG(pangea,check,tablehash);
HASH_AND_INT(pangea,raise,tablehash,numchips);
HASH_AND_INT(pangea,bet,tablehash,numchips);
HASH_ARG(pangea,fold,tablehash);
HASH_AND_STRING(pangea,mode,tablehash,modestr);
HASH_ARG(pangea,history,tablehash);
HASH_AND_INT(pangea,handhistory,tablehash,hand);
The first thing that is done is a "host" by any node. the "params"
should be an arbitrary json (like encryptjson) as it needs to be at the
top level and it has quite a few different parameters still subject to
change. The lobby API will just display all the hosted tables.
once a table exists, players can join and then buyin. the buyin is
denominated in chips, each chip's value is determined by the host's
initial parameters.
once there are enough players joined with adequate buyin's verified,
the host will be able to do a start. if done before it will
(eventually) give an error. for now it will just proceed.
The host and players that have joined a tablehash, need to do regular
status calls to see if the game has started. Probably just once per 5
or even 10 seconds is fine before the start. Once the game starts (the
status will have this info) then once per second polling is needed.
Then when it is your turn (as indicated by status) you need to do one
of the 5 actions (fold, call, check, raise, bet). do not worry if you
dont understand what all these do, just allow the user to do any of
these. I guess it is possible to submit it ahead of time. I will
support internally remembering the most recent action done prior to it
being your turn. once it is your turn and an action is sent to the
table, it is too late to change.
The last API calls are for getting handhistory where hand is 0 to N-1,
being the numbering of the hands played at that table. if just history,
all the history for all hands at the table is coming back, so it could
be quite big. probably I will make it a summary, but for the GUI just
display the returned values.
the mode is to change some poker specific modes, so just allow there to
be a string entered.
do not worry about understanding the pokerness of the API, just the
overall flow:
host -> creates, join/buyin -> fills up player slots, start -> starts
the game
status -> to determine when the game starts (or if it is cancelled) and
once started
actions -> game specific but basically just (button + arg) that is the
user input
results are via status for current game and history for past ones
please try to do the above logic in a generic way so it can be reused
for other games. The basic flow should be the same for almost all
multiplayer turn based games and even for multiplayer realtime games
For InstantDEX:
on the apikeypair/userid there needs to be two modes. one for when
there is no stored apikey and the current form is fine, just need to
make it wider as most apikeys are quite long. Now once there is an
apikey saved all that is needed is the passphrase to unlock it. So here
is where the encrptjson/decryptjson is used. When saving the apikey for
the first time, it can be:
a) not saved -> nothing extra to do
b) saved without password -> you can just save to a file and use it to
load it back in. use confs dir confs/instantdex.exchange.api or
something like that
c) saved with password (optional filename for native) -> probably best
to save in the confs dir to indicate that there is an encrypted file
for this, so just that and not the actual passphrase in the file
with the above, when the exchange is selected, you can see if the confs
file exists and if it has the plaintext, just populate the field, if
not, then indicate that a passphrase is needed. if the user provides
the passphrase, then decryptjson and populate the fields and autosubmit.
A special case is to encrypt the apikeys with the passphrase used when
logging in. This is only available if the checkbox to "remember
passphrase during session" is set on the main iguana login screen. (i
forgot to mention that checkbox!) So the login passphrase is stored in
memory, then the GUI simply uses that + encryptjson for
storing/decrypting. I would imagine that storing in the confs file that
it is encrypted using "handle"'s account login might be a good way to
differentiate between this mode of password usage.
OK, so we now have the insecure plaintext, the decent using handle's
passphrase and paranoid different passphrase for each exchange (with
additional permanentfile for native versions)
"SUPPORT" -> "SUPPORTS" just a typo
and "allpairs" API is missing from the selection
Might as well add a "tradebots" tab:
THREE_STRINGS_AND_DOUBLE(tradebot,monitor,exchange,base,rel,commission);
STRING_AND_DOUBLE(tradebot,monitorall,exchange,commission);
THREE_STRINGS(tradebot,unmonitor,exchange,base,rel);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,accumulate,exchange,base,rel,pr
ice,volume,duration);
THREE_STRINGS_AND_THREE_DOUBLES(tradebot,divest,exchange,base,rel,price,
volume,duration);
STRING_ARG(tradebot,activebots,exchange);
TWO_STRINGS(tradebot,status,exchange,botid);
TWO_STRINGS(tradebot,pause,exchange,botid);
TWO_STRINGS(tradebot,stop,exchange,botid);
TWO_STRINGS(tradebot,resume,exchange,botid);
the above are API for exchange specific bots, most should be
self-explanatory. bots are created via "accumulate" or "divest" API
call. it returns botid. once created, you can do status, pause, stop,
resume to a botid. and an activebots API call lists all the active bots
for an exchange.
duration is in seconds
the "monitor" API starts background monitoring of a specific base/rel,
"unmonitor" stops this. "monitorall" just does a monitor to the entire
list of "allpairs" for that exchange. Keep in mind that doing a
monitorall will not add load to an exchange as the request to each
exchange is governed by pollgap, but if you have 3 things monitored, it
will take 3*pollgap + time each one takes to execute. and if N are
monitored it is N*pollgap + time of each, with the "time of each"
possibly taking a very long time.
And one final request for today: Bitmap tab.
It should be an active bitmap using mouse api. either a dropdown to
select the bitmap or a form entry. then the rest of the page (resize
the bitmap to the page size) being the active bitmap. So on a small
screen the bitmap is smaller x/y dimensions and larger on larger
screens. plz make sure the proper dimensions are communicated to the
pexe via API if it ever is changed.
@vineet.bhargav86: I changed the "passphrase" fieldname to "password"
for the encryptjson/decryptjson related API. The reason is that the
password is like a wallet password and is only local, so it doesnt need
to be as high entropy as passphrase. I also added a field to the login
API as I realized that the 12 word "passphrase" is the payload and
usually wont be sent in:
FOUR_STRINGS(SuperNET,login,handle,password,permanentfile,passphrase);
using "abiglongpassword" for the passphrase ->
{"pubkey":"6c469ba10b40b3eb9d1dba569d7f929d55a29d8f97cd5425907ef2f38f906
209","RS":"NXT-KGV9-DXX8-TM86-DXR96","NXT":"12834974574569896807","btcpu
bkey":"024e7641dc947b211bc30fe3339765258902794687b227121fc217284f9d8503c
8","rmd160":"33453c24914db7b77069b7ea24df44f6be145938","BTC":"15g6QK2dSd
iW9ZTQEnnJxKrSph6uP7uU23","BTCD":"RDxHUpuv3TX5DZpbhxmS3rBeaxZW1fvYvC","r
esult":"success","handle":"test","tag":"14805226009240621255"}
and if you use that to log into NXT, it gives the same address. The BTC
and BTCD addresses are all derived from the same privkey so they are
all interchangeable with the NXT address. The user can therefore select
which coin's addressing they are most comfortable with
I also added an "allin" action API for pangea. all the action API will
autocalculate the number of chips if passed in 0 for numchips
***************** security issue ********
please dont use the GET URL method when dealing with passphrase!!!
Those URL's tend to get logged and available in browser histories. so
anything dealing with the actual passphrase needs to use the postCall
form or POST
9 years ago
|
|
|
|
|
|
|
|
#endif
|
