Canaan has added the avalon9 branch to their cgminer repository on GitHub. It looks like the first of the A9 series will be called the AvalonMiner 921. Options to tweak the voltage level (" --avalon9-voltage-level") and the voltage level offset (" --avalon9-voltage-level-offset") remain. The A921's default temperature target appears to have been bumped up to 97°C. The cutoff temperature remains at 105°C. The default fan speed percentage remains at 100%. The OpenWrt firmware for the A9 series appears to be incompatible with earlier AvalonMiner models. This means that it would be not possible to run a mix of different generations on the same Raspberry Pi. Release binaries for the A921 that incorporate the most recent commits from the avalon9 branch have not been released yet. The latest release binary of the A921's OpenWrt firmware is dated June 28, 2018 at the time of writing. The nexttesting directory is dated September 10, 2018, but is empty at the time of writing. This means that there could yet be further changes to the A921's cgminer code before its first release. The A921's MM firmware, however, has been released. The latest release, at the time of writing, is dated September 10, 2018, and its changelog simply says: Version 9211809-ac35af0
* First MM's firmware for A921
|
|
|
|
I think all frodo is saying is their fork made their efforts void more so than than the introduction of overt.
More accurately, the activation of segwit made covert AsicBoost obsolete. No one is able to use covert AsicBoost anymore as long as segwit remains active because covert AsicBoost simply no longer works.
Does not change the fact that bitmain would have to surrender all patents of the covert asic boost patent. If they implemented it.
So while segwit was effective this was the second bolt in the door.
Note my sentence says "was good way to prevent ...."
Does not say "only way to prevent covert boost"
Does not say "it did prevent covert asic boost"
I know you can delete or edit this reply , but I was not wrong to say that it is a good way to prevent covert asic boost.
I leave it at that.
Fair enough. We'll leave it at that. |
|
|
|
I was the one who deleted (or rather, moved to the Trashcan) jackg's topic. The reason I deleted jackg's topic should be obvious to anyone who bothered to read the rules governing the Mining section, which are plastered at the top of every Mining board. The relevant rule here is this: Hardware - This is for dedicated discussion regarding BITCOIN mining hardware ONLY and hardware in development. There should be only one topic per new piece of hardware [emphasis added], preferably started by the creator of the hardware, and they can then provide support for that hardware on that one thread. Where hardware has no manufacturer representative on this forum, the thread can be started by anyone but all discussion should remain in the one thread. If the manufacturer has stared a thread but it is self moderated, then you are free to create your own personal thread to discuss that hardware and avoid the manufacturer's censorship, but discussion of actual support should go in the Mining support subsection.
When jackg posted their topic in Hardware, theymos had already restored all of the previous S9 Hydro-related threads that I had moved to the Trashcan. There were four threads: this one by Shad0wSmurf, this one by taserz, this one by coinbeamer, and the currently active one by Philopolymath. The new topic that was started by jackg was therefore redundant, and their question should have been posted in Philopolymath's thread instead. For the record, I disagree with theymos' interpretation of the rules regarding this issue and sidehack's contention that the S9 Hydro is a distinctly new and unique model that warranted its own thread. -ck's rule as quoted above is unequivocal in its assertion that only one unique topic may be started for a "new piece of hardware." I interpret this as meaning a distinctly new and unique model or make of mining hardware. The S9 Hydro, in my opinion, does not qualify as a distinctly new and unique model. Here are two reasons why. Firstly, Bitmain itself clearly did not seek to market the S9 Hydro as a distinctly new and unique model. If they did, they would not have used the S9 moniker to market the S9 Hydro. The fact that they did continue to use the S9 moniker to label the S9 Hydro shows that they intended to market the S9 Hydro as a mid-cycle upgrade that is still part of the S9 series, like how they market the S9i and the S9j as mid-cycle hardware refreshes of the stock S9. Secondly, and flowing from the first reason, all of the miners that bear the S9 label including the S9 Hydro are designed and built upon the same foundation, i.e., Bitmain's 16nm chip. Others have noticed this too. The differences that sidehack mentions elsewhere seem to me as changes that were made merely to accommodate the new liquid-based cooling system and to perhaps bump up the spec sheet figures for marketing purposes. There is nothing revolutionary regarding the S9 Hydro to justify calling it an entirely new model that would qualify it for having its own thread. Nevertheless, since theymos has decided otherwise, and being my superior, I am therefore obliged to respect his decision and to allow Philopolymath's S9 Hydro thread to remain. This does not mean, however, that I will in any way relax my interpretation and enforcement of the forum's rules. All further discussion regarding the S9 Hydro should therefore be posted in Philopolymath's thread. The only exception here would be requests for technical support, which are to be posted in Mining Support. |
|
|
|
Good day everyone. Just curious, does anyone use Co-Location services here. I have maxed out where I am at and want to keep expanding? I have called a few places but not sure if its a right fit. Looking for any recommendations. Thanks in advance.
I recommend checking out Dalkore's list of colocation service providers. |
|
|
|
Do fried pork skins count as a meat meal?
Not according to your arteries. |
|
|
|
It did not work chained to the 841 chain
That's most likely because the Controller in your existing chain of 841s is running pre-851 software. The 841s and the 851s should work on a Controller that is running post-851 software, as the Controller software for the 851 seems to have retained the code needed to support the 841s. |
|
|
|
I even know 1 pool op that has blamed ASIC firmware versions for bad luck (not mentioning any names, but his nickname rhymes with guano  ) Touchι. |
|
|
|
I think the asic boost from Halong miners is helping the luck of the pool somehow.
Our last block (530771) wasn't a version-rolled one. |
|
|
|
The Bitcoin network is incapable of identifying miners at the consensus layer. To put it very simply, all that the network sees when a new block is added to the blockchain are the block's contents (i.e., the transactions in the block) and its metadata (i.e., the block's hash, the block's merkle root, the block's size and weight, etc.). There is no indication whatsoever at the consensus layer of which entity mined the block. The identity of a particular block's miner as shown by block explorers e.g., Blockchain and Blockchair are simply guesses by the block explorers themselves, based on various block attributes such as the block's coinbase text and the output(s) in the block's coinbase transaction. There is no indication whatsoever in the block itself that mining pool X or miner Y was the one that mined the block. Even hashpower estimates by block explorers are mere guesses by the block explorers themselves, based on algorithms that take into account, among other things, the time interval between blocks. There is therefore no way for the Bitcoin network to distinguish between the top 50% or the bottom 50% of mining power at any given time, making this proposal unfeasible. Even if there is a feasible method of distinguishing between the top 50% and the bottom 50% of mining power e.g., through the use of oracles such a method would most likely require a hard fork. Given how messy segwit's soft fork was (it wasn't even a hard fork), I highly doubt that such a proposal would even get past the proposal stage. And that's not even including the fact that the hard fork would need to add a sidechain mechanism for the altcoin portion of this proposal. Even if, by some fluke, the Bitcoin community developers, miners, and users agreed to the hard fork, such a change would then open another can of worms. Now that the Bitcoin network would be able to identify a particular block's miner(s) at the consensus layer, and now that the Bitcoin community has been emboldened by a successful hard fork that supposedly mitigated the centralization of mining power, what's there to stop Bitcoin from undergoing new forks (soft or hard) that prevent certain miners from mining new blocks once they are deemed to have too much mining power? While this may seem like a good thing on its surface mining pools would be further disincentivized from amassing more than 50% of Bitcoin's mining power this essentially introduces an element of censorship into the network at the consensus layer and sets a precedent for further censorship. Mining pools would, of course, evade such censorship by splitting up their mining power to appear to the network as multiple discrete entities i.e., a Sybil attack. Not nodes. This altcoin reward goes to Bitcoin block producers only.
A Bitcoin full node e.g., Bitcoin Core is a block producer's only interface to the Bitcoin network. Without a full node, a block producer would not be able to submit any new blocks to the Bitcoin network, in the same way that without a web browser, an Internet user would not be able to access the web. |
|
|
|
|
It doesn't have to be from a specific blockchain explorer. The hash of the block itself is sufficient.
The rationale behind this is that there is no way to predict the hash of a particular block until that block itself has been mined. In this way, we know that a message containing the hash of a particular block could not have been created any earlier than the block itself. Consequently, the earliest possible time that the goods (with the accompanying message) could have been in existence is the time when that particular block was mined. Note, however, that this is only useful in showing proof of existence of the goods. It does not reliably show proof of ownership. The latter requires more robust methods of verification.
My preferred method of proving ownership of the goods is to conduct a video call using Signal. Forum PM would be used to initiate contact with the seller, to exchange Signal phone numbers, and to perform out-of-band key verification i.e., verifying each other's Signal safety numbers before initiating the video call. The goods must be clearly shown in the video call, together with a message containing the seller's forum user name. Since a video call takes place in real time, there would be no need for a timestamp. I would then prefer to limit all further correspondence with the seller to within Signal, as our communications would be protected by Signal's robust end-to-end encryption. (If the seller prefers to send pictures of the goods instead of showing the goods via a video call, then a message containing a timestamp and the hash of the latest Bitcoin block would be required to be shown alongside the goods.)
|
|
|
|
Deleting a moderator's post was not smart and I've taken the liberty of correcting their post for them.
I've also taken the liberty of replacing the link to their website with a link to the Scam Accusations thread. |
|
|
|
Not that this is funny at all but I would have loved to have read sidehacks post.
So would I. Thanks for responding, I do appreciate that. I would have preferred actually if you marked it bad if you didn't agree with it.
1) I did not report NFW's because I completely agree it is not spam (ie it did not break forum rules) and the onus is always on the customer to do their own dd
2) I did not report the Self Mod'd thread as I did not see it as breaking any rules.
3) I reported Hagssfin post because it looks like another "great project" one line shit post we have all deleted hundreds of times. I actually thought there was sufficient rule being broken to warrant deleting it.
4) I did not ask to remove the post to stoop down to the OP's level or have it removed because it's an endorsement of sorts. I asked for it to be removed as Spam or breaking the rules the side effect being it was not their anymore. I asked for the post to be removed because it violates forum rules IMO, if you don't agree I can and will respect that.
Honestly man I am not looking for a fight I respect your decision and I will leave it at that!
Understood, and thanks. I nevertheless remain of the opinion that HagssFIN was merely being sarcastic, until proven beyond a reasonable doubt to be otherwise. His post therefore currently does not qualify as spam in my opinion. |
|
|
|
- Include a handwritten note containing with a date stamp and your forum user name
Including the hash of the latest Bitcoin block and its associated block height in the note in addition to the timestamp and forum user name may add credence in proving that the said goods did exist and was in the possession of the seller at the time of that particular block. |
|
|
|
@ mods WTF is going on here?
I don't know. I'm just as puzzled about this whole thing as any of you currently are. I'm going to report haggsfins post in the sm thread as spam (because it actually is LOL) hopefully ck or frodocooper agree and remove it at least we wont have a ringing endorsement there.
I disagree. While it is indeed out of character for both NotFuzzyWarm and HagssFIN to be seemingly endorsing Asgard Mining this prematurely (whether explicitly or implicitly), deleting their posts would amount to censorship. We already have Asgard Mining censoring their own thread; I would very much like to avoid stooping to their level. Also, the onus is on any potential customer to conduct their own due diligence before purchasing from Asgard Mining. The most that can reasonably be expected of us in this situation is simply to provide sufficient warning regarding the risks of purchasing from Asgard Mining. I'm convinced that this thread and the one in Scam Accusations constitute adequate warning. There is therefore no reason, in my opinion, for -ck and myself to begin censoring asgardmint's thread, even if for the benevolent purpose of removing questionable endorsements from NotFuzzyWarm and HagssFIN. I nevertheless marked your report as Handled as a concession. The appropriate action to be taken would have been to mark it as a Bad report. On that note, there may be a remote possibility that HagssFIN was merely being sarcastic. |
|
|
|
But they got ass guard...
The Pun is s thorong with this one. |
|
|
|
Thanks, I didn't know it went past -2, where is this documented at currently?
Here: #ifdef USE_AVALON8
OPT_WITH_CBARG("--avalon8-voltage-level",
set_avalon8_voltage_level, NULL, &opt_set_avalon8_voltage_level,
"Set Avalon8 default level of core voltage, range:[0, 15], step: 1"),
OPT_WITH_CBARG("--avalon8-voltage-level-offset",
set_avalon8_voltage_level_offset, NULL, &opt_set_avalon8_voltage_level_offset,
"Set Avalon8 default offset of core voltage level, range:[-2, 1], step: 1"),
OPT_WITH_CBARG("--avalon8-freq",
set_avalon8_freq, NULL, &opt_set_avalon8_freq,
"Set Avalon8 default frequency, range:[25, 1200], step: 25, example: 800"),
OPT_WITH_ARG("--avalon8-freq-sel",
set_int_0_to_4, opt_show_intval, &opt_avalon8_freq_sel,
"Set Avalon8 default frequency select, range:[0, 4], step: 1, example: 3"),
OPT_WITH_CBARG("--avalon8-fan",
set_avalon8_fan, NULL, &opt_set_avalon8_fan,
"Set Avalon8 target fan speed, range:[0, 100], step: 1, example: 0-100"),
OPT_WITH_ARG("--avalon8-temp",
set_int_0_to_100, opt_show_intval, &opt_avalon8_temp_target,
"Set Avalon8 target temperature, range:[0, 100]"),
OPT_WITH_ARG("--avalon8-polling-delay",
set_int_1_to_65535, opt_show_intval, &opt_avalon8_polling_delay,
"Set Avalon8 polling delay value (ms)"),
OPT_WITH_ARG("--avalon8-aucspeed",
opt_set_intval, opt_show_intval, &opt_avalon8_aucspeed,
"Set AUC3 IIC bus speed"),
OPT_WITH_ARG("--avalon8-aucxdelay",
opt_set_intval, opt_show_intval, &opt_avalon8_aucxdelay,
"Set AUC3 IIC xfer read delay, 4800 ~= 1ms"),
OPT_WITH_ARG("--avalon8-smart-speed",
opt_set_intval, opt_show_intval, &opt_avalon8_smart_speed,
"Set Avalon8 smart speed, range 0-1. 0 means Disable"),
OPT_WITH_ARG("--avalon8-th-pass",
set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_pass,
"Set A3210 th pass value"),
OPT_WITH_ARG("--avalon8-th-fail",
set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_fail,
"Set A3210 th fail value"),
OPT_WITH_ARG("--avalon8-th-init",
set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_init,
"Set A3210 th init value"),
OPT_WITH_ARG("--avalon8-th-ms",
set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_ms,
"Set A3210 th ms value"),
OPT_WITH_ARG("--avalon8-th-timeout",
opt_set_uintval, opt_show_uintval, &opt_avalon8_th_timeout,
"Set A3210 th timeout value"),
OPT_WITH_ARG("--avalon8-th-add",
set_int_0_to_1, opt_show_intval, &opt_avalon8_th_add,
"Set A3210 th add value"),
OPT_WITHOUT_ARG("--avalon8-iic-detect",
opt_set_bool, &opt_avalon8_iic_detect,
"Enable Avalon8 detect through iic controller"),
OPT_WITH_ARG("--avalon8-nonce-mask",
set_int_24_to_32, opt_show_intval, &opt_avalon8_nonce_mask,
"Set A3210 nonce mask, range 24-32."),
OPT_WITH_ARG("--avalon8-nonce-check",
set_int_0_to_1, opt_show_intval, &opt_avalon8_nonce_check,
"Set A3210 nonce check, range 0-1."),
OPT_WITH_ARG("--avalon8-roll-enable",
set_int_0_to_1, opt_show_intval, &opt_avalon8_roll_enable,
"Set A3210 roll enable, range 0-1."),
OPT_WITH_ARG("--avalon8-mux-l2h",
set_int_0_to_2, opt_show_intval, &opt_avalon8_mux_l2h,
"Set Avalon8 mux l2h, range 0-2."),
OPT_WITH_ARG("--avalon8-mux-h2l",
set_int_0_to_1, opt_show_intval, &opt_avalon8_mux_h2l,
"Set Avalon8 mux h2l, range 0-1."),
OPT_WITH_ARG("--avalon8-h2ltime0-spd",
set_int_0_to_255, opt_show_intval, &opt_avalon8_h2ltime0_spd,
"Set Avalon8 h2ltime0 spd, range 0-255."),
#endif
Note that --avalon8-voltage-level and --avalon8-voltage-level-offset are two different parameters and therefore do two different things. You may, however, set both parameters concurrently.
Does it require a certain firmware?
All current A8 firmware releases support the above parameters.
Also is this for both 821 and 841?
Yes. |
|
|
|
Looks like Canaan are looking to revert the A8's target temperature back to 90°C, according to commit ae73ff0 in the avalon8-dev branch of their cgminer repository. |
|
|
|
Here is a simple explainer on how HERP and DERP works. HERP is ckpool.org's equivalent of conventional PPLNS's "last N shares." HERP exists on two levels: at the pool level and at the individual level. At the pool level, HERP is the pool's total tally of miners' shares at any given point in time. All shares are weighted by their respective difficulty values. In other words, a share with a higher difficulty value occupies a greater proportion of the pool's tally of shares compared to a share with a lower difficulty value. In contrast, conventional PPLNS does not take into account the difficulty value of each share. At the individual level, HERP is your own tally of difficulty-weighted shares within the pool's total tally. The N value used by ckpool.org is 5 x (the current Bitcoin network difficulty value). For example, the Bitcoin network's difficulty value currently stands at 4,143,878,474,754.19 as of block 522147. Therefore, ckpool.org will keep a rolling tally of up to 20,719,392,373,770.95 difficulty-weighted shares. When the pool's tally of difficulty-weighted shares reaches that limit, new shares will constantly replace the oldest shares to keep the total tally at 20,719,392,373,770.95 difficulty-weighted shares. DERP is the proportion of your individual-level HERP compared to the pool-level HERP, and this is what determines your actual payout amount. Your DERP value may be found by dividing your individual-level HERP by the pool-level HERP. In other words, your DERP is determined by how many of those 20,719,392,373,770.95 difficulty-weighted shares belong to you. The greater the proportion of individual-level HERP you have out of the pool-level HERP, the greater your payout amount will be. For example, if at this point in time, you have accumulated your own individual-level HERP of 21,000,000,000, then your DERP would be 21,000,000,000 / 20,719,392,373,770.95 = 0.00101354. You are paid only at the exact moment the pool finds a block, with your payout amount being your DERP at that particular moment in time. I hope this helps to clear up some of the confusion regarding HERP and DERP. |
|
|
|
mm: 8411803-14b0f10
May 4th firmware
There is no MM firmware that is dated May 4, 2018. The MM firmware that you have (version 8411803-14b0f10) is dated March 6, 2018. |
|
|
|
|
Show Posts
