Wikimedia Foundation Now Accepts Bitcoin – Diff

hashflare

Discussion based on cloud mining specifically using HashFlare.
[link]

Gridcoin 5.0.0.0-Mandatory "Fern" Release

https://github.com/gridcoin-community/Gridcoin-Research/releases/tag/5.0.0.0
Finally! After over ten months of development and testing, "Fern" has arrived! This is a whopper. 240 pull requests merged. Essentially a complete rewrite that was started with the scraper (the "neural net" rewrite) in "Denise" has now been completed. Practically the ENTIRE Gridcoin specific codebase resting on top of the vanilla Bitcoin/Peercoin/Blackcoin vanilla PoS code has been rewritten. This removes the team requirement at last (see below), although there are many other important improvements besides that.
Fern was a monumental undertaking. We had to encode all of the old rules active for the v10 block protocol in new code and ensure that the new code was 100% compatible. This had to be done in such a way as to clear out all of the old spaghetti and ring-fence it with tightly controlled class implementations. We then wrote an entirely new, simplified ruleset for research rewards and reengineered contracts (which includes beacon management, polls, and voting) using properly classed code. The fundamentals of Gridcoin with this release are now on a very sound and maintainable footing, and the developers believe the codebase as updated here will serve as the fundamental basis for Gridcoin's future roadmap.
We have been testing this for MONTHS on testnet in various stages. The v10 (legacy) compatibility code has been running on testnet continuously as it was developed to ensure compatibility with existing nodes. During the last few months, we have done two private testnet forks and then the full public testnet testing for v11 code (the new protocol which is what Fern implements). The developers have also been running non-staking "sentinel" nodes on mainnet with this code to verify that the consensus rules are problem-free for the legacy compatibility code on the broader mainnet. We believe this amount of testing is going to result in a smooth rollout.
Given the amount of changes in Fern, I am presenting TWO changelogs below. One is high level, which summarizes the most significant changes in the protocol. The second changelog is the detailed one in the usual format, and gives you an inkling of the size of this release.

Highlights

Protocol

Note that the protocol changes will not become active until we cross the hard-fork transition height to v11, which has been set at 2053000. Given current average block spacing, this should happen around October 4, about one month from now.
Note that to get all of the beacons in the network on the new protocol, we are requiring ALL beacons to be validated. A two week (14 day) grace period is provided by the code, starting at the time of the transition height, for people currently holding a beacon to validate the beacon and prevent it from expiring. That means that EVERY CRUNCHER must advertise and validate their beacon AFTER the v11 transition (around Oct 4th) and BEFORE October 18th (or more precisely, 14 days from the actual date of the v11 transition). If you do not advertise and validate your beacon by this time, your beacon will expire and you will stop earning research rewards until you advertise and validate a new beacon. This process has been made much easier by a brand new beacon "wizard" that helps manage beacon advertisements and renewals. Once a beacon has been validated and is a v11 protocol beacon, the normal 180 day expiration rules apply. Note, however, that the 180 day expiration on research rewards has been removed with the Fern update. This means that while your beacon might expire after 180 days, your earned research rewards will be retained and can be claimed by advertising a beacon with the same CPID and going through the validation process again. In other words, you do not lose any earned research rewards if you do not stake a block within 180 days and keep your beacon up-to-date.
The transition height is also when the team requirement will be relaxed for the network.

GUI

Besides the beacon wizard, there are a number of improvements to the GUI, including new UI transaction types (and icons) for staking the superblock, sidestake sends, beacon advertisement, voting, poll creation, and transactions with a message. The main screen has been revamped with a better summary section, and better status icons. Several changes under the hood have improved GUI performance. And finally, the diagnostics have been revamped.

Blockchain

The wallet sync speed has been DRASTICALLY improved. A decent machine with a good network connection should be able to sync the entire mainnet blockchain in less than 4 hours. A fast machine with a really fast network connection and a good SSD can do it in about 2.5 hours. One of our goals was to reduce or eliminate the reliance on snapshots for mainnet, and I think we have accomplished that goal with the new sync speed. We have also streamlined the in-memory structures for the blockchain which shaves some memory use.
There are so many goodies here it is hard to summarize them all.
I would like to thank all of the contributors to this release, but especially thank @cyrossignol, whose incredible contributions formed the backbone of this release. I would also like to pay special thanks to @barton2526, @caraka, and @Quezacoatl1, who tirelessly helped during the testing and polishing phase on testnet with testing and repeated builds for all architectures.
The developers are proud to present this release to the community and we believe this represents the starting point for a true renaissance for Gridcoin!

Summary Changelog

Accrual

Changed

Most significantly, nodes calculate research rewards directly from the magnitudes in EACH superblock between stakes instead of using a two- or three- point average based on a CPID's current magnitude and the magnitude for the CPID when it last staked. For those long-timers in the community, this has been referred to as "Superblock Windows," and was first done in proof-of-concept form by @denravonska.

Removed

Beacons

Added

Changed

Removed

Unaltered

As a reminder:

Superblocks

Added

Changed

Removed

Voting

Added

Changed

Removed

Detailed Changelog

[5.0.0.0] 2020-09-03, mandatory, "Fern"

Added

Changed

Removed

Fixed

submitted by jamescowens to gridcoin [link] [comments]

Warning: Blockchain difficulty adjustment affecting price movements

Below are notable difficulty adjustments when hash rate fell and block times become slower for Bitcoin.
  1. 26 Mar 2020 [difficulty adjustment -15.95%, avg block time 11min 54secs]. On the 28th price crashed from $6674 to $6138 ( -8%).
  2. 8 Nov 2019 [difficulty adjustment -7.1%, avg block time 10min 46secs]. On the same day price crashed from $9234 to $8783 ( -4.88%).
  3. The next big adjustment was around Nov to Dec 2018 and there were 3 big adjustments with high block times.

Current situation:
We are 1 day 10 hours from the next difficulty adjustment. Projected difficulty adjustment is -5.61% (https://fork.lol/pow/retarget), which could indicate a small dip. However, take note that the date of last adjustment was the 5th and the 3rd halving was on the 11th, between the 5th to the 11th there was increased hashrate from miners trying to mine the final week of 12.5btc that offset the really slow block times after the halving. Therefore it will be the next difficulty adjustment after the one on the 20th that will completely reflect the slower block times after the halving. Currently the median block time taken on the 17th was around 14min (-28.5% difficulty adjustment).
For people who do not understand blockchain, basically with the Bitcoin 3rd halving, mining profitability fell for a lot of miners and they probably turned off their miners therefore the blockchain mining time became considerably slower which is reflected with slow transaction speed and higher fees as seen currently. Bitcoin sellers moving their BTC from wallet to an exchange are faced with slow transaction speed and therefore the sell pressure of BTC fell considerably which will attribute to the current price increase. There is a correlation between sell pressure and blockchain congestion (the size of the correlation is undetermined).
There is going to be a race. A race between BTC price hiking high enough to attract more miners to reduce avg block times versus the closing window of roughly 2 weeks before the next difficulty adjustment. If the price does not jump high enough, the next difficulty adjustment in the first week of June could signal a huge dip.
I am not an expert. I just did some research on the above and wanted to share with fellow Bitcoin compatriots so that we can tread with caution and not lose our shirts. I do not plan to short BTC but I will exit my BTC positions if I expect double digit negative difficulty adjustment in early June.
Please visit the original post here https://www.reddit.com/Bitcoin/comments/gm23pe/warning_blockchain_difficulty_adjustment/
There are pictures in the original post as well as 2nd halving evidence with pics. I could not post pics here. If possible please upvote the original post, a lot of people downvote it. Not sure why people downvote it, maybe veterans attempting to hide information from newcomers to fleece them of their shirt.

Update 1:>! As of writing, I have opened a small short position on Bitcoin. Stop loss around 10k, estimated take profit around 8500. The reason is because the difficulty adjustment in the next 20 hours, even though is just -5% roughly is still significant. I direct you to look into all the difficulty adjustments in the last 2 years and you will know how rare it is. The ones I caught were all listed at the very top of the post. Since it is my first time shorting BTC, I take this as a learning opportunity so that I will have some experience to face the bigger difficulty adjustment in the first week of June. Analysis into execution, even in failure I am happy.!<
Update 2: The difficulty adjustment (DA) happened roughly 6 hours ago and the sell pressure from -6% DA did not seem to be affecting the market much. However, please take a look now at the estimation for the next DA.
On https://bitcoin.clarkmoody.com/dashboard/ it is estimated to be -25%.
On https://fork.lol/pow/retarget estimated to be -18%.
On https://www.blockchain.com/charts/median-confirmation-time the median block time for the last day was 16.8min.
My original proposition that the true DA of the halving can only be realized in the next DA stands and that it will be considerable. The increased sell pressure from that DA will be highly significant. That is why there is a race by current miners to get the BTC price up high enough to attract more miners to not have the DA drop too much.
Update 3: Current BTC price at $9100 ( ~39 hours after DA). Then again BTC could have dropped from all sorts of reason. However the coincidence with the DA and with all the past DA is just too high to simply shrug off as irrelevant. Anyways past result cannot predict future ones, stay safe with the trading. Will no longer check on this post.
References:
Difficulty adjustment dates taken from https://btc.com/stats/diff
Bitcoin graph history for price movement taken from coinmarketcap.
Median confirmation time (block time) taken from https://www.blockchain.com/charts/median-confirmation-time

Credits to people who assisted the analysis:
kairepaire for pointing out faster block times between 5th-11th.
babies_eater for https://fork.lol/pow/retarget
moes_tavern_wifi for https://bitcoin.clarkmoody.com/dashboard/
Pantamis for https://diff.cryptothis.com/
submitted by theforwardbrain to BitcoinMarkets [link] [comments]

Warning: Blockchain difficulty adjustment affecting price movement

Warning: Blockchain difficulty adjustment affecting price movement
Below are notable difficulty adjustments when hash rate fell and block times become slower for Bitcoin.
  1. 26 Mar 2020 [difficulty adjustment -15.95%, avg block time 11min 54secs]. On the 28th price crashed from $6674 to $6138 ( -8%).
  2. 8 Nov 2019 [difficulty adjustment -7.1%, avg block time 10min 46secs]. On the same day price crashed from $9234 to $8783 ( -4.88%).
  3. The next big adjustment was around Nov to Dec 2018 and there were 3 big adjustments with high block times.
  • 19 Dec 2018 [-9.56%, avg block time 11min 3secs]
  • 3 Dec 2018 [-15.13%, avg block time 11min 47secs]
  • 17 Nov 2018 [-7.39%, avg block time 10min 48secs]
  • There was huge drop off starting on 14th Nov all the way to a bottom on 14-15th Dec ($6351 to $3288 around -48%).

Current situation:
We are 1 day 10 hours from the next difficulty adjustment. Projected difficulty adjustment is -5.61% (https://fork.lol/pow/retarget), which could indicate a small dip. However, take note that the date of last adjustment was the 5th and the 3rd halving was on the 11th, between the 5th to the 11th there was increased hashrate from miners trying to mine the final week of 12.5btc that offset the really slow block times after the halving. Therefore it will be the next difficulty adjustment after the one on the 20th that will completely reflect the slower block times after the halving. Currently the median block time taken on the 17th was around 14min (-28.5% difficulty adjustment).

https://preview.redd.it/ysnv85wh0lz41.jpg?width=597&format=pjpg&auto=webp&s=e130b077f9dc2fc9d02666ef89e6f9249a05f535
For people who do not understand blockchain, basically with the Bitcoin 3rd halving, mining profitability fell for a lot of miners and they probably turned off their miners therefore the blockchain mining time became considerably slower which is reflected with slow transaction speed and higher fees as seen currently. Bitcoin sellers moving their BTC from wallet to an exchange are faced with slow transaction speed and therefore the sell pressure of BTC fell considerably which will attribute to the current price increase. There is a correlation between sell pressure and blockchain congestion (the size of the correlation is undetermined).
There is going to be a race. A race between BTC price hiking high enough to attract more miners to reduce avg block times versus the closing window of roughly 2 weeks before the next difficulty adjustment. If the price does not jump high enough, the next difficulty adjustment in the first week of June could signal a huge dip.
I am not an expert. I just did some research on the above and wanted to share with fellow Bitcoin compatriots so that we can tread with caution and not lose our shirts. I do not plan to short BTC but I will exit my BTC positions if I expect double digit negative difficulty adjustment in early June.

Bitcoin 2nd halving evidence:

2nd halving falls between the 5th and the 19th adjustment so it is only reflected on the 3rd of Aug difficulty adjustment ( -5.43%).

See the dip on the 3rd of August. Price fell from $600 to $533 about 11% drop.
Update 1:>! As of writing, I have opened a small short position on Bitcoin. Stop loss around 10k, estimated take profit around 8500. The reason is because the difficulty adjustment in the next 20 hours, even though is just -5% roughly is still significant. I direct you to look into all the difficulty adjustments in the last 2 years and you will know how rare it is. The ones I caught were all listed at the very top of the post. Since it is my first time shorting BTC, I take this as a learning opportunity so that I will have some experience to face the bigger difficulty adjustment in the first week of June. Analysis into execution, even in failure I am happy.!<
Update 2: The difficulty adjustment (DA) happened roughly 6 hours ago and the sell pressure from -6% DA did not seem to be affecting the market much. However, please take a look now at the estimation for the next DA.
On https://bitcoin.clarkmoody.com/dashboard/ it is estimated to be -25%.
On https://fork.lol/pow/retarget estimated to be -18%.
On https://www.blockchain.com/charts/median-confirmation-time the median block time for the last day was 16.8min.
My original proposition that the true DA of the halving can only be realized in the next DA stands and that it will be considerable. The increased sell pressure from that DA will be highly significant. That is why there is a race by current miners to get the BTC price up high enough to attract more miners to not have the DA drop too much.
References:
Difficulty adjustment dates taken from https://btc.com/stats/diff
Bitcoin graph history for price movement taken from coinmarketcap.
Median confirmation time (block time) taken from https://www.blockchain.com/charts/median-confirmation-time

Credits to people who assisted the analysis:
kairepaire for pointing out faster block times between 5th-11th.
babies_eater for https://fork.lol/pow/retarget
moes_tavern_wifi for https://bitcoin.clarkmoody.com/dashboard/
Pantamis for https://diff.cryptothis.com/
submitted by theforwardbrain to Bitcoin [link] [comments]

Transcript of discussion between an ASIC designer and several proof-of-work designers from #monero-pow channel on Freenode this morning

[08:07:01] lukminer contains precompiled cn/r math sequences for some blocks: https://lukminer.org/2019/03/09/oh-kay-v4r-here-we-come/
[08:07:11] try that with RandomX :P
[08:09:00] tevador: are you ready for some RandomX feedback? it looks like the CNv4 is slowly stabilizing, hashrate comes down...
[08:09:07] how does it even make sense to precompile it?
[08:09:14] mine 1% faster for 2 minutes?
[08:09:35] naturally we think the entire asic-resistance strategy is doomed to fail :) but that's a high-level thing, who knows. people may think it's great.
[08:09:49] about RandomX: looks like the cache size was chosen to make it GPU-hard
[08:09:56] looking forward to more docs
[08:11:38] after initial skimming, I would think it's possible to make a 10x asic for RandomX. But at least for us, we will only make an ASIC if there is not a total ASIC hostility there in the first place. That's better for the secret miners then.
[08:13:12] What I propose is this: we are working on an Ethash ASIC right now, and once we have that working, we would invite tevador or whoever wants to come to HK/Shenzhen and we walk you guys through how we would make a RandomX ASIC. You can then process this input in any way you like. Something like that.
[08:13:49] unless asics (or other accelerators) re-emerge on XMR faster than expected, it looks like there is a little bit of time before RandomX rollout
[08:14:22] 10x in what measure? $/hash or watt/hash?
[08:14:46] watt/hash
[08:15:19] so you can make 10 times more efficient double precisio FPU?
[08:16:02] like I said let's try to be productive. You are having me here, let's work together!
[08:16:15] continue with RandomX, publish more docs. that's always helpful.
[08:16:37] I'm trying to understand how it's possible at all. Why AMD/Intel are so inefficient at running FP calculations?
[08:18:05] midipoet ([email protected]/web/irccloud.com/x-vszshqqxwybvtsjm) has joined #monero-pow
[08:18:17] hardware development works the other way round. We start with 1) math then 2) optimization priority 3) hw/sw boundary 4) IP selection 5) physical implementation
[08:22:32] This still doesn't explain at which point you get 10x
[08:23:07] Weren't you the ones claiming "We can accelerate ProgPoW by a factor of 3x to 8x." ? I find it hard to believe too.
[08:30:20] sure
[08:30:26] so my idea: first we finish our current chip
[08:30:35] from simulation to silicon :)
[08:30:40] we love this stuff... we do it anyway
[08:30:59] now we have a communication channel, and we don't call each other names immediately anymore: big progress!
[08:31:06] you know, we russians have a saying "it was smooth on paper, but they forgot about ravines"
[08:31:12] So I need a bit more details
[08:31:16] ha ha. good!
[08:31:31] that's why I want to avoid to just make claims
[08:31:34] let's work
[08:31:40] RandomX comes in Sep/Oct, right?
[08:31:45] Maybe
[08:32:20] We need to audit it first
[08:32:31] ok
[08:32:59] we don't make chips to prove sw devs that their assumptions about hardware are wrong. especially not if these guys then promptly hardfork and move to the next wrong assumption :)
[08:33:10] from the outside, this only means that hw & sw are devaluing each other
[08:33:24] neither of us should do this
[08:33:47] we are making chips that can hopefully accelerate more crypto ops in the future
[08:33:52] signing, verifying, proving, etc.
[08:34:02] PoW is just a feature like others
[08:34:18] sech1: is it easy for you to come to Hong Kong? (visa-wise)
[08:34:20] or difficult?
[08:34:33] or are you there sometimes?
[08:34:41] It's kind of far away
[08:35:13] we are looking forward to more RandomX docs. that's the first step.
[08:35:31] I want to avoid that we have some meme "Linzhi says they can accelerate XYZ by factor x" .... "ha ha ha"
[08:35:37] right? we don't want that :)
[08:35:39] doc is almost finished
[08:35:40] What docs do you need? It's described pretty good
[08:35:41] so I better say nothing now
[08:35:50] we focus on our Ethash chip
[08:36:05] then based on that, we are happy to walk interested people through the design and what else it can do
[08:36:22] that's a better approach from my view than making claims that are laughed away (rightfully so, because no silicon...)
[08:36:37] ethash ASIC is basically a glorified memory controller
[08:36:39] sech1: tevador said something more is coming (he just did it again)
[08:37:03] yes, some parts of RandomX are not described well
[08:37:10] like dataset access logic
[08:37:37] RandomX looks like progpow for CPU
[08:37:54] yes
[08:38:03] it is designed to reflect CPU
[08:38:34] so any ASIC for it = CPU in essence
[08:39:04] of course there are still some things in regular CPU that can be thrown away for RandomX
[08:40:20] uncore parts are not used, but those will use very little power
[08:40:37] except for memory controller
[08:41:09] I'm just surprised sometimes, ok? let me ask: have you designed or taped out an asic before? isn't it risky to make assumptions about things that are largely unknown?
[08:41:23] I would worry
[08:41:31] that I get something wrong...
[08:41:44] but I also worry like crazy that CNv4 will blow up, where you guys seem to be relaxed
[08:42:06] I didn't want to bring up anything RandomX because CNv4 is such a nailbiter... :)
[08:42:15] how do you guys know you don't have asics in a week or two?
[08:42:38] we don't have experience with ASIC design, but RandomX is simply designed to exactly fit CPU capabilities, which is the best you can do anyways
[08:43:09] similar as ProgPoW did with GPUs
[08:43:14] some people say they want to do asic-resistance only until the vast majority of coins has been issued
[08:43:21] that's at least reasonable
[08:43:43] yeah but progpow totally will not work as advertised :)
[08:44:08] yeah, I've seen that comment about progpow a few times already
[08:44:11] which is no surprise if you know it's just a random sales story to sell a few more GPUs
[08:44:13] RandomX is not permanent, we are expecting to switch to ASIC friendly in a few years if possible
[08:44:18] yes
[08:44:21] that makes sense
[08:44:40] linzhi-sonia: how so? will it break or will it be asic-able with decent performance gains?
[08:44:41] are you happy with CNv4 so far?
[08:45:10] ah, long story. progpow is a masterpiece of deception, let's not get into it here.
[08:45:21] if you know chip marketing it makes more sense
[08:45:24] linzhi-sonia: So far? lol! a bit early to tell, don't you think?
[08:45:35] the diff is coming down
[08:45:41] first few hours looked scary
[08:45:43] I remain skeptical: I only see ASICs being reasonable if they are already as ubiquitous as smartphones
[08:45:46] yes, so far so good
[08:46:01] we kbew the diff would not come down ubtil affter block 75
[08:46:10] yes
[08:46:22] but first few hours it looks like only 5% hashrate left
[08:46:27] looked
[08:46:29] now it's better
[08:46:51] the next worry is: when will "unexplainable" hashrate come back?
[08:47:00] you hope 2-3 months? more?
[08:47:05] so give it another couple of days. will probably overshoot to the downside, and then rise a bit as miners get updated and return
[08:47:22] 3 months minimum turnaround, yes
[08:47:28] nah
[08:47:36] don't underestimate asicmakers :)
[08:47:54] you guys don't get #1 priority on chip fabs
[08:47:56] 3 months = 90 days. do you know what is happening in those 90 days exactly? I'm pretty sure you don't. same thing as before.
[08:48:13] we don't do any secret chips btw
[08:48:21] 3 months assumes they had a complete design ready to go, and added the last minute change in 1 day
[08:48:24] do you know who is behind the hashrate that is now bricked?
[08:48:27] innosilicon?
[08:48:34] hyc: no no, and no. :)
[08:48:44] hyc: have you designed or taped out a chip before?
[08:48:51] yes, many years ago
[08:49:10] then you should know that 90 days is not a fixed number
[08:49:35] sure, but like I said, other makers have greater demand
[08:49:35] especially not if you can prepare, if you just have to modify something, or you have more programmability in the chip than some people assume
[08:50:07] we are chipmakers, we would never dare to do what you guys are doing with CNv4 :) but maybe that just means you are cooler!
[08:50:07] and yes, programmability makes some aspect of turnaround easier
[08:50:10] all fine
[08:50:10] I hope it works!
[08:50:28] do you know who is behind the hashrate that is now bricked?
[08:50:29] inno?
[08:50:41] we suspect so, but have no evidence
[08:50:44] maybe we can try to find them, but we cannot spend too much time on this
[08:50:53] it's probably not so much of a secret
[08:51:01] why should it be, right?
[08:51:10] devs want this cat-and-mouse game? devs get it...
[08:51:35] there was one leak saying it's innosilicon
[08:51:36] so you think 3 months, ok
[08:51:43] inno is cool
[08:51:46] good team
[08:51:49] IP design house
[08:51:54] in Wuhan
[08:52:06] they send their people to conferences with fake biz cards :)
[08:52:19] pretending to be other companies?
[08:52:26] sure
[08:52:28] ha ha
[08:52:39] so when we see them, we look at whatever card they carry and laugh :)
[08:52:52] they are perfectly suited for secret mining games
[08:52:59] they made at most $6 million in 2 months of mining, so I wonder if it was worth it
[08:53:10] yeah. no way to know
[08:53:15] but it's good that you calculate!
[08:53:24] this is all about cost/benefit
[08:53:25] then you also understand - imagine the value of XMR goes up 5x, 10x
[08:53:34] that whole "asic resistance" thing will come down like a house of cards
[08:53:41] I would imagine they sell immediately
[08:53:53] the investor may fully understand the risk
[08:53:57] the buyer
[08:54:13] it's not healthy, but that's another discussion
[08:54:23] so mid-June
[08:54:27] let's see
[08:54:49] I would be susprised if CNv4 ASICs show up at all
[08:54:56] surprised*
[08:54:56] why?
[08:55:05] is only an economic question
[08:55:12] yeah should be interesting. FPGAs will be near their limits as well
[08:55:16] unless XMR goes up a lot
[08:55:19] no, not *only*. it's also a technology question
[08:55:44] you believe CNv4 is "asic resistant"? which feature?
[08:55:53] it's not
[08:55:59] cnv4 = Rabdomx ?
[08:56:03] no
[08:56:07] cnv4=cryptinight/r
[08:56:11] ah
[08:56:18] CNv4 is the one we have now, I think
[08:56:21] since yesterday
[08:56:30] it's plenty enough resistant for current XMR price
[08:56:45] that may be, yes!
[08:56:55] I look at daily payouts. XMR = ca. 100k USD / day
[08:57:03] it can hold until October, but it's not asic resistant
[08:57:23] well, last 24h only 22,442 USD :)
[08:57:32] I think 80 h/s per watt ASICs are possible for CNv4
[08:57:38] linzhi-sonia where do you produce your chips? TSMC?
[08:57:44] I'm cruious how you would expect to build a randomX ASIC that outperforms ARM cores for efficiency, or Intel cores for raw speed
[08:57:48] curious
[08:58:01] yes, tsmc
[08:58:21] Our team did the world's first bitcoin asic, Avalon
[08:58:25] and upcoming 2nd gen Ryzens (64-core EPYC) will be a blast at RandomX
[08:58:28] designed and manufactured
[08:58:53] still being marketed?
[08:59:03] linzhi-sonia: do you understand what xmr wants to achieve, community-wise?
[08:59:14] Avalon? as part of Canaan Creative, yes I think so.
[08:59:25] there's not much interesting oing on in SHA256
[08:59:29] Inge-: I would think so, but please speak
[08:59:32] hyc: yes
[09:00:28] linzhi-sonia: i am curious to hear your thoughts. I am fairly new to this space myself...
[09:00:51] oh
[09:00:56] we are grandpas, and grandmas
[09:01:36] yet I have no problem understanding why ASICS are currently reviled.
[09:01:48] xmr's main differentiators to, let's say btc, are anonymity and fungibility
[09:01:58] I find the client terribly slow btw
[09:02:21] and I think the asic-forking since last may is wrong, doesn't create value and doesn't help with the project objectives
[09:02:25] which "the client" ?
[09:02:52] Monero GUI client maybe
[09:03:12] MacOS, yes
[09:03:28] What exactly is slow?
[09:03:30] linzhi-sonia: I run my own node, and use the CLI and Monerujo. Have not had issues.
[09:03:49] staying in sync
[09:03:49] linzhi-sonia: decentralization is also a key principle
[09:03:56] one that Bitcoin has failed to maintain
[09:04:39] hmm
[09:05:00] looks fairly decentralized to me. decentralization is the result of 3 goals imo: resilient, trustless, permissionless
[09:05:28] don't ask a hardware maker about physical decentralization. that's too ideological. we focus on logical decentralization.
[09:06:11] physical decentralization is important. with bulk of bitnoin mining centered on Chinese hydroelectric dams
[09:06:19] have you thought about including block data in the PoW?
[09:06:41] yes, of course.
[09:07:39] is that already in an algo?
[09:08:10] hyc: about "centered on chinese hydro" - what is your source? the best paper I know is this: https://coinshares.co.uk/wp-content/uploads/2018/11/Mining-Whitepaper-Final.pdf
[09:09:01] linzhi-sonia: do you mine on your ASICs before you sell them?
[09:09:13] besides testing of course
[09:09:45] that paper puts Chinese btc miners at 60% max
[09:10:05] tevador: I think everybody learned that that is not healthy long-term!
[09:10:16] because it gives the chipmaker a cost advantage over its own customers
[09:10:33] and cost advantage leads to centralization (physical and logical)
[09:10:51] you guys should know who finances progpow and why :)
[09:11:05] but let's not get into this, ha ha. want to keep the channel civilized. right OhGodAGirl ? :)
[09:11:34] tevador: so the answer is no! 100% and definitely no
[09:11:54] that "self-mining" disease was one of the problems we have now with asics, and their bad reputation (rightfully so)
[09:13:08] I plan to write a nice short 2-page paper or so on our chip design process. maybe it's interesting to some people here.
[09:13:15] basically the 5 steps I mentioned before, from math to physical
[09:13:32] linzhi-sonia: the paper you linked puts 48% of bitcoin mining in Sichuan. the total in China is much more than 60%
[09:13:38] need to run it by a few people to fix bugs, will post it here when published
[09:14:06] hyc: ok! I am just sharing the "best" document I know today. it definitely may be wrong and there may be a better one now.
[09:14:18] hyc: if you see some reports, please share
[09:14:51] hey I am really curious about this: where is a PoW algo that puts block data into the PoW?
[09:15:02] the previous paper I read is from here http://hackingdistributed.com/2018/01/15/decentralization-bitcoin-ethereum/
[09:15:38] hyc: you said that already exists? (block data in PoW)
[09:15:45] it would make verification harder
[09:15:49] linzhi-sonia: https://the-eye.eu/public/Books/campdivision.com/PDF/Computers%20General/Privacy/bitcoin/meh/hashimoto.pdf
[09:15:51] but for chips it would be interesting
[09:15:52] we discussed the possibility about a year ago https://www.reddit.com/Monero/comments/8bshrx/what_we_need_to_know_about_proof_of_work_pow/
[09:16:05] oh good links! thanks! need to read...
[09:16:06] I think that paper by dryja was original
[09:17:53] since we have a nice flow - second question I'm very curious about: has anyone thought about in-protocol rewards for other functions?
[09:18:55] we've discussed micropayments for wallets to use remote nodes
[09:18:55] you know there is a lot of work in other coins about STARK provers, zero-knowledge, etc. many of those things very compute intense, or need to be outsourced to a service (zether). For chipmakers, in-protocol rewards create an economic incentive to accelerate those things.
[09:19:50] whenever there is an in-protocol reward, you may get the power of ASICs doing something you actually want to happen
[09:19:52] it would be nice if there was some economic reward for running a fullnode, but no one has come up with much more than that afaik
[09:19:54] instead of fighting them off
[09:20:29] you need to use asics, not fight them. that's an obvious thing to say for an asicmaker...
[09:20:41] in-protocol rewards can be very powerful
[09:20:50] like I said before - unless the ASICs are so useful they're embedded in every smartphone, I dont see them being a positive for decentralization
[09:21:17] if they're a separate product, the average consumer is not going to buy them
[09:21:20] now I was talking about speedup of verifying, signing, proving, etc.
[09:21:23] they won't even know what they are
[09:22:07] if anybody wants to talk about or design in-protocol rewards, please come talk to us
[09:22:08] the average consumer also doesn't use general purpose hardware to secure blockchains either
[09:22:14] not just for PoW, in fact *NOT* for PoW
[09:22:32] it requires sw/hw co-design
[09:23:10] we are in long-term discussions/collaboration over this with Ethereum, Bitcoin Cash. just talk right now.
[09:23:16] this was recently published though suggesting more uptake though I guess https://btcmanager.com/college-students-are-the-second-biggest-miners-of-cryptocurrency/
[09:23:29] I find it pretty hard to believe their numbers
[09:24:03] well
[09:24:09] sorry, original article: https://www.pcmag.com/news/366952/college-kids-are-using-campus-electricity-to-mine-crypto
[09:24:11] just talk, no? rumors
[09:24:18] college students are already more educated than the average consumer
[09:24:29] we are not seeing many such customers anymore
[09:24:30] it's data from cisco monitoring network traffic
[09:24:33] and they're always looking for free money
[09:24:48] of course anyone with "free" electricity is inclined to do it
[09:24:57] but look at the rates, cannot make much money
[09:26:06] Ethereum is a bloated collection of bugs wrapped in a UI. I suppose they need all the help they can get
[09:26:29] Bitcoin Cash ... just another get rich quick scheme
[09:26:38] hmm :)
[09:26:51] I'll give it back to you, ok? ha ha. arrogance comes before the fall...
[09:27:17] maye we should have a little fun with CNv4 mining :)
[09:27:25] ;)
[09:27:38] come on. anyone who has watched their track record... $75M lost in ETH at DAO hack
[09:27:50] every smart contract that comes along is just waiting for another hack
[09:27:58] I just wanted to throw out the "in-protocol reward" thing, maybe someone sees the idea and wants to cowork. maybe not. maybe it's a stupid idea.
[09:29:18] linzhi-sonia: any thoughts on CN-GPU?
[09:29:55] CN-GPU has one positive aspect - it wastes chip area to implement all 18 hash algorithms
[09:30:19] you will always hear roughly the same feedback from me:
[09:30:52] "This algorithm very different, it heavy use floating point operations to hurt FPGAs and general purpose CPUs"
[09:30:56] the problem is, if it's profitable for people to buy ASIC miners and mine, it's always more profitable for the manufacturer to not sell and mine themselves
[09:31:02] "hurt"
[09:31:07] what is the point of this?
[09:31:15] it totally doesn't work
[09:31:24] you are hurting noone, just demonstrating lack of ability to think
[09:31:41] what is better: algo designed for chip, or chip designed for algo?
[09:31:43] fireice does it on daily basis, CN-GPU is a joke
[09:31:53] tevador: that's not really true, especially in a market with such large price fluctuations as cryptocurrency
[09:32:12] it's far less risky to sell miners than mine with them and pray that price doesn't crash for next six months
[09:32:14] I think it's great that crypto has a nice group of asicmakers now, hw & sw will cowork well
[09:32:36] jwinterm yes, that's why they premine them and sell after
[09:32:41] PoW is about being thermodynamically and cryptographically provable
[09:32:45] premining with them is taking on that risk
[09:32:49] not "fork when we think there are asics"
[09:32:51] business is about risk minimization
[09:32:54] that's just fear-driven
[09:33:05] Inge-: that's roughly the feedback
[09:33:24] I'm not saying it hasn't happened, but I think it's not so simple as saying "it always happens"
[09:34:00] jwinterm: it has certainly happened on BTC. and also on XMR.
[09:34:19] ironically, please think about it: these kinds of algos indeed prove the limits of the chips they were designed for. but they don't prove that you cannot implement the same algo differently! cannot!
[09:34:26] Risk minimization is not starting a business at all.
[09:34:34] proof-of-gpu-limit. proof-of-cpu-limit.
[09:34:37] imagine you have a money printing machine, would you sell it?
[09:34:39] proves nothing for an ASIC :)
[09:35:05] linzhi-sonia: thanks. I dont think anyone believes you can't make a more efficient cn-gpu asic than a gpu - but that it would not be orders of magnitude faster...
[09:35:24] ok
[09:35:44] like I say. these algos are, that's really ironic, designed to prove the limitatios of a particular chip in mind of the designer
[09:35:50] exactly the wrong way round :)
[09:36:16] like the cache size in RandomX :)
[09:36:18] beautiful
[09:36:29] someone looked at GPU designs
[09:37:31] linzhi-sonia can you elaborate? Cache size in RandomX was selected to fit CPU cache
[09:37:52] yes
[09:38:03] too large for GPU
[09:38:11] as I said, we are designing the algorithm to exactly fit CPU capabilities, I do not claim an ASIC cannot be more efficient
[09:38:16] ok!
[09:38:29] when will you do the audit?
[09:38:35] will the results be published in a document or so?
[09:38:37] I claim that single-chip ASIC is not viable, though
[09:39:06] you guys are brave, noone disputes that. 3 anti-asic hardforks now!
[09:39:18] 4th one coming
[09:39:31] 3 forks were done not only for this
[09:39:38] they had scheduled updates in the first place
[09:48:10] Monero is the #1 anti-asic fighter
[09:48:25] Monero is #1 for a lot of reasons ;)
[09:48:40] It's the coin with the most hycs.
[09:48:55] mooooo
[09:59:06] sneaky integer overflow, bug squished
[10:38:00] p0nziph0ne ([email protected]/vpn/privateinternetaccess/p0nziph0ne) has joined #monero-pow
[11:10:53] The convo here is wild
[11:12:29] it's like geo-politics at the intersection of software and hardware manufacturing for thermoeconomic value.
[11:13:05] ..and on a Sunday.
[11:15:43] midipoet: hw and sw should work together and stop silly games to devalue each other. to outsiders this is totally not attractive.
[11:16:07] I appreciate the positive energy here to try to listen, learn, understand.
[11:16:10] that's a start
[11:16:48] <-- p0nziph0ne ([email protected]/vpn/privateinternetaccess/p0nziph0ne) has quit (Quit: Leaving)
[11:16:54] we won't do silly mining against xmr "community" wishes, but not because we couldn'd do it, but because it's the wrong direction in the long run, for both sides
[11:18:57] linzhi-sonia: I agree to some extent. Though, in reality, there will always be divergence between social worlds. Not every body has the same vision of the future. Reaching societal consensus on reality tomorrow is not always easy
[11:20:25] absolutely. especially at a time when there is so much profit to be made from divisiveness.
[11:20:37] someone will want to make that profit, for sure
[11:24:32] Yes. Money distorts.
[11:24:47] Or wealth...one of the two
[11:26:35] Too much physical money will distort rays of light passing close to it indeed.
submitted by jwinterm to Monero [link] [comments]

Xthinner mainnet compression performance stats

I've been collecting some compression efficiency data on BCH mainnet blocks with Xthinner for the last 1.5 days, and thought I would share some results.
Of the last 200 blocks, there were 13 instances in which the recipient was missing one or more transactions and had to fetch with a round trip, for a 6.5% fetch rate.
I calculated the compression efficiency in 3 separate ways:
  1. With all data sent by Xthinner, including the shortID segment, the missing transactions, the coinbase transaction, and the block header;
  2. With the shortIDs, coinbase, and header, but not the missing transactions; and
  3. With only the shortIDs.
The mean compression rates for these 201 blocks were as follows:
99.563% without cb+header+missing 99.385% with cb+header w/o missing 99.209% with everything 
In terms of bits/tx, those numbers are:
14.021 bits/tx without cb+header+missing 19.721 bits/tx w cb+header w/o missing 25.348 bits/tx with everything 
The average block size during this test was 327 tx/block or 131 kB/block. I expect these numbers to tend towards 12 bits/tx asymptotically as block sizes increase.
These numbers were calculated using the sum of the Xthinner message sizes divided by the sum of the block sizes, rather than the mean of the individual blocks' compression rates. This means that my mean compression numbers are weighted by block size.
In comparison, bissias reported yesterday that Graphene got a median compression (with everything) of 98.878% on these dinky mainnet BCH block sizes. Graphene does much better at large block sizes, though, getting up to 99.88% on the biggest blocks, which is about 2x-3x better than the best Xthinner can do.
Except for the missing transactions, there were 0 errors decoding Xthinner messages. Specifically, of the last 201 blocks, there were 0 instances of Xthinner encoding too little information to disambiguate between transactions in the recipient's mempool, and there were 0 instances of checksum errors during decoding. (This is normal and expected for normal operation. In adversarial cases or extreme stress-test scenarios with desynced mempools, these numbers might go up, but if they do they only cause an extra round trip.
The full dataset of 201 blocks (with lame formatting) can be found here.
Astute observers might notice that this performance result is much better than what I first reported, in which around 75% of blocks had "missing" transactions. It turns out that these were actually decoding ambiguities caused by my encoder having an off-by-one error when finding the nearest mempool neighbor. Oopsies. Fixed. I also changed my test setup to have better and more realistic mempool synchrony. These two changes lowered the missing transaction rate to about 6.5% of blocks.
If anyone wants to dig into the code or play around with it, you can find it here. Keep in mind that there may still be remote crash or remote code execution vulnerabilities, so don't run this code on anything you want to not get hacked.
Edit: I think I prefer the alternate formulation for compression ratios in which 0% is the ideal. Using that formula, Xthinner was able to compress the blocks down to an average of
0.437% without cb+header+missing 0.615% with cb+header w/o missing 0.781% with everything 
of their original size, whereas Graphene was able to get to1.122% on the median block, and 0.117% on the best block.
Edit2: If we examine only the 5 blocks with more than 1000 tx in them, we get:
Fetched transactions 0 of 5 times Mean compression: 0.390% without cb+header 0.420% with everything 13.285 bits/tx average 12.330 bits/tx without coinbase+header 
Edit4: It's been almost two weeks, and I now have 197 blocks over 1k tx in the dataset:
Fetched transactions 9 of 107 times 0 ambiguities, 0 checksum errors Mean compression: 99.563% without cb+header+missing 99.518% with cb+header w/o missing 99.500% with everything 14.522 bits/tx average with missing, 14.017 bits/tx average without 12.701 bits/tx without coinbase+header 
submitted by jtoomim to btc [link] [comments]

down the Node-Red rabbit hole, part 5 - hold my beer

part1 part2 part3 part4
so, it's been 4 months since i started this journey and i gotta say that NR has really re-vitalized my personal interest in home-automation, as well as, my HA and whole house setup.
i've done more in the past 4 months, to streamline my setup and adding new automations than i've done in the three years since i started using HA somewhere around v0.24.x'ish. i got that shit dialed in now.
(also some credit to EspHome for being awesome, despite having meh documentation. yeah, i said it. meh👏doc👏u👏men👏ta👏shun)
at this point i have about 36 NR tabs. some are just testing, or playing around with a particular component/palette, but most have at least one flow on it that is live and in use.
so, i thought i'd break some of them down for you guys, 'barney style+':
(also, some of these are way to huge to post readable screenshots of, so i'm just gonna describe them. plus some of these i detailed in my previous posts.)
first up is my globals. where i set global.vars
arrive/away
morning/bedtime/naptime
alarm
sonos
ping
watchdog
battery (the nodes are very similar to above)
switch control
harmony
remote
long term away
spotify
washedryer
doorbell
disk space
gmail
calendar
alexa TTS (subflow)
drafthouse
twitter link
so, yeah. i'd like to see some of you post some of your flows/ideas if only so i could totally steal them.
.
.
+obscure skippy joke. it's from a book++.
++yes i read. well, i audiobook, but same diff+++.
+++i mean, it's just basic science!++++
++++i mean, that study coulda been bullshit, sponsored by "the audiobook council" or some shit, but i'm taking it at face value.
submitted by stoneobscurity to homeassistant [link] [comments]

I literally have tens of thousands of dollars in top-shelf hardware, looking to repurpose some before selling on eBay to build a NAS system, possibly a dedicated firewall device as well. o_O

Q1) What will you be doing with this PC? Be as specific as possible, and include specific games or programs you will be using.**

A1) This will be a dedicated NAS system for my home network. As such, I'm looking to have it:

- Host ##TB's of 720, 1080 & up resolution Movies and TV Shows I'm about to begin ripping from a MASSIVE DVD & Blueray collection I have.

- My kids are big on Minecraft. I understand it's possible to host your own "worlds" (or whatever they call the maps you can build) on your own "server". I think it would be pretty neat to offer them (& their friends - if can be done 'safely/securely') their own partition on one of my NAS HDD's.

- I also have accounts with a couple diff VPN companies... I understand it's possible (?) to sync said VPN's with a NAS, this might be a more relative topic on the next point/purpose...

- I'd like to be able to remotely link to this NAS for when I travel overseas and want to stream at my temp location from my house/this NAS.
______________________
Q2) What is your maximum budget before rebates/shipping/taxes?**

* A2) Here's where I make matters more complicated than most others would... I've been an advocate for Bitcoin and crypto-currencies in general since 2013. I invested in a small mining outfit back in 2014 (strictly Bitcoin/ASIC's). One of my buddies is the President of a large-scale mining operation (foreign and domestic) and he convinced me to dabble in the GPU mining-space. I made my first hardware purchase in Q4, 2017 and launched a small-scale GPU-Farm in my house since then. I had the rigs mining up until Q3 of 2018 (not cost-efficient to keep on, especially living in SoFlo) and since then, the hardware's been collecting dust (& pissing off my family members since they lost access to 3X rooms in the house - I won't let anyone go near my gear). One of my New Years Resolutions for 2019 was to clear out the house of all my mining equipment so that's all about to go up on eBay. So "budget" is relative to whatever I "MUST" spend if I can't repurpose any of the parts I already have on hand for this build... (Anyone having something I "need" and is looking to barter for one of the items I'll list later on in here, LMK).
______________________
Q3) When do you plan on building/buying the PC? Note: beyond a week or two from today means any build you receive will be out of date when you want to buy.**

A3) IMMEDIATELY! :)
______________________
Q4) What, exactly, do you need included in the budget? (ToweOS/monitokeyboard/mouse/etc\)**

A4) Well I had a half-assed idea approximately 1 year ago that it might be wise to build a bunch of 'gaming rigs' to sell on eBay with my intended repurposed mining hardware so I went on a shopping spree for like 6 months. That said; I've got a plethora of various other components that aren't even unboxed yet. 90% of the items I've purchased for this additional project were items that were marked down via MIR (mail-in-rebates) & what-not...
AFAIK, there are only 3X items I absolutely do not have which I 'MUST' find. Those would be - 1) Motherboard which accepts "ECC RAM". 2) CPU for said MOBO. 3) Said "ECC RAM".\* 
______________________
Q5) Which country (and state/province) will you be purchasing the parts in? If you're in US, do you have access to a Microcenter location?**

A5) I'm located in Southwest Florida. No Microcenter's here. Best Buy is pretty much my only option although I am a member of Newegg, Amazon & Costco if that makes any difference?
______________________
Q6) If reusing any parts (including monitor(s)/keyboard/mouse/etc), what parts will you be reusing? Brands and models are appreciated.**

A6) In an attempt to better clean up this Q&A, I'm going to list the items I have on-hand at the end of this questionnaire in-case passers-by feel like this might be a TLDR.* (Scroll to the bottom & you'll see what I mean).
______________________
Q7) Will you be overclocking? If yes, are you interested in overclocking right away, or down the line? CPU and/or GPU?**

A7) I don't think that's necessary for my intended purpose although - I'm not against it if that helps & FWIW, I'm pretty skilled @ this task already (it's not rocket science).
______________________
Q8) Are there any specific features or items you want/need in the build? (ex: SSD, large amount of storage or a RAID setup, CUDA or OpenCL support, etc)**

A8) As stated in A4; ECC RAM is non-negotiable... RAID seems like a logical application here as well.

- This will predominantly be receiving commands from MacOS computers. I don't think that matters really but figured it couldn't hurt to let you guys know.\*

- I'd also be quite fond of implementing "PFSENSE" (or something of that caliber) applied to this system so I could give my Netgear Nighthawks less stress in that arena, plus my limited understanding of PFSENSE is that it's ability to act as a firewall runs circles around anything that comes with consumer-grade Wi-Fi routers (like my Nighthawks). Just the same, I'm open to building a second rig just for the firewall.\*

- Another desirable feature would be that it draws as little electricity from the wall as possible. (I'm EXTREMELY skilled in this arena. I have "Kill-A-Watts" to test/gauge on, as well as an intimate understanding of the differences between Silver, Gold, Platinum and Titanium rated PSU's. As well as having already measured each of the PSU's I have on-hand and taken note of the 'target TDP draw' ("Peak Power Efficiency Draw") each one offers when primed with X amount of GPU's when I used them for their original purpose.\*

- Last, but not least, sound (as in noise created from the rig). I'd like to prop this device up on my entertainment center in the living room. I've (almost) all of the top-shelf consumer grade products one could dream of regarding fans and other thermal-related artifacts.

- Almost forgot; this will be hosting to devices on the KODI platform (unless you guys have better alternative suggestions?)
______________________
Q9) Do you have any specific case preferences (Size like ITX/microATX/mid-towefull-tower, styles, colors, window or not, LED lighting, etc), or a particular color theme preference for the components?**

A9) Definitely! Desired theme would be WHITE. If that doesn't work for whatever reason, black or gray would suffice. Regarding "Case Size". Nah, that's not too important although I don't foresee a mini-ITX build making sense if I'm going to be cramming double digit amounts of TB in the system, Internal HDD's sounds better than a bunch of externals plugged in all the USB ports.
______________________
Q10) Do you need a copy of Windows included in the budget? If you do need one included, do you have a preference?**

A10) I don't know. If I do need a copy of Windows, I don't have one so that's something I'll have to consider I guess. I doubt that's a necessity though.
______________________
______________________
______________________
**Extra info or particulars:*\*

AND NOW TO THE FUN-STUFF... Here's a list of everything (PARTS PARTS PARTS) I have on-hand and ready to deploy into the wild &/or negotiate a trade/barter with:

CASES -
Corsair Carbide Series Air 540 Arctic White (Model# Crypto-Currency-9011048-WW) - (Probably my top pick for this build).
Cooler Master HAF XB EVO (This is probably my top 1st or 2nd pick for this build, the thing is a monster!).
Cooler Master Elite 130 - Mini ITX - Black
Cooler Master MasterBox 5 MID-Tower - Black & White
Raidmax Sigma-TWS - ATX - White
MasterBox Lite 5 - ATX - Black w/ diff. Colored accent attachments (included with purchase)
NZXT S340 Elite Matte White Steel/Tempered Glass Edition
EVGA DG-76 Alpine White - Mid Tower w/ window
EVGA DG-73 Black - Mid Tower w/ window (I have like 3 of these)

______________________
CPU's -
***7TH GEN OR BELOW INTEL's ("Code Name Class mentioned next to each one)**\*
Pentium G4400 (Skylake @54W TDP) - Intel ARK states is "ECC CAPABLE"
Celeron G3930 (Kaby Lake @ 51W TDP) - Intel ARK states is "ECC CAPABLE" :)
i5 6402P (Skylake @65W TDP) - Intel ARK states is "NOT ECC CAPABLE" :(
i5 6600k (Skylake @ 91W TDP) - Intel ARK states is "NOT ECC CAPABLE" :(
i7 6700 (Skylake @ 65W TDP) - Intel ARK states is "NOT ECC CAPABLE" :(
i7 7700k (Kaby Lake @ 95W TDP) - Intel ARK states is "NOT ECC CAPABLE" :(


***8TH GEN INTEL's **\*
i3-8350K (Coffee Lake @91W TDP) - Intel ARK states is "ECC FRIENDLY" :)
I5-8600K (Coffee Lake @95W TDP) - Intel ARK states is "NOT ECC CAPABLE" :(


***AMD RYZEN's **\*
Ryzen 3 2200G
Ryzen 5 1600
Ryzen 7 1700X

______________________
MOTHERBOARDS -

***7TH GEN AND BELOW INTEL BASED MOBO'S - **\*
MSI Z170A-SLI
ASUS PRIME Z270-A
ASUS PRIME Z270-P
ASUS PRIME Z270-K
EVGA Z270 Stinger
GIGABYTE GA-Z270XP-SLI
MSI B150M ARCTIC
MSI B250M MICRO ATX (PRO OPT. BOOST EDITION)

***8TH GEN INTEL BASED MOBO'S - **\*
EVGA Z370 FTW
GIGABYTE Z370XP SLI (Rev. 1.0)
MSI Z370 SLI PLUS


***AMD RYZEN BASED MOBO'S - **\*
ASUS ROG STRIX B350-F GAMING
MSI B350 TOMAHAWK
MSI X370 GAMING PRO
ASROCK AB350M PRO4
______________________


RAM -

Way too many to list, nothing but 4 & 8GB DDR4 sticks and unfortunately, none are ECC so it's not even worth mentioning/listing these unless someone reading this is willing to barter. At which time I'd be obliged to send an itemized list or see if I have what they're/you're specifically looking for.\*
______________________
THERMAL APPLICATIONS/FANS -
JUST FANS -
BeQuiet -
Pure Wings 2 (80mm)
Pure Wings 2 (120mm)
Pure Wings 2 (140mm)
Silent Wings 3 PWM (120mm)

NOCTUA -
PoopBrown - NF-A20 PWM (200mm) Specifically for the BIG "CoolerMaster HAF XB EVO" Case
GREY - NF-P12 Redux - 1700RPM (120mm) PWM
Corsair -
Air Series AF120LED (120mm)

CPU COOLING SYSTEMS -
NOCTUA -
NT-HH 1.4ml Thermal Compound
NH-D15 6 Heatpipe system (this thing is the tits)

EVGA (Extremely crappy coding in the software here, I'm like 99.99% these will be problematic if I were to try and use in any OS outside of Windows, because they barely ever work in the intended Windows as it is).
CLC 240 (240mm Water-cooled system
CRYORIG -
Cryorig C7 Cu (Low-Profile Copper Edition*)

A few other oversized CPU cooling systems I forget off the top of my head but a CPU cooler is a CPU cooler after comparing to the previous 3 models I mentioned.
I almost exclusively am using these amazing "Innovation Cooling Graphite Thermal Pads" as an alternative to thermal paste for my CPU's. They're not cheap but they literally last forever.

NZXT - Sentry Mesh Fan Controller
______________________
POWER SUPPLIES (PSU's) -
BeQuiet 550W Straight Power 11 (GOLD)

EVGA -
750P2 (750W, Platinum)
850P2 (850W, Platinum)
750T2 (750W, TITANIUM - yeah baby, yeah)

ROSEWILL -
Quark 750W Platinum
Quark 650W Platinum

SEASONIC -
Focus 750W Platinum
______________________
STORAGE -
HGST Ultrastar 3TB - 64mb Cache - 7200RPM Sata III (3.5)
4X Samsung 860 EVO 500GB SSD's
2X Team Group L5 LITE 3D 2.5" SSD's 480GB
2X WD 10TB Essential EXT (I'm cool with shucking)
+ 6X various other external HDD's (from 4-8TB) - (Seagate, WD & G-Drives)
______________________

Other accessories worth mentioning -
PCI-E to 4X USB hub-adapter (I have a dozen or so of these - might not be sufficient enough &/or needed but again, 'worth mentioning' in case I somehow ever run out of SATA & USB ports and have extra external USB HDD's. Although, I'm sure there would be better suited components if I get to that point that probably won't cost all that much).
______________________
______________________
______________________
Needless to say, I have at least 1X of everything mentioned above. In most all cases, I have multiples of these items but obviously won't be needing 2X CPU's, Cases, etc...

Naturally, I have GPU's. Specifically;

At least 1X of every. Single. NVIDIA GTX 1070 TI (Yes, I have every variation of the 1070 ti made by MSI, EVGA and Zotac. The only brand I don't have is the Gigabyte line. My partners have terrible experience with those so I didn't even bother. I'm clearly not going to be needing a GPU for this build but again, I'm cool with discussing the idea of a barter if anyone reading this is in the market for one.

I also have some GTX 1080 TI's but those are already spoken for, sorry.

It's my understanding that select CPU's I have on this list are ECC Friendly and AFAIK, only 1 of my MOBO's claims to be ECC Friendly (The ASROCK AB350M PRO4), but for the life of me, I can't find any corresponding forums that confirm this and/or direct me to a listing where I can buy compatible RAM. Just the same, if I go w/ the ASROCK MOBO, that means I'd be using one of the Ryzens. Those are DEF. power hungry little buggers. Not a deal-breaker, just hoping to find something a little more conservative in terms of TDP.


In closing, I don't really need someone to hold my hand with the build part as much as figuring out which motherboard, CPU and RAM to get. Then I'm DEFINITELY going to need some guidance on what OS is best for my desired purpose. If building 2X Rigs makes sense, I'm totally open to that as well...
Rig 1 = EPIC NAS SYSTEM
Rig 2 = EPIC PFSENSE (or the like) DEDICATED FIREWALL

Oh, I almost forgot... The current routers I'm using are...
1X Netgear Nighthawk 6900P (Modem + Router)
1X Netgear Nighthawk X6S (AC 4000 I believe - Router dedicated towards my personal devices - no IoT &/or Guests allowed on this one)
1X TP-Link Archer C5 (Router). Total overkill after implementing the Nighthawks but this old beast somehow has the best range, plus it has 2X USB ports so for now, it's dedicated towards my IoT devices.
---- I also have a few other Wi-Fi routers (Apple Airport Extreme & some inferior Netgear's but I can only allocate so many WiFi Routers to so many WiFi channels w/out pissing off my neighbors) On that note, I have managed to convince my neighbors to let me in their house/WiFi configuration so we all have our hardware locked on specific, non-competing frequencies/channels so everyone's happy. :)


Please spare me the insults as I insulted myself throughout this entire venture. Part of why I did this was because when I was a kid, I used to fantasize about building a 'DREAM PC' but could never afford such. To compensate for this deficiency, I would actually print out the latest and greatest hardware components on a word document, print the lists up & tape to wall (for motivation). I was C++ certified at the age of 14 and built my first PC when I was 7. At the age of 15 I abandoned all hope in the sector and moved on to other aspirations. This entire ordeal was largely based off me finally fulfilling a childhood fantasy. On that note = mission accomplished. Now if I'm actually able to fulfill my desires on this post, I'm definitely going to feel less shitty about blowing so much money on all this stuff over the last couple years.

TIA for assisting in any way possible. Gotta love the internets!


THE END.
:)

EDIT/UPDATE (5 hours after OP) - My inbox is being inundated with various people asking for prices and other reasonable questions about my hardware being up for sale. Not to be redundant but rather to expound on my previous remarks about 'being interested in a bartetrade' with any of you here...

I did say I was going to sell my gear on eBay in the near future, I also said I wanted to trade/barter for anything relative to helping me accomplish my OP's mission(s). I'm not desperate for the $$$ but I'm also not one of those people that likes to rip other people off. That said; I value my time and money invested in this hardware and I'm only willing to unload it all once I've established I have ZERO need for any of it here in my home first. Hence my writing this lengthy thread in an attempt to repurpose at least a grand or two I've already spent.

One of the most commonly asked questions I anticipate receiving from interested bodies is going to be "How hard were you on your hardware?" Contrary to what anyone else would have probably done in my scenario which is say they were light on it whether they were or weren't, I documented my handling of the hardware, and have no problem sharing such documentation with verified, interested buyers (WHEN THE TIME COMES) to offer you guys peace of mind.

I have photo's and video's of the venture from A-Z. I am also obliged to provide (redacted) electricity bill statements where you can correlate my photo's (power draw on each rig), and also accurately deduct the excess power my house consumed with our other household appliances. Even taking into consideration how much (more) I spent in electricity from keeping my house at a constant, cool 70-72F year-round (via my Nest thermostat). Even without the rigs, I keep my AC @ 70 when I'm home and for the last 1.5-2 years, I just so happened to spend 85% of my time here at my house. When I would travel, I'd keep it at 72 for my wife & kids.
Additionally; I had each GPU 'custom' oveunderclocke'd (MSI Afterburner for all GPU's but the EVGA's).*
I doubt everyone reading this is aware so this is for those that don't.... EVGA had the brilliant idea of implementing what they call "ICX technology" in their latest NVIDIA GTX GPU's. The short(est) explanation of this "feature" goes as follows:

EVGA GPU's w/ "ICX 9 & above" have EXTRA HEAT/THERMAL SENSORS. Unlike every other GTX 1070 ti on the market, the one's with this feature actually have each of 2/2 on-board fans connected to individual thermal sensors. Which means - if you were to use the MSI Afterburner program on one of these EVGA's and create a custom fan curve for it, you'd only be able to get 1/2 of the fans to function the way intended. The other fan simply would not engage as the MSI Afterburner software wasn't designed/coded to recognize/ communicate with an added sensor (let alone sensor'S). This, in-turn, would likely result in whoever's using it the unintended way having a GPU defect on them within the first few months I'd imagine... Perhaps if they had the TDP power settings dumbed down as much as I did (60-63%), they might get a year or two out of it since it wouldn't run as near as hot, but I doubt any longer than that since cutting off 50% of the cooling system on one of these can't be ignored too long, surely capacitors would start to blow and who knows what else...
(Warning = RANT) Another interesting side-note about the EVGA's and their "Precision-X" OveUnderclocking software is that it's designed to only recognize 4X GPU's on a single system. For miners, that's just not cool. My favorite builds had 8X and for the motherboards that weren't capable of maintaining stable sessions on 8, I set up with 6X. Only my EVGA Rigs had 3 or 4X GPU's dedicated to a single motherboard. Furthermore, and as stated in an earlier paragraph, (& this is just my opinion) = EVGA SOFTWARE SUCKS! Precision X wasn't friendly with every motherboard/CPU I threw at it and their extension software for the CLC Close-Loop-Cooling/ CPU water-coolers simply didn't work on anything, even integrating into their own Precision-X software. The amount of time it took me to finally find compatible matches with that stuff was beyond maddening. (END RANT).
Which leads me to my other comments on the matter. That's what I had every single 1070 ti set at for TDP = 60-63%. Dropping the power load that much allowed me to bring down (on average) each 1070 ti to a constant 110-115W (mind you, this is only possible w/ "Titanium" rated PSU's, Platinum comes pretty damn close to the Titanium though) while mining Ethereum and was still able to maintain a bottom of 30 MH/s and a ceiling of 32 MH/s. Increasing the TDP to 80, 90, 100% or more only increased my hashrates (yields) negligibly, like 35-36 MH/s TOPS, which also meant each one was not only pulling 160-180W+ (Vs. the aforementioned 115'ish range), it also meant my rigs were creating a significantly greater amount of heat! Fortunately for the GPU's and my own personal habits, I live in South Florida where it's hot as balls typically, last winter was nothing like this one. Increasing my yields by 10-15% didn't justify increasing the heat production in my house by >30%, nor the added electricity costs from subjecting my AC handlers to that much of an extra work-load. For anyone reading this that doesn't know/understand what I'm talking about - after spending no less than 2-3 hours with each. and. every. one. I didn't play with the settings on just one and universally apply the settings to the rest. I found the 'prime' settings and documented them with a label-maker and notepad. Here's the math in a more transparent manner:

*** I NEVER LET MY GPU's BREACH 61C, EVER. Only my 8X GPU rigs saw 60-61 & it was the ones I had in the center of the build (naturally). I have REALLY high power fans (used on BTC ASIC MINERS) that were sucking air from those GPU's which was the only way I was able to obtain such stellar results while mining with them. **\*
Mining at "acceptable" heat temps (not acceptable to me, but most of the internet would disagree = 70C) and overclocking accordingly brings in X amount of yields per unit. =
'Tweaking' (underclocking) the GPU's to my parameters reduced my yield per unit from -10-15%, but it SAVED me well over 30-35% in direct electricity consumption, and an unknown amount of passive electricity consumption via creating approximately 20%+ less heat for my AC handler to combat.

I say all this extra stuff not just for anyone interested in mining with their GPU's, but really to answer (in-depth) the apparent questions you people are asking me in PM's. Something else that should help justify my claims of being so conservative should be the fact I only have/used "Platinum and Titanium" rated PSU's. Heat production, power efficiency and longevity of the hardware were ALWAYS my top priority.* . I truly thought Crypto would continue to gain and/or recover and bounce back faster than it did. If this project had maintained positive income for 12 months+, I'd have expanded one of our sites to also cater to GPU mining on a gnarly scale.

Once I have my NAS (& possibly 2nd rig for the firewall) successfully built, I'll be willing/able to entertain selling you guys some/all of the remaining hardware prior to launching on eBay. If there's something you're specifically looking for that I listed having, feel free to PM me with that/those specific item(s). Don't count on an immediate response but what you can count on is me honoring my word in offering whoever asks first right of refusal when the time comes for me to sell this stuff. Fortunately for me, PM's are time-stamped so that's how I'll gauge everyone's place in line. I hope this extra edit answers most of the questions you guys wanted to have answered and if not, sorry I guess. I'll do my best to bring light to anything I've missed out on after I realize whatever that error was/is. The only way anyone is getting first dibs on my hardware otherwise is if they either offer compelling insight into my original questions, or have something I need to trade w/.

THE END (Round#2)


submitted by Im-Ne-wHere to buildapcforme [link] [comments]

Logs of yesterday's dev meeting

 Dev meeting?  Would say so, yes  The people are still exhausted from the payment ID meeting :)  Guess we could ping some people  vtnerd, moneromooo, hyc, gingeropolous, TheCharlatan, sarang, suraeNoether, jtgrassie  Anyone up for a meeting?  Yep I'm here  Here  o/  Perhaps we should just start and people will eventually hop in?   oof   sorry guys, I'm working on the new FFS and I forgot all about this. Got a couple of new volunteers.   This literally might be able to launch tomorrow.  I know that. It's called "flow" :)  I could run if you're out of time?   go for it dEBRUYNE   you guys are going to like this new FFS. We're like 99% done.  Hi  rehrar: someone else do the milestone thing already?  All right, jtgrassie, perhaps you'd to start w/ briefly describing your most recent PR? https://github.com/monero-project/monero/pull/5091   oneiric, xiphon did everything   like....everything  As far as I can see, it allows the user to push his transaction over I2P, thereby masking the origin IP of the sendeuser  great  And it hooks into vtnerd's PR right?  Sure. It basically just builds on vtnerds Tor stuff.  sorry dEBRUYNE  Really not much added.  I have it running and tested.  From the perspective of the user, what needs to be configured exactly?  Nice  Assuming the PR is included in the release binaries  I'm using knacccs i2p-zero duirng testing but will of course work with any i2p setup   sorry dEBRUYNE <= Np  Looks a little like dams breaking, now that we have some dark clouds over Kovri and people take matters into their own hands ...  User needs to run i2p, expose a socks service and and inbound tunnel.  Basically same as Tor  Okay, so should be reasonable as long as we write proper documentation for it (e.g. an elaborate guide)  rbrunner, yes, knaccc credit for jumping on i2p-zero really  dEBRUYNE: documentation monero side is kindof done. i2p side is very much implementation specific.  I suppose we could write some guides for the most popular implementations?  e.g. i2p-zero aims to be zero conf, but i2pd or Kovri would be differnet.  I see, great  vtnerd___: Do you want to add anything?  could amend the current kovri guide for monero use from --exclusive-peer to the new proxy support  Now I have i2p-zero running and tested with the #5091, I plan to jump back over to helping knaccc on getting that polished.  I added support for socks proxy in the basic wallets  ^ excellent  Yes vtnerd___ I havent tested it yet but looks sweet.  So connections to `monerod` over Toi2p are possible within wallet cli and wallet rpc  Awesome  This also implies auth+encryption even if ssl is not in use (when using an onion or i2p address)  All right  moneromooo: are you here? If so, could you perhaps share what you've been working on?  I am.  I revived the SSL PR, more stuff on multi sender txes, an implementation of ArticMine's new block size algorithm.  I presume a multi sender tx works similar to multisig insofar as the senders have to exchange data before the transaction can be performed right?  Yes.  There are 2 SSL PRs. What's the diff?  Theoretically this would also allow the sender to provide an output right? Which would be kind of similar to Bitcoin's P2EP  The second one adds some things like selecting a cert by fingerprint.  Yes.  (for the first sentence)  All right, awesome  For anyone reading, this breaks the assumption of the inputs belonging to a single sender, which makes analysis more difficult  Nice side-effect.  Much work coming for the various wallets to support that  rbrunner: Anything you'd like to share in the meeting btw?  Yes, just a little info  I have started to seriously investigate what it would mean to integrate Monero into OpenBazaar  I have already talked with 2 of their devs, was very interesting  In maybe 2 or 3 weeks I intend to write a report  Too early to tell much more :)  Soon^tm I guess :)  Yep  Currently wrestling with Go debugging  whole new world  moneromooo: Has pony recently shared any insights regarding the upcoming 0.14 release btw?  No.  All right  I would love to see the tor & i2p PR's merged sooner rather than later so we can get more testing done.  ^ +1  Isn't that famous early code freeze already on the horizon?  fluffypony, luigi1111 ^  I suppose I could provide a little update regarding the GUI btw  As always, lots of bug fixes and improvements :-P  selsta has recently added a feature to support multi accounts  dsc_ has revamped the wizard and will now start working on implementing the different modes and a white theme  dsc_ is working fulltime on the GUI already?  yes  :)   dsc_ is bae  In light of the recent payment ID discussion, we've also, by default, disabled the option to add a payment ID unless the user explicitely activates the option on the settings page  rehrar ^  nice   I spoke about this yesterday at the coffee chat, this is not a good decision.  How does it handle integrated addresses? The same way?  rehrar ?   For the next many months, we are still stuck with PAyment IDs in the ecosystem. Making it harder for people to access them will make Monero suck so hard to use for the average person for many months.  i agree with rehrar   Remove the option of Payment IDs when we remove Payment IDs  rehrar: The new GUI release won't be live until probably mid march though  Which is a few weeks in advance of the scheduled protocol upgrade   Payment ID removal comes in October   right, but Payment IDs are not removed in March  Did we not have loose consensus on removing the old, unencrypted payment IDs in march?   they are removed in October  We had discussed a deprecation in March  and a ban in October   ok, then if we are going to do that, we have to commit to it and contact the exchanges like Binance that use them and get rid of them in the next few months  (of unencrypted)   Binance is huge, and if they still use them, then people will be very upset that they can't deposit or use Payment IDs easily   I'm just speaking from a UX perspective.  I thought it was unencrypted in April and possibly encrypted in October  Yes I do agree  Timeline and notes: https://github.com/monero-project/meta/issues/299  impossible to remove them for march, many exchanges still use them  We can defer it to the 0.15 release if needed  Well, that wasn't the impression for them log that I just read today  This was all discussed in the earlier meeting linked above   We have to force the ecosystem off of Payment IDs before we remove them from the UI, is all I'm saying  Remove != make difficult to use  ... or make them more difficult there, right?  ping sgp_   sarang, I understand, and I agreed with you during that meeting. But then I started thinking of it as a UX person, which I am.   And that huge massive problem leapt out at me  i think making them difficult to generate is a good idea but making them difficult to consume and use is a bad idea  well, maybe not a good idea, but a better idea   ^  If we defer the decision to depriciate long payment IDs to october, won't we have the same issue then?  The UI can gave an expandable payment ID field like MyMonero and we can still call it deprecated   It is foolhardy to remove an option that the ecosystem uses. So I suggest we keep the Payment ID in the UI until October when they are completely banned.   no dEBRYUNE, because they will be banned via consensus  sgp_ imo it may be a misdirection of dev resources to add that since things are proceeding in the short term rather than long term  but this is a relatively minor point  Nothing matters til exchanges change  All right   The issue is that consensus will still have them in April, and exchanges won't upgrade because they are still allowed. Thus they must still be in the UI.  endogenic these changes are already merged in the GUI to hide it like you do  ok   But when they are banned, exchanges are forced to upgrade or stop using Monero, so we can remove them safely because they won't be in use  rehrar: that's a strong assumption   sarang that they will upgrade?  yes   if they don't, then they can't use Monero  If exchanges require pid, users need a way to set a pid. Making it hard for the user in the interim is just going to be a nightmare.   we have decided to take our "stand" in October  A way that is not too hard, then  To be clear, we still intend to deprecate long encrypted payment IDs in April right? But no enforcement until October   the term "deprecated" doesn't mean much if it's still allowed, and used in popular places   yes, as far as I understand it   jtgrassie, exactly  True I suppose  dEBRUYNE: we need to be more specific when talking about deprecation   the person who suffers is the user  There are two proposals for GUI deprecation:  1. Hide it in the send screen with a simple option to expand (currently merged iirc)  2. Hide it completely in the send screen unless users enable the field in advanced settings (PR'd but not merged yet iirc)  What are the arguments for 2?   Both are poor options, but 1 is better than 2 by a long shot   Well the people who need to be made to "suffer" are the exchanges. And I don't see a way to make exchanges "suffer" other than by having their suffering customers complain to them constantly that they need to update.  ^  CLI has something similar where users need to set a manual payment ID transfer mode. Not sure if it's merged yet   the way to make the exchanges suffer is when we ban PIDs. They either upgrade or don't use Monero.  exact;y  Agree with rerahr here  have exchanges been provided with clear, practical, sufficient technical upgrade plans for supporting what they're doing with PIDs but with subaddrs?    Both are poor options, but 1 is better than 2 by a long shot <= I wouldn't call 1. a poor option. Have you actually checked how it looks?  Because it states "Payment ID" and a user has to click on the + to expand the field  endogenic: yes the email when out. Blog post coming soon, but contains the same info as the email  also the exhcnages' users are often using wallets that don't support subaddresses  ok great   as well, it should be noted that the timeline for exchanges to upgrade is September, not October when the fork is.  Which wallets are that?  Rehrar: I don't see option 1. causing any issues/confusion  i guess it doesnt matter too much if withdrawing as a personal user the main address should suffice   Because September is when the new versions will be coming out without PIDs in the UI  If there's opposition to 2, 1 is fine. We can still call it deprecated which is the optics we need anyway   exchange users are often just using other exchanges lol. No wallets involved.   dsc_ dEBRUYNE, ok, I trust you guys here then  rbrunner: i was thinking mymonero last i heard  Ok  pigeons: rbrunner yes receiving on subaddresses won't be supported yet  sending to them has been possible though  and yes as learnandlurkin says often they withdraw to other systems like exhcnages that also dont yet support subaddresses  I really can't come up with any good argument for 2. right now  endogenic: seems not much of an issue then. Exchanges will typically support withdrawals to both subaddresses and plain addresses (especially if we are going to force them to use subaddresses)  For deposits, MyMonero works properly if the user sends to a subaddress  Actually the second solution was already merged: https://github.com/monero-project/monero-gui/pull/1866  Maybe not enough eyes watching :)   The important thing is to have done something to justify having a big "DEPRECATED IN APRIL" stamp on PIDs to spook exchanges in the interim  This was for solution 1: https://github.com/monero-project/monero-gui/pull/1855   The Monero Community Workgroup will start making noise everywhere we can to exchanges, and everywhere else that will listen. Try to get on those garbage news sites also.   So everyone knows that deprecated in April, and banned in September  Hey, for solution 1, write "Payment ID (optional, deprecated)" or similar there  rbrunner: noted  rehrar: probably wait until the blog post, but it should only be a few days   Maybe a Reddit sticky post would be useful?   With the blog post   If people are over freaking out about the hashrate  or terabyte blockchain :)  sigh  Any questions for the MRL side?  Is someone checking ArticMine's block size changes for weird behaviour in some cases etc ?  How would such testing work? Private blockchain?  I'm waiting on cost information from ArticMine to complete the model  Or just simulations?  Also, smooth suggested a mean rather than median for the 100000 block op. It would indeed be much nicer if it doesn't make the change worse.  You mean computationally or what?  Nicer ? Yes.  no sorting needed for mean  I'll add a separate sim for that  Well, just nicer. Forger the much.  Forger the Much sounds like the formal name of a Lord of the Rings character  :)  To close the payment ID discussion, in essence, we agree that we shouldn't make it difficult for the user to add a payment ID right (until 0.15 is released)  ?  I don't. I did make it harder.  In the CLI, somewhat other story, I would say  than the GUI  People there are used to juggle with options and CL parameters  rehrar: I recommend opening another issue to reverse 1866 and we can gather feedback on it there  Sounds good, to me at least   Dudes, if I do a Jitsi stream right now to show the new FFS in action, would you guys be interested in watching it?  I'd watch it, if the meeting is formally done  sure  yeah, can I start one and record it?   I'll give it in like fifteen minutes   I'll let you all know, stand by  I have a question on tx_extra if no one else has anything to talk about  People have said you can put arbitrary data in there in whatever format you want as long as you're willing to pay for it. However, do you need to mine the transaction for it to be included? I didn't think nodes would block transactions with arbitrary tx_extra data  It'll be in nodes' txpool when you relay it. A wallet could see it before it's mined.  moneromooo: will it be mined though?  by others  Is it valid ?  assume it's otherwise valid  Does it have a high enough fee ?  assume it does yes  I ran into conflicting information here: https://monero.stackexchange.com/a/3627/42  Then it will probably be mined.  I once had the idea to put "my" MMS messages in there, looked at the code, and found no hard blocks for tx_extra data  That answer looks incorrect.  It is incorrect  If it will be mined, then that meets my assumption. There seems to be some misconception that people will not mine transactions with arbitrary tx_extra. I can add some comments there  And please don't spam it, and don't put fingerprintable stuff in it. It's meant to be here for *useful* stuff that's "uniform" enough.  It will be mined, whether a wallet *displays* the tx_extra is a different question.  I don't think any wallet currently displays that  it soes if its a pid  I think  Yeah, of course :)  Great, that answers my question 
submitted by dEBRUYNE_1 to Monero [link] [comments]

Continuous Pool Disconnection & 0 Mh/s Speeds

What's up internet/fellow miners. About a week ago I've made the decision to turn my gaming PC to a mining rig. I've had some success solo mining with nicehashminer (Bitcoin miner) but decided that it would be better to mine Ethereum. I've followed the guide and kept coming across these issues. . . I don't know if it's because my config files are whack or another underlying issue.
(EDIT) Connected to us1.ethermine.org:4444 now i'm getting different issues. Here are my most recent logs.
11:11:21:867 c20 args: -epool us1.ethermine.org:4444 -ewal 0x390C9630e0672Eb1DD15D2Eb3891B07069e6c6F2.lightsdriftminer -epsw x 11:11:21:869 c20 11:11:21:878 c20 ÉÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍ» 11:11:21:883 c20 º Claymore's Dual GPU Miner - v14.7 º 11:11:21:894 c20 º ETH + DCSIA/LBC/PASC/BLAKE2S/KECCAK º 11:11:21:896 c20 º Supercharged Edition º 11:11:21:899 c20 ÈÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍÍͼ 11:11:21:912 c20 11:11:21:914 c20 b745 11:11:22:117 c20 ETH: 2 pools are specified 11:11:22:125 c20 Main Ethereum pool is us1.ethermine.org:4444 11:11:22:128 c20 DCR: 0 pool is specified 11:11:22:200 c20 OpenCL platform: NVIDIA CUDA 11:11:22:201 c20 AMD OpenCL platform not found 11:11:22:441 c20 CUDA initializing...
11:11:22:442 c20 NVIDIA Cards available: 1 11:11:22:443 c20 CUDA Driver Version/Runtime Version: 10.2/8.0 11:11:22:444 c20 GPU #0: GeForce GTX 960, 4096 MB available, 8 compute units, capability: 5.2 (pci bus 1:0:0) 11:11:22:445 c20 Total cards: 1 11:11:26:468 c20 NVML version: 10.430.86 11:11:27:273 c20 SSL: Imported 60 certificates from local storage 11:11:27:308 33f8 ETH: Stratum - connecting to 'us1.ethermine.org' <172.65.218.238> port 4444 (unsecure) 11:11:27:331 33f8 sent: {"worker": "eth1.0", "jsonrpc": "2.0", "params": ["0x390C9630e0672Eb1DD15D2Eb3891B07069e6c6F2.lightsdriftminer", "x"], "id": 2, "method": "eth_submitLogin"}
11:11:27:332 33f8 ETH: Stratum - Connected (us1.ethermine.org:4444) (unsecure) 11:11:27:375 c20 No pool specified for Decred! Ethereum-only mining mode is enabled
11:11:27:383 c20 ETHEREUM-ONLY MINING MODE ENABLED (-mode 1)
11:11:27:385 c20 ETH: eth-proxy stratum mode 11:11:27:386 c20 Watchdog enabled 11:11:27:388 c20 Remote management (READ-ONLY MODE) is enabled on port 3333 11:11:27:397 c20
11:11:27:404 33f8 buf: {"id":2,"jsonrpc":"2.0","result":true}
11:11:27:405 33f8 ETH: Authorized 11:11:27:412 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:11:27:468 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xa4dc2ea0667952442926fb027314fd0cd783cb300063809c3ce279d84884953f","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df052"]}
11:11:27:505 1cf8 Setting DAG epoch #275... 11:11:29:851 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xb34311e461aeedbc6e19ff26eb477bb24241f67c6fcca04ae0ce5c9ea9416c9b","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df052"]}
11:11:29:852 33f8 ETH: 07/30/19-11:11:29 - New job from us1.ethermine.org:4444 11:11:29:853 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:29:855 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:29:856 33f8 ETH: GPU0 0.000 Mh/s 11:11:30:189 1cf8 Setting DAG epoch #275 for GPU0 11:11:30:192 1cf8 Create GPU buffer for GPU0 11:11:33:056 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x246dfc2d4c7299214c5bff6890eaec46e95326f10a0f7778a2c3711893fc20eb","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:33:058 33f8 ETH: 07/30/19-11:11:33 - New job from us1.ethermine.org:4444 11:11:33:060 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:33:067 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:33:070 33f8 ETH: GPU0 0.000 Mh/s 11:11:33:114 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xffd191ec99473ea193905f976655434dc56a0818a92e0bc3f49759df4ce6a428","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:33:116 33f8 ETH: 07/30/19-11:11:33 - New job from us1.ethermine.org:4444 11:11:33:118 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:33:125 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:33:128 33f8 ETH: GPU0 0.000 Mh/s 11:11:37:182 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xa9a3b30ea8bb6f0f46147809276667bd3d72f0f54efab024a1014c5f3a2d2da5","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:37:184 33f8 ETH: 07/30/19-11:11:37 - New job from us1.ethermine.org:4444 11:11:37:186 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:37:193 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:37:259 33f8 ETH: GPU0 0.000 Mh/s 11:11:37:472 33f8 ETH: checking pool connection... 11:11:37:474 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:11:37:515 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xa9a3b30ea8bb6f0f46147809276667bd3d72f0f54efab024a1014c5f3a2d2da5","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:41:214 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x08148d13c03fc8be24926cf555957aa73eebaa6fb9a0f7bc802f2e4a59b27508","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:41:216 33f8 ETH: 07/30/19-11:11:41 - New job from us1.ethermine.org:4444 11:11:41:218 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:41:225 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:41:247 33f8 ETH: GPU0 0.000 Mh/s 11:11:45:196 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x7ce7a4c8ff23af05ae5b2a100b57a704d55f0ba2b7f57e4f4d96e8115b643c5d","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:45:198 33f8 ETH: 07/30/19-11:11:45 - New job from us1.ethermine.org:4444 11:11:45:200 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:45:208 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:45:211 33f8 ETH: GPU0 0.000 Mh/s 11:11:47:486 33f8 ETH: checking pool connection... 11:11:47:488 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:11:47:529 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x7ce7a4c8ff23af05ae5b2a100b57a704d55f0ba2b7f57e4f4d96e8115b643c5d","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:49:322 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x126f150e00540173459de4712848eeb5993cf40f015de6bef8e1b921b0ab1014","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df053"]}
11:11:49:324 33f8 ETH: 07/30/19-11:11:49 - New job from us1.ethermine.org:4444 11:11:49:326 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:49:334 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:49:337 33f8 ETH: GPU0 0.000 Mh/s 11:11:49:676 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x998033b4ddf28107f5b4d5e55b2d4cdf1ca5206ad5d1b0eacbf4a4a33e04c796","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df054"]}
11:11:49:677 33f8 ETH: 07/30/19-11:11:49 - New job from us1.ethermine.org:4444 11:11:49:678 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:49:682 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:49:684 33f8 ETH: GPU0 0.000 Mh/s 11:11:49:794 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xc29af38a326413d6ccee7806a33d6af54eb6118d2035c9f5e1e042cf355d61fa","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df054"]}
11:11:49:796 33f8 ETH: 07/30/19-11:11:49 - New job from us1.ethermine.org:4444 11:11:49:798 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:49:805 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:49:983 33f8 ETH: GPU0 0.000 Mh/s 11:11:51:336 1cf8 GPU0 DAG creation time - 20882 ms 11:11:51:339 1cf8 Setting DAG epoch #275 for GPU0 done 11:11:52:152 2664 GPU0 t=48C fan=45% P=45W 11:11:52:162 2664 Total GPUs power consumption: 45 Watts 11:11:52:404 3344 em hbt: 0, fm hbt: 78, 11:11:52:406 3344 watchdog - thread 0 (gpu0), hb time 1063 11:11:52:407 3344 watchdog - thread 1 (gpu0), hb time 1063 11:11:53:742 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xff392982f7826cc5d2c866c6e29cb156157adfb9390f546cabea7c37522410e1","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df054"]}
11:11:53:744 33f8 ETH: 07/30/19-11:11:53 - New job from us1.ethermine.org:4444 11:11:53:746 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:53:753 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:55:069 33f8 ETH: GPU0 0.000 Mh/s 11:11:55:350 1cf8 GPU 0, GpuMiner cu_k1 failed 30, unknown error 11:11:55:353 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:11:55:361 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:11:55:363 1cf8 GPU 0, GpuMiner kx failed 1 11:11:55:369 1cf8 Set global fail flag, failed GPU0 11:11:55:410 1cf8 GPU 0 failed 11:11:55:424 37fc GPU 0, GpuMiner cu_k1 failed 30, unknown error 11:11:55:432 37fc GPU 0, GpuMiner kx failed 1 11:11:55:436 37fc Set global fail flag, failed GPU0 11:11:55:440 37fc GPU 0 failed 11:11:57:502 33f8 ETH: checking pool connection... 11:11:57:504 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:11:57:542 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xff392982f7826cc5d2c866c6e29cb156157adfb9390f546cabea7c37522410e1","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df054"]}
11:11:57:660 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x787a852f5ac545481815d71276fd0a24414e57d78626b67cb3cb9ba02cf4d0aa","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df054"]}
11:11:57:662 33f8 ETH: 07/30/19-11:11:57 - New job from us1.ethermine.org:4444 11:11:57:664 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:11:57:672 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:11:57:675 33f8 ETH: GPU0 0.000 Mh/s 11:11:58:418 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:11:58:429 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:00:381 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xd9a845fe323638bbfc0901441a5959e6f2e73b625dda369cc55a51d855896e03","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df055"]}
11:12:00:382 33f8 ETH: 07/30/19-11:12:00 - New job from us1.ethermine.org:4444 11:12:00:383 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:00:388 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:00:391 33f8 ETH: GPU0 0.000 Mh/s 11:12:00:490 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x4302100500931a1c914b488a598d8737ff3edbf3f3633468314d6c4e28dab922","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df055"]}
11:12:00:491 33f8 ETH: 07/30/19-11:12:00 - New job from us1.ethermine.org:4444 11:12:00:492 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:00:497 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:00:498 33f8 ETH: GPU0 0.000 Mh/s 11:12:01:488 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:01:500 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:04:502 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xde108059f93a8a4ea034bb5febc5150be8e60ae89581d5ff7d41bd418c8cb815","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df055"]}
11:12:04:504 33f8 ETH: 07/30/19-11:12:04 - New job from us1.ethermine.org:4444 11:12:04:506 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:04:514 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:04:518 33f8 ETH: GPU0 0.000 Mh/s 11:12:04:557 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:04:569 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:07:486 33f8 sent: {"id":6,"jsonrpc":"2.0","method":"eth_submitHashrate","params":["0x0", "0x00000000000000000000000000000000000000000000000000000000b5f052d5"]}
11:12:07:518 33f8 ETH: checking pool connection... 11:12:07:519 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:12:07:525 33f8 buf: {"id":6,"jsonrpc":"2.0","result":true}
11:12:07:558 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xde108059f93a8a4ea034bb5febc5150be8e60ae89581d5ff7d41bd418c8cb815","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df055"]}
11:12:07:626 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:07:638 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:08:620 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x25869655f7de1b4af101faf41f51e59fa600e7fea8b139c90dbcfaa55b6c9fb6","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df055"]}
11:12:08:622 33f8 ETH: 07/30/19-11:12:08 - New job from us1.ethermine.org:4444 11:12:08:624 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:08:634 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:08:637 33f8 ETH: GPU0 0.000 Mh/s 11:12:10:592 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x31c0d6df2259de2b9db8cecd3ae97eadb63342697df59490297136aa71c2ac8d","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df056"]}
11:12:10:594 33f8 ETH: 07/30/19-11:12:10 - New job from us1.ethermine.org:4444 11:12:10:596 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:10:604 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:10:607 33f8 ETH: GPU0 0.000 Mh/s 11:12:10:696 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:10:706 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:10:768 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x428bacd8f4c294dccc3870b0402b8ea1ba9a5b578ef42309a312ea78e37e7ae4","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df056"]}
11:12:10:769 33f8 ETH: 07/30/19-11:12:10 - New job from us1.ethermine.org:4444 11:12:10:770 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:10:775 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:10:777 33f8 ETH: GPU0 0.000 Mh/s 11:12:11:654 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xf9a5e3322470de0aca5def6fbfa5c559e350f580687ec91f6c452e693b64084e","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df057"]}
11:12:11:656 33f8 ETH: 07/30/19-11:12:11 - New job from us1.ethermine.org:4444 11:12:11:658 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:11:676 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:11:679 33f8 ETH: GPU0 0.000 Mh/s 11:12:11:754 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x77acbeb5ef7ac259f42365da8bc180d934d14d7e61514475e431a74bb33092e8","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df057"]}
11:12:11:755 33f8 ETH: 07/30/19-11:12:11 - New job from us1.ethermine.org:4444 11:12:11:756 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:11:761 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:11:763 33f8 ETH: GPU0 0.000 Mh/s 11:12:13:764 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:13:767 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:15:902 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x61c461dc5d400f04c95e7af0113e2be581749c3aef0a73e79f615657bf79a17d","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df057"]}
11:12:15:904 33f8 ETH: 07/30/19-11:12:15 - New job from us1.ethermine.org:4444 11:12:15:906 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:15:914 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:15:917 33f8 ETH: GPU0 0.000 Mh/s 11:12:16:823 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:16:835 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:17:534 33f8 ETH: checking pool connection... 11:12:17:536 33f8 sent: {"worker": "", "jsonrpc": "2.0", "params": [], "id": 3, "method": "eth_getWork"}
11:12:17:575 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0x61c461dc5d400f04c95e7af0113e2be581749c3aef0a73e79f615657bf79a17d","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df057"]}
11:12:19:862 33f8 buf: {"id":0,"jsonrpc":"2.0","result":["0xac10bfccd03a5ada731630cbccba3733cfbccfecc5b9f531c6373ccd47cf9e71","0x05a66c07931e801a56d8e423677f6ff2ff4814d538d377e1253810b3520f97c9","0x0000000112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba","0x7df057"]}
11:12:19:864 33f8 ETH: 07/30/19-11:12:19 - New job from us1.ethermine.org:4444 11:12:19:866 33f8 target: 0x0000000112e0be82 (diff: 4000MH), epoch 275(3.15GB) 11:12:19:873 33f8 ETH - Total Speed: 0.000 Mh/s, Total Shares: 0, Rejected: 0, Time: 00:00 11:12:19:876 33f8 ETH: GPU0 0.000 Mh/s 11:12:19:893 2664 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:19:903 2664 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:22:679 3344 em hbt: 0, fm hbt: 63, 11:12:22:680 3344 watchdog - thread 0 (gpu0), hb time 31344 11:12:22:682 3344 watchdog - thread 1 (gpu0), hb time 27281 11:12:22:684 3344 WATCHDOG: GPU error, you need to restart miner :( 11:12:22:759 11f8 NVML: cannot get current temperature, error 999 (an internal driver error occurred) 11:12:22:770 11f8 NVML: cannot get fan speed, error 999 (an internal driver error occurred) 11:12:24:035 3344 Restarting OK, exit...
Config File.txt -

WARNING! Remove "#" characters to enable lines, with "#" they are disabled and will be ignored by miner! Check README for details.

WARNING! Miner loads options from this file only if there are not any options in the command line!

-epool us1.ethermine.org:4444 -ewal 0x390C9630e0672Eb1DD15D2Eb3891B07069e6c6F2.lightsdriftminer -epsw x

-dpool stratum+tcp://yiimp.ccminer.org:4252

-dwal DsUt9QagrYLvSkJHXCvhfiZHKafVtzd7Sq4

-dpsw x

-esm 1 -mode 0 -tt 70 -asm 0
epool file.txt-

WARNING! Remove "#" characters to enable lines, with "#" they are disabled and will be ignored by miner! Check README for details.

POOL: eth-eu.dwarfpool.com:8008, WALLET: 0xD69af2A796A737A103F12d2f0BCC563a13900E6F/YourWorker, PSW: x, ESM: 0, ALLPOOLS: 0

POOL: us1.ethermine.org:4444, WALLET: 0x390C9630e0672Eb1DD15D2Eb3891B07069e6c6F2.lightsdriftminer, PSW: x, ESM: 1, ALLPOOLS: 0

POOL: coinotron.com:3344, WALLET: YourUserName.YourWorkerName, PSW: YourWorkerPass, WORKER: , ESM: 2, ALLPOOLS: 1, ESTALE: 1

POOL: us-east1.ethereum.miningpoolhub.com:20535, WALLET: YourLogin.YourWorkerName, PSW: YourWorkerPass, WORKER: YourLogin.YourWorkerName, ESM: 2

ANY HELP/GUIDANCE IS APPRECIATED
submitted by FlawlessPig to EtherMining [link] [comments]

Difference Between Stock Market and Cryptocurrency Market  Hindi What is Bitcoin? Ano ba ang Bitcoin? Gold vs all Comparing Size of Diff Markets -PMs , Bitcoin, Stock Market, Debt, and Derivatives!? Difference between Bitcoin, Ethereum & Litecoin Difference between Bitcoin and Altcoin

Bitcoin mining pools are a way for Bitcoin miners to pool their resources together and share their hashing power while splitting the reward equally according to the amount of shares they contributed to solving a block. A "share" is awarded to members of the Bitcoin mining pool who present a valid proof of work that their Bitcoin miner solved ... Bitcoin’s drop doesn’t disprove the safe-haven argument. It just shows bitcoin is designed to be a safe-haven from a worse storm. Bitcoin vs. Bitcoin Cash: An Overview . Since its inception, there have been questions surrounding bitcoin’s ability to scale effectively. Transactions involving the digital currency bitcoin are ... For those unfamiliar with bitcoin, it’s a relatively new digital currency, currently being accepted by a growing number of institutions and merchants throughout the world. Members of our community have asked the Foundation to start accepting bitcoin. These requests, coupled with recent guidance from the US Internal Revenue Service, encouraged the Foundation to once again review our capacity ... The Bitcoin network has a global block difficulty. Valid blocks must have a hash below this target. Mining pools also have a pool-specific share difficulty setting a lower limit for shares. How often does the network difficulty change? Every 2016 blocks. What is the formula for difficulty? difficulty = difficulty_1_target / current_target (target is a 256 bit number) difficulty_1_target can be ...

[index] [21166] [43955] [4186] [17894] [20651] [9141] [42096] [49201] [1145] [36084]

Difference Between Stock Market and Cryptocurrency Market Hindi

Chamath Palihapitiya interview: Bitcoin Halving, Stock news, BTC 2020, Crisis Chamath Palihapitiya 120,695 watching Live now Fixed Mindset vs Growth Mindset - Topic of the Day - Duration: 8:31. TAGS stock market,stock market vs cryptocurrency,stock market crash 2019,stock market prediction 2019,cryptocurrency,stock market vs bitcoin,bitcoin price prediction 2019,crypto market ... If money is only valuable when we believe in it, how much is a BitCoin actually worth? Jonathan explains the virtual currency as well as how to mine it and t... Learn what are the key difference and advantages of Bitcoin, Etherium and Litecoin. You can start trading all major cryptocurrencies with ActivTrades at: htt... Difference between Bitcoin and Altcoin Bitcoin 1. Bitcoin is the first decentralized Cryptocurrency 2. Bitcoin is original developed 3. Bitcoin are not variants of any other Cryptocurrency Altcoin ...

#