Topic: ASICMINER: Entering the Future of ASIC Mining by Inventing It - page 1303. (Read 3917029 times)

Don't be confused by the owner account having only 19 posts - that's just an account created for posting in respect of btc.co.  Guess he didn't make that plain anywhere.

The manager/developer is burnside who runs LTC-GLOBAL exchange - which you likely wouldn't be aware of as it's for Litecoin so in the Alt currencies section.

https://bitcointalksearch.org/topic/ltc-global-the-litecoin-global-virtual-stock-exchange-public-beta-101694

He also runs a mining bond and a mining pool.

The new exchange runs the same code that was used on LTC-GLOBAL.  If you look at the thread above you'll be able to see quite clearly that he's a heck of a lot better than nefario ever was at responding to users, updating the site etc.  And the site's nothing like the slow, clunky thing that was GLBSE.  Some of the shares giving ownership of btc.co are traded on LTC-GLOBAL - they're now proxy shares into the Bermuda-registered company owning the site.

I'm also an asset-owner on LTC-GLOBAL (a tiny LTC-denominated fundm and shortly a fixed-rate bond).  My fund holds a few ASIC-MINER shares - hence my interest in this thread.

The "owner" is a large group of shareholders in the community.

The posts you see come from the company account, created for the new BTC version of the exchange.

Cheers.

This is a good point. No offense to anyone.

Yeah I'd like the few shares I own on that exchange too.  I use both Cryptostocks.com and litecoinglobal.com (the same software as the quoted exchange) and litecoinglobal.com is much more easy to use and with more features too.

https://btct.co/ & LTC-GLOBAL security issuers have full access to shareholder information(email address & # of shares held) updated every transaction. This information is also periodically emailed to the asset issuers email address of record. Safeguards against a GLBSE like calamity have been built into both exchanges from the start.

Disclosure: I am a LTC-GLOBAL shareholder and asset issuer.

Learning from past mistakes, I advice to research how much control the asset issuer has over the shareholder information. As with GLBSE, any exchange can vanish over nite, taking all the data with it.

ADDENDUM: Also, I advice larger shareholders to still take advantage of the "direct" shares lock-in option offered by friedcat, once the claims are processable.

Friedcat, this new exchange could be of interest.

They have setup a protocol to 'import' an asset if had previously been listed at GLBSE.

Now that it seems Nefario is sending out the asset info list in a regular format, it might be practical.

https://bitcointalksearch.org/topic/m.1350580

Actually there is another thread which is supposed to be dedicated to the device (block erupter). I'd say that includes any software which operates it: https://bitcointalksearch.org/topic/block-erupter-dedicated-mining-asic-project-open-for-discussion-91173

This thread is rather reserved for discussions about bitfountain funding and shareholder information.

I'll post it here
(then we can create a thread if a discussion develops here)

I'm using libusb on linux and libusbx on windows (so a consistent code interface for both - same code for both)

In it's first incarnation it's using Bulk transfer to do everything coz I have it running (already working) on an FPGA ModMinerQuad
Working with no trouble already on Linux - just reworking the device identification code coz it didn't work on windows
The ASIC version may need Interrupt transfers for better performance, but I'll get to that, if needed, after the initial code is fully working with Bulk transfers.

If your MCU developer is well versed with the different USB transfers and their advantages/disadvantages then they will be glad to know that the basic identification code (not finished yet) will allow any Transfer Type - but I've only implemented Bulk so far in data transfer.

The MMQ code runs 4 threads (to 4 devices) over a single MCU - so there's no issues (at least for me) for dealing with multiple threads and multiple endpoints - but I envisage only using a single interface - hopefully with 2 endpoint pairs

FPGA MMQ's poll (and so do BFL FPGAs - but Icarus FPGA doesn't) so the actual MMQ code won't look like how it will with ASIC
(I sincerely hope you do not implement any polling requirement - I'm pretty sure neither BFL or bASIC will - and since Avalon is from the Icarus developer who didn't do that in their first FPGA I'm pretty sure they wont with Avalon)

The expected high level interface is: send work, wait for zero or more nonce replies, after zero or more replies sent, get a completion message back.

If you go beyond that level to handling difficulty or even implementing something like stratum in the MCU, then that will of course be done differently.

If you implement difficulty, I'd have the miner actually request shares at an easier difficulty than required (and have some limit even on that) since the advantage of a short known expected average response time is that you also find out quickly when something has gone wrong.
(device disconnect, USB reset required etc)
Clearly there is a trade off between response time and USB limitations - e.g. if someone has 100 mining devices on a single computer

USB1 has a transaction time of 1ms and USB2 of 0.125ms (but can be faster with different transfers)
So hopefully you will be using at least USB2 (some of the FPGAs are currently USB1)

I'm not much of a USB expert (I've only been messing around with it for a few weeks) but there would be advantage to having multiple endpoints so that one pair is used for the mining and another pair can be used for the status type protocol.
(e.g. temperature, configuration, etc over a different endpoint pair to mining)
Would obviously make the mining software easier but I'm not sure of the positive or negative effects of that on USB.

As for the MCU firmware itself, I'm 99.9% sure the firmware will be uploadable on all ASIC devices, so I don't expect you'll gain much by hiding the details of that.

Meanwhile if you wish to discuss anything in PM or private IRC then that's fine.
But obviously once the miner code is implemented there won't be many secrets

We are very sorry for our misunderstanding. We are using an older version of TheSeven's Bitcoin miner written in Python as the code base to run our test boards. It had been also used for testing when we were in the FPGA verification phase. However, since the chips are not out yet, we are running with artificial unreal signals without the actual chips producing them. So "our part" of specialization/optimization couldn't be done without real chips providing real statistics.

We chose it because we wanted to focus on the hardware and spend less time on fixing the code. It may be totally abandoned and switched to a C-written miner if we couldn't push the number of mining boards each controller board could handle high enough with the overhead of the Python interpreter.

We are very sorry but it is now hard to achieve the projected date given by the time we were doing the design, because of the delay from our chip manufacturer.

With respect to the firmware, that is, software running on each mining board's controller MCU, there are no reason why we couldn't make them public except that they are not final. What we would like to keep secret is the RTL design, which contains a lot of optimizations. Everything else will be open since they are almost straightforward.

So the community will get the firmware immediately after we get a really running version with real chips. We are sorry again for the original estimated date and the current slower progress.

Would you mind if you could PM us for some more details please? We are doing everything we could to make sure we are not the cause of the critical path of the whole project and reduce the whole deploying time. So we will be very glad if we could get any help and idea from you.

I completely forgot about that post.
Oops. Sorry.

But yeah I guess I asked again coz things are getting close to deadlines and I've actually not heard from any of the ASIC developers yet.
I'd have thought at least one of them would have sorted out their firmware by now, but not even a whisper yet.

BFL will be sending me to their factory when things are ready, and Tom will be sending me a a bASIC once they have the dev devices ready.
Like most everyone else, I'm getting a little agitated waiting and will not be surprised if we're given zero time to get the software ready
(though I've almost completed the new internal libraries to use direct USB rather than Serial-USB to help with performance and to hopefully simplify ASIC implementations)

Hrm, if friedcat sent me one to keep, I'd get DiabloMiner working with it I bet.

Edited with the right quote marks, as it was Friedcat who said it, not me

So to repeat this question with, I guess, more info, coz it wasn't obvious what I meant (and no one replied)

What software are you using?

Update

We are very sorry for the delay of chips delivery. The OP was initially created to raise funds. Now it should used for other purposes like general information. However, the current OP also serves as a detailed version of the contract. With GLBSE unable to recover the contract text, we ask for people to first quote it several times before we make a significant change to it.

Yes. The wafer process is done layer by layer and we could see the progress on track. We began receiving software generated excel updates from the foundry bypassed through our foundry agent showing the production status almost every workday.

Nice. We will keep people updated whenever we receive them.

It is in principle not able to 100% distinguish false claims with wrong claims caused by dynamic open orders and inaccurate memory. So we would rather not to make them open, especially that we don't have the right to publicize information with the owners want them be private.

This is very good news!!!

Nefario is supplying the asset info starting with the largest assets in descending order

So I guess Friedcat should get a userlist pretty soon

http://blog.glbse.com/issuers-being-given-shareholder-lists