Evil-Knievel
Legendary
 Offline
Activity: 1260
Merit: 1168
|
 |
October 13, 2016, 11:51:33 AM |
|
The POW checks significantly slows down the mining process. The reason is that 64000 integers are hashed after every iteration of the program in order to obtain the PoW hash so it can be checked against the target value. Without the PoW check we have 50.000 evaluations per second using the (just updated) miner for a simple 5 line arithmetic program. With the PoW check we drop as low as 600 evaluations per second. Same with the personalizedIntStream, which uses SHA256 to obtain deterministic input numbers . Any idea? Should we move from SHA256 for the PoW hash after all? Or is it just the shitty java implementation? What do you think?  |
|
|
|
|
|
|
|
Each block is stacked on top of the previous one. Adding another block to the top makes all lower blocks more difficult to remove: there is more "weight" above each block. A transaction in a block 6 blocks deep (6 confirmations) will be very difficult to remove.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
ttookk
|
|
October 13, 2016, 12:47:34 PM
Last edit: October 13, 2016, 01:04:00 PM by ttookk |
|
@akhavr,ttook: The problem with rating schemes is imho that you can create an infinite number of alternative identities, all with a clear background. Reputation may work in centralized systems that require some sort of authentication like e.g. eBay, but if we do not want to penalize new users without any rating, we will have a hard time coming up with a reputation system that really works. I mean I could rip off some workers, collect negative reputation, move the XEL to a fresh account and start over.
What do you think?
The whole identity business is true and I don't think there is going to be a clean solution. that's why I came up with the idea to implement a voting system similar to Lisk(I'll explain the lisk voting system a little further at the bottom): (…)
@Evil-Knievel (and the rest), what do you think about the possibility to implement a whitelist for miners, meaning, a job author can decide who is or isn't allowed to work on their job? Obviously, this list is not meant to be mandatory, but job authors can decide to use one or not and who is on their list. I know this has implications, but maybe this should be a consideration nonetheless. As pointed out above, this may be a (albeit cruel) solution to possible attacks.
(…)
I mean, a blacklist wouldn't work, but a non-mandatory whitelist would, if it was well-maintained by a trusted source (although this would probably be a kind of hidden centralization). More thoughts on that matter, especially in regards to Lisks system: The more I think about it, the more I like the idea of a non-mandatory whitelist and reputation system.
The scenario could look like this:
- Under normal circumstances, job authors don't use the reputation system, because they would obviously want to have as many miners working on their job as possible.
- If the system is under attack, job authors can choose to activate the reputation system. This system consists of two parts:
- They can either decide to only let certain miners work on their job. They can create a list of miners, or use the list of another trusted entity.
- They can also set a certain "minimum of approval" threshold. This means, that only miners with the set minimum of approval or more are allowed to work on the job.
- To earn approval, the XEL network can vote for miners. To get people to vote for you, you can share earnings with them (since they hold XEL and are interested in XELs financial well-being, they are interested to vote in legit miners and withdraw approval if a miners shows malicious activity). This system would work similar to Lisks DPoS system, but without a fixed number of Delegates/miners obviously. Miners with zero reputation can mine on the network, but run the risk of getting blacklisted. A miner could still vote for themselves, but ideally, the needed amount would be very high.
I have to admit, that I smell abusive potential, but I can't point my finger at it. The worst I see at the moment is a scenario in which most job authors use the list to whitelist only certain miners, keeping the majority of miners outside of it, but I don't see that as likely…
EDIT: This is a bit out there, but you could also use the whitelist system to chop jobs, so that the risk of a single miner mining the majority of your blocks is reduced. Let's say, you have sensitive data, that you don't want to have in one hand. You could divide them up into different jobs and whitelist different miners for each of those jobs. Obviously, the nodes would be weak links in this scenario…
To explain Lisks voting system a little further: Every wallet which contains LSK(or XEL…) has a voting weight equal to the XEL it contains. To vote with a wallet for a miner, a special transaction is made, which requires a small fee. the miner is now essentially "approved by this wallet", the "amount" of approval is based on the weight of the wallet. This can change obviously depending on tokens getting in or out of the wallet, so it is checked regularly. In Lisks system, the 101 delegates with the highest "approval" are allowed to forge Lisk. In Elastics network, there wouldn't be such a hard cap in place, instead a job author can decide to set a minimum amount of approval. To ensure some kind of "job security" and to keep the overhead low, I'd modify the voting system in a way, in which there is only one voting every week. This would mitigate the issues at hand in two ways: - A miner wouldn't want to spread out over different identities, because they would have to get voted for multiple times. - Am miner could still buy XEL and vote for themselves, but ideally, this would be extremely expensive, and the Elastic community could enforce voting of other miners to raise the minimum amount of approval over the level of the attacker. I admit that this is far from being a clean solution, but it's something  |
|
|
|
|
|
coralreefer
|
|
October 13, 2016, 03:56:55 PM |
|
Any idea? Should we move from SHA256 for the PoW hash after all? Or is it just the shitty java implementation?
What do you think?
I see the same performance issues in my C miner, so it's not just java. This is the issue I've been raising for a while that running ElasticPL is very inefficient...almost all effort is in the sha256 hashing. I was thinking that you were hashing the 64012 integers so that the miner proved they actually ran the ElasticPL code. If you get rid of it, how do you prove the miner actually ran the ElasticPL code and didn't just throw random numbers into the memory? As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL...that way miners are always there regardless of whether or not there are Work Packages. Then when Work Packages are there, they do both POW and ElasticPL submitting the bounties as currently designed. |
|
|
|
|
|
ttookk
|
|
October 13, 2016, 05:12:15 PM |
|
(…)
As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL...that way miners are always there regardless of whether or not there are Work Packages. Then when Work Packages are there, they do both POW and ElasticPL submitting the bounties as currently designed.
Since the amount of XEL is fixed, the miners would mine air if there are no jobs, though… |
|
|
|
|
|
coralreefer
|
|
October 13, 2016, 05:14:23 PM |
|
(…)
As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL...that way miners are always there regardless of whether or not there are Work Packages. Then when Work Packages are there, they do both POW and ElasticPL submitting the bounties as currently designed.
Since the amount of XEL is fixed, the miners would mine air if there are no jobs, though… The would compete for the same fees as POS mining as well Work Fees when available. |
|
|
|
|
|
ttookk
|
|
October 13, 2016, 05:52:35 PM |
|
I'd like to elaborate on my thoughts on a reputation system, so, here it is:
As stated before, a negative reputation system wouldn't work, because miners can simply change identities. A positive reputation system needs to have ways to let new miners enter the system and shouldn't be mandatory in the first place.
Nevertheless, any reputation system will create a barrier to new miners, which might cause a problem, because if the miners are not sufficiently rewarded for their efforts, they won't bother mining XEL, which leads to less computing power, leading to less jobs, leading to lower XEL prices, and so on, turning into a diabolic downward spiral.
That being said, here are my thoughts on the reputation system. I welcome criticism and suggestions:
I'll use a simplified scenario. Let's assume we have 100 XEl in the system, 5 miners(Miner01, Miner02 and so on) and 5 wallets, containing different amounts of XEL:
Wallet(05):5 XEL
Wallet(15):15 XEL
Wallet(20):20 XEL
Wallet(25):25 XEL
Wallet(35):35 XEL
Every wallet can only vote for a maximum number of miners, in this cenario, let's assume 2 (in reality, I think a numbe rbetween 25-50 is appropriate).
The miners register as miners and try to collect votes. They can do so by using the most common channels, XEL will have, be it a dedicated forum, twitter or whatever.
The wallets can vote all the time. They can change their mind as well and vote for other miners, but voting will cost them a small fee. Every X blocks (probably a timeframe that would be around a week IRL), a snapshot is made in which is checked,
- Which wallet voted for which miners (The last vote sent in counts)
- How much XEL is held in the wallets which voted.
The amount of approval a wallet can give to a miner is equal to the XEL it holds at the time of the snapshot. The whole weight counts for every miner, the wallet voted for, therefore, voting for a smaller number of miners than possible has no direct advantage.
In our scenario, it could look like this:
Wallet(05): Miner01, Miner02
Wallet(15): Miner01, Miner02
Wallet(20): Miner02, Miner03
Wallet(25): Miner03, Miner04
Wallet(35): Miner03, miner05
This would give our miners these amounts of approval:
Miner01: 20
Miner02: 40
Miner03: 80
Miner04: 25
Miner05: 35
Job authors may now decide to set a minimum amount of approval for their jobs, because they fear an attack. Let's say, they set the amount at 30. This would mean, only Miner02, Miner03 and Miner05 are allowed to work on the job.
Here, we can see a problem this system still has: There is a chance that the holder of Wallet(35) and Miner05 are the same person and have malicious intent.
I'd still like to combine this solution with the option of using a whitelist, in which specific miners are listed. This whitelist wouldn't be Elastic-wide, of course, but it would be created by the job author.
In this scenario, Miners will probably build pools and conglomerates to collectively vote for one mining identity. I'm not sure what to think about this, but I have the feeling that this is not our business. In the end, it might even be positive to XEL, because there pools have good reason to stay on the good side.
Happy to hear your thoughts on that matter. I'm not exactly in love with this idea and would like to hear other solutions.
|
|
|
|
|
Evil-Knievel
Legendary
Offline
Activity: 1260
Merit: 1168
|
|
October 13, 2016, 06:51:43 PM
Last edit: October 13, 2016, 07:06:10 PM by Evil-Knievel |
|
Any idea? Should we move from SHA256 for the PoW hash after all? Or is it just the shitty java implementation?
What do you think?
I see the same performance issues in my C miner, so it's not just java. This is the issue I've been raising for a while that running ElasticPL is very inefficient...almost all effort is in the sha256 hashing. I was thinking that you were hashing the 64012 integers so that the miner proved they actually ran the ElasticPL code. If you get rid of it, how do you prove the miner actually ran the ElasticPL code and didn't just throw random numbers into the memory? Maybe we can make this more efficient here ;-) SHA256 can hash with a rate of 169.49 MB/s (according to numerous benchmarks presented in sources like this one). 64012 Integers are roughly 256KB. So my computer is limited to 169.49 / 0.25 ~ 677 evaluations for any elastic program in the best case ... likely less. So, this sucks big time! EDIT: My calculation sucks somehow ... even any 3rd class Bitcoin CPU miner can make several million SHA256 hashes (https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#Intel) per second. Maybe it's really just the implementation?? Sidenote: If you ever need to find out the real MB/s speed of SHA256, never consult any of the sources you find using your favorite search engine ... they are simply wrongI think we need to come up with an alternative scheme to verify that "work has been done" in terms of "hashes that meet a certain target are submitted". As I mentioned before, I really see the best solution as having POW participate in the block mining rather than ElasticPL... What's wrong with POS? Does it really matter from the tech point of view if POW or POS is used for block mining,? Isn't it that the only difference is that while the first choice wastes energy and the second doesn't? ElasticPL itself was never involved in block mining. ElasticPL mining is done using transaction's only ... no ElasticPL miner can create a "block" just submit a "claim" transaction to get his reward. |
|
|
|
|
|
|
|
chikiuso
|
|
October 13, 2016, 07:06:42 PM |
|
Hi, You also xel's dev? Hagie. Good job. |
|
|
|
|
|
coralreefer
|
|
October 13, 2016, 07:07:47 PM |
|
What's wrong with POS? Does it really matter from the tech point of view if POW or POS is used for block mining,? Isn't it that the only difference is that while the first choice wastes energy and the second doesn't? ElasticPL itself was never involved in block mining. ElasticPL mining is done using transaction's only ... no ElasticPL miner can create a "block" just submit a "claim" transaction to get his reward. I didn't mean to imply getting rid of POS. What I was trying to solve for is that, regardless of reputation, efficiency, etc, we need a way to encourage miners to be on the network and readily available for when work packages are submitted. It won't do the work owner much good if he submits the first package in a week and no POW miners are on the network...his work will just stagnate. So I was trying to think of a way to keep miners on the network while also solving the POW efficiency issue. I threw out letting the miners share in the fees with the POS miners, but realize there are lots of issues there as well (i.e. wrong algo and we get into the asic wars and still don't have miners for work package). I'm just coming at this from a different angle than most. One of building up a pool of miners ready for work packages. |
|
|
|
|
|
|
|
hagie
|
|
October 13, 2016, 07:12:23 PM |
|
@ek: still getting "Could not validate unsigned bytes returned by the server." when I try to update my account info on testnet :-(
regards
|
|
|
|
|
|
coralreefer
|
|
October 13, 2016, 07:18:56 PM |
|
Also, I just throw out the "last resort" option. If we really can't solve for keeping miners around when there are few to no work packages, maybe we should just go the other extreme and get rid of POW. Miners get paid the same when no package is available...nothing. When I comment POW out of my code, the ElasticPL parser runs great. It just seems that there is a need for a lot of overhead on the POW piece to ensure mining is fair. Honestly, if I was mining a package at this point I would just turn off the POW myself even if we decide to keep it.
I guess I've come around to your original comments that the bounty reward is what will really draw miners.
|
|
|
|
|
|
ttookk
|
|
October 13, 2016, 07:49:52 PM |
|
Also, I just throw out the "last resort" option. If we really can't solve for keeping miners around when there are few to no work packages, maybe we should just go the other extreme and get rid of POW. Miners get paid the same when no package is available...nothing. When I comment POW out of my code, the ElasticPL parser runs great. It just seems that there is a need for a lot of overhead on the POW piece to ensure mining is fair. Honestly, if I was mining a package at this point I would just turn off the POW myself even if we decide to keep it.
I guess I've come around to your original comments that the bounty reward is what will really draw miners.
You've got a point regarding the "keeping miners on Elastic" issue. As I wrote before, I think the solution is based on the amount of work we expect on the Elastic network. A possible solution that was mentioned before was essentially turning the Elastic network into a mining pool for cryptocurrencies other than XEL. So when no jobs are to be solved, the miners mine other coins instead, until a job is submitted. I suspect this only works for smaller voids, though. |
|
|
|
|
|
chris_nor
|
|
October 13, 2016, 07:58:57 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
|
|
|
|
|
ImI
Legendary
Offline
Activity: 1946
Merit: 1019
|
|
October 13, 2016, 08:03:29 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
2 months |
|
|
|
|
|
ttookk
|
|
October 13, 2016, 08:04:49 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
2 monthsWhen it's ready |
|
|
|
|
|
hagie
|
|
October 13, 2016, 08:20:50 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
2 months2 month AFTER testnet runs stable |
|
|
|
|
|
chris_nor
|
|
October 13, 2016, 08:23:31 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
2 months2 month AFTER testnet runs stable So baiscally since it's not stable now (I'm guessing), it won't be here 2 months from now. |
|
|
|
|
|
unvoid
|
|
October 13, 2016, 09:28:32 PM |
|
When will Elastic be released? The 1st page has no information, and I'm getting errors on the webpage.
2 months2 month AFTER testnet runs stableI think we should take some date at some point that we will launch mainnet. Saying over and over "two months" or "three weeks" like @Lannister predicted isn't healthy for Elastic. We have competition as all of you know. We will have bugs always. Even after mainnet. Thing is, when we believe that we have software that is able to be mainnet release we have to release it. We can sit and wait forever as @EK develop Elastic but at some point we have to go mainstream. Sitting here for two/four/twelve more months isn't something that will transform into successful cryptocurrency. Don't get me wrong. We need solid project before mainnet. But we have to at some point decide that this is time for action. I didn't invested in Elastic much (much less than 0.5BTC). I just believe in this idea and I try to help as much as I can. If you all end with endless loop of "we will release mainnet after X" I don't give a shit about it. I just hope that this project have sense and: 1) will be successful, or 2) will be inspiration for better project this kind We are observing Golem and other projects. Do not think that they are not watching us. |
BTC: 1CMgHWx4wkAaAy2FfeCyPdedUExmhGhfi5
XEL: XEL-HCM8-KB6E-YFLK-8BWMF
|
|
|
|
