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

It seems BFL now expects to have the chips in hand from the foundry the week of Dec 11th (towards the end)

https://forums.butterflylabs.com/bfl-forum-miscellaneous/437-asic-update-26-november-2012-a.html

Delays all around !

Nono, flowers please.

So 3-4 tickers a day eh GLBSE? Should we go after Nefario with torches and pitchforks yet?

+1 for BTCT.CO for the above reasons.

After GLBSE I'd expect quite a few will share your sentiments about using ANY online exchange - and that's not unreasonable.  It's also the case that there's definitely risks associated with using ANY online exchange - be it BTC.CO, MPEX, CRYPTO or whatever.  Even if they provide fairly timely (as if the case with BTC.CO) or very timely (as is the case with MPEX) information to identify shareholders, there's never going to be a total guarantee that they won't just run with your funds.  And no company ownership structure can change that - at the end of the day SOMEONE is going to have access to the wallets.  Adding more people with that access would increase risk, not decrease it.


But on the other side of the coin there's also some of us (myself included) who would like to be able to trade our shares - either selling the ones we have or buying more.  In my case I'd like to be able to do both - as I generally trade rather than invest.

So isn't the obvious solution for ASICMINER to list on an exchange - but only transfer to it the shares of those who WANT to trade on there (and accept the risks associated with that).  As an existing user of LTC-GLOBAL who likes the platform and the way burnside runs things I'm in favour of BTC.CO - but if ASICMINER went to cryptostocks instead I'd settle for that.

There's no risk to ASICMINER in such a move:

The fee for creating an asset on BTC.CO would be refunded,
The distribution of initial shares would be largely automated (once a list had been compiled of those who wanted their shares there),
The only funds ASICMINER would have to hold there would be dividends for the shares on there briefly prior to disbursement.

Investors who wanted their shares kept off an exchange could just leave the with friedcat to be handled however they'd be dealt with if there wasn't an exchange listing at all.

This would allows those who want to trade shares to do so - without friedcat having to participate in it.  Any risk to their BTC deposited there would be nothing to do with ASICMINER, and if BTC.CO suddenly vanished then friedcat could just look in his mailbox for the last emailed list of shareholders and use that for ownership of those shares (or he could set up a cron job to query the API every 5 minutes and always have a list no more than 5 minutes out of date).

So yeah - there's a risk.  But there's also a reward.  Let those of use who believe that risk/reward ratio is favourable take the risk - and enjoy the reward.

Don't want to hijack.  Response here: https://bitcointalksearch.org/topic/m.1352600

burnside is a good egg, but the fact is you don't have to trust him. As always you have to trust the asset issuer, that has not changed.

Apologies friedcat, not trying to derail your thread.

Skepticism is a good thing to have in this community.

I'd definitely like everyone to look into what we've built, but I highly doubt that it'll be a perfect fit for all the assets that were on GLBSE.  Good thing is, there's lots of options out there.   

Oops. Sorry for rushing to conclusions. This seems worth considering.

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)