Regarding exchanges and nodes running on exchanges: Wouldn't it be possible to have a node that is detached from any work done and just uses basic functionality like receive/send? Why is it necessary that an exchange also processes XEL-jobs?
Simply because that's the current design that's in git. We'll have to wait to hear back from EK but your proposal may be a quicker/easier solution for exchanges than trying to rush the SN work. But unlike most here, I'm not concerned about launching or getting on exchanges...I am more interested on what is the best solution for xel to be able to work as a decentralized super-computer. Would it be possible to add "a switch" that could be used to not accept jobs to be processed by a node? The exchanges could use wallet features only, and we could continue working on developing SNs. |
|
|
|
-No progress in development - I wouldn't be surprised if they decided to do it all again from scratch :-)
Such statements are completely false. Anyone can track the development on GitHub https://github.com/LiskHQAha, so your advice is to track the development? Cool, let's track it... if all of us will start tracking the development, then the market will believe in Lisk again. Since you seem to believe they've done so well, tell me please why is it so bad ? I have only responded to your extremely stupid statement "no progress in development" Many factors are responsible for the current price, logical. But the fact is, your sentence was stupid. Thank you |
|
|
|
-No progress in development - I wouldn't be surprised if they decided to do it all again from scratch :-)
Such statements are completely false. Anyone can track the development on GitHub https://github.com/LiskHQAha, so your advice is to track the development? Cool, let's track it... if all of us will start tracking the development, then the market will believe in Lisk again. Since you seem to believe they've done so well, tell me please why is it so bad ? |
|
|
|
Yeah lisk is the worst project 2017 lose a lots of money in this project
Hadn't kept an eye on Lisk for a while - the price is sub 10k on Polo, normally i'd be buying - but not feeling it with Lisk. Still holding the coins I have - only time will tell if that's a good idea or not. How come the price has gone down so dramatically? Is it the inflation from forging? How is the dapp development coming along? -Terrible DPoS system -Forging started -Bad communication with the market -No progress in development - I wouldn't be surprised if they decided to do it all again from scratch :-) |
|
|
|
|
Guys, compiled elastic-pl and elastic-core from github.
Wallet works fine, but can't sync the blockchain - I guess there're no peers and/or SNs, right?
Are we ready for testing...?
|
|
|
|
so you will only be sold on the exchange and after that go to bring BTC without redemption, so?
well, as I just said, we will get our %, but dracshares holders too. at the begining it will be like this:94% to exchanges 6% team + users profits from this 94% will be distributed like this:6% will represent now the 100%= 600.000 (as all the dracshare holders will have tokens from this 6%), so: If you have 1 dracshare, it will be 0.00016% of the profits from the 94% sold. I'm not sure if I get it correctly: -you're going to sell 94% of the initial supply on exchanges, and then -start generating profits out of the collected BTC -distribute the profits to holders of 600k coins (which will become 100% of total shares) Questions: -if 600k shares will become 100% of the total share, then what will be the 94% sold to exchanges ? -what will be the incentive to buy the 94%? -how are you going to generate the profits? |
|
|
|
What are you trying to improve in cryptocurrency space with your new coin? Do you mean that other alts are not safe? How can you reach daily use if even Bitcoin doesn't?
first of all, having instant transactions, and not 30 hours of delay  we try to solve this and also volatility, feel free to read our WP and join us at slack to talk to the devs How are you going to "solve" volatility...? |
|
|
|
No ICO but will be sent directly to exchanges? What does that mean?
It means that you will receive bounties if you join us at slack, and that you would be able to sell the XDRAC to the exchange that first accept us. If you want to sell, ofc.. you can always hold haha Damn, my brain is crashing, 100 people with 0,1 free token = 10 tokens, its a 10M tokens in total cmon haha, free tokens just to join us at slack... XD however it is the first bountie, we will add more once we have more people. XDRAC won't be cheap... Even if the price was $10 (which is extremely unlikely, as it would mean market cap of $100 M which is huge for new coin) then 0.1 is just $1. What price (or market cap) do you expect? |
|
|
|
Dear people, how to buy XEL? I want to invest too!
Wait for an exchange or Wait for mainnet and then buy from someone. Mainnet candidate will be launched this weekend. |
|
|
|
Nice! Will it be possible to run a full node on the laptop? Won't it burn it?
I don't want to sell computing powers, just to sync blockchain and use wallet.
Version 0.8 was running fine, on live Ubuntu, on my few years old laptop (Core2Duo@2.1, 4G RAM), so I think you should be fine unless you have something really ancient :-) [Edit: I tried it on persistent USB too without issues. Persistent (or full) install would be probably better for increasing size of the mainchain] |
|
|
|
although yobit is also an option.
Seriously you prefer yobit over nova or cryptopia? Yobit is notorious for being a sleazy exchange. ^this. Also, while some of the smaller exchanges have impressive volume (yobit), this is largely due to fake volume. Which while attractive to traders, isn't indicative of a large an interested userbase, which is what I believe the goal of getting XEL on an exchange is. Actual additional fundamental investors in the project. And yes, as stated Poloniex would be optimal, but good luck with that. As far as I know Bittrex does not take a "bribe" to add a coin. They do, however, sometimes charge a fee for legal costs if they think the coin could have regulatory issues. One of main flags for this is are coins with a focus on gambling (since Bittrex is licensed in the USA), or ICOs that were funded elsewhere, as they wish to ensure the coin isn't a security, et cetera. Anyway, not fan boying for any one exchange, Just pointing out some options the community and community leaders could pursue, and noting that some of the exchange addition requests have to be led by a community leader/dev. Regardless, while I think getting on an exchange eventually will help grow and strengthen our community, it is nice to see the devs focused on the actual programming work at hand. Exchange listing will allow work order providers to get XEL for their jobs. Otherwise they can only buy from ICO hodlers. |
|
|
|
But by limiting the number of SN we limit the overall supercomputer calculating power, isn't it? If it's gonna be 300k XEL then we'll have the maximum number of 333 supercomputer clusters, 30k XELs means 3330 SN (in the best case scenario, of course).
I agree with ttook that maybe we could make this number a variable? But only not an increasing, but a decreasing one: from 300k to, let's say, 3k over time due to XEL's price increase and increasing resources consumption.
From my understanding the SN's are only validating the computational jobs done by the individual network nodes. I dont see the number of SN's as a factor in overall network computational potential, but I do recognize that having a low # of SN's could create a bottleneck... But either way, the data supporting my claims here doesnt exist yet. A variable amount for operating SN's might help out. But it seems most are concerned with the Fiat cost of ownership at this point - We cant peg XEL to fiat and expect it to be a accurate 6 months down the road. In addition to that fact, a Fiat / Xel calculation that determines the amount of XEL required for a supernode has absolutely no technical implications on the network. TLDR: XEL Supernodes =/= Masternodes (DASH, PIVX, ect.) - Network computational power is not supplied by Supernodes alone. You can mine / compute with the other nodes. SNs not only validate the jobs, but also help to keep it all running becasue of limitations of the regular nodes. But it's pretty obvious the SNs will have their own limits, so not sure if it will resolve the available-resources-related issues, unless we are sure what config will be capable of handling ALL possible jobs, ie. how many SNs at what specs |
|
|
|
I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.
I think I disagree with most of what you wrote... Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user
That is the reason for the 300K...we don't want it easy / cheap for people to create malicious supernodes. -new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.
If there is only one supernode, then xel has failed it purpose anyway. What's the point of xel if no one is interested in supporting the network. -no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network
Huh? What about POW rewards and Bounties? Are those not incentive enough to run a regular node? What other incentives would they need? -is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?
Yes this scenario is handled in the design. I'll let EK speak to how it would work. -introducing supernodes and guardnodes makes the ecosystem much more complex
Ok, this may be the only thing I agree with that you wrote. Yes it makes things more complex. But this complexity provides a couple things. 1) Without it, xel can only work on small jobs with limited memory. With SN, we can increase the size / complexity of the use cases considerably. 2) Read what EK wrote above...without SNs it would mean that for Exchanges, etc to run a wallet, they would be required to verify all the ElasticPL jobs / solutions / pow submissions flowing through the network. I don't really think you'll find many, if any exchanges that would agree to this. Thank you coralreefer. I do hope you're right, and the design is "strong" enough to withstand the test of time :-) I just wonder why not make it as easy as running regular nodes, and allow node operators choosing whether they want to accept jobs or not? Or maybe let the network decide if a node has enough resources to allow it to perform jobs processing. Would it be possible to detect configuration and auto-decide? What I really don't like is complexity since it always leads to problems... I know it's actually little late for this discussion, but the supernodes idea hasn't been discussed on this forum, so no one knows what to expect. [Edit: or maybe I missed such discussion?] |
|
|
|
Also, we need to set a strategy what to do when no supernodes are available (nor registered in the system). Just verify all work instantly? Block any work from being done? Or don't care about it al all?
All the little details have to be sorted out now ;-)
My vote would be that the supernodes are required for any ElasticPL processing (of course, wallets would still work fine w/o SNs). But in the least I don't think we should allow any new work to be submitted if there are no SNs. That was also my initial guess ;-) EK, can you clarify something about the SNs, which may help make this decision...my understanding is that we went to the SN approach to offload the ElasticPL validation from the core server for a couple reasons, the main ones being: 1) The time it takes to validate the submissions from multiple jobs (even small ones) could impact the performance of the core server if done there 2) Using SNs would allow us to increase the memory available to ElasticPL jobs If either or both of these are the case, I would think SNs are required for ElasticPL processing. Yeah, the main reason was to have more ram and to support a higher WCET (how high, we still have to specify). Otherwise, we would have to limit the available resources to what we expect the weakest nodes in the network to have. Nice side effect, no matter how crippled the ElasticPL language is, it can never halt the network. This can be also seen as: no code is executed anywhere else than on guard nodes and super nodes - worth to mention to those, who are potentially afraid of this since they want to run Elastic on critical systems such as exchange servers. Is it possible that a job can exceed resources available on the weakest supernode? Will the configuration required for supernode be enough for all jobs? |
|
|
|
Well, how many 300k contributors do we have at the start of the mainnet? And how many of them are willing to run a supernode?
In general, I think supernodes are a good idea and 300k is ok as collateral, but maybe there should be a starting period of X blocks, in which supernodes require less collateral, to get people started? Maybe the required collateral should start at, let's say 50k and rise gradually, until it reaches 300k. Or is that a stupid idea?
Progressive collateral would be good if we're listed on exchange (so you could buy some), or there're jobs for which supernode owner could get XEL. It's rather unlikely to start getting XEL immediately after launch |
|
|
|
|
I must say I'm not big fan of the idea of supernodes and guardnodes.
Why? Because we're to build decentralized supercomputer, and those new node types will probably make the computations centralized.
Few reasons that I can think of now:
-300k XEL collateral will most likely be not possible for an average user
-new attack vectors against supernodes, or against network.
Examples: (1) supernode owner can switch it off purposely just to cut off someone (or whole network, if it's the only supernode) from computations, (2) supernodes can be attacked (DDoSed for instance) just because their owners are rich, or the network relies on them, etc.
-no incentive for "ordinary" users to run nodes, ie. why should I run the node if there's no supernode in the network
-is it possible supernodes will be cheating? what is exactly a procedure of seizing the collateral in case supernode is assumed to be malicious? what if the procedure will be used to eliminate someone from the network?
-introducing supernodes and guardnodes makes the ecosystem much more complex
Also, do we know anyone interested to run supernode at launch?
If not, then we can expect no supernodes, unless developers will run one.
|
|
|
|
I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly.
So the best testnet will become a de facto mainnet? Is that a good idea? That's how I understand EK's proposal to allow users to launch the mainnet by simply start using the system. Don't know if it's good or bad, but there will be bugs after that for sure. I think we just need to make sure there're no major flaws, and the system works as expected. Also, nobody has seen supernodes and guardnodes yet, so we'll need to test it too before going "live". |
|
|
|
@EK last week in your roadmap, do you have any updates for us?
Whole package arrives as promised on weekend, including a full documentation and in fully operable state. The roadmap was reorganized a bit, but (from my side) everything went (and goes) as planned. So no more testnet before mainnet launch ? regards I doubt there will be single start point for the mainnet. I think a testnet will be formed by (new version) nodes initially, and then depending on the network state (no bugs), users will start redeeming their stakes slowly. |
|
|
|
|
Show Posts
