Bitcoin Forum
July 18, 2019, 06:19:07 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 [136] 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 ... 346 »
  Print  
Author Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer  (Read 449651 times)
This is a self-moderated topic. If you do not want to be moderated by the person who started this topic, create a new topic.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 23, 2016, 01:24:03 PM
 #2701

@coralreefer: pull request for a command line option to skip "renice" just submitted ;-)

Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild".
For serious testing, please wait for 0.7.1.

Hi hardworking people!

@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.

Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.

Keep up good work.

Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.

Code:
// Redeemer-Account is not allowed to do any transaction whatsoever
if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){
throw new NxtException.NotValidException(
"Redeem Account is not allowed to do anything.");
}
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1563473947
Hero Member
*
Offline Offline

Posts: 1563473947

View Profile Personal Message (Offline)

Ignore
1563473947
Reply with quote  #2

1563473947
Report to moderator
unvoid
Hero Member
*****
Offline Offline

Activity: 535
Merit: 500



View Profile
November 23, 2016, 01:33:46 PM
 #2702

@coralreefer: pull request for a command line option to skip "renice" just submitted ;-)

Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild".
For serious testing, please wait for 0.7.1.

Hi hardworking people!

@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.

Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.

Keep up good work.

Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.

Code:
// Redeemer-Account is not allowed to do any transaction whatsoever
if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){
throw new NxtException.NotValidException(
"Redeem Account is not allowed to do anything.");
}

Awesome. Hope this piece of code will remain rock solid Wink Thank you for clarification. I'm sure that if I had not asked that question someone sooner or later would have similar doubts.

Any info about your testnet peers from github config? Do they take incoming connections w/o any problems? Should I look on my side?

BTC: 1CMgHWx4wkAaAy2FfeCyPdedUExmhGhfi5
XEL: XEL-HCM8-KB6E-YFLK-8BWMF
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
November 23, 2016, 01:34:05 PM
 #2703

Hi EK,

I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.

Also, I fixed that "unknown request type" error you reported earlier.  Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 23, 2016, 01:39:20 PM
 #2704

Hi EK,

I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.

Also, I fixed that "unknown request type" error you reported earlier.  Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.

Runs smoothly, however, there is still a 5 second delay. And it's not the slow response time of the server. When you take a look at this:

Code:
[14:37:50] CPU1: Submitting POW Solution (000000CC23914E1AFDA22E46...) [t:000000FFFFFFFFFFFFFFFFFF...]
[14:37:55] CPU2: 815.21 kEval/s
[14:37:55] CPU1: 877.87 kEval/s
[14:37:55] CPU0: 860.86 kEval/s
[14:37:55] DEBUG: Submit request - http://127.0.0.1:6876/nxt?requestType=createPoX deadline=3&feeNQT=0&amountNQT=0&work_id=8543365767744104724&multiplicator=010000000000000000000000000000000000000000000000A22B4F26EED0F06C&is_pow=true&secretPhrase=test
[14:37:55] CPU1: ***** POW Accepted! *****
[14:37:55] DEBUG: Submit complete...deleting request

You see that the solution is found at 14:37:50, but the submit request is issued at 14.37:55.
I am also looking hard, but I did not identify the cause yet.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 23, 2016, 02:00:29 PM
 #2705

@coralreefer: I know the problem.

It is here:
Code:
new_block = check_new_block(curl);

Longpoll blocks (by design) at most 5 seconds until it times out when nothing happened. If something happens (like a new block) it returns an event earlier.
Maybe it's better to leave it in a separate thread?
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 23, 2016, 02:24:41 PM
 #2706

@coralreefer:

Found a serious bug in the miner  Wink

Take a look at that
Code:
// POW Solution Found
if ((swap32(hash32[0]) <= g_pow_target[0]) && swap32(hash32[1]) <= g_pow_target[1])
rc = 2;
else
rc = 0;

I think that this check throws away a great deal of valid solutions into the trash can.

What if the target is:
Code:
000000cc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc

And our solution has the perfectly right hash:
Code:
000000aa ffcccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc

It won't make it through the check, will it?

mr.coinzy
Hero Member
*****
Offline Offline

Activity: 504
Merit: 507



View Profile
November 23, 2016, 02:39:22 PM
 #2707

I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
November 23, 2016, 02:47:48 PM
 #2708

@coralreefer:

Found a serious bug in the miner  Wink

Take a look at that
Code:
// POW Solution Found
if ((swap32(hash32[0]) <= g_pow_target[0]) && swap32(hash32[1]) <= g_pow_target[1])
rc = 2;
else
rc = 0;

I think that this check throws away a great deal of valid solutions into the trash can.

What if the target is:
Code:
000000cc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc

And our solution has the perfectly right hash:
Code:

000000aa ffcccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc

It won't make it through the check, will it?



Good catch, I'll fix this and throw longpoll back into it's own thread.  I originally consolidated it as I thought it was causing an issue, but i've since found the root cause of that issue and is fixed in the latest on github.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 23, 2016, 02:48:22 PM
 #2709

I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.

Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.

I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.

I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.
coralreefer
Sr. Member
****
Offline Offline

Activity: 465
Merit: 260


View Profile
November 23, 2016, 03:27:48 PM
 #2710

EK, I've moved longpoll back to it's own thread.  Please let me know if you find any other issues.

Edit:  I still have to add some additional error handling as well as some general cleanup, so feel free to offer suggestions if you see a way to improve something.  It's still very much a work in progress.
mr.coinzy
Hero Member
*****
Offline Offline

Activity: 504
Merit: 507



View Profile
November 23, 2016, 03:43:55 PM
 #2711

I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.

Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.

I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.

I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.

I really appreciate your time and effort spent trying to find a solution into this matter. I think it could give a very tangible feature for the users to enable them to have real life / realtime information regarding profitability of using a product like elastic. At the end of the day people are gonna be selling their computational power to generate profit and the easier it is to know where is your cut off point for profit the better.
I tried to find a reliable method for this measurement in the past but didnt find something convincing...
If anyone has any idea about it, it could be highly useful to add to the elastic client.


tomkat
Hero Member
*****
Offline Offline

Activity: 1022
Merit: 507


View Profile
November 23, 2016, 04:12:42 PM
Last edit: November 23, 2016, 05:12:28 PM by tomkat
 #2712

I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.

Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.

I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.

I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.


I really appreciate your time and effort spent trying to find a solution into this matter. I think it could give a very tangible feature for the users to enable them to have real life / realtime information regarding profitability of using a product like elastic. At the end of the day people are gonna be selling their computational power to generate profit and the easier it is to know where is your cut off point for profit the better.
I tried to find a reliable method for this measurement in the past but didnt find something convincing...
If anyone has any idea about it, it could be highly useful to add to the elastic client.




Not sure if it wil be of any use for you, but Intel has something like this
https://software.intel.com/en-us/articles/intel-power-gadget-20
which is able to log CPU power to an external file.

Obviously it's limited to Intel's CPUs only, so graphic cards, and other mining equipment won't b possible.
Additionaly CPU is rather bad idea for mining, however, it would be something ... for the start Smiley

On the other hand, I think it's pure waste of time at this stage.
The current development should be focused on launching the mainnet + initial distribution.
Once the mainnet is live with no major issues, we can start thinking on additional features.
MiningSev0
Full Member
***
Offline Offline

Activity: 205
Merit: 105

Old Account was Sev0 (it was hacked)


View Profile
November 24, 2016, 05:35:55 AM
 #2713

Obviously it's limited to Intel's CPUs only, so graphic cards, and other mining equipment won't b possible.
Additionaly CPU is rather bad idea for mining, however, it would be something ... for the start Smiley

For the long run - I'm not a coder - but a medical-engenieer (and so an electronics-guy) and as far i know the CPU is the only Processing-Unit which is able to run all processes - slower than other propietary devices but most flexible.
You can't know before the Mainnet lauch what our main-usecase would be ("cusomers decide") - so we aren't able to know if a gpu miner for these funcions would be possible.

Correct me if i'm wrong.

ttookk
Hero Member
*****
Offline Offline

Activity: 966
Merit: 513


View Profile
November 24, 2016, 08:22:15 AM
 #2714

Ok, stupid question:

If there are methods to effectively monitor power usage, wouldn't miners use them already? I mean, it's in their best interest to monitor this anyway, no matter what they mine.
Evil-Knievel
Legendary
*
Offline Offline

Activity: 1274
Merit: 1160



View Profile
November 24, 2016, 08:28:32 AM
 #2715

MiningSev: I think a GPU miner is trivial, at least for the current version of the ElasticPL language and if we (for now) leave out the special crypto functions. Maybe, if I find some time, I can create a variant of coralreefers xel_miner which compiles "OpenCL" code and executes it inside its "execute_vm" function instead of running the compiled program on the CPU.
unvoid
Hero Member
*****
Offline Offline

Activity: 535
Merit: 500



View Profile
November 24, 2016, 08:31:22 AM
Last edit: November 24, 2016, 08:51:56 AM by unvoid
 #2716

Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.

BTC: 1CMgHWx4wkAaAy2FfeCyPdedUExmhGhfi5
XEL: XEL-HCM8-KB6E-YFLK-8BWMF
Ghoom
Full Member
***
Offline Offline

Activity: 170
Merit: 100


View Profile
November 24, 2016, 09:21:05 AM
 #2717

Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.

No (testing with 0.7.1).

Code:
No peers found.

Ps:

And it's confusing to do "java -jar target/elastic-core-0.6.0.jar" for launch 0.7.1
anhpt192
Hero Member
*****
Offline Offline

Activity: 629
Merit: 500



View Profile
November 24, 2016, 10:30:50 AM
 #2718

Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.

i'm running wallet 0.7.0, it is downloading blockchain (60 blocks left)  Grin
is that fine?



             ▄█
            ██  ██
           ██  ████
          ██  ██  ██
         ██  ██    ██
        ██  ██  ██  ██
       ██  ██    ██  ██
      ██  ██  ██  ██  ██
     ██  ██  ████  ██  ██
    ██  ██  ██  ██  ██  ██
   ██  ██  ██    ██  ██  ██
  ██  ██  ██████████  ██  ██
 ██                    ██  ██
█████████████████████▄  ██  █
                         ██
▀███████████████████████████




█████ █   █ █████      ███          █████████████▄▄    ████            ████     ▄▄██████████      ▄▄██████████
  █   █   █ █         █████         ████████████████    ████          ████     █████████████     █████████████
  █   █████ █████    ███████        ███         ▀███     ████        ████     ███▀              ███▀
  █   █   █ █        ███ ███        ███          ███      ████      ████      ███               ███
  █   █   █ █████   ███   ███       ███          ███       ████    ████       ███               ███
                    ███   ███       ███         ▄███        ████  ████        ███▄              ███▄
                   ███     ███      ██████████████▀          ████████          ██████████▄▄      ██████████▄▄
                   ███     ███      ██████████████▄           ██████            ▀▀██████████      ▀▀██████████
                  ███       ███     ███         ▀███           ████                      ▀███              ▀███
                  █████████████     ███          ███           ████                       ███               ███
                 ███████████████    ███          ███           ████                       ███               ███
                 ███         ███    ███         ▄███           ████                      ▄███              ▄███
                ███           ███   ████████████████           ████           ██████████████    ██████████████
                ███           ███   █████████████▀▀            ████           ███████████▀▀     ███████████▀▀

█  █
█  █
█  █
█  █
█  █
█▄▄
▀▀█
█  █
█  █
█  █
█  █
█  █

█  █
█  █
█  █
█  █
█  █
█▄▄
▀▀█
█  █
█  █
█  █
█  █
█  █
.PRE-SALE▬.... Nov 29 2017
.TOKEN SALE. Dec 12 2017

ANN Thread  ■  Whitepaper
■  Twitter
■  Telegram
■  Facebook
chinadaye
Member
**
Offline Offline

Activity: 85
Merit: 10


View Profile
November 24, 2016, 01:36:37 PM
 #2719

Public nodes updated to 0.7.1

Powerful EK, Pandora's Box is about to open, EK will be in the history of the block chain to leave a brilliant footprint

Join the Elastic revolution!  Elastic - The Decentralized Supercomputer
ELASTIC WEBSITE | ANNOUNCEMENT THREAD | ELASTIC SLACK | ELASTIC FORUM
wwdz99
Sr. Member
****
Offline Offline

Activity: 245
Merit: 250



View Profile
November 24, 2016, 02:39:40 PM
 #2720

Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.

Compile from source and running wallet 0.7.0 fine.
Pages: « 1 ... 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 [136] 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 ... 346 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!