|
I can see immature balances are updating but not going into unpaid balance at all for hours. hmm.
|
|
|
|
Example of command line processing function header. My english aint no perfect as it is my second language but that is not the point. It is only few hundred lines of code, believe me I don't ever wanna look at the function's code! I guarantee, it will take days or weeks to figure it out!! # The pSysArgv is the all values of sys.argv as it is. This is what the # users of particular enters in the command line. # The pSupportedArgv is the tuple list of supported arguments in dictionary format passed # on by scripts and therefore its contents are specific to a particular script's implementation. # However following universal convention are used throughout to enable uniform processing # for any or almost any types, variants and number of switches and arguments. # Dictionary key holds the name of the argument in the naming convention: "--<argName>" # Dictionary value holds the tuple list object, serving as an initial indicator implying how many # values the arg needs (refer to examples below): # Current implementation divides the tuple values as two types in general: # 1. (<value1>, <value2>) - implies literal processing, which means the supportedArgs lists out the # actual values that user can enter in the command line for that particular switches and no other # allowed value. Example is if particular scripts --drive switches accepts only C: D: E: drive # letters and any other drive letters are not allowed. # 2. ('__range__', <list>) - implies that there is no restrictions on the values provided by user # for particular switch, however the <list> contains the range of number of allowed values for that # particular switch. This is useful in case, it is not known what value user will be putting at the # command line or there too many possibilities for particular variable. # For example, if --ip switches requires one value which is IPv4 address but the range of valid # IPv4 is too many to listed out as literal however --ip will accept only one value, in this case # supported switch is declared as: ('__range__', 1) # if --ip allows up from one to up to 5 different IP address following, (as in the case: # --ip 10.24.11.0 10.0.0.1 12.0.0.1 192.168.0.1 172.17.0.0 # then it should be declared and passed as: # ('__range__', 1, 2, 3, 4, 5) # or possible: # ('__range__', range(0, 5)) # pSupportedArgs typical examples are below but not limited to: # ------------------------------------------------------------------------------------- # Arg name Initial indicator of value count, tuple list type Valid user input # ------------------------------------------------------------------------------------- # '--timeout': (1,), (needs one and only one value for argument) # -> user input --timeout 100 # '--timeout': () (needs no value) -> user input --timeout # '--timeout': (1,2,3)(needs somewhere between 1 to 3 values, inclusive) # -> user input --timeout 1 # -> user input --timeout 1 100 2 # -> user input --timeout 1 100 # !!! This is currently unimplementable, needs to look!!! Currently it is not supported. # '--timeout': [1:CONFIG_MAX_ARG_VALUES] (needs somewhere between 1 to CONFIG_MAX_ARG_VALUES # number of values, which effectively implies "greater than 1") # -> user input --timeout 1 # -> user input --timeout 1 100 2 # -> user input --timeout 1 100 # -> user input --timeout 1 2 3 4 5 6 7 # -> user input --timeout 1 2 3 4 5 6 7 10 11 # ------------------------------------------------------------------------------------- # Once the arguments are processes and validated, the values of the dictionary will be populated # with the user supplied values from the command line. If user has not provided the argument, its # corresponding dictionary value remain unchanged, tuple list type, implying that the caller script # will not process it. # # input: # - pSysArgv - sys.argv() as it is. # - pSupportedArgs - dictionary type consisting of tuple list of argument that particular calling scripts supports. # - key holds the name of the argument. # - tuple list type holding indication of how many values are needed for the argument # (for details, refer to function header) # - helpStringArr - if user input --help argument, use this string to display the help message. # output: # - pSupportedArgs' values are populated with the validated command line argument values as list type. # - if particular argument is not provided by user, value remains unchanged as list tuple type. # - EXIT_NO_ERR if --help is supplied. # EXIT_ERR on any error condition. def prepArgs(pSysArgv, pSupportedArgs, helpStringArr): Again, IMHO to be useful this comment should be 4 - 5 times shorter, while reading it as wanted to scroll down in order to see actual code  . I do not see much sense in writing comments addressed to person who does not know the language in which the is written. it can not be shorter because function itself has a broad range of usage parameters to be explained, it is not like "hello world()" function. If you wanted to look at function, it appears you are conditioned to work with code that continually keep breaking and/or needs fixing (which of course not a good practice considering what the function is designed for). Function are normally designed to be bug free or near bug free to make useful. |
|
|
|
I advise you to mine through multipools.club instead. They're brilliant and provide basically 24/7 support in their telegram channel, whatever problem arises it gets fixed immediately
i have been mining on flypools for month, i also do on different mining pools for other coins. |
|
|
|
|
Yesterday, fired up my 20 1080-S on zec flypool but for 2-3 hours nothing happened, nada nothing. Usually within minutes, I start seeing immature shares but it was frozen on mining status page. Has anyone seen it? Difficulty for zec has been fluctuating around 5k-10k within last few months and still see within that range.
|
|
|
|
Example of command line processing function header. My english aint no perfect as it is my second language but that is not the point. It is only few hundred lines of code, believe me I don't ever wanna look at the function's code! I guarantee, it will take days or weeks to figure it out!! # The pSysArgv is the all values of sys.argv as it is. This is what the # users of particular enters in the command line. # The pSupportedArgv is the tuple list of supported arguments in dictionary format passed # on by scripts and therefore its contents are specific to a particular script's implementation. # However following universal convention are used throughout to enable uniform processing # for any or almost any types, variants and number of switches and arguments. # Dictionary key holds the name of the argument in the naming convention: "--<argName>" # Dictionary value holds the tuple list object, serving as an initial indicator implying how many # values the arg needs (refer to examples below): # Current implementation divides the tuple values as two types in general: # 1. (<value1>, <value2>) - implies literal processing, which means the supportedArgs lists out the # actual values that user can enter in the command line for that particular switches and no other # allowed value. Example is if particular scripts --drive switches accepts only C: D: E: drive # letters and any other drive letters are not allowed. # 2. ('__range__', <list>) - implies that there is no restrictions on the values provided by user # for particular switch, however the <list> contains the range of number of allowed values for that # particular switch. This is useful in case, it is not known what value user will be putting at the # command line or there too many possibilities for particular variable. # For example, if --ip switches requires one value which is IPv4 address but the range of valid # IPv4 is too many to listed out as literal however --ip will accept only one value, in this case # supported switch is declared as: ('__range__', 1) # if --ip allows up from one to up to 5 different IP address following, (as in the case: # --ip 10.24.11.0 10.0.0.1 12.0.0.1 192.168.0.1 172.17.0.0 # then it should be declared and passed as: # ('__range__', 1, 2, 3, 4, 5) # or possible: # ('__range__', range(0, 5)) # pSupportedArgs typical examples are below but not limited to: # ------------------------------------------------------------------------------------- # Arg name Initial indicator of value count, tuple list type Valid user input # ------------------------------------------------------------------------------------- # '--timeout': (1,), (needs one and only one value for argument) # -> user input --timeout 100 # '--timeout': () (needs no value) -> user input --timeout # '--timeout': (1,2,3)(needs somewhere between 1 to 3 values, inclusive) # -> user input --timeout 1 # -> user input --timeout 1 100 2 # -> user input --timeout 1 100 # !!! This is currently unimplementable, needs to look!!! Currently it is not supported. # '--timeout': [1:CONFIG_MAX_ARG_VALUES] (needs somewhere between 1 to CONFIG_MAX_ARG_VALUES # number of values, which effectively implies "greater than 1") # -> user input --timeout 1 # -> user input --timeout 1 100 2 # -> user input --timeout 1 100 # -> user input --timeout 1 2 3 4 5 6 7 # -> user input --timeout 1 2 3 4 5 6 7 10 11 # ------------------------------------------------------------------------------------- # Once the arguments are processes and validated, the values of the dictionary will be populated # with the user supplied values from the command line. If user has not provided the argument, its # corresponding dictionary value remain unchanged, tuple list type, implying that the caller script # will not process it. # # input: # - pSysArgv - sys.argv() as it is. # - pSupportedArgs - dictionary type consisting of tuple list of argument that particular calling scripts supports. # - key holds the name of the argument. # - tuple list type holding indication of how many values are needed for the argument # (for details, refer to function header) # - helpStringArr - if user input --help argument, use this string to display the help message. # output: # - pSupportedArgs' values are populated with the validated command line argument values as list type. # - if particular argument is not provided by user, value remains unchanged as list tuple type. # - EXIT_NO_ERR if --help is supplied. # EXIT_ERR on any error condition. def prepArgs(pSysArgv, pSupportedArgs, helpStringArr): |
|
|
|
|
it is always welcoming to challenging opinions here, save for a few crude nuggets who only wants to bash and troll around.
|
|
|
|
code without proper comments along header was considered to be a garbage and not worth a single cent
I think it is actually becoming more and more preferred that one writes code in a way that does not require comments. You often will hear things like "good code explains itself." I'm not too big a fan of this, but that is the direction the industry seems to be going in. That being said, bitcoin does still fail here at times--especially when you encounter single lines where boost functions are passed to other boost functions to other boost functions in a way that quickly taxes your senses of what is really happening. The jazzy naming conventions also are unappealing to me. (Ex: CConnman. Just call it ConnectionManager ffs.) For the longest time everyone seemed to be perfectly okay with AppInit2 as a function name. Now we have AppInitMain, which isn't at all intuitively different from the name AppInit. Overall, the code base does seem to be improving. Two steps forward, one step back. I can somewhat agree that industry moving forward self descriptive code and you guys put forth a challenge and argument, but still I believe at most companies I worked, the code sucks, and engineering hours are wasted. For large enterprise where million and billions are at stake poor code become actually unfixable. Self descriptive code that you can glance through will work with smaller project and/or smaller functions with few dozens or hundreds of code, but I have worked with overly convoluted functions that are several thousands lines work and it is a b** to work with. It is always better to describe in literal language with IN/OUT clearly defined like a black box. |
|
|
|
|
90w was most efficient for founder's edition for rog strix most efficient range appears to be around 100-120w. Yes you are correct, it does not let go lower than 90w.
|
|
|
|
The genius of satoshi was in the cryptographic field, and most importantly, having the vision to put all the (already existing) pieces to form a new thing. PoW was already there, distributed networks with nodes were already there, he just made a pack and it worked. The code was rough, apparently it lacked a lot of fine tuning, but that's not important when the concept is genius and it actually works in practice.
This is why someone that is a better coder could come up with another cryptocurrency, but if it's not a game changer at the scale of what Bitcoin was in 2009 (and still is) then it's not going to get anywhere, the network effect is too strong in Bitcoin.
Whoever wants to challenge Bitcoin must come up with with a completely new way to solve the Byzantine General's problem and do it in a much more efficient way, which I doubt it's going to happen for at least 100 years which is what these big problems usually take for someone to come up with new solutions.
bitcoin is falling out of favor with outrageous fees and being congested during peak hours. And appears to have become political. There are lot of other coins catching up to fill that avoid. But I agree, it is still the dominant coin but I am almost sure if not something significant being done, another coin will catch up in the next few years. IMO. My biggest gripe is mining, no longer mineable by small-time GPU-ers like me, and as far as mining concerned, it is not decentralized anymore. What the core dev-s are doing against the ASIC mining is not certain. I am working on platform to be able to switch many hosts into any coin and bitcoin (and other asic compatible coins) is/are not even in the consideration for obvious reason. Sure, Bitcoin has it's problems, but something that scammers typically claim is how their altcoin is going to solve Bitcoin's problems, only to find out that eventually their altcoins succumb when faced with the same problems and deal with these problems even worse, usually by centralizing the network (huge blocks) or by a system that is exploitable (PoS, DAG-Tangle stuff) There isn't a single coin out there that is objectively superior to Bitcoin and solves it's problems, if this was the case, everyone would dump and sit on that other network, but guess what, that doesn't exist. The "Core devs" don't have enough power to do something about mining. All they would create is yet another altcoin, because I doubt the rest of the community would follow, unless the idea was complete genius and long lasting. I can not say for sure, personally I'd rather bitcoin succeed as dominant but the way it is now with super high fees, and other problems, not sure. And it is not jus I am saying many people is concerned about it. I can not say which one will prevail over Bitcoin and/or which technology will prevail, there is no single person that can analyze 1000+ coin's whitepaper make a judgement, so only time will tell. I myself usually interested in gpu mining and managed to go over few dozen coins only, but the way I see now there are several altcoins that are looking better than bitcoin. |
|
|
|
Look at some of the advice and opinion you have received on this:
It's an Open Source project. Go ahead and make it better!
If you're not going to make it better, then it is YOUR FAULT that the quality is so bad.
Throwing completely substancesless insults at quality work in order to fool people who couldn't tell for themselves into thinking that you're brilliant seems to be a favorite pastime for folks who feel insecure about their lack of competence adequate enough to accomplish anything themselves.
If you are really a coder, you would get the thing about "Standing on the shoulders of giants". If your work ethic was anywhere near that of the people who have made bitcoin code, network and social phenomena possible, we would be getting valid suggestions and feedback. Maybe some real work too. But instead you take it upon yourself to become the hypothetical CEO of a hypothetical Bitcoin LLC, completely ignoring the whole decentralization criterion. This is the best you could come up with:
I don;t know, I haven't been involved. But on the other hand, do you think ASIC friendly is a good thing (mining centralized)?
If I were a CEO of a Bitcoin LLC or Bitcoin Inc., I will do definitely strip out SHA-256 and plug-in GPU friendly algo. Not only that I will start it in a blink of an eye and possibly re-architect so any algorithm can be a "plug-n-play"-ed.
- "I don't know"
- "I haven't been involved"
- "But Yo, I could totally be THE CEO"...LOL
You Sir, are a lot of hot air and no substance. And from post history, it seems you have been that way for a lot of years. What a waste of time and potential!! so saying that, u must be a better than me, perhaps must be a one of those giant lololol  , when critisizing me, u completely forgot about how big of an loser u re urself, game of critisism is ths tough dude, at least i my critisizm did not directed to you but you ended up being critisizing me for nothing, for that i can only say one thing in reply, fok yo and get the fok out of hyoooo... You just stated 3 blantant lies and got called out for it, yet you continue to keep trolling or? If I were a CEO of a Bitcoin LLC or Bitcoin Inc. That's the thing. It's open source and decentralized. There's no such thing as a "CEO" who controls how bitcoin works. There's consensus that determines the changes. do you think ASIC friendly is a good thing (mining centralized) Asics have nothing to do whether or not the mining is centralized. Sure, it might make the process of mining harder, ( meaning that only big companies will do it, but anyone can buy an asic and operate/mine for themselves. No one is stopping you. (+ There's not 1 company having 51% control right now. ( and there probably won't be.) Seriously is wrong with you. Your post is so retarded I wanna tell you to take some English class as well as some reading comprehension, analytical, reasoning and critical thinking skills. |
|
|
|
writing a code is easy, documenting what you do is hard, as well as debugging as hard, fixing bug is hard, root causing is hard. i could say most of the engineers i interacted with love writing (shitty)code but hates debugging, documenting and root causing problems so "brilliant" engineers mostly resist doing anything other than writing shitty code. I dont expect better on this forum either. so I expected some reasonable code when look through bitcoind but was disappointed. Anyways I am out of here |
|
|
|
Truth be told i am a fun of bitcoin and other crypto technology but utterly disappointed by the quality of code.
There was not even single line of documentation all of the few files I peeked through. In several of the technology companies I worked, code without proper comments along header was considered to be a garbage and not worth a single cent. There are lot of philosophy behind making a good coding practice which I can not start over here, it is even taught in CS101.
I also read the source code. IMVHO (based on 40 years of computer experience) code is pretty reasonably commented. I looked particularly in src/primitives, src/rpc, src/wallet and some other subdirs. In .h files that contain data descriptions, some structures have description of each field. After reading those files, .cpp files can be easily read and understood. well, i did not find it reasonable. i have less than 15 yrs exp, but imho, experience does not really count much after 5-6 yrs. In fact, if particular engineer is opinionated about commenting and documentation is NOT necessary it seems it is even harder to have 'em change their habit because he/she becomes more inflexible as person gets aged. |
|
|
|
|
I bought bunch of gtx1080 founders edition and rig strix. I am running on lowest power possible at 90w and fans are turning much slower than full 180w. How far do you think i can go with these??
|
|
|
|
sole prop has 1040 schedule c which has utilities section in box 25 and supplies section in box 22: https://www.irs.gov/pub/irs-pdf/f1040sc.pdfI am going to cram all the huge expenses of GPU into box 22 and sky hi electricity into box 25. Hopefully there are some refunds. But these were actual expenses and severe expenses. Haha. |
|
|
|
Look at some of the advice and opinion you have received on this:
It's an Open Source project. Go ahead and make it better!
If you're not going to make it better, then it is YOUR FAULT that the quality is so bad.
Throwing completely substancesless insults at quality work in order to fool people who couldn't tell for themselves into thinking that you're brilliant seems to be a favorite pastime for folks who feel insecure about their lack of competence adequate enough to accomplish anything themselves.
If you are really a coder, you would get the thing about "Standing on the shoulders of giants". If your work ethic was anywhere near that of the people who have made bitcoin code, network and social phenomena possible, we would be getting valid suggestions and feedback. Maybe some real work too. But instead you take it upon yourself to become the hypothetical CEO of a hypothetical Bitcoin LLC, completely ignoring the whole decentralization criterion. This is the best you could come up with:
I don;t know, I haven't been involved. But on the other hand, do you think ASIC friendly is a good thing (mining centralized)?
If I were a CEO of a Bitcoin LLC or Bitcoin Inc., I will do definitely strip out SHA-256 and plug-in GPU friendly algo. Not only that I will start it in a blink of an eye and possibly re-architect so any algorithm can be a "plug-n-play"-ed.
- "I don't know"
- "I haven't been involved"
- "But Yo, I could totally be THE CEO"...LOL
You Sir, are a lot of hot air and no substance. And from post history, it seems you have been that way for a lot of years. What a waste of time and potential!! so saying that, u must be a better than me, perhaps must be a one of those giant lololol , when critisizing me, u completely forgot about how big of an loser u re urself, game of critisism is ths tough dude, at least i my critisizm did not directed to you but you ended up being critisizing me for nothing, for that i can only say one thing in reply, fok yo and get the fok out of hyoooo... |
|
|
|
Sounds like if you play by the rules and deduct as much as you can. Cash out slowly after a year out and keep buying more haedware, the IRS has to pay you to play with your hobby. Not a bad deal if you do your due diligence.
sounds like a good plan. |
|
|
|
What the core dev-s are doing against the ASIC mining is not certain. What exactly would you like them to do? Hard-fork and completely change the underlying POW algorithm? Because that's pretty much the only way to do anything about ASIC mining... SHA-256 is "ASIC friendly", you can't change that. I don;t know, I haven't been involved. But on the other hand, do you think ASIC friendly is a good thing (mining centralized)? If I were a CEO of a Bitcoin LLC or Bitcoin Inc., I will do definitely strip out SHA-256 and plug-in GPU friendly algo. Not only that I will start it in a blink of an eye and possibly re-architect so any algorithm can be a "plug-n-play"-ed. |
|
|
|
The genius of satoshi was in the cryptographic field, and most importantly, having the vision to put all the (already existing) pieces to form a new thing. PoW was already there, distributed networks with nodes were already there, he just made a pack and it worked. The code was rough, apparently it lacked a lot of fine tuning, but that's not important when the concept is genius and it actually works in practice.
This is why someone that is a better coder could come up with another cryptocurrency, but if it's not a game changer at the scale of what Bitcoin was in 2009 (and still is) then it's not going to get anywhere, the network effect is too strong in Bitcoin.
Whoever wants to challenge Bitcoin must come up with with a completely new way to solve the Byzantine General's problem and do it in a much more efficient way, which I doubt it's going to happen for at least 100 years which is what these big problems usually take for someone to come up with new solutions.
bitcoin is falling out of favor with outrageous fees and being congested during peak hours. And appears to have become political. There are lot of other coins catching up to fill that avoid. But I agree, it is still the dominant coin but I am almost sure if not something significant being done, another coin will catch up in the next few years. IMO. My biggest gripe is mining, no longer mineable by small-time GPU-ers like me, and as far as mining concerned, it is not decentralized anymore. What the core dev-s are doing against the ASIC mining is not certain. I am working on platform to be able to switch many hosts into any coin and bitcoin (and other asic compatible coins) is/are not even in the consideration for obvious reason. |
|
|
|
gif is not playing, can only see still pics.  clock on the link even the pic shows what i think about pay taxes for crypto  taxes for crypto thats a fucking joke Honest question, out of curiosity, do you feel that way about all types of income taxation? It is much bigger topic than that, but in general, taxation is unavoidable should be for all sources income but the current rate and how it is being used?? nahhhh... |
|
|
|
|
can you control arbitrary number of miner hosts? 100-s and 1000s with this with one click?
|
|
|
|
|
Show Posts
