[ANN][BURST] Burst | Efficient HDD Mining | New 1.2.3 Fork block 92000

[crowetic]

Burstforum seems down (at least to me)
Any info?

no update regarding the down time

I guess admin is offline and unfortuantely don't know about it :/

Dang, I need to get a hold of BitV... I'll see what I can do. I'm only a mod there and don't have any actual admin to the back end.

[1715396276]

1715396276

[1715396276]

1715396276

[1715396276]

1715396276

[1715396276]

1715396276

[1715396276]

1715396276

[FakeAccount]

Plot Optimizer v1.6

Per FakeAccount's suggestion, I have added an option to not delete the original plot file. When I have more time, I will organize the order of the parameter list better. The new option is used with a -del 1 to delete the original file or -del 0 to keep the original file and is placed before the memory used option. If you do not include a -del parameter, the default will delete the original file.

Download Link:
http://bitshare.com/?f=epn02ow4

any chance you can post on a site that doesn't try to install a ton of useless software and malware (bitshare.com)?
github, dropbox, mega might be better?
thanks

[FakeAccount]

looking in the wallet, list of found blocks has changed sorting order(low->high vs. descending previously) and it is not possible to see a list of all mined blocks now with this update?

Burst 1.1.5

Download: https://mega.co.nz/#!r9RywR4b!e0MqN4kXx1uiW5th8PBxiwjOfdNhjxjS52UqXwihGW8
sha256: 5b8a5e9d2ebcc35052a885b299764ed257346f3c849e92768bd5b725ad685ac7
Or github: https://github.com/BurstProject/burstcoin

Update is required for all users.
Hard fork will be triggered at least 4-5 days from now, depends on how fast people update.
If using an existing copy of the blockchain, first startup will take several minutes.

Short summary:
Updated to latest Nxt(1.3.2)
Added subscriptions(reoccurring payments)(more details will be given when enabled)
Escrow updated to use result transactions instead of just adding to balance.

Longer story:
This release took far longer than I intended it to. Subscriptions turned out to be more of a challenge than expected, and about when I had a first release candidate, nxt 1.3.0 was released. Nxt 1.3.0 was a massive restructuring which I considered a necessary update since it was to fix scalability issues I already knew would need to be addressed at some point, however it broke compatibility with a lot of my code. Rather than debugging subscriptions, then updating, and debugging it again, I went straight to updating to Nxt 1.3.0, which required me to re-write most of the subscription, escrow, and reward recipient assignment code. Nxt 1.3.1 and 1.3.2 were also released fairly shortly after, and their updates went a lot more smoothly. Re-testing everything took some time, and I ended up re-factoring subscriptions a few times to ensure everything was done consistently.

Next plans:
I'm going to be postponing the last part of advanced transactions for now, and starting on BurstID(more details will be given later), and maybe some of the DHT code.

[Pilotseye]

Plot Optimizer v1.6

Per FakeAccount's suggestion, I have added an option to not delete the original plot file. When I have more time, I will organize the order of the parameter list better. The new option is used with a -del 1 to delete the original file or -del 0 to keep the original file and is placed before the memory used option. If you do not include a -del parameter, the default will delete the original file.

Download Link:
http://bitshare.com/?f=epn02ow4

any chance you can post on a site that doesn't try to install a ton of useless software and malware (bitshare.com)?
github, dropbox, mega might be better?
thanks

try the services of Premiumize.me, it creates an all-in-one premium account for a lot of filesharing sites and they accept Bitcoin as well

[mafostedu]

@ Blago,

Does your latest miner supports special characters in pass phrase for solo ?
If not, can you add it in the future version ?

Thanks.

Yes, support.   https://github.com/Blagodarenko/miner-burst/blob/master/miner.cpp  string #517

Oh OK that's great.
One last question, if I have say 5 rigs & all rigs are connected to the same internet connection as individual system (Not like client-server scenario),
can I mine solo with wallet running on each system & your miner running individually on each system ? or should I create client-server setup & use your latest miner with running the wallet on server (1 of the 5 rigs) & other 4 systems connected as a client to it. Thanks for your great work & prompt reply.

Yes, will work, but wallet only needs be on 1 server. Just edit nxt-default.properties

Or you can run wallet for each rigs and set
   "Mode" : "solo",
   "Server" : "127.0.0.1",
   "Port": 8125,
   "UpdaterAddr" : "127.0.0.1",
   "UpdaterPort": 8125,
   "EnableProxy": false,

Alright that's great. Where should I put my passphrase.txt file (Is it passphrase.txt or passphrases.txt) ?
In Miner folder or in Wallet folder ?
It is just a simple .txt file with only passphrase written inside (Without any syntax) right ?

If I have two burst accounts, can I keep both passphrases in the same .txt file or need to run 2 instances ?

I tried to keep it in both but the miner doesn't start at all with the changes you advised above. With pool it works like a charm.

[Blago]

Alright that's great. Where should I put my passphrase.txt file (Is it passphrase.txt or passphrases.txt) ?
In Miner folder or in Wallet folder ?

in miner folder, passphrases.txt

It is just a simple .txt file with only passphrase written inside (Without any syntax) right ?

yes

If I have two burst accounts, can I keep both passphrases in the same .txt file or need to run 2 instances ?
I tried to keep it in both but the miner doesn't start at all with the changes you advised above. With pool it works like a charm.

you can make 2 miner's folders for different accounts and have passphrases.txt for each.

[jamoes]

My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!

You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.

[sellbuy]

Code:

Caused by: java.nio.channels.UnresolvedAddressException
	at sun.nio.ch.Net.checkAddress(Unknown Source)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	... 9 more
2014-11-05 22:25:58 INFO: Started peer networking server at 0.0.0.0:8123
2014-11-05 22:25:58 SEVERE: Errors running startup tasks:
java.net.SocketException: Unresolved address

java.lang.RuntimeException: Errors running startup tasks:
java.net.SocketException: Unresolved address

	at nxt.util.ThreadPool.runAll(ThreadPool.java:133)
	at nxt.util.ThreadPool.start(ThreadPool.java:62)
	at nxt.Nxt$Init.<clinit>(Nxt.java:189)
	at nxt.Nxt.init(Nxt.java:149)
	at nxt.Nxt.main(Nxt.java:140)
2014-11-05 22:25:58 INFO: Shutting down...
2014-11-05 22:25:58 INFO: Database shutdown completed
2014-11-05 22:25:58 INFO: Burst server 1.1.5 stopped.

why error? 1.1.3 work fine

[ltcnim]

Code:

Caused by: java.nio.channels.UnresolvedAddressException
	at sun.nio.ch.Net.checkAddress(Unknown Source)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	... 9 more
2014-11-05 22:25:58 INFO: Started peer networking server at 0.0.0.0:8123
2014-11-05 22:25:58 SEVERE: Errors running startup tasks:
java.net.SocketException: Unresolved address

java.lang.RuntimeException: Errors running startup tasks:
java.net.SocketException: Unresolved address

	at nxt.util.ThreadPool.runAll(ThreadPool.java:133)
	at nxt.util.ThreadPool.start(ThreadPool.java:62)
	at nxt.Nxt$Init.<clinit>(Nxt.java:189)
	at nxt.Nxt.init(Nxt.java:149)
	at nxt.Nxt.main(Nxt.java:140)
2014-11-05 22:25:58 INFO: Shutting down...
2014-11-05 22:25:58 INFO: Database shutdown completed
2014-11-05 22:25:58 INFO: Burst server 1.1.5 stopped.

why error? 1.1.3 work fine

did you use your old config? with the old config, the server crashes at startup, so you need to use the config that comes with 1.1.5 and modify it according to your needs.

[fivebells]

My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

By random, do you mean randomly machine generated, or chosen manually by you?

OS is Windows 8.1, so it stores the password in an unencrypted text file :/

https://www.virustotal.com/en/file/d3992c3d8be28d99b4f58b17a1d7eccbb04ba18e6471bcc3321a82b8011e0475/analysis/1413153796/

Either a false positive or  a very obscure trojan. After initial scam, this is hard to swallow and keep faith. Any insight into why this has shown up Dev?

no threat found on my end. false positive, its common with windows-qt and that particular antivirus


its scanned with 53 virus protectors and only 1/53 come up with a false positive

Alright, just thought I would check, have recently had some malware problems on the machine that hosts my wallets.

It looks like you have recently had security issues.  What steps have you taken to mitigate them?

[callmejack]

My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!

You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.

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.

[sellbuy]

Code:

Caused by: java.nio.channels.UnresolvedAddressException
	at sun.nio.ch.Net.checkAddress(Unknown Source)
	at sun.nio.ch.ServerSocketChannelImpl.bind(Unknown Source)
	... 9 more
2014-11-05 22:25:58 INFO: Started peer networking server at 0.0.0.0:8123
2014-11-05 22:25:58 SEVERE: Errors running startup tasks:
java.net.SocketException: Unresolved address

java.lang.RuntimeException: Errors running startup tasks:
java.net.SocketException: Unresolved address

	at nxt.util.ThreadPool.runAll(ThreadPool.java:133)
	at nxt.util.ThreadPool.start(ThreadPool.java:62)
	at nxt.Nxt$Init.<clinit>(Nxt.java:189)
	at nxt.Nxt.init(Nxt.java:149)
	at nxt.Nxt.main(Nxt.java:140)
2014-11-05 22:25:58 INFO: Shutting down...
2014-11-05 22:25:58 INFO: Database shutdown completed
2014-11-05 22:25:58 INFO: Burst server 1.1.5 stopped.

why error? 1.1.3 work fine

did you use your old config? with the old config, the server crashes at startup, so you need to use the config that comes with 1.1.5 and modify it according to your needs.

problem was with config, defautl launches successfully

[crazyearner]

Any reason for why burstforum is down cant access.

[m3ta]

java.net.SocketException: Unresolved address

no, its new config file. i have changed only allowedBotHosts and apiServerHost to the same values as in 1.1.3.

Double-check the address you're connecting to.

[Nevril]

Any reason for why burstforum is down cant access.

It is down since this morning (GMT)... still no news

[Pinecone]

looking in the wallet, list of found blocks has changed sorting order(low->high vs. descending previously) and it is not possible to see a list of all mined blocks now with this update?

Burst 1.1.5

Download: https://mega.co.nz/#!r9RywR4b!e0MqN4kXx1uiW5th8PBxiwjOfdNhjxjS52UqXwihGW8
sha256: 5b8a5e9d2ebcc35052a885b299764ed257346f3c849e92768bd5b725ad685ac7
Or github: https://github.com/BurstProject/burstcoin

Update is required for all users.
Hard fork will be triggered at least 4-5 days from now, depends on how fast people update.
If using an existing copy of the blockchain, first startup will take several minutes.

Short summary:
Updated to latest Nxt(1.3.2)
Added subscriptions(reoccurring payments)(more details will be given when enabled)
Escrow updated to use result transactions instead of just adding to balance.

Longer story:
This release took far longer than I intended it to. Subscriptions turned out to be more of a challenge than expected, and about when I had a first release candidate, nxt 1.3.0 was released. Nxt 1.3.0 was a massive restructuring which I considered a necessary update since it was to fix scalability issues I already knew would need to be addressed at some point, however it broke compatibility with a lot of my code. Rather than debugging subscriptions, then updating, and debugging it again, I went straight to updating to Nxt 1.3.0, which required me to re-write most of the subscription, escrow, and reward recipient assignment code. Nxt 1.3.1 and 1.3.2 were also released fairly shortly after, and their updates went a lot more smoothly. Re-testing everything took some time, and I ended up re-factoring subscriptions a few times to ensure everything was done consistently.

Next plans:
I'm going to be postponing the last part of advanced transactions for now, and starting on BurstID(more details will be given later), and maybe some of the DHT code.

I also would like to request if there could be some way to return the "Blocks" section of the wallet back to the old style where newest blocks found were displayed first as it did in pre-1.1.5

I had relied on this more than I thought to see my mined blocks now that its reversed order.

[crowetic]

Any reason for why burstforum is down cant access.

no news from admin... I don't have any other forms of contact for him either.

[fivebells]

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 think this is the relevant patch.

Code:

commit 56e44b38e524ea52a7b2f5a7e25d126c929ece72
Author: Jean-Luc Picard <jlp666@yandex.ru>
Date:   Sat Mar 15 06:05:36 2014 +0100

    applied Curve25519 patch from DoctorEvil

Come-From-Beyond claims that there were a number of deliberately-introduced vulnerabilities in the original NXT source code, to deter NXT clones.  It sounds like an incredibly irresponsible thing to do, but there it is.  Supposedly they're all patched, now.  Someone here probably knows the date of the last such patch... the NXT source should be checked for  patches to any vulnerabilities reported prior to that.

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.

People should panic-sell.  Just let me in on the bargain-basement prices. :-)

[burstcoin]

My password is a random string of numbers and letters, caps and no caps, 30 symbols long. So weak password is not an issue.

It's unlikely that the password was bruteforced, but I think 30 symbols doesn't provide maximum security.
Please correct me if I'm wrong: 256 bits are used in the hash, that's 32 bytes. But we aren't using the full 0-255 character range in passwords, so they should be much much longer. 26 (a-z) + 26 (A-Z) + 10 (numbers) = only 62 chars subset is used for passwords. Using words instead of random letters raises bruteforcing chances even more. The passwords need to be 4.2 times longer: at least 134 symbols!

You're on the right track, but your math is not quite right. If you choose a password from a set of 62 characters, then each character is providing 5.95 bits of entropy (ln(62) / ln(2)). So, if you want to achieve 256 bits of entropy, your password should be at least 43 characters long.

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.

The signing issue isn't due to integer size differences, but due to java's lack of unsigned integer types. The proposed patch on the page you linked has been applied to the Curve25519.java file, so this hasn't been an issue for quite a while.

Regarding the passphrase generator, I don't know where the cut-off would be for considering it bruteforceable, however 105 bits does seem very low compared to what you would get from the recommended 35+ characters alphanumeric with symbols.

I think you're looking at the wrong account. Stacy's account had all 9.8k transfered, however they didn't continue to transfer new coins that came in from mining.

[lootz]

https://www.cryptsy.com/coinvotes/

Need help with the votes

I just voted