Bitcoin Forum
June 18, 2021, 01:11:13 PM *
News: Latest Bitcoin Core release: 0.21.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 »
1  Economy / Service Discussion / Re: [List] Gift cards providers on: April 02, 2021, 12:12:01 AM
It appears that a customer can no longer buy a prepaid Mastercard or Visa virtual credit card from Coinsbee without first signing up for a Coinsbee account. Also, it appears that they have updated their privacy policy to give themselves more leeway in their use of collected user data and to change the name of the company that operates the Coinsbee service from "TSMH GmbH" to "Coinsbee GmbH."
2  Economy / Service Announcements / Re: Coinsbee.com - Buy gift cards with about 50 crypto currencies! on: October 29, 2020, 03:09:00 AM
I would very much welcome a Coinsbee v3 onion service, albeit one that does not leak secure cookies into insecure backend channels.

Etsy gift cards would also be a welcome addition to your catalog.
3  Economy / Service Discussion / Re: [List] Gift cards providers on: October 01, 2020, 01:11:01 AM
With Coinsbee currently unable to offer Mastercard and Visa prepaid cards for sale, are there other trustworthy Mastercard or Visa prepaid card providers that accept monero or bitcoin?
4  Economy / Service Announcements / Re: Coinsbee.com - Buy gift cards with about 50 crypto currencies! on: September 27, 2020, 04:55:01 AM
American Express, Mastercard, and Visa prepaid cards appear to have vanished from Coinsbee's catalog at the time of writing. Visiting their respective pages redirects the browser to Coinsbee's home page.
5  Economy / Service Announcements / Re: Coinsbee.com - Buy gift cards with about 50 crypto currencies! on: July 24, 2020, 01:00:01 AM
Would you consider accepting monero as payment?
6  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 256 blocks solved! on: June 20, 2020, 03:05:00 AM
Setting up a v3 onion service is a far better long-term solution against censorship. The pool may opt to set up a single onion service instead of a conventional one in order to reduce latency, but at the cost of reduced server-side location anonymity. A single onion service uses only three hops in the circuit instead of the usual six.

An onion service may be set up as a single onion service by adding the following two options to the onion service's torrc entry:

Code:
HiddenServiceSingleHopMode 1
HiddenServiceNonAnonymousMode 1

Here are the relevant entries for single onion services in the Tor manual:

HiddenServiceSingleHopMode 0|1

Experimental - Non Anonymous Hidden Services on a tor instance in HiddenServiceSingleHopMode make one-hop (direct) circuits between the onion service server, and the introduction and rendezvous points. (Onion service descriptors are still posted using 3-hop paths, to avoid onion service directories blocking the service.) This option makes every hidden service instance hosted by a tor instance a Single Onion Service. One-hop circuits make Single Onion servers easily locatable, but clients remain location-anonymous. However, the fact that a client is accessing a Single Onion rather than a Hidden Service may be statistically distinguishable.

WARNING: Once a hidden service directory has been used by a tor instance in HiddenServiceSingleHopMode, it can NEVER be used again for a hidden service. It is best practice to create a new hidden service directory, key, and address for each new Single Onion Service and Hidden Service. It is not possible to run Single Onion Services and Hidden Services from the same tor instance: they should be run on different servers with different IP addresses.

HiddenServiceSingleHopMode requires HiddenServiceNonAnonymousMode to be set to 1. Since a Single Onion service is non-anonymous, you can not configure a SOCKSPort on a tor instance that is running in HiddenServiceSingleHopMode. Can not be changed while tor is running. (Default: 0)

HiddenServiceNonAnonymousMode 0|1

Makes hidden services non-anonymous on this tor instance. Allows the non-anonymous HiddenServiceSingleHopMode. Enables direct connections in the server-side hidden service protocol. If you are using this option, you need to disable all client-side services on your Tor instance, including setting SOCKSPort to "0". Can not be changed while tor is running. (Default: 0)
7  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 256 blocks solved! on: June 19, 2020, 01:09:00 AM
Thank you very much, -ck, for deploying TLS on the web server.

The web server's TLS configuration looks decent. The SSL Server Test by Qualys SSL Labs has given an A grade to solo4.ckpool.org. There's room for improvement, but I suppose that the current TLS configuration is sufficient for now.

The SSL Server Test was unable to connect to the web server over IPv6 at the time of testing.
8  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 20, 2020, 01:04:00 AM
Without HTTPS, browsers cannot tell if the web server that they are talking to is the true solo.ckpool.org web server. HTTP offers no means of authentication whatsoever, and BGP cannot be relied upon to properly route internet traffic to the correct destinations.

Without HTTPS, browsers send and receive everything in plaintext. This includes requests for the path to the pool's records for specific Bitcoin addresses, and the web server's responses to those requests. Any entity sitting between the user and the web server—e.g., ISPs, network intruders, IP transit providers, OVHcloud, etc.—can see and log what Bitcoin addresses are of interest to the user that is making those requests, and what the pool says about those addresses. These eavesdroppers can therefore make reasonable assumptions regarding the user—e.g., that the user that they are spying on (a) mines bitcoin, (b) uses a certain Bitcoin address, (c) possesses a certain amount of hashpower, (d) mines at certain times or at all times, (e) has this or that amount of bitcoins associated with that Bitcoin address, (f) spends this or that amount of bitcoins at certain times, (g) sends this or that amount of bitcoins to certain addresses at certain times, and (h) is worth targeting to steal the user's private keys when the user mines a block. This list of assumptions is not exhaustive. Unencrypted HTTP and the completely transparent nature of the Bitcoin blockchain enable methods of surveillance far more comprehensive and sophisticated than I have time to list here.

Without HTTPS, you are open to the risk of a user, or a group of users, being pwned simply by visiting the pool's website. This is because unencrypted HTTP allows any network intruder to inject malicious code into the stream of traffic that passes between the user and the web server. Although modern web browsers and operating systems have made tremendous leaps forward in terms of security, zero-day vulnerabilities remain an ever-present significant risk, notwithstanding the risk of user error and/or ignorance. At the time of writing, the reward in US dollar terms for successfully mining a Bitcoin block is approximately $61,000. That's a lot of money, and it therefore paints a very large bullseye on the person who mined the block.

It is very hard to recommend in good conscience a service that does not seem to take into account its unique threat model and incorporate the most basic and foundational element of modern web security to help mitigate those risks. There is zero reason to ignore HTTPS. It offers reasonable security and privacy at almost no financial and technical costs. There may be a large gap between reasonable security and robust security, but there is an infinite gap between no security and reasonable security.
9  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 19, 2020, 03:56:46 AM
Merely using port 443 to evade censorship is no longer effective, if it ever was to begin with.

Since the stratum protocol is unencrypted, it is trivial for censors to deploy filters that block the protocol if they want to block bitcoin mining. It is also trivial for them to deploy DNS filtering to prevent miners' networks from resolving the domain names of known mining pools, and if miners decide to use unencrypted public DNS resolvers, to hijack their DNS requests to either prevent them from resolving pools' domain names, or feed them fraudulent IP addresses to connect to. And then there are other more sophisticated forms of internet censorship that are not only in use by state-level censors, but also by enterprise networks—e.g., deep packet inspection, etc.
10  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 19, 2020, 03:29:00 AM
Also if you're wondering about the web interface, I'm doing as frodocooper suggested and installing https support which is why it's currently unavailable, and of course port 443 is being used by the pool itself so it would need another IP address or irregular port >_<

Thanks, -ck.

The simplest solution to the port problem that I can think of is to let the pool's stratum server listen on port 80 instead of port 443. This frees up port 443 for the web server to use for HTTPS traffic. This makes a bit more sense anyway, since port 80 is intended for unencrypted HTTP traffic, and the stratum protocol is itself unencrypted. Outgoing connections to port 80 are also usually allowed by default in most firewalls.

One downside to this approach is that visitors to the pool's website would have to manually add the https:// prefix to the pool's web address every time they enter it into their browser's address bar, because the pool's web server can't listen on the occupied port 80 to redirect them to port 443—unless the pool's website is (a) included in the HSTS preload list and/or (b) incorporates the EFF's HTTPS Everywhere rulesets to allow visitors using the HTTPS Everywhere browser extension to be automatically directed to port 443. The upside to this approach is that you do not need to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs.

If you prefer to reserve port 80 for the pool's web server to use, then another simple solution would be to let the pool's stratum server listen on port 53 instead of port 443. This frees up both port 80 and port 443 for the web server to use. Port 53 is meant for unencrypted DNS traffic, and so outgoing connections to port 53 are also usually allowed by default in most firewalls. This approach requires you to configure the web server to forcibly redirect unencrypted HTTP requests to HTTPS URIs. Registering the pool's website on the HSTS preload list and incorporating HTTPS Everywhere rulesets remain highly recommended when using this approach.

A more complicated solution that doesn't involve setting up an additional network interface with additional IP addresses on the same machine, would be to terminate TLS connections at a HAProxy instance on a cheap VPS that in turn relays web traffic to and from the upstream web server (ideally encrypted, over a private network). Upsides to this approach include (a) allowing you to leave the pool's current setup on the dedicated server mostly untouched, and (b) freeing up the pool's dedicated server from not only having to manage TLS connections with web clients, but also from having to manage web traffic with clients at all. The downside to this approach is that it involves more effort and money to set up and maintain, because you would have to manage two servers instead of one.

And then there's setting up an additional virtual network interface with additional IPv4 and IPv6 addresses on the same machine, and binding the pool's stratum server to one virtual interface and the web server to another. This seems quite straightforward in concept, but I do not have any experience with this approach, and so I can't say much about it, nor can I recommend it with confidence. It does seem cheaper and simpler than setting up HAProxy as a reverse proxy on another VPS, though.
11  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 18, 2020, 05:37:00 AM
Also, may I strongly recommend deploying HTTPS on the pool's web server, configured to support TLS 1.3 and HSTS? There's currently no way for any visitor to the pool's website to tell if (a) they landed at the true solo.ckpool.org web server, (b) that third parties are not eavesdropping on their communications with the web server, and (c) that their traffic to and from the web server has not been tampered with or injected with malicious code by third parties.

The performance overhead associated with HTTPS and TLS is less than negligible, especially with TLS 1.3. And since the pool's new dedicated server has at least a hundred times the computing and networking resources needed to run the pool efficiently, I see no plausible reason for leaving out a foundational element of modern web security in the current rebuild of the pool's infrastructure.

Mozilla has a very handy TLS configuration generator that does most of the heavy lifting for you when configuring TLS parameters. I highly recommend selecting Mozilla's Modern configuration instead of their Intermediate configuration. I see no reason to support legacy versions of web browsers; users of such browsers have far bigger problems than merely being unable to visit a website. Dropping support for TLS 1.2 also reduces the performance baggage that comes with it.

EFF's Certbot automatically obtains and renews TLS certificates from Let's Encrypt for you. Let's Encrypt's certificates are free, and they also offer wildcard certificates.
12  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 16, 2020, 01:38:00 AM
To those who are curious as to what the donations bought for this pool, and also to the geeks among us who are naturally curious about such things—if I'm not mistaken, and hopefully with his permission to post this, -ck used the money to migrate the pool to this beast of a machine. Here are its specs:

ProviderOVH US LLC
TypeDedicated server
LocationVint Hill, Virginia, USA
ProcessorIntel Xeon E-2274G Processor (8M Cache, 4.00 GHz)
Memory32GB DDR4 ECC 2666MHz
Storage3 x 4 TB HDD SATA Soft RAID or 2 x 960 GB SSD NVMe Soft RAID
Public bandwidth1 Gbps unmetered (burst 2 Gbps)

-ck wasn't kidding when he said that the new server is "massively overqualified for the task now." I think that that's a colossal understatement, and even more so if he went with the NVMe SSD variant.
13  Bitcoin / Pools / Re: [∞ YH] solo.ckpool.org 2% fee solo mining 255 blocks solved! on: May 15, 2020, 01:51:00 AM
[...]

[...]

The IPv4 subnet of 104.16.0.0/12, which includes NiceHash's IPv4 address of 104.17.254.46 and Mining Rig Rentals's IPv4 address of 104.26.0.61, belongs to Cloudflare. The IPv6 subnet of 2606:4700::/32, which includes NiceHash's IPv6 address of 2606:4700::6811:ff2e and Mining Rig Rentals's IPv6 address of 2606:4700:20::681a:3d, also belongs to Cloudflare. Therefore, the most plausible reason for why the measured latency from the pool to those hosts were so remarkably low isn't that NiceHash's and Mining Rig Rentals's servers are in the same datacenter as the pool, but that the ICMP echo request packets sent by the pool to those addresses were directed to Cloudflare's CDN instead of the upstream hosts. The latency measurements by -ck are therefore meaningless, as -ck measured the latency to Cloudflare's CDN, which most likely has a network of nodes in the same datacenter as the pool, instead of NiceHash's and Mining Rig Rental's upstream hosts.

If your network supports IPv6, then I recommend using IPv6 instead of IPv4. Routing and packet processing are more efficient with IPv6, which therefore theoretically results in better overall network performance. And since both NiceHash and Mining Rig Rentals also rely on Cloudflare's DNS infrastructure, you would do well to set Cloudflare's public DNS resolver as your network's DNS resolver. It may help to shave a few milliseconds when resolving NiceHash's and Mining Rig Rental's domain names. For the more adventurous folks, you may also want to consider running OpenWrt on your network routers and then running Stubby for OpenWrt with Cloudflare's public DNS resolver as its upstream resolver. If you do run Stubby for OpenWrt, then I recommend forcing its use of TLS 1.3 and disabling Stubby's round-robin scheduling of upstream resolvers. And while you're at it, you may also want to consider running luci-app-sqm to help mitigate bufferbloat, which in turn helps to improve network performance under load.
14  Other / Meta / Re: A reply of yours, quoted below, was deleted by a Bitcoin Forum moderator. on: February 18, 2020, 03:20:59 AM
I deleted wwzsocki's posts because I have reason to believe that he made those posts merely for the sake of qualifying for ChipMixer's signature campaign. Note the timestamp of wwzsocki's application:

Username: wwzsocki
Post Count: 5031
BTC Address (must be SegWit): 3K4SRdXd6225BQufBPC3qLH2vz4tsadC3Q

As far as I'm aware, wwzsocki had never posted on any of the Mining boards throughout my time as moderator. He started posting there only after being apparently advised by DarkStar_ to do so:

... Last time we have a talk after recruitment and you advised me to write across more boards (which I did), but seems to be still not enough.

Would you be so kind and answer, please? I want to know what shall I do or change to have a better chance next time?

He has also referred to posting on this forum as "work":

... these are long working hours that have been irrevocably removed.

... but in 1% of the cases hours of someone's work disappeared and there is no easy way to find out why?

Wwzsocki doesn't appear to be working for the Bitcoin Forum as a moderator or an administrator. Therefore, I believe that it is reasonable to infer from at least these words that he sees this forum as primarily, if not exclusively, a mere opportunity for financial gain through signature and bounty campaigns. His post history, especially with regards to his various endorsements of something called GOLD, his participation in its bounty campaign, and his recent application for at least one other signature campaign, bears witness to wwzsocki's motives for posting. DarkStar_ himself noticed this, as did asche and suchmoon:

Yeah, I mean posting style. I agree with asche here...

It kinda looks like you are trying to change your postings habits to match the campaign... That usually doesn't go too well... I would be better to find a campaign that suits your natural posting (without any paid incentive) and not the other way around...

You're trying too hard and you're using 500 words where 5 would suffice: "Thanks, will try next time".

Also, posts are just that: posts. What significance do they have in your life that you feel compelled to make such an earnest effort to vindicate the worth of your posts and your self-perceived literary and intellectual prowess? Is not life more important than posts on a forum that 99.99% of the world isn't even aware of? Unless, of course, this forum serves primarily or exclusively as a mere means to financial gain for you, because any action on the part of the forum's staff that is detrimental to that goal is then taken as a threat to your material self-interests.

Therefore, to be clear, I have zero tolerance for anyone whom I have reason to believe is posting exclusively or primarily for mere financial gain through signature or bounty campaigns. This forum is intended to facilitate reasonable discussions made in good faith according to its rules. (I'm of the opinion that signature campaigns are generally detrimental to this forum's usefulness.) Additionally, the Mining boards are for facilitating serious discussions of bitcoin mining-related topics according to the rules of that section and the standards of the Serious Discussion and Ivory Tower boards. Unless wwzsocki is deemed to exhibit a genuine interest in bitcoin mining and a genuine eagerness to contribute quality discourse without regard for financial gain through signature and bounty campaigns, then he is not welcome in the Mining section.
15  Economy / Digital goods / [SOLD] Newegg Gift Cards on: January 14, 2020, 01:59:59 AM
Hello. The following Newegg Gift Cards are up for sale.

Quantity
Value
Item
Price
Expiration Date
SOLD
$440.33
Newegg Store Credit Gift Card
$400.00
None
SOLD
$46.34
Newegg Store Credit Gift Card
$40.00
None
SOLD
$29.99
Newegg Customer Care Gift Card
$20.00
2020-04-09T23:21:01Z

All Newegg Gift Cards are subject to Newegg's Gift Card terms and conditions.

All list prices are denominated in US dollars.

I accept payment in monero (XMR) only, either directly or via any escrow service provider from this list that both accepts monero and is willing to escrow gift card transactions. If payment is made via escrow, then the buyer shall pay the escrow service provider's fees in full.

To purchase or to request for more information, please contact me via forum PM.



2020-01-17T02:00:00Z

All Newegg Gift Cards have been sold.
16  Economy / Computer hardware / [SOLD] MSI B450 TOMAHAWK MAX and Delta DX-62 fans on: December 24, 2019, 02:00:00 AM
Hello. The following items are up for sale.

Quantity
Item
Unit Price
Condition
Dimensions
Mass
SOLD
1
MSI B450 TOMAHAWK MAX
$50.00
New
N/A
N/A
SOLD
3
Delta DX-62 fan
Pay what you want
Used
120 mm x 120 mm x 38 mm
N/A

All listed prices are denominated in US dollars. The buyer may denominate pay-what-you-want prices in monero (XMR) or US dollars. All prices exclude outbound shipping charges.

All items ship from a colocation datacenter in Canby, OR 97013, USA.

I accept payment in XMR only, via DarkStar's escrow service. DarkStar's escrow fee shall be equally divided between the buyer and myself. BitcoinAverage's published USD/XMR exchange rate at the time of the initiation of the escrow transaction shall be the reference exchange rate.

To purchase or to request for more information, please contact me via forum PM.



2020-01-08T03:00:00Z

The MSI B450 TOMAHAWK MAX and the Delta DX-62 fans have been sold.
17  Bitcoin / Mining support / Re: Monitoring IP connections to Antminer S9, showing connection to pool AND another on: November 02, 2019, 03:41:16 AM
If you would like to find out more information about those IP addresses before deciding whether to block them, then I suggest performing reverse lookups of the IP addresses to see what domain names they are mapped to, if any, and then performing WHOIS lookups of the returned domain names to see if those IP addresses belong to any entity that you know and trust.

If you are using a *nix OS — e.g., macOS or any Linux distribution — open a terminal window and enter the following:

Code:
dig @2606:4700:4700::1111 -x [IP address] +dnssec +multiline

(Replace [IP address] with the IP address that you are looking up. The IPv6 address 2606:4700:4700::1111 points to Cloudflare's public DNS resolver. You may change it to an IPv4 or IPv6 address of any other public resolver or simply leave out the @ field to query your local system's DNS resolver.) This should return the domain name that is mapped to the IP address, if any.

Then, perform a WHOIS lookup of the returned domain name by entering the following into your terminal:

Code:
whois [domain name]

(Replace [domain name] with the domain name that you are looking up. You may instead use a web-based WHOIS lookup client if you wish.)

If the returned results are suspicious or unknown to you, then I recommend blocking those IP addresses.
18  Bitcoin / Hardware / Re: Canaan Announces 11 Series on: October 19, 2019, 11:51:15 AM
I beg to differ.

Canaan announced the A721 on 2016-11-07. Commit 04e6a4b, titled Add Avalon7 support, was committed by qinfengling on 2016-07-29 and published by Canaan in the avalon7-dev branch of their cgminer repository on 2016-11-05. In other words, Canaan published the source code for the A721's version of cgminer two days before they officially announced the miner.

Canaan announced the A821 on 2017-12-20 at the latest. Commit 6786bbd, titled Add Avalon8 support, was committed by qinfengling on 2017-09-11 and published by Canaan in the avalon8 branch of their cgminer repository on 2017-09-27. In other words, Canaan published the source code for the A821's version of cgminer roughly three months before they officially announced the miner.

Canaan announced the A921 on 2018-09-19 at the latest. Commit fbc869b, titled Add Avalon921 support, was committed by Johnson-Fan on 2018-09-10 and published by Canaan in the avalon9 branch of their cgminer repository on 2018-09-11. In other words, Canaan published the source code for the A921's version of cgminer roughly eight days before they officially announced the miner.

Canaan announced the A10 at 2019-03-28T15:21Z. It is now almost seven months since the official announcement and there is still no published source code for the A10 in any of their GitHub repositories at the time of writing. The only entry for the A10 to date is the avalon10-docs repository, which merely contains a manual for the A10's API.
19  Bitcoin / Hardware / Re: Canaan Announces 11 Series on: October 19, 2019, 04:13:09 AM
It appears that Canaan has stopped publishing their source code in their GitHub repositories since the release of the A10 series. Given that the A10 (and presumably the A11) use cgminer — at least according to the only available documentation for the A10 — Canaan appears to have followed in the footsteps of the other manufacturers in violating cgminer's license.

If the A10 and A11 are using OpenWrt as the base OS, then Canaan is also violating OpenWrt's license by not publishing the source code for their fork of OpenWrt.

This is a regrettable development.
20  Other / Meta / Re: pool post ripped to altcoin pools on: July 31, 2019, 12:04:07 PM
I didn't move it. As far as I'm concerned, your topic did not violate the Pools board's rules, as it focused on announcing and discussing the bitcoin side of the pool.
Pages: [1] 2 3 4 5 6 7 8 9 10 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!