working at the AE client atm. testing and balance tracing is going on but close to finish.
the apphub client needs to refactor, enabling a distributed applications approach. means
only the account handling is included make it max lightweigthed. alias and AM and some
additional tools are loadable modules on demand via a distributed application layer.

Maybe I just had to pay TWICE for one order on the AE:

accBal was:

 987945 conf, 873090 unconf. before the trade.
 702845 conf, 302990 unconf. after the trade

conf Balance: 987945 -   702845 = 285100 = 1900*150 + 100(FEE) OK

unconf Balance: 873090 - 302990 = 570100 =   2*   1900*150 + 100(FEE)

lets wait how the balance looks later when the conf==unconf -  - but how is it that the Trade hits the unconf Balance TWICE?!?!


Can anyone reproduce this or know anything about it

Order was : 1900HIVE @ 150 (1.5nxt?) -> 2850
 

{'bidOrderId': '2084814903449362881', 'quantity': 1900, 'askOrderId': '12983022864822577544', 'timestamp': 8203706, 'price': 150}]


my bid order:
2084814903449362881

deadline - 10
timestamp - 8203691
recipient - 1739068987193023818
fee - 1
attachment - {'asset': '5738361901523075871', 'quantity': 1900, 'price': 150}
senderPublicKey - 5f7605dfd9ddba1c7843add87f2afc0b9edb1776ad9ae7c9cce18013fa892471
amount - 0
signature - 2e1444f7ff479b8a73cde8270afb88e12842ec22a6b4ff6633b479f3bcf1c206b48f41ddde79ba1 99ab0c4cdc7d0da7d4f9465df194a048d98065da599b784a9
referencedTransaction - 0
confirmations - 7
block - 15113600740772845724
subtype - 3
sender - 1738404304940813414
type - 2
 

I always hated documenting unside the code, Just make an SRS with apot of models and good description of API amd we sre golden.

It is march soon! let me guess it will be for april.

Btw, those that don't have an IRC program, download one of these:

Windows Linux: http://hexchat.github.io/downloads.html
Mac: http://colloquy.info/downloads.html

Then join us on the server irc.freenode.net, and go to the #nxtalk channel. See you there!

Please, please dont start to pay members of the committees!

I'll try again...

Would one solution be to have a sequence of nodes, where the next 'n' forging nodes are always known not necessarily in parallel but in close sequence, so node 1 identifies node 2 and node 2 identifies node 3 (based on 1 & 2), node 3 identifies 4 (based on 1,2,3), this would create a forging mesh within the network and clients could choose which node to send to based on latency and forging window. (mobile networks and phones do something like this all the time - yes I know about dropped calls its not perfect!)

The choice of node not just based on the current params but also its awareness of the network topography would mean a continual distribution of nodes resulting in statistically a node being close in latency and forging window to a client that wanted to transact...

Depending on the capacity required the nodes would seek an optimum connection with other nodes to achieve that capacity, also if the network can advertise its current processing capacity based on its current demand and ask for more nodes who might be sleeping because not needed before.

You don't have to deploy static network models like hub/spoke or regional or whatever...

Normally people think the a system is stronger than any one single part but what I read here is how for a moment one part has to stand out from all the rest and that makes it vulnerable.

groups of forging accounts = Pool