I've posted my designs at the URL below. Sprocket also appears to have made his designs available. We need community developers to take this code and turn it into bitstreams targeting the BCU1525 board found here.

https://github.com/sense-it/rtl

https://github.com/sprocket-fpga/FPGA_Mining_AWS

https://github.com/raiden017/moneroasic

Join us in the discord chat!
https://discord.gg/UgBquHS

[News / Updates:]

News / Updates:
05/29/18 - We are going to delay pre-sales at this time. We have calls scheduled with both Intel and Xilinx for this week. News to follow.
06/01/18 - Store opened at https://fpga.land/ for user registration. We are still not taking orders at this time but you can register and receive updates when hashrates, pricing and order information becomes available.
06/04/18 - Any developers in the community wishing to develop bitstreams please send me a private message. If you can't make a crypto core in RTL, this doesn't apply to you.
06/04/18 - We will NOT be able to accept credit cards for batch 1. Credit card processors are unwilling to allow us to process credit cards to sell you FPGA that any other site who doesn't market specifically to the crypto community would be able to sell and accept credit cards for. If we sold them as "FPGA Accelerators", no one would care. I should add, this is one of the reasons crypto was created in the first place.
06/05/18 - Pricing information has been released on our website https://fpga.land/
06/07/18 - Orders will open at 4PM EST on 06/07/2018
06/07/18 - Paypal disabled due to fraud and charge backs
06/08/18 - Sales have closed at this time. We may reopen sales if devices free up from cancelled or unpaid orders.
06/08/18 - Additional stock as opened up. Payments via crypto and bank wire only. Paypal has suspended our account.
06/12/18 - Paypal requested additional information to re-open our account for pre-orders. We won't be able to provide them the information by the time the sales close. They have agreed though to continue working with us in the future. We'll be allowed to sell via paypal for future batches.
06/14/18 - Several RTL source codes have been released by ourselves as well as Sprocket to bootstrap community RTL development. You can find our github repo here and sprocket's github repo here. Between the 2 of us we're covering around 90% of the algos in used today.
06/16/18 - Sales have closed. Register on the website to receive notice of openings for future sales.
06/21/18 - For those of you who purchased your fpga through us but wish to host with mineority will be given the opportunity to do so. We'll send out an email and update with details when we have them.
09/13/18 - Our pre-production BCU-1525 units shipped from Xilinx today. Volume production to follow; Current expectations are to start shipping volume units in early Oct. Additional shipping updates expected to follow once we have more information on exact shipping dates. We're hopeful we'll be able to ship all orders before the end of Oct.
10/20/18 - We've been busy shipping BCU-1525 units. To date a minimum of 800 units have been shipped out to customers of all sizes who did not opt to wait for additional upgrades (waterblocks, passive block upgrades, etc). We still have more units in the warehouse to prep for shipping and more units on the way scheduled to arrive next week.
11/2/18 - New build of minerator, bmc firmware and 60Mh/s lyra2z coming soon! We're expecting some community dev releases this week as well.


Allmine Developer / Miner website: https://all-mine.co/
BCU-1525 Instructions: https://miner.all-mine.co/setup-instructions
Discord Link: https://discord.gg/QMavGwv


FAQ

What are the hardware requirements for FPGA mining?

Currently there are no known specific hardware requirements for FPGA mining beyond basic requirements for GPUs. That is, a basic CPU, minimal ram, minimal disk, and x1 PCI-E 3.0 connectivity. There may be other hardware needs in the future for specific bitstreams. Some developers may opt to use the PCI-E bandwidth to communicate between cards or offload some processing from the FPGA to the CPU. In these instances, those developers will make known these hardware requirements. You may opt to upgrade or change your infrastructure then to support those bitstreams. The FPGA present a new way of doing things and there are countless possibilities for how various resources could be used in mining. Because this is an open but new development environment it will take some time for things to mature and the most efficient way of doing things to become evident.

What operating systems are supported for FPGA operations?

At launch we are planning only Linux support. When you're mining, even in windows, all that's really necessary is for you to be able to edit a file and run a command line interface application. We do not see using linux as a blocking point for the operation for miners. Detailed setup and installation instructions will be provided. We're also planning integration into some mining-specific linux distributions which will allow easy web interface management. However, even without the web management it should not be difficult for someone who's operated a GPU miner or ASIC miner to also operate a FPGA miner.

Can the FPGA multi-mine?

Yes! The FPGA can use resources however is needed for the developer to achieve their goal. It would be possible to mine several different algorithms at the same time on these devices. There are situations where some resources are more optimally used for one thing than another. Using the FPGA it's possible to mix and match algorithms and designs to achieve the best mix of resource utilization for profitability. An example of this, CN7 has a better hashrate using blockram. It would be possible to use CN7 on blockram, Lyra2z on the ultraram and using the rest of the logic space for a small tribus or other logic algo mix. Going forward with future generations of devices as they become larger I'd expect even greater variation of mining. It's becoming clear that the most profitable bitstreams will be multi-algo bitstreams.

What is "the shell" and why do I need it?

"The Shell" fundamentally is a wrapper around any mining bitstream that will run on your FPGA. The wrapper provides a common set of communication and programming functionality to allow anyone's bitstream or design to operate on your FPGA without re-programming the FPGA using the USB cable. We're able to provide this because we've burned an encryption key onto every FPGA shipped. This encryption key is what enables the creation of our secure shell environment. Some examples of functionality that the shell provides are:

    Hardware Management (Temperature, Power (Voltage/Amperage), Clock sources, PCI-E, Programming / Reprogramming)
    Bitstream Management (Bitstream distribution, developer fee collection)
    Mining Software (Bitstream management, Algo management, common communications platform for all bitstreams)

For Developers:

It allows developers an easier time to get started without needing to build their own software, communications, or worry about secure their development fee. They can focus solely on producing the best possible bitstream designs for maximum profitability. Due to the secure nature of the bitstreams it will enable developers who previously may have not released their designs, to release their designs, as they won't fear people attempting to cut out the developer fee and diminish their work.

For Miners:

Miners will get a wider selection of bitstreams, an easier and faster way to switch between them (over pci-e instead of USB), and easier management of their miners with our online config builder and management system. As of now, if you want to switch from one bitstream to another it would take possibly hours of reprogramming depending on the number of FPGA you have. Using our shell it will take seconds to switch bitstreams and starting mining a new one. This creates a better environment for profit switching and increased gains.

In addition, the shell and software provide user side control of clocking and overclocking. The user can define their own parameters for what they find to be desirable for voltage, clock, temperature, etc. Or, if desired, tell the software to overclock to the maximum of the safety limits.





Hashrates:
Lyra2z (8,8,8) - 40Mh/s 225W ~ Still under development
Cryptonight variant 1 / monero version 7 - 14Kh/s 150W



Notes: Only posting hashrate numbers we're 100% sure about. Cores still under development are expected to increase in hashrate.

I have 2 bitmain A3 units I'm looking to part with for $3500 ea. All 3 hashboards are fully functional on both units. Both units were underclocked to keep temps <= 75c. One unit was clocked at 500mhz the other unit at 550mhz. Located in the mid-east. I can ship out monday EST TZ at the earliest.

I have a bitmain L3+ with the kill-a-watt meter it shows it consuming around 900W at 120v. Since switching it over to my 240V tripplite pdu (+/-1% billing grade current accuracy), the PDU is showing around 720watts consumption. That's a pretty big difference and only about 30watts can be explained by the PSU efficiency increase on 240v over 120v. Starting to think those things (killawatt) really aren't all that accurate.


 

Selling 2x AMD Vega 56's ($550) and 1x AMD Vega 64 ($600).





Reason for sale: I can't fucking tolerate the AMD drivers. I need to sell these cards before I make a youtube video of me bashing $1800 worth of gpus with a hammer.

Price doesn't include shipping.

-- I had not seen this posted yet, so I thought I would post it. It's critical all exchanges, pools, etc upgrade their kernels immediately to address this issue. If these services are operating inside of VMs, they will need to contact their hosts to make sure the hypervisor kernel is upgraded to patch the issue as well. The patch for the problem results in an estimated 30% decrease in performance.

https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/

Final update A fundamental design flaw in Intel's processor chips has forced a significant redesign of the Linux and Windows kernels to defang the chip-level security bug.

Programmers are scrambling to overhaul the open-source Linux kernel's virtual memory system. Meanwhile, Microsoft is expected to publicly introduce the necessary changes to its Windows operating system in an upcoming Patch Tuesday: these changes were seeded to beta testers running fast-ring Windows Insider builds in November and December.

Crucially, these updates to both Linux and Windows will incur a performance hit on Intel products. The effects are still being benchmarked, however we're looking at a ballpark figure of five to 30 per cent slow down, depending on the task and the processor model. More recent Intel chips have features – such as PCID – to reduce the performance hit. Your mileage may vary.
Similar operating systems, such as Apple's 64-bit macOS, will also need to be updated – the flaw is in the Intel x86-64 hardware, and it appears a microcode update can't address it. It has to be fixed in software at the OS level, or go buy a new processor without the design blunder.

Details of the vulnerability within Intel's silicon are under wraps: an embargo on the specifics is due to lift early this month, perhaps in time for Microsoft's Patch Tuesday next week. Indeed, patches for the Linux kernel are available for all to see but comments in the source code have been redacted to obfuscate the issue.

However, some details of the flaw have surfaced, and so this is what we know.
Impact

It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka FUCKWIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

Whenever a running program needs to do anything useful – such as write to a file or open a network connection – it has to temporarily hand control of the processor to the kernel to carry out the job. To make the transition from user mode to kernel mode and back to user mode as fast and efficient as possible, the kernel is present in all processes' virtual memory address spaces, although it is invisible to these programs. When the kernel is needed, the program makes a system call, the processor switches to kernel mode and enters the kernel. When it is done, the CPU is told to switch back to user mode, and reenter the process. While in user mode, the kernel's code and data remains out of sight but present in the process's page tables.

Think of the kernel as God sitting on a cloud, looking down on Earth. It's there, and no normal being can see it, yet they can pray to it.

These KPTI patches move the kernel into a completely separate address space, so it's not just invisible to a running process, it's not even there at all. Really, this shouldn't be needed, but clearly there is a flaw in Intel's silicon that allows kernel access protections to be bypassed in some way.

The downside to this separation is that it is relatively expensive, time wise, to keep switching between two separate address spaces for every system call and for every interrupt from the hardware. These context switches do not happen instantly, and they force the processor to dump cached data and reload information from memory. This increases the kernel's overhead, and slows down the computer.

Your Intel-powered machine will run slower as a result.
How can this security hole be abused?

At best, the vulnerability could be leveraged by malware and hackers to more easily exploit other security bugs.

At worst, the hole could be abused by programs and logged-in users to read the contents of the kernel's memory. Suffice to say, this is not great. The kernel's memory space is hidden from user processes and programs because it may contain all sorts of secrets, such as passwords, login keys, files cached from disk, and so on. Imagine a piece of JavaScript running in a browser, or malicious software running on a shared public cloud server, able to sniff sensitive kernel-protected data.

Specifically, in terms of the best-case scenario, it is possible the bug could be abused to defeat KASLR: kernel address space layout randomization. This is a defense mechanism used by various operating systems to place components of the kernel in randomized locations in virtual memory. This mechanism can thwart attempts to abuse other bugs within the kernel: typically, exploit code – particularly return-oriented programming exploits – relies on reusing computer instructions in known locations in memory.

If you randomize the placing of the kernel's code in memory, exploits can't find the internal gadgets they need to fully compromise a system. The processor flaw could be potentially exploited to figure out where in memory the kernel has positioned its data and code, hence the flurry of software patching.

However, it may be that the vulnerability in Intel's chips is worse than the above mitigation bypass. In an email to the Linux kernel mailing list over Christmas, AMD said it is not affected. The wording of that message, though, rather gives the game away as to what the underlying cockup is:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

A key word here is "speculative." Modern processors, like Intel's, perform speculative execution. In order to keep their internal pipelines primed with instructions to obey, the CPU cores try their best to guess what code is going to be run next, fetch it, and execute it.

It appears, from what AMD software engineer Tom Lendacky was suggesting above, that Intel's CPUs speculatively execute code potentially without performing security checks. It seems it may be possible to craft software in such a way that the processor starts executing an instruction that would normally be blocked – such as reading kernel memory from user mode – and completes that instruction before the privilege level check occurs.

That would allow ring-3-level user code to read ring-0-level kernel data. And that is not good.

The specifics of the vulnerability have yet to be confirmed, but consider this: the changes to Linux and Windows are significant and are being pushed out at high speed. That suggests it's more serious than a KASLR bypass.

Also, the updates to separate kernel and user address spaces on Linux are based on a set of fixes dubbed the KAISER patches, which were created by eggheads at Graz University of Technology in Austria. These boffins discovered [PDF] it was possible to defeat KASLR by extracting memory layout information from the kernel in a side-channel attack on the CPU's virtual memory system. The team proposed splitting kernel and user spaces to prevent this information leak, and their research sparked this round of patching.

Their work was reviewed by Anders Fogh, who wrote this interesting blog post in July. That article described his attempts to read kernel memory from user mode by abusing speculative execution. Although Fogh was unable to come up with any working proof-of-concept code, he noted:

My results demonstrate that speculative execution does indeed continue despite violations of the isolation between kernel mode and user mode.

It appears the KAISER work is related to Fogh's research, and as well as developing a practical means to break KASLR by abusing virtual memory layouts, the team may have somehow proved Fogh right – that speculative execution on Intel x86 chips can be exploited to access kernel memory.
Shared systems

The bug will impact big-name cloud computing environments including Amazon EC2, Microsoft Azure, and Google Compute Engine, said a software developer blogging as Python Sweetness in this heavily shared and tweeted article on Monday:

There is presently an embargoed security bug impacting apparently all contemporary [Intel] CPU architectures that implement virtual memory, requiring hardware changes to fully resolve. Urgent development of a software mitigation is being done in the open and recently landed in the Linux kernel, and a similar mitigation began appearing in NT kernels in November. In the worst case the software fix causes huge slowdowns in typical workloads.

There are hints the attack impacts common virtualisation environments including Amazon EC2 and Google Compute Engine...

Microsoft's Azure cloud – which runs a lot of Linux as well as Windows – will undergo maintenance and reboots on January 10, presumably to roll out the above fixes.

Amazon Web Services also warned customers via email to expect a major security update to land on Friday this week, without going into details.

There were rumors of a severe hypervisor bug – possibly in Xen – doing the rounds at the end of 2017. It may be that this hardware flaw is that rumored bug: that hypervisors can be attacked via this kernel memory access cockup, and thus need to be patched, forcing a mass restart of guest virtual machines.

A spokesperson for Intel was not available for comment. ®
Updated to add

The Intel processor flaw is real. A PhD student at the systems and network security group at Vrije Universiteit Amsterdam has developed a proof-of-concept program that exploits the Chipzilla flaw to read kernel memory from user mode:

The Register has also seen proof-of-concept exploit code that leaks a tiny amount of kernel memory to user processes.

Finally, macOS has been patched to counter the chip design blunder since version 10.13.3, according to operating system kernel expert Alex Ionescu. And it appears 64-bit ARM Linux kernels will also get a set of KAISER patches, completely splitting the kernel and user spaces, to block attempts to defeat KASLR. We'll be following up this week.
Final update

Check out our summary of the processor bug, here, now that full details are known. Bear in mind there are two flaws at play here: one called Meltdown that mostly affects Intel, and what the above article is all about, and another one called Spectre that affects Intel, AMD, and Arm cores.

See our analysis of Intel's response here.

I wish I could get this design on my AMEX gold. EPIC. Maybe tenx? or monaco?

Bounty: 0.2 BTC

I'm trying to mine XVG/Verge through the YIIMP/YAAMP stratum server. I'm getting the following error in the wallet debug.log when a block is found and submitted. "first tx is not coinbase"

I've tried setting:

rpcencoding POW
txmessage 1/0
hassubmitblock 1/0
hasmasternodes 1/0
setting "account"
setting "master_wallet"
multialgos 1/0

and a few other things.

I will have other work in the future, if you're a C coder who's familiar with the YIIMP/YAAMP stratum server and are knowledgeable about coin wallets. I will have a lot of work for you going forward.

I wanted to cash out some funds to my US accounts to pay off some debts. I can't do this directly to any of my accounts because all of my accounts are with banks that will immediately close your account if you're dealing with BTC. Hoping I can use etrade as a middleman.

Has anyone tried to cash out via etrade before? If so, what amounts have you cashed out?

Does anyone know of a btc friendly bank in the US?

Are there any RPC to Stratum proxies that are designed for solo mining?

Right now the pool server I'm mining on has terrible luck. It makes me think they're scamming and I'd rather just go it alone. Unfortunately my mining software doesn't support a direct RPC connection. I need some sort of middleman between the wallet and my miner that supports stratum.

I would prefer it if the stratum didn't verify if a share was valid (reduce CPU load and complexity) before pushing it off to the wallet. If it sees a share > networkdiff it would immediately push it to the wallet. This would give it sort of universal support.

In my mind I'm thinking -- Why would anyone put in all that work and get nothing for it? How many altruists do you really know in your life? Am I really expected to believe that those doing it here are all great people?

Am I the only one who when they see "0% fee" runs for the hills? What do you think?

I've already caught a few pools pulling shady shit (for example, inserting shares to the DB that appear on the graphs but aren't associated with any user). I have a significant amount of hashrate so when I mine on a pool where I'm 80%+ of all hashes.... It's easily noticeable when they start throwing in an extra 20% here and there. No one else on the pool has that level of hashrate and it's well beyond variance.

I think I need to start solo mining again...

  

I'm currently looking for investments in our mining venture so we can enter production. We're already mining on prototype hardware. We're raising $2M in total to enter production. I'd like to keep the investments at a minimum of $100,000 per investor. Valuation will be set at $10M. Returns are far beyond anything from GPU or ASIC mining investment. Risk has been minimized in the business plan.

Contact me if you're interested. I'll be making a worldwide fundraising tour soon and might be able to stop by to give you a presentation in person. I'll need to see proof of funds in the form of a bank statement or a signed message from your bitcoin wallet as a proof of capacity.

Can we please do something to speed up transaction time and the high transaction fees?

This is getting absurd. I just spent $10 USD to send $7500 but my fee was too low. It may take a week for my transaction to process. Who knows. I should have spent 3x that figure to get processing within 1 hour ($30). With that same fee I could have just used a wire transfer from a bank online and it would have been just as fast as bitcoin. The selling point of bitcoin is that it was supposed to be 'better' than traditional banking services. It's not.

IMO, the following things need to happen.

#1) Block time decrease from 10 minutes to 1 minute. (and decreasing reward by / 10 per block)
#2) Difficulty readjustment period from 2016 blocks to 720 blocks. (2 difficulty readjustments per day with the decrease in block time from #1)
#3) Apply a system of master nodes where there are 10,000 nodes that receive an equal split of 1% of all bitcoins generated. (Comes out to about $200/month at current USD rates, enough to pay for a dedicated server or colocation space to host the node in a good environment almost anywhere in the world.)
#4) Reduce the amount of read/writes to disk on a bitcoin full node. I stopped running a full node because it lags everything else my computer tries to do. Not because of the disk space it consumes.

We just went 50 minutes between blocks as I was writing this!

Everyone sell before bitcoin hits $0!! Tulips have no value!! The market is crashing! Sky is falling! You're going to lose all your money! SEGWIT IS COMING TO TAKE YOUR COINS!


















Sorry, I wouldn't normally do this. But after reading /r/bitcoin on reddit; I had to.

With difficulties more or less locked for the next 14-28 days. What do you think is going to happen once AMD starts pumping out the GPUs again?

Personally, I'm not going to buy any more cards. Concerned the difficulty is going to exceed profitability due to my high electrical cost.

Just waiting for the... "just bought $5k worth of video cards! they're only making $10 per month?" threads..

I have a system I just built with 1x RX 570 pulse 4GB and 1x RX 570 nitro 4gb. The system runs fine with just the pulse or nitro. If both are together it crashes (screen shows lines / hard crash). I've been playing with memclock and gpuclock settings for a few hours now thinking that was the problem. Until I realized it wasn't.

Why are they crashing? Is it the mining software that's the problem, drivers, or what? Is there a fix? I don't really want to build another system just for 1 gpu.

I'm running ubuntu 16.04 with AMDGPU-PRO-17.10

I ordered 10x tishric ver006c from 'ShenZhen TISHRIC Factory Store' on May 31st. 8 days in, no shipment, no replies after saying they were going to ship them. I cancelled the order today.

I ordered 6x tishric ver006c from 'Micro computer products' on June 2nd. 6 days in, they entered a fake tracking number, then updated the tracking number 24 hours after, and after 2 days of having issued a real tracking number still have not given the package to the shipping company.

Are all the sellers of pci-e extenders aliexpress scams or what? I ordered some other non-mining related items on June 6 and I already have them. Has anyone successfully ordered pci-extenders from aliexpress?

I just setup a few gpu miners today trying to get back into the swing of things.

I have the units mining, but am unable to tweak them as I can't find the aticonfig/amdconfig utility anywhere. I installed the latest amdgpu-pro driver (17.10) on Ubuntu 16.04 x86_64. It's mining just fine, but the utility necessary to modify clock rates, etc is missing. Any ideas?

I managed a team who developed a X11 RTL firmware. While the X11 itself is too large to be usable in most commodity FPGA; some of the newer coins which are picking up steam are using algos contained within X11. Others are using variations which only require slight modifications to get running. We're looking at the possibility of leasing bitstreams to those who may be interested in monetizing hardware that is collecting dust.

Anything from a spartan 6 LX150 and up can be monetized.

Selling brand new Lenovo Thinkpad P50 laptop in original unopened packaging. I placed an order on black friday and they sent me a double order. They wanted a restock fee to accept the return so I decided to sell the extra unit instead. The laptop is located in the US and will include ground shipping inside the continental 48 states free of charge. I'm willing to ship outside the US if you pay the shipping costs and any necessary duties / taxes.

• CPU: Intel Core I7 6700HQ
• Memory: 16GB DDR4
• Video: NVIDIA Quadro M1000M 4GB
• Display: 15.6 FHD IPS Non-Touch
• Disk: 256GB SSD SATA3 OPAL2
• Wireless: Intel 8260AC+BT 2x2 No vPro
• Security: Fingerprint reader
• Keyboard: Backlit keyboard
• Operating System: Windows 10 Home

Asking $1250 in BTC (roughly 1.2BTC) -- Current price on the lenovo site for the same unit is $1,641.60