Topic: [ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000 - page 590. (Read 2171061 times)

you can use the account api function.
replace 127.0.0.1 with your walltet ip if it differs and enter your account (BURST-XXX.... or numeric) in the "getAccountTransactions" section.
http://127.0.0.1:8125/test?requestTag=ACCOUNTS

this should return all transactions as json into the output area.
to retrieve it directly as json you can use this as url (replace XXX with your account): http://127.0.0.1:8125/burst?requestType=getAccountTransactions&account=XXX

this is a json response and therefore not readable like the transaction list in the wallet ui but it contains all data the wallets blockchain supplies.

any idea how to search a transaction from 6 weeks ago? The current wallet doesn't seem to go back that far. Block explorer also, not that far back.

i have'nt looked into the code on how the pk is used to sign transactions but i think it is ecdh based.
doing a google search for the included java code from nxt to do the signing brought up a site stating the sign function is not as secure as the original code where it was ported from to java. this is because java uses different size integers and a c big int variable has only the maximum size of an unsigned int in java (https://gist.github.com/doctorevil/9521116).
someone with java knowledge maybe can verify that the described flaw applies or hopefully does'nt apply to the code in src/java/nxt/crypto/Curve25519.java file or finds out this whole function is only included due to forking reasons.

this in combination with the wallet which offers 12 words OUT OF 1626 by default (html/ui/js/crypto/passphrasegenerator.js) makes it in my opinion attackable.
within an bruteforce attack this is less than 11 bit for each word which sums up to about 105 bits of combinations.
if the ecdh implementation shows the mentioned flaw it cuts internal 256 bit variables at 64 bit.
without further analysis this provides a option to bruteforce wallet generated keys by software designed to utilize this flaw by testing less than 32 bit of combinations. i am no crypto specialist and if someone with knowledge about all this could take a look into it would be great. i think as long as someone uses custom generated private keys even if the flaw exists in the code the required energy to break 105 bits is much more than what you get for the coins in the wallets. on the other hand it may be possible to bruteforce all known wallet addresses in one run without much more costs...

i currently do not understand why someone did'nt empty the whole account and only took 40k.
i dont want to make people panic sell and drive the price down but if you hold a certain amount of coins within one wallet think about all this if you used the wallet to generate your private key.

Right, yea, I am not sure how to get a hold of BitV, besides messaging him here.

Let's hope it gets fixed... BLTPS project is "locked" too. I have a backup but without the subscriptions and PMs I got.

Also, no idea what's up with burstforum, but if it stays down longer I may be hiring someone to build a new forum.

Hm burst.ga is down for several hours, anyone know whats happening ...