1697 replies to this topic

[bauen1]

nayrnayr1, on 15 February 2016 - 05:56 PM, said:

When does it update the database and I get my minecraft money?

Most miners tell you when you mined a block, 12 (or more) krist are then immediately transferred to your account.

[___]

It says last block updated but I have none.

bauen1, on 15 February 2016 - 05:58 PM, said:

nayrnayr1, on 15 February 2016 - 05:56 PM, said:

When does it update the database and I get my minecraft money?

Most miners tell you when you mined a block, 12 (or more) krist are then immediately transferred to your account.

It says last block updated but I have none. I have done more than 12 blocks.

[bauen1]

nayrnayr1, on 15 February 2016 - 06:01 PM, said:

It says last block updated but I have none.

last block updated says someone else got the block, it usually says 'solved' somewhere when you mine one, have pation, it could take multiple hours.

[___]

bauen1, on 15 February 2016 - 06:02 PM, said:

nayrnayr1, on 15 February 2016 - 06:01 PM, said:

It says last block updated but I have none.

last block updated says someone else got the block, it usually says 'solved' somewhere when you mine one, have pation, it could take multiple hours.

Successfully Submitted, you are correct.

[bauen1]

Btw, could we get a static (no web socket, no fancy updating) page for Lottery, because it doesn't work on my mobile device (iPad)

[Lemmmy]

bauen1, on 15 February 2016 - 06:05 PM, said:

Btw, could we get a static (no web socket, no fancy updating) page for Lottery, because it doesn't work on my mobile device (iPad)

Suggest this at the KLottery thread.

[apemanzilla]

Tron, on 15 February 2016 - 05:42 PM, said:

Are v2 addresses really safe? Just on an 8-core cloud server I get 600 thousand addresses (Not really a full address, since I only calculate part of the address to check if it matches) per second, which when put into this site http://calc.opensecurityresearch.com/ says would take about 6 years to crack, if you estimate a 100x speedup using a GPU it would only take about 20 days to crack an address

Edit: Forgot to mention I got 8 MA/S when I used a 32 core AWS server.

There won't be much of a speedup, if any, when using GPUs to crack Krist addresses. In fact, it would probably just slow down cracking. Why? Because of the way graphics cards work.

GPUs are very good at doing the same thing on a lot of data. For example, if you have a list of numbers and you want to add 1 to each item in the list, on a CPU you would have to iterate over the entire array and add 1 each time. On a GPU, you can simply add 1 to the entire array almost simultaneously - each of the 1000+ cores on the GPU will add 1 to a specific item in the array.

One limitation, however, is that the cores have to be doing the same thing, just on different data. One core cannot be adding while the rest are multiplying. This is fine for things like mining, you're doing the exact same operations each time, on different data.

However, when generating krist addresses, there are variable length loops. This means that, for some addresses, it will take more iterations of the loops than others. This is VERY bad on a GPU - if one core needs to loop extra times, ALL the cores must stop and wait for it before moving on to the next address.

Additionally, graphics cards are EXTREMELY slow (compared to CPUs) when you are performing comparisons or branching - so if statements are very slow. And generating a v2 address requires 2 if statements and multiple comparisons.

And don't forget about double vaults either - they are much more secure than regular addresses.

Creator, on 15 February 2016 - 05:43 PM, said:

How difficult would it be to make an ASIC miner? (Or however that special box is called.)

Well, you'd have to create the chips yourself and everything. Have fun with that.

Edited by apemanzilla, 15 February 2016 - 06:22 PM.

[Tron]

apemanzilla, on 15 February 2016 - 06:22 PM, said:

There won't be much of a speedup, if any, when using GPUs to crack Krist addresses. In fact, it would probably just slow down cracking. Why? Because of the way graphics cards work.

GPUs are very good at doing the same thing on a lot of data. For example, if you have a list of numbers and you want to add 1 to each item in the list, on a CPU you would have to iterate over the entire array and add 1 each time. On a GPU, you can simply add 1 to the entire array almost simultaneously - each of the 1000+ cores on the GPU will add 1 to a specific item in the array.

One limitation, however, is that the cores have to be doing the same thing, just on different data. One core cannot be adding while the rest are multiplying. This is fine for things like mining, you're doing the exact same operations each time, on different data.

However, when generating krist addresses, there are variable length loops. This means that, for some addresses, it will take more iterations of the loops than others. This is VERY bad on a GPU - if one core needs to loop extra times, ALL the cores must stop and wait for it before moving on to the next address.

Additionally, graphics cards are EXTREMELY slow (compared to CPUs) when you are performing comparisons or branching - so if statements are very slow. And generating a v2 address requires 2 if statements and multiple comparisons.

And don't forget about double vaults either - they are much more secure than regular addresses.

First off, double vaults are just regular addresses to the Krist server and so are as easy/hard to crack.
Secondly, until the protein is created all the GPU cores would do the same thing, and almost all addresses can be discarded after this step, any remaining addresses can be safely and quickly calculated by the CPU.

GPU pseudocode

	masterkey = "string" + nonce
	protein = []
	stick = sha256(sha256(master_key))
	n = 0
	result_addr = "k"
	while n < 9:
		protein.append(stick[0:2])
		stick = sha256(sha256(stick))
		n = n+1

Edited by Tron, 15 February 2016 - 06:34 PM.

[bauen1]

Well i guess its best to spread your krist to multiple addresses.
So if the work goes low enough that its better to mine for addresses (using cpu or gpu) we are gonna have a problem

Edited by bauen1, 15 February 2016 - 06:46 PM.

[apemanzilla]

Tron, on 15 February 2016 - 06:31 PM, said:

apemanzilla, on 15 February 2016 - 06:22 PM, said:

There won't be much of a speedup, if any, when using GPUs to crack Krist addresses. In fact, it would probably just slow down cracking. Why? Because of the way graphics cards work.

GPUs are very good at doing the same thing on a lot of data. For example, if you have a list of numbers and you want to add 1 to each item in the list, on a CPU you would have to iterate over the entire array and add 1 each time. On a GPU, you can simply add 1 to the entire array almost simultaneously - each of the 1000+ cores on the GPU will add 1 to a specific item in the array.

One limitation, however, is that the cores have to be doing the same thing, just on different data. One core cannot be adding while the rest are multiplying. This is fine for things like mining, you're doing the exact same operations each time, on different data.

However, when generating krist addresses, there are variable length loops. This means that, for some addresses, it will take more iterations of the loops than others. This is VERY bad on a GPU - if one core needs to loop extra times, ALL the cores must stop and wait for it before moving on to the next address.

Additionally, graphics cards are EXTREMELY slow (compared to CPUs) when you are performing comparisons or branching - so if statements are very slow. And generating a v2 address requires 2 if statements and multiple comparisons.

And don't forget about double vaults either - they are much more secure than regular addresses.

First off, double vaults are just regular addresses to the Krist server and so are as easy/hard to crack.
Secondly, until the protein is created all the GPU cores would do the same thing, and almost all addresses can be discarded after this step, any remaining addresses can be safely and quickly calculated by the CPU.

GPU pseudocode

	masterkey = "string" + nonce
	protein = []
	stick = sha256(sha256(master_key))
	n = 0
	result_addr = "k"
	while n < 9:
		protein.append(stick[0:2])
		stick = sha256(sha256(stick))
		n = n+1

The 'password' for double vaults is much longer than a normal address, however.

Additionally, on a GPU you would be generating somewhere in the realm of ~2000 krist addresses per cycle. The problem is that if any one of those addresses takes more loops than usual, ALL of the other cores have to stop and wait for it to finish. Not to mention there are a lot of comparisons and branching, which also slow down generation a lot.

There's also no 'string' object for GPUs. Minor inconvenience.

And finally, GPU code is an absolute pain in the arse. Difficult to write, difficult to debug, difficult to use, and extremely verbose. I would know as I had to write, from scratch, a SHA256 implementation in OpenCL. You're more than welcome to try to write an address cracker for the GPU, but I highly doubt you will get anything out of it. And in the end, it's just Krist.

Edited by apemanzilla, 15 February 2016 - 06:51 PM.

[Tron]

apemanzilla, on 15 February 2016 - 06:50 PM, said:

The 'password' for double vaults is much longer than a normal address, however.

Additionally, on a GPU you would be generating somewhere in the realm of ~2000 krist addresses per cycle. The problem is that if any one of those addresses takes more loops than usual, ALL of the other cores have to stop and wait for it to finish. Not to mention there are a lot of comparisons and branching, which also slow down generation a lot.

There's also no 'string' object for GPUs. Minor inconvenience.

And finally, GPU code is an absolute pain in the arse. Difficult to write, difficult to debug, difficult to use, and extremely verbose. I would know as I had to write, from scratch, a SHA256 implementation in OpenCL. You're more than welcome to try to write an address cracker for the GPU, but I highly doubt you will get anything out of it. And in the end, it's just Krist.

I just want to say you are completely right, coding a GPU miner address cracker would be very difficult and will likely never be done, I just wanted to point out the theoretical possibility of a GPU miner address cracker.
Secondly, and I've mentioned this before, when brute forcing and address I'd assume you will not find the original password, but one that makes a collision with the real one, I've demonstrated a few posts back the collisions do exist with v2 addresses. Once your password is beyond ~20 characters the original doesn't really matter for brute forcing, what collides with the address does.
Finally, the GPU code would not really do more loops, the same code would be executed, an address cracker would likely save the final loop that determines placement of characters for addresses with a protein containing only characters that are in the address being cracked for the CPU.

Edited by Tron, 15 February 2016 - 07:08 PM.

[apemanzilla]

Tron, on 15 February 2016 - 07:00 PM, said:

apemanzilla, on 15 February 2016 - 06:50 PM, said:

The 'password' for double vaults is much longer than a normal address, however.

Additionally, on a GPU you would be generating somewhere in the realm of ~2000 krist addresses per cycle. The problem is that if any one of those addresses takes more loops than usual, ALL of the other cores have to stop and wait for it to finish. Not to mention there are a lot of comparisons and branching, which also slow down generation a lot.

There's also no 'string' object for GPUs. Minor inconvenience.

And finally, GPU code is an absolute pain in the arse. Difficult to write, difficult to debug, difficult to use, and extremely verbose. I would know as I had to write, from scratch, a SHA256 implementation in OpenCL. You're more than welcome to try to write an address cracker for the GPU, but I highly doubt you will get anything out of it. And in the end, it's just Krist.

I just want to say you are completely right, coding a GPU miner would be very difficult and will likely never be done, I just wanted to point out the theoretical possibility of a GPU miner.
Secondly, and I've mentioned this before, when brute forcing and address I'd assume you will not find the original password, but one that makes a collision with the real one, I've demonstrated a few posts back the collisions do exist with v2 addresses. Once your password is beyond ~20 characters the original doesn't really matter for brute forcing, what collides with the address does.
Finally, the GPU code would not really do more loops, the same code would be executed, an address cracker would likely save the final loop that determines placement of characters for addresses with a protein containing only characters that are in the address being cracked for the CPU.

Just want to point out that you said a GPU miner will never be created...

[Tron]

apemanzilla, on 15 February 2016 - 07:02 PM, said:

Tron, on 15 February 2016 - 07:00 PM, said:

apemanzilla, on 15 February 2016 - 06:50 PM, said:

The 'password' for double vaults is much longer than a normal address, however.

Additionally, on a GPU you would be generating somewhere in the realm of ~2000 krist addresses per cycle. The problem is that if any one of those addresses takes more loops than usual, ALL of the other cores have to stop and wait for it to finish. Not to mention there are a lot of comparisons and branching, which also slow down generation a lot.

There's also no 'string' object for GPUs. Minor inconvenience.

And finally, GPU code is an absolute pain in the arse. Difficult to write, difficult to debug, difficult to use, and extremely verbose. I would know as I had to write, from scratch, a SHA256 implementation in OpenCL. You're more than welcome to try to write an address cracker for the GPU, but I highly doubt you will get anything out of it. And in the end, it's just Krist.

I just want to say you are completely right, coding a GPU miner would be very difficult and will likely never be done, I just wanted to point out the theoretical possibility of a GPU miner.
Secondly, and I've mentioned this before, when brute forcing and address I'd assume you will not find the original password, but one that makes a collision with the real one, I've demonstrated a few posts back the collisions do exist with v2 addresses. Once your password is beyond ~20 characters the original doesn't really matter for brute forcing, what collides with the address does.
Finally, the GPU code would not really do more loops, the same code would be executed, an address cracker would likely save the final loop that determines placement of characters for addresses with a protein containing only characters that are in the address being cracked for the CPU.

Just want to point out that you said a GPU miner will never be created...

Meant to say a GPU address miner/cracker, sorry.

Edited by Tron, 15 February 2016 - 07:13 PM.

[bauen1]

If the work gets to the point where it should take multiple hours to get a block with available tools, krist will not get so much popularity as people aren't able to get a decent amount of krist and people might start mining for addresses.
Addresses which are generated using KVanity can also get generate again using KVanity, making it faster because it only uses some characters. (This is for addresses like yours (Your funds still "have" to go through your real address using a double vault, so an attacker could automatically check and transfer any money that gets in there.))

Edited by bauen1, 15 February 2016 - 07:23 PM.

[Tron]

bauen1, on 15 February 2016 - 07:21 PM, said:

If the work gets to the point where it should take multiple hours to get a block with available tools, krist will not get so much popularity as people aren't able to get a decent amount of krist and people might start mining for addresses.
Addresses which are generated using KVanity can also get generate again using KVanity, making it faster because it only uses some characters. (This is for addresses like yours (Your funds still "have" to go through your real address using a double vault, so an attacker could automatically check and transfer any money that gets in there.))

I am by no means an expert on KVanity but I believe it includes the option of a prefix and probably uses enough characters that it will not often use the same key while looking for a vanity address, and I find it highly unlikely it will output the same vanity address multiple times.

[bauen1]

It uses no random generator meaning that if given the same arguments, it should produce the same results, as the arguments you can use the target address as the prefix.
It also only uses A-Z and 0-9 for the password in the generation process.
Now use KVanity with

java -jar kvanity.jar -p k5ztameslf

It should produce the same results (and the same cpu cycle used).

Example explaining the above:

-- The Programm uses no random gen and when given a number for arg it will always produce the same output for the same argument
print (arg + 1)
-- This Programm uses a random generator and 'should' output different results for the same number for arg
print (arg + math.random ())

For the geeks:
This also applies to most random generators, give it a seed and the output of the next random calculation is always the same

Edited by bauen1, 15 February 2016 - 07:39 PM.

[___]

Anyone want to donate to me?
Feeling generous:
k38gq88ehl

[___]

I am going to set up my own cluster and post what I get on that. Should take a little while...

[bauen1]

There is an internal server error displayed, maybe related to the latest update.

[Lemmmy]

bauen1, on 15 February 2016 - 07:53 PM, said:

There is an internal server error displayed, maybe related to the latest update.

That's me working on something new, that will be fixed when I push the latest changes to git.