Bitcoin Forum
July 20, 2018, 07:33:07 PM *
News: Latest stable version of Bitcoin Core: 0.16.1  [Torrent]. (New!)
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 »
1  Bitcoin / Pools / Re: [110PH] ZERO FEE SPLNS no registration mining pool US/DE/CN on: July 07, 2018, 04:40:00 AM
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 Tongue)

2  Bitcoin / Pools / Re: [110PH] ZERO FEE SPLNS no registration mining pool US/DE/CN on: July 07, 2018, 03:55:00 AM
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.
3  Bitcoin / Mining / Re: Solution to mining centralization; Reward bottom 50% mining power with altcoin on: July 07, 2018, 02:30:00 AM
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.
4  Other / Meta / Re: Posting guidelines for Computer Hardware section on: July 03, 2018, 03:31:10 AM
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.)
5  Bitcoin / Mining speculation / Re: WARNING WARNING WARNING about asgard sales something is up on: July 03, 2018, 02:43:10 AM
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.
6  Bitcoin / Mining speculation / Re: WARNING WARNING WARNING about asgard sales something is up on: July 01, 2018, 02:42:38 PM
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.
7  Other / Meta / Re: Posting guidelines for Computer Hardware section on: July 01, 2018, 01:59:22 PM
  • 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.
8  Bitcoin / Mining speculation / Re: warning about asgard sales somethng is up on: July 01, 2018, 01:26:46 PM

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.
9  Economy / Scam Accusations / Re: ASGARD Asic miners: vapor staff, vapor ware...? on: July 01, 2018, 12:35:40 PM
But they got ass guard...

The Pun is sthorong with this one.
10  Bitcoin / Hardware / Re: Avalon 8 official specs released on: May 12, 2018, 08:28:41 PM
Thanks, I didn't know it went past -2, where is this documented at currently?


#ifdef USE_AVALON8
     set_avalon8_voltage_level, NULL, &opt_set_avalon8_voltage_level,
     "Set Avalon8 default level of core voltage, range:[0, 15], step: 1"),
     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"),
     set_avalon8_freq, NULL, &opt_set_avalon8_freq,
     "Set Avalon8 default frequency, range:[25, 1200], step: 25, example: 800"),
     set_int_0_to_4, opt_show_intval, &opt_avalon8_freq_sel,
     "Set Avalon8 default frequency select, range:[0, 4], step: 1, example: 3"),
     set_avalon8_fan, NULL, &opt_set_avalon8_fan,
     "Set Avalon8 target fan speed, range:[0, 100], step: 1, example: 0-100"),
     set_int_0_to_100, opt_show_intval, &opt_avalon8_temp_target,
     "Set Avalon8 target temperature, range:[0, 100]"),
     set_int_1_to_65535, opt_show_intval, &opt_avalon8_polling_delay,
     "Set Avalon8 polling delay value (ms)"),
     opt_set_intval, opt_show_intval, &opt_avalon8_aucspeed,
     "Set AUC3 IIC bus speed"),
     opt_set_intval, opt_show_intval, &opt_avalon8_aucxdelay,
     "Set AUC3 IIC xfer read delay, 4800 ~= 1ms"),
     opt_set_intval, opt_show_intval, &opt_avalon8_smart_speed,
     "Set Avalon8 smart speed, range 0-1. 0 means Disable"),
     set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_pass,
     "Set A3210 th pass value"),
     set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_fail,
     "Set A3210 th fail value"),
     set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_init,
     "Set A3210 th init value"),
     set_int_0_to_65535, opt_show_intval, &opt_avalon8_th_ms,
     "Set A3210 th ms value"),
     opt_set_uintval, opt_show_uintval, &opt_avalon8_th_timeout,
     "Set A3210 th timeout value"),
     set_int_0_to_1, opt_show_intval, &opt_avalon8_th_add,
     "Set A3210 th add value"),
     opt_set_bool, &opt_avalon8_iic_detect,
     "Enable Avalon8 detect through iic controller"),
     set_int_24_to_32, opt_show_intval, &opt_avalon8_nonce_mask,
     "Set A3210 nonce mask, range 24-32."),
     set_int_0_to_1, opt_show_intval, &opt_avalon8_nonce_check,
     "Set A3210 nonce check, range 0-1."),
     set_int_0_to_1, opt_show_intval, &opt_avalon8_roll_enable,
     "Set A3210 roll enable, range 0-1."),
     set_int_0_to_2, opt_show_intval, &opt_avalon8_mux_l2h,
     "Set Avalon8 mux l2h, range 0-2."),
     set_int_0_to_1, opt_show_intval, &opt_avalon8_mux_h2l,
     "Set Avalon8 mux h2l, range 0-1."),
     set_int_0_to_255, opt_show_intval, &opt_avalon8_h2ltime0_spd,
     "Set Avalon8 h2ltime0 spd, range 0-255."),

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?

11  Bitcoin / Hardware / Re: Avalon 8 official specs released on: May 12, 2018, 04:04:29 AM
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.
12  Bitcoin / Pools / Re: [20PH] ZERO FEE SPLNS no registration mining pool US/DE/CN servers on: May 11, 2018, 03:44:41 AM
Here is a simple explainer on how HERP and DERP works.

HERP is'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 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, 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.
13  Bitcoin / Mining support / Re: Avalon 841 PG 3 on: May 05, 2018, 12:59:50 AM
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.
14  Bitcoin / Mining speculation / Re: Avalon 822 on: May 04, 2018, 02:26:49 AM
Here are the changes made to Canaan's avalon8-dev branch of their cgminer repository to add support for the A851.

It looks like the A851 may simply be an overclocked version of the A841, judging from the increased base frequency setting (AVA8_DEFAULT_FREQUENCY_825M) in line 170 of driver-avalon8.c in the avalon8-dev branch. The A841 uses a base frequency setting of AVA8_DEFAULT_FREQUENCY_775M.

Similarly, the A831 may either be an overclocked version of the A821 or an underclocked version of the A841. The A831 uses a base frequency setting of AVA8_DEFAULT_FREQUENCY_725M.

The rest of the cgminer code is the same for the A821, A831, A841, and A851.

Note that the addition of support for the A831 and the A851 are in separate branches of Canaan's cgminer repository — code for the A831 is found only in the avalon8 branch and code for the A851 is found only in the avalon8-dev branch. This suggests that Canaan may not be looking to release two new models, but may instead be looking to see which model — the A831 or the A851 — would be most viable for release, possibly as a replacement for the preceding model.

On a side note, Canaan also recently added two new experimental options in the avalon8-dev branch: --avalon8-spdlow and --avalon8-spdhigh. I don't know what spd stands for, but if it is shorthand for speed, then we may be looking at potential options to select arbitrary levels of lower and upper frequency bounds for the A8s, similar to how we are currently able to set arbitrary voltage levels and voltage level offset values. Both --avalon8-spdlow and --avalon8-spdhigh are configurable using integer values from 0 to 3.
15  Bitcoin / Mining speculation / Re: Avalon 822 on: May 02, 2018, 11:18:09 PM
Canaan renamed it to the A831 about 19 hours ago.
16  Other / Meta / Re: Moderators removed post of dragonminer on: April 24, 2018, 04:56:41 AM
Who quantify what is substantial, you?


23. When deciding if a user has broken the rules, the staff have the right to follow their interpretation of the rules.[e]


23. This rule is meant to prevent from users exploiting possible loopholes in the rules or some interpretations that follow the literal meaning of the rule rather than the meaning of what it truly wanted to prevent.

The Dragonmint T1 posts where all removed and I was first to post it.

No, you weren't. The first thread about the DragonMint T1 was started by castiel0504 at 2:10:42 PM on November 22, 2017 (UTC±00:00). That thread was never removed.

Your forum account, on the other hand, didn't exist until 8:15:09 PM on January 8, 2018 (UTC±00:00).
17  Other / Meta / Re: Moderators removed post of dragonminer on: April 24, 2018, 02:01:31 AM
In addition to what -ck said, your topic posts were deleted because every single one of them contained advertisements for your website and social media channels at the bottom of each post. This is not allowed under the forum's rules:

24. Advertisements (including signatures within the post area) in posts aren't allowed unless the post is in a thread you started and is really substantial and useful.[9][e]



Ads are typically not allowed in posts (outside of the signature area) because they are annoying and off-topic. It is especially disallowed to put ads or signatures at the bottom of all of your posts. Except for traditional valedictions, which are tolerated but discouraged, signatures are for the signature area only.

However, if you are using the forum as a publishing platform to host something really substantial and useful, selling ads in that substantial work is allowed. To be eligible for this, your post must be in a topic that you started, and your post must be substantial and long enough to make the ad seem entirely insignificant. If in doubt, ask me.

Now, you may argue that your topic posts qualified for the rule's exception — i.e., they were substantial and useful. I disagree. A transcript of a YouTube video — which is what your DragonMint review topic was — does not qualify as substantial and useful and does not make the advertisements at the bottom of the transcript any less significant. If anything, it's lazy, annoying, and only served to betray the intention of the post as an attempt to attract traffic to your website and social media channels.

For examples of truly substantial, useful, and valuable review topics, see HagssFIN's various reviews. That's how on-forum and for-forum reviews are properly done.
18  Bitcoin / Mining speculation / Re: Orion Miner - New Manufacturer - Up to 20 TH/s - SCAM!? on: April 12, 2018, 01:12:47 AM
Sounds like yet another "I want to sound important by repeating vague claims I've not bothered actually checking into" type "journalist".

This "journalist" also happens to be a Bitcoin Core contributor, the founder of Programming Blockchain, and a venture partner at Blockchain Capital.
19  Bitcoin / Mining speculation / Re: Overt AsicBoost Released today? on: April 07, 2018, 05:14:22 PM

2) In the end this up and coming company then proceeds to strive for continual improvement investing their funds into R&D. Now the older companies can effectively sit on their heels and let the new patents pour in. It's not a great long term strategy but if someone else is going to put in the work and you already have the "Brand power" to coast why wouldn't you.
This is the outcome I would expect from the given example of a company choosing to leave; as opposed to them paying to use Patents they didn't deem worthy on the off chance the next development is better.


The issue here isn't so much whether the incumbents would get to "coast" on the back of the newcomers' R&D, should the newcomers even decide to invest in their own R&D. In fact, the way the BDPL is currently set up actually incentivizes the opposite — the newcomers would be a lot better off simply leaching off the incumbents' patents and resources. And if the incumbents decide to simply stop developing because of the burden of spoon-feeding the other BDPL users, everyone loses, because the entire BDPL pool of developers and manufacturers would grind to a halt. They would all then very soon be overtaken by non-BDPL developers and manufacturers. In other words, it would be far better for the incumbents to have never joined the BDPL in the first place.

The issue here instead is that should any company choose to leave the BDPL, they remain obliged to license their patents to BDPL users for free, while the BDPL users would then be allowed to impose additional terms on the leaving companies for their continued use of BDPL patents. This isn't just unfair, it's extortion.
20  Bitcoin / Mining speculation / Re: Overt AsicBoost Released today? on: April 06, 2018, 01:20:42 AM
... I think we are all still better off today than if they never came along.

I disagree. Halong's method of choice for patenting their implementation of AsicBoost — the Blockchain Defensive Patent License (BDPL) — actually sets the stage for further centralization of mining technology, and not the converse as advertised by Halong and the BDPL's website.

Under the first question of the BDPL website's FAQ page — "How do you benefit by using the BDPL?" — it is stated that in return for immunity from patent-related lawsuits from other BDPL users, each BDPL user receives "royalty-free licenses from every other user's patent portfolio." This looks great at first glance on its surface, because it seems to encourage technology-sharing and prevents any one BDPL user from being a patent troll.

However, upon closer inspection, the BDPL begins to look more and more like a very cleverly disguised weapon designed to obtain competitors' valuable intellectual property for free, and then snuff them out.

We know that Halong now has their implementation of AsicBoost patented under the BDPL. If then, for example, Canaan wants to use Halong's implementation of AsicBoost, Canaan would have to join the BDPL and license all of their patented intellectual property to Halong (and other BDPL users) for free. In effect, Canaan gets AsicBoost, and Halong gets access to all of Canaan's patented technology, on which Canaan had previously spent millions, if not billions, in prior research and development. The playing field between Halong and Canaan has now been leveled, but at Canaan's expense. (It may be argued here that Canaan also has access to Halong's portfolio of patented technology under the BDPL, but at this point it is reasonable to assume that Halong doesn't have anything else to offer that is of competitive value. The BDPL only works if the playing field was already level to begin with.)

Things get worse from here. If, in the above example, Canaan now decides to pull all of their patents from the BDPL, Halong still gets to keep licensing all of Canaan's patents for free. Halong, on the other hand, is now allowed under the BDPL to impose additional terms ("fair, reasonable, and non-discriminatory terms (FRAND)" according to the BDPL's website, whatever that means) on Canaan for Canaan's continued licensing of Halong's patents. In other words, Halong now gets to use Canaan's patented technology for free, while Canaan has to pay Halong to use Halong's patented technology, in addition to whatever terms that Halong may now impose on Canaan at Halong's discretion. Again, Halong wins at Canaan's expense. If Canaan hasn't already been forced to shutter their doors at this point, they may soon have to, due to them being placed at such a competitive disadvantage as a result of the BDPL's terms.

This is but one slice of how the BDPL is designed to unfairly benefit startups like Halong — startups who dangle one carrot in exchange for a thousand pieces of gold. A better and more equitable way of democratizing access to mining technology would be to release them under one of the many free and open-source software and hardware licenses.

So no, we are not better off today than if Halong and the BDPL never came along. We may actually have regressed far more than we realize.
Pages: [1] 2 3 4 5 6 7 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!