That's why we started a company, so we can work full time on Bitcoin.

That's withdrawing, not sending. I suppose you could withdraw to someone else's address, but some services have rules against that.

Review of terms of service (I only skimmed, as I don't intend to sign up regardless; also, IANAL and TINLA): Better than ChangeTip (you retain your civil rights, and I don't see any prohibition of RE).

BTW, where do you have MSB licensing?

My question is: you say you can send bitcoins to "anyone" - but does that include being able to send bitcoins to bitcoin users? That is, to an explicit bitcoin address and/or via the payment protocol, so the recipient isn't forced to sign up for Backslash?

If not, this is just an ewallet that forces others to use it rather than Bitcoin itself.

Sidechains use a concept called a "peg" which is for moving the same token between different independent blockchains.
There are (at least?) 3 different ways to implement a peg:

• SNARK peg: Uses a cryptographic proof of the other blockchain's rules being followed.
• SPV peg: Uses a "lightweight" proof that a transaction was mined, relying on trust in the miner collective for the other blockchain.
• Federated peg: Uses a set of trusted functionaries who all* must sign off on valid transactions between blockchains.

SNARK pegs and SPV pegs require a "softfork" (miner-only upgrade).
Federated pegs can be done with up to 15 functionaries using Bitcoin's multisig today.

The plan is to use SPV pegs for transfers out of the Bitcoin blockchain to a "SPV peg test sidechain", with return transactions (back to Bitcoin) using a federated peg.
Once the SPV peg test sidechain is mature/stable/well-tested to everyone's satisfaction, at that point there can be a softfork to make it the "main" blockchain (at which point the federated peg becomes unnecessary and goes away).

SNARK pegs are more complicated than SPV pegs, but can follow a similar process when the time comes.

* You can have fewer than all functionaries necessary to sign off, in case of lost keys or some going rogue.

A normal stratum error is fine.
{"id": whatever id the request has, "result": null, "error": (20, "Not supported", null)}

Good idea. If 3.1.1 works, it makes troubleshooting 5.0 much easier

The hardware error rate looks really high - is it possible that it may be defective?
Maybe try cgminer (you'll have to mess up your drivers with Zadig if you use Windows... ) and see if it performs any better with that? (if it does, let me know and I'll see if I can help fix BFGMiner..)

scrypt-n is not supported at this time.

Edit: Also, the only hardware I am aware of supporting scrypt-n is KnCMiner's Titan, NOT gridseed or zeusminer...

slush proposed a mining.get_hashrate for this a while ago... not sure if there's any specification/documentation of it though.

You'll need to hack the code for one of them.

work2d.c:work2d_init assigns work2d_xnonce2sz = 2

If you assign this to 3 on your pool-side proxy, it will divide 4+ byte pool extranonce into 3 byte chunks, and then the normal BFGMiner can divide that into 2 byte chunks.

They did send hardware... which is part of why it's confusing that they stopped communicating.

Nope.

That's what README.ASIC is for..

I haven't tried them, but there are a number of GUIs available for BFGMiner (yes, including BFL's EasyMiner - which should work for any supported device).

Uh, what?

So don't scan USB0...?

To not require an external PSU means they have to put in an internal PSU.
Which means additional certifications are needed, and can sometimes delay customs/shipment...

(that being said, I agree it's nice to have)

One could drop the MCU and use a USB-to-GPIO (or similar, depending on chip interface) to offload work onto the host....

Do you have enough test units to send one so I can try to have BFGMiner support at time of production shipping?
How about specs?