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

[crowetic]

How did you link the wallet to the user?

It says its alias right there on tiga's block explorer

OK. Thanks but beware of a ruse.

That is exactly why I said to use own judgment. That info could've easily been placed there to mislead.

Need to investigate the person deeper to see if a link can be established. There are too many scams in crypto right now. I expect the regulators to do a sweep soon and tough laws and regs to be enacted.

If anyone on here has coins in Cryptsy they should be careful because they may be in the crosshairs of the law for their involvement with the PayCoin Scandal.

I'm already looking into this and sent a message to the person on burstforum and also in the blockchain, hopefully they'll get back to me and we can figure this out.

Do we know anything about the original password style? How many characters, was it built from dictionary words, did it contain numbers and symbols?  I'm curious about the brute force capabilities, what type of password was the algorithm able to crack?

Currently I don't know much other than what I've posted, as I said tiga has been really busy lately and we haven't seen much of him. So that makes this 10x harder.

[callmejack]

How did you link the wallet to the user?

It says its alias right there on tiga's block explorer

OK. Thanks but beware of a ruse.

That is exactly why I said to use own judgment. That info could've easily been placed there to mislead.

Need to investigate the person deeper to see if a link can be established. There are too many scams in crypto right now. I expect the regulators to do a sweep soon and tough laws and regs to be enacted.

If anyone on here has coins in Cryptsy they should be careful because they may be in the crosshairs of the law for their involvement with the PayCoin Scandal.

I'm already looking into this and sent a message to the person on burstforum and also in the blockchain, hopefully they'll get back to me and we can figure this out.

Do we know anything about the original password style? How many characters, was it built from dictionary words, did it contain numbers and symbols?  I'm curious about the brute force capabilities, what type of password was the algorithm able to crack?

Currently I don't know much other than what I've posted, as I said tiga has been really busy lately and we haven't seen much of him. So that makes this 10x harder.

the whole password discussion already happened many pages back.
one of the most meaningful posts is this:
https://bitcointalk.org/index.php?topic=731923.msg9451896#msg9451896

it says if your passphrase is random enough you are "save".
the only way to prevent weak passwords on wallet side would be to analyze the entropy and discline the public key generation if it is bad.
i dont speak java but in general there must exist several string entropy analyzer even for java  
the issue with such an approach becomes the usability for an average user if you get forced to use secure passwords.

[12gaFacelift]

I do not read all thing about what happen since my english is limited but i am not sure now i want to buy more asset/share in ByteEnt.

*Effective Immediately, all ByteEnt and ByteBank asset payouts are paused while we figure out this issue.

[mczarnek]

Hey DEV is there a way to limit brute force wallet attacks while not inconveniencing legit wallet owner?

No

Problem is the public ledger, you can download the blockchain yourself and the formula for turning passwords into account numbers is known, so the attacker can brute force his own version of the database, then only use the 'good' passwords.  So no, not without some pretty significant changes.

Edit: Actually.. you could require the creation of the password to be a POW.. basically somehow prove to the network that you did a POW without also telling the network what your password is. Something along the lines of requiring that all public keys(aka account numbers) are within a certain range(or under a certain target) in order to be valid.  Meaning the only way to find a valid account number is to perform a POW that takes maybe 10 seconds on your average PC to find one.  Would be a nice combination alongside the wallet.dat file.  You'd have to allow access to funds in legacy accounts but this could be considered the way to generate a special 'secure' account.  Or even be required after block number X.

[haitch]

Hey DEV is there a way to limit brute force wallet attacks while not inconveniencing legit wallet owner?

No

Problem is the public ledger, you can download the blockchain yourself and the formula for turning passwords into account numbers is known, so the attacker can brute force his own version of the database, then only use the 'good' passwords.  So no, not without some pretty significant changes.

What about adding a secondary passphrase? The primary one can't be changed, but it shouldn't be too difficult to add a secondary passphrase that can optionally be blank, and that can be changed.

The primary can't be changed because it's tied to the account number, the secondary can just be a suitably secure hash thats not tied to the account ID.

H.

[crowetic]

-[ANNOUNCEMENT]-

We have figured out the issue, it wasn't a "hack", but it was human error that caused the leak of the password.


Byte Enterprises assets are unaffected. The only one that is still currently affected, is ByteEnt, because I'm awaiting the return of the asset from the account that took it.

Once the assets that were taken have been returned, everything will go back to normal.



Sorry for the issue, I just wanted to make sure to be transparent and make sure everyone knew what was going on.


Once again, ALL BYTE ENTERPRISES ASSETS ARE UNAFFECTED BY THE ISSUE. The assets (as long as ByteEnt that were taken are returned) will payout as planned on the first of the month. Thanks!

[crowetic]

I do not read all thing about what happen since my english is limited but i am not sure now i want to buy more asset/share in ByteEnt.

*Effective Immediately, all ByteEnt and ByteBank asset payouts are paused while we figure out this issue.

No need to worry, I put things on pause for a minute while I figured it all out. It has been figured out and things will go back to normal.


If this had been something that affected things more long term, I would have made other adjustments. No matter what there is no reason to avoid Byte Enterprises' assets. It is all about the people behind them, and I would never rip anyone off.

Thank you.

[mczarnek]

Hey DEV is there a way to limit brute force wallet attacks while not inconveniencing legit wallet owner?

No

Problem is the public ledger, you can download the blockchain yourself and the formula for turning passwords into account numbers is known, so the attacker can brute force his own version of the database, then only use the 'good' passwords.  So no, not without some pretty significant changes.

What about adding a secondary passphrase? The primary one can't be changed, but it shouldn't be too difficult to add a secondary passphrase that can optionally be blank, and that can be changed.

The primary can't be changed because it's tied to the account number, the secondary can just be a suitably secure hash thats not tied to the account ID.

H.

Actually POW doesn't really make it any harder to crack..  so forget my idea.  The problem is that there already is a secure way to generate a password, use the built in password generator instead of inputting your own easy to crack password!

Yeah second password would work well.. maybe if there was a way to enter one password from one device and the second from the other device.  Also, if you lose one of those passwords(in other words haven't used it for 1 year or however long) then only one password is needed?

[haitch]

Hey DEV is there a way to limit brute force wallet attacks while not inconveniencing legit wallet owner?

No

Problem is the public ledger, you can download the blockchain yourself and the formula for turning passwords into account numbers is known, so the attacker can brute force his own version of the database, then only use the 'good' passwords.  So no, not without some pretty significant changes.

What about adding a secondary passphrase? The primary one can't be changed, but it shouldn't be too difficult to add a secondary passphrase that can optionally be blank, and that can be changed.

The primary can't be changed because it's tied to the account number, the secondary can just be a suitably secure hash thats not tied to the account ID.

H.

Actually POW doesn't really make it any harder to crack..  so forget my idea.  The problem is that there already is a secure way to generate a password, use the built in password generator instead of inputting your own easy to crack password!

Yeah second password would work well.. maybe if there was a way to enter one password from one device and the second from the other device.  Also, if you lose one of those passwords(in other words haven't used it for 1 year or however long) then only one password is needed?

I will defer to the developers, who are a damn sight smarter than me, to figure out the details; but to me adding a second level of security, that can be controlled by the account owner, seems like a no brainer to me.

POW is an interesting idea, in that it could stop brute forcing if you delay so many seconds between password attempt.

Two device authentication seems problematic to me - what if I want to make a transaction while mobile, and only have one device? What could be workable is devising a method to securely authorize a device to access the account. Use a second authorizing passphrase to authorize your mac address, which is stored as an account attribute in a hash. Authorized devices would need the account password, unauthorized devices could be temporarily or permanently authenticated by the use of a second level passphrase.

The time limit on a secondary password is also interesting. Lose your secondary password and in X time period it expires.Or maybe an AT to trigger a password reset to a registered email address after X blocks with no activity?

H.

[xizmax]

http://burstcoin.eu/transaction/16735348886334100917

Funds have been returned. This little ordeal is over now, thanks to all who helped resolve it.

Lesson to us all, stay frosty and try not to make mistakes.

[katlogic]

increasing the amount of work to verify a nonce should be for the average wallet user no real issue since there will also be checkpoints added.
for pools this may turn into a big challenge since most current pools seem to have already issues with the nonce verification under high load.
i tested it out and can say all pools except the dev2 one have them (if you run one of them pm me to share info about).

With current PoC settings, top of line CPUs can verify about 100 nonces/s, GPUs about 10k nonce/s (fancy private kernel). GPU and especially ASIC proofing involves raising the difficulty (hash arena size) by at least 1000 fold - which makes it 1 nonce every 10s on CPU, 10 nonce/s on GPU. Pools won't like that
(though they can use GPU to make it viable), but especially users syncing blockchain will see this as an inconvenience.

Current setting strikes a good balance between user friendlyness and ASIC resistance, but has no safe margin - again ballpark, if top of line GPU can mine as 600GB (with 240s deadline median), ASIC being 1000 times faster equals 600TB. But it will cost more than 600TB worth of drives, and use more power than 120x5TB drive (600W HDDs vs 1kW+ ASIC).

Beware that PoC2 works differently and ASIC and HDD work in synergy, not one replacing another.

what about a distributed pool feature as next big announcement? does any coin has one?

It wouldn't be that difficult to implement, however I'm not sure about demand for one though. As for alts with p2pool - all bitcoin codebase derived ones can implement one with no effort by adapting existing p2pool code.

i already thought of simply doing this using the at technology but it makes only sense for big miners due to the code execution fees.

Yes, p2pool is AT friendly. Note that winners of the round would pay fees to themselves (winning block includes the txes with payouts, with lengthy AT computation), so that wouldn't be an issue.

[MiningAtlas]

Can i mine this with my rig farm hard drives ? SSD ?

[blizzen1]

Yes, but probably SSD too small to make sense

[Merick]

http://burstcoin.eu/transaction/16735348886334100917

Funds have been returned. This little ordeal is over now, thanks to all who helped resolve it.

Lesson to us all, stay frosty and try not to make mistakes.

What does this mean?
Was there a theft and the thief had a change of heart?

Did BURST get accidentally sent to the wrong address and the receiver sent them back?

The origonal statement was that an account was hacked and the funds drained, did this not happen?

[xizmax]

http://burstcoin.eu/transaction/16735348886334100917

Funds have been returned. This little ordeal is over now, thanks to all who helped resolve it.

Lesson to us all, stay frosty and try not to make mistakes.

What does this mean?
Was there a theft and the thief had a change of heart?

Did BURST get accidentally sent to the wrong address and the receiver sent them back?

The origonal statement was that an account was hacked and the funds drained, did this not happen?

Passphrase to the account was accidentally leaked, there was no hack. Person who found the leaked passphrase was a victim of a hack themselves a while ago so they did this in effort to 'teach us a lesson' about security, as they were not fortunate enough to have their funds returned. The person is, apparently, a supporter of BURST and did not seem to approach this in a malicious way.

One could argue whether this kind of 'shock therapy' is the best way to approach security issues, but the issue at hand was successfully resolved and it served as a reminder to keep us on our toes when it comes to security.
We have all agreed to work together on improving BURST security both technologically and in improving our own diligence about our coins/passphrases.

[MiningAtlas]

32. is the smallest i have some bigger but i don't know how to calculate it 

[Blago]

[miner]

new version Burst-miner v1.150509
https://github.com/Blagodarenko/miner-burst/releases/download/1.150509/miner-burst-1.150509.zip

- solved memory usage issue
- parameter "UseCleanMem" did not used
- key "q" - quit/exit
- key "m" - memory cleaner
- new lib pdcurses.dll

limits:
Nonces, stagger and CacheSize must be a multiple of HDD's sector size / 64 ( 4096 by default / 64 = 64 ).
Miner's window not resizing and not scrolling.



https://github.com/Blagodarenko/miner-burst

[bitladen]

In my opinion.. short term, low prices are good, we need to attract more developers and entrepreneur types and let miners who are mining for short term profit go ahead and dump.. the more business and development minded people we get on board at these prices, the better long term.

I partially agree. Short term low prices are good, but as long as there is volume.  Haven't had any decent volume in ages. If people sell, but not make buy orders, it's not gonna happen. But I see the order book has increased slightly during this week

Please let the price fall down to 100 satoshi. At 100 satoshi i will place a 10 BTC buywall (and more BTC incoming if necessary).

Please?? Go ahead and dump, I'm buying.  Make action on the market, don't just sit and wait

[Grim]

[miner]

new version Burst-miner v1.150509
https://github.com/Blagodarenko/miner-burst/releases/download/1.150509/miner-burst-1.150509.zip

- solved memory usage issue
- parameter "UseCleanMem" did not used
- key "q" - quit/exit
- key "m" - memory cleaner
- new lib pdcurses.dll

limits:
Nonces, stagger and CacheSize must be a multiple of HDD's sector size / 64 ( 512 by default / 64 = 8 ).
Miner's window not resizing and not scrolling.



https://github.com/Blagodarenko/miner-burst

isn't 4kb sector size standard these days?

[Blago]

isn't 4kb sector size standard these days?

perhaps... All my HDDs have sector size = 512  
maybe i'm very old...  

https://en.wikipedia.org/wiki/Hard_disk_drive
"... the number of bytes per sector (most commonly 512)..."

ok, my post edited. Thank you, Grim!
https://support.microsoft.com/en-us/kb/140365