[ANN][XEL] Elastic Project - The Decentralized Supercomputer

[ttookk]

(…)

Password is

Code:

NoDaddyNotToday

exactly the way it is written

I expected at least a Monty Python reference.

[1713413380]

1713413380

[1713413380]

1713413380

[1713413380]

1713413380

[1713413380]

1713413380

[Evil-Knievel]

I expected at least a Monty Python reference.

Good idea, we should save that one for the main version 

[BTCspace]

@EK as a part of a bug bounty please post at public passphrase (aka private key) to XEL-9HQ9-BXCV-TARZ-BRDNA account. We want to test if we can spend/forge/do anything with this account. As all of you know this account is used for redeem XEL to original donators. This address also need to be secured for a lot of attack factors. I know that this address could (and will change) when mainnet will be live but we need to be sure that this address is bulletproof before mainnet (and logic/code is in place before then).

Thanks! I'll test this address as soon as you post passphrase for this account.

Password is

Code:

NoDaddyNotToday

exactly the way it is written

nice password.

Should be longer.

[coralreefer]

EK, can you check if the Elliptic Curve algo is wired in correctly to the java ElasticPL code.  For example, when I run the following program and look at the VM memory in the debugger, xel_miner updates the VM memory with the right PK, but I don't think the java code is getting the correct PK.

Code:

m[100] = 371591043;
m[101] = 3825931891;
m[102] = 376660522;
m[103] = 3366301765;
m[104] = 4231963823;
m[105] = 1895245811;
m[106] = 4192807901;
m[107] = 975035458;
SECP256K1PrivToPub 100 true;
verify (m[20]==10);

The PK I expect to see is:  0282006E9398A6986EDA61FE91674C3A108C399475BF1E738F19DFC2DB11DB1D28

Note to others:  we will need help testing the various crypto functions supported by ElasticPL to ensure they are all working correctly.

[HomoHenning]

Hi will you have any countdown for launch ?

christmas?

[me1507]

Hi will you have any countdown for launch ?

christmas?

Hope this the best Christmas gift to all of us 

[logictense]

Just hover around the feeders hand, he will grant u free tokens soon or late. Additionally, I think the video will illustrate how the tokens will be distributed. Most likely through faucet. Thought i died a month ago.

[Evil-Knievel]

Just hover around the feeders hand, he will grant u free tokens soon or late. Additionally, I think the video will illustrate how the tokens will be distributed. Most likely through faucet. Thought i died a month ago.

Hi and welcome! Just out of pure curiosity: which video and which faucet do you exactly refer to?

[Evil-Knievel]

@coralreefer, I will have the SECP bug fixed by tomorrow.

[Evil-Knievel]

Does anyone of you guys know if there are any efficient homomorphic encryption schemes out there? Would be a nice to have, ain't it?

Maybe some easy Paillier system for now? But then we need a BigInteger functionality, working on our M array, allowing to perform calculations of big integers spread across multiple consecutive integers.

[ttookk]

Does anyone of you guys know if there are any efficient homomorphic encryption schemes out there? Would be a nice to have, ain't it?

Maybe some easy Paillier system for now? But then we need a BigInteger functionality, working on our M array, allowing to perform calculations of big integers spread across multiple consecutive integers.

Agreed

A homomorphic encryption option would not only be nice, but could be pretty much mandatory at some point in the future. Not necessarily at the beginning, but it looks like privacy is becoming an important factor in evaluating a blockchain technology. Now, this may be a fad, but I don't think so. If you can provide privacy with little to no downsides (probably not gonna happen here; I expect homomorphic encryption to slow down computation considerably), it will be considered not as a bonus, but as a given, with every technology not having it being viewed as inferior.

I'm not sure, whether this needs to be implemented directly, though. Does it? Or can this be decided on the job authors side, or does the miner need to be prepared for dealing with it?


Small off-topic:
now that I have langtons ant running (although it is running on a cylindric map ) in C++, I need a new challenge. Any ideas (something easy, of course)?

Is there going to be a bounty for finding out the mainnet genesis address password? Monty Python may be enough of a hint

EDIT: Three fucking winkey smilies. This is a new low. I'm off emoticons for a while. Cold turkey.

[graviteta]

EK, a man like Walter White.

[Evil-Knievel]

Is there going to be a bounty for finding out the mainnet genesis address password? Monty Python may be enough of a hint

It will be closely related to Monty Python  

[ttookk]

(…)

Maybe some easy Paillier system for now? But then we need a BigInteger functionality, working on our M array, allowing to perform calculations of big integers spread across multiple consecutive integers.

Ok, I guess this answers my question about homomorphic encryption option having to be built into the miner itself (or at least creating an enviroment, in which this is possible).

I actually understood like ten percent of that. Makes me prouder than it should.  

[coralreefer]

Maybe some easy Paillier system for now? But then we need a BigInteger functionality, working on our M array, allowing to perform calculations of big integers spread across multiple consecutive integers.

I think adding BigInteger functionality would be pretty straightforward.  Let me know if you want to head down this direction and I'll update the miner accordingly...although I hope this is after mainnet  

Edit:  I looked at the Paillier cryptosystems and it definitely looks doable.  I did see some references that it's not fully homomorphic, but I'm not clear on what the gaps are.

[Evil-Knievel]

EK, can you check if the Elliptic Curve algo is wired in correctly to the java ElasticPL code.  For example, when I run the following program and look at the VM memory in the debugger, xel_miner updates the VM memory with the right PK, but I don't think the java code is getting the correct PK.

Code:

m[100] = 371591043;
m[101] = 3825931891;
m[102] = 376660522;
m[103] = 3366301765;
m[104] = 4231963823;
m[105] = 1895245811;
m[106] = 4192807901;
m[107] = 975035458;
SECP256K1PrivToPub 100 true;
verify (m[20]==10);

The PK I expect to see is:  0282006E9398A6986EDA61FE91674C3A108C399475BF1E738F19DFC2DB11DB1D28

Note to others:  we will need help testing the various crypto functions supported by ElasticPL to ensure they are all working correctly.

It's no bug, it's a coding error! ;-)
3825931891 for example is not an integer!

Use thise, and then it works ;-9

Code:

[DEBUG] Took byte array: 16260783E40B16731673622AC8A5B045FC3EA4AF70F727F3F9E92BDD3A1DDC42
[DEBUG] Putting bytes back to state: 0282006E9398A6986EDA61FE91674C3A108C399475BF1E738F19DFC2DB11DB1D28

Code:

m[100] = 371591043;
m[101] = -469035405;
m[102] = 376660522;
m[103] = -928665531;
m[104] = -63003473;
m[105] = 1895245811;
m[106] = -102159395;
m[107] = 975035458;
SECP256K1PrivToPub 100 true;
verify (m[20]==10);

Maybe we should allow HEX input to avoid confusion!? For now, I have changed elastic editor to support HEX output! Its runnable out of IntelliJ IDEA for now! Works with MVN as well!

[BTCspace]

So right now we are at the open test phase?

who will do the code review?

[ImI]

So right now we are at the open test phase?

who will do the code review?

HMC?

[HomoHenning]

So right now we are at the open test phase?

who will do the code review?

everbody who want I guess

[coralreefer]

EK, can you check if the Elliptic Curve algo is wired in correctly to the java ElasticPL code.  For example, when I run the following program and look at the VM memory in the debugger, xel_miner updates the VM memory with the right PK, but I don't think the java code is getting the correct PK.

Code:

m[100] = 371591043;
m[101] = 3825931891;
m[102] = 376660522;
m[103] = 3366301765;
m[104] = 4231963823;
m[105] = 1895245811;
m[106] = 4192807901;
m[107] = 975035458;
SECP256K1PrivToPub 100 true;
verify (m[20]==10);

The PK I expect to see is:  0282006E9398A6986EDA61FE91674C3A108C399475BF1E738F19DFC2DB11DB1D28

Note to others:  we will need help testing the various crypto functions supported by ElasticPL to ensure they are all working correctly.

It's no bug, it's a coding error! ;-)
3825931891 for example is not an integer!

Use thise, and then it works ;-9

Code:

[DEBUG] Took byte array: 16260783E40B16731673622AC8A5B045FC3EA4AF70F727F3F9E92BDD3A1DDC42
[DEBUG] Putting bytes back to state: 0282006E9398A6986EDA61FE91674C3A108C399475BF1E738F19DFC2DB11DB1D28

Code:

m[100] = 371591043;
m[101] = -469035405;
m[102] = 376660522;
m[103] = -928665531;
m[104] = -63003473;
m[105] = 1895245811;
m[106] = -102159395;
m[107] = 975035458;
SECP256K1PrivToPub 100 true;
verify (m[20]==10);

Maybe we should allow HEX input to avoid confusion!? For now, I have changed elastic editor to support HEX output! Its runnable out of IntelliJ IDEA for now! Works with MVN as well!

Thanks EK, that explains it...I dumped the data as an unsigned int instead of int.  I think HEX input would be helpful as a user, you wouldn't want to have to convert all your unsigned inputs to signed inputs, so if you decide to change the core server to support HEX, please let me know as I'll need to update the C parser as well....but once again....something that can probably wait for after mainnet launch