ASICMINER: Entering the Future of ASIC Mining by Inventing It

[DiabloD3]

how the hell would a 2fa protect any glbse user from the alleged "session fixation attack"?

It can ONLY if 2fa is enabled for everything as the attacker cannot guess the 2fa sequence. GLBSE does not yet offer 2fa for everything, just almost everything.

[1714908222]

1714908222

[1714908222]

1714908222

[1714908222]

1714908222

[1714908222]

1714908222

[1714908222]

1714908222

[friedcat]

Friedcat, is it possible to provide a timeline or a line without time   of what is to happen next ?

Thanks

+1

Was one of the large volume sell spikes yesterday (~4 PM and ~7 PM UTC) you moving to USD? If so, I think we got a pretty good price.

The large volume sell was not caused by us. We sold the 8,000 Bitcoins mainly via btcchina, with some other ways. The international bank wire fee ((2000 rmb + bank fee) for each withdrawal) and the limitation of withdrawal of mtgox made us not choose them. We caught some rally in the middle but not all, and finally got about 535k rmb after the transaction fee (0.3%) and the bank fee (1%). The cost of the MLM mask-set production and the first batch of chips are now secured no matter how deep the BTC price will dip.

We are busy working with the simulation, which is trying to make things 100% right on the design side before taping out.

The line will be:
1. We finish the simulation stage.
2. We do the three things in parallel:
    (1) waiting for the foundry to make the mask and produce the first batch of chips.
    (2) negotiating the final price and making formal contract with the packaging service company.
    (3) produce the first batch of PCBs.
3. The chips are packed and used for making boards.

Stage 2 consumes most of the time, it's about 45-50 days including several days of merging PLLs into our layout.
Currently we have no serious problem of the design, according to first two back-end iterations in this month. Therefore, the optimal delivering time (within October) and the non-optimal delivering time (November) are still expected.

This is not a formal update. I will make a more elaborated one when we reach the next milestone (all simulation done). Hopefully more tangible results could also be given. And we are getting ready for the financial report for the first major payments.

Sorry to all people that I didn't manage to reply in time.

[LoweryCBS]

The cost of the MLM mask-set production and the first batch of chips are now secured no matter how deep the BTC price will dip.

That is great news -- Very exciting!

We caught some rally in the middle but not all...

If you sold into this rally (see below) on the Chinese exchange, congratulations!

[arklan]

i'm wondering what we're looking at for the final product. a single chip for really low cost, multiple chips, or big TH boxes...

any info friedcat?

[friedcat]

i'm wondering what we're looking at for the final product. a single chip for really low cost, multiple chips, or big TH boxes...

any info friedcat?

In the first batch, we will get boards with multiple chips on each.
Single chips could be provided for sale later, when there are interested business partners.

[arklan]

i'm wondering what we're looking at for the final product. a single chip for really low cost, multiple chips, or big TH boxes...

any info friedcat?

In the first batch, we will get boards with multiple chips on each.
Single chips could be provided for sale later, when there are interested business partners.

good to hear. i'm not in any position to buy a $30,000 box, afterall... gona be lots small units bought over time here.

[xkrikl]

I don't really understand what you're saying, xkrikl.

Sorry, I didn't explain well myself. I was talking more in general without stating it.

"let them have a vote in some decisions"

They have no more nor less 'vote' than their number of shares weighted against all the other shares.

Generaly it doesn't have to be so. They could be the executive board. But that would have to be stated in the contract or standing orders. That's not the case of ASICMINER also because ... see next point

"only as a communication platform"

Yes. Their only significant 'power' is the ability to 'examine the books' of the 'company'. That is, verify, or not, that Bitfountain is doing what they say they're doing.

In case of ASICMINER the executive part is in Bitfountain only and ASICMINER as whole is only shareholder and ASICMINER's board is more like Control board.

As such, they have a vested interest in 'making things look rosy'. That is, communicate good news to the community until they benefit from an inflated share price and can dump their stock. (After which, of course, they could then 'bare their souls' and tell everyone why they sold all they had. So, in a sense, they are canaries in the coal mine.)

Well that might be problem if there is only few large investors who control small part (ie. less than 50%) and a lot of small investors. In such case they could take advantage of their position but I don't expect it to be the case here as I expect large percentage of ASICMINER's shares to be owned by the board members. Anyway that would be an interesting information to know.

Really, I only see the board member position as a, reasonable, way for Bitfountain to restrict who all they need to communicate fully with while at the same time having a credible amount of transparency.

Credible is the key word here. And now that the IPO is finished, it is pretty much a moot point.

We have all placed our bets. We'll see how they come out.

Yep and I believe that this will be a success and want to thank Friedcat for the great work he's doing in managing this IPO and communicating with us.
Thanks!

[nedbert9]

I'd like to thank Jatarul and Horserider for their offer to sell back the shares to me.

However unlikely, I'd like to make a plea to the buyer of

ASICMINER   2443   0.00021   2012-08-23 17:00:01

To purchase those shares.

[Jutarul]

I'm sorry to hear that.

However, isn't that a commitment you made?

I'm very sorry for all the confusion. By "extra" I didn't mean leftover unsold shares, I meant
the extra shares for large investors.

Sending leftover shares proportionally to shareholders is technically very hard.

This sentence isn't a excuse for me to avoid my commitment with "technical difficulty".
It's just to explain that I understood it's very hard in the first place so my "extra shares" did
mean extra 10% and 12.5% for larger bulk purchasers, but not all leftover ones.

I'm sorry again and it's my fault to bring so much confusion in my last post of announcement.

Alright. Then the unsold shares are currently an asset of asicminer. I guess we can keep them for later use. Might be interesting to release them slowly at market value when the first batch of chips arrived and the mining operation started. This way we can even raise more capital for further chip development and production without the need to modify the volume of total shares. Alternatively the surplus of the sale could go into paying dividends.

[HorseRider]

@Jutarul

Within my understanding, the way friedcat raise capital for the bitfountain is a little different than traditional. The total number of shares of the bitfountain is 400k, and no matter how many ASIC shares we purchase through the IPO, the number of bitfountain shares outstanding will not be impacted. Things happen in this way:

1. Bitfountain has 400k shares issued, which all belongs to the 3 partners.
2. An SPV set up named ASICMINER. the total number of shares outstanding is not decided.
3. Whenever ASICMINER issue 1 share, the 3 partners will sell 1 share of bitfountain to the ASICMINER at the price of 0.
4. ASICMINER will be responsible for the R&D cost of the bitfountain. if the money ASICMINER raised through its IPO is more than bitfountain need, there will be a special big dividend.
5. ASICMINER's share in bitfountain has a preference in the dividend distribution of bitfountain.

In conclusion, 1 ASICMINER share represents 1 bitfountain share, with some privilege.

[Jutarul]

@Jutarul

Within my understanding, the way friedcat raise capital for the bitfountain is a little different than traditional. The total number of shares of the bitfountain is 400k, and no matter how many ASIC shares we purchase through the IPO, the number of bitfountain shares outstanding will not be impacted. Things happen in this way:

1. Bitfountain has 400k shares issued, which all belongs to the 3 partners.
2. An SPV set up named ASICMINER. the total number of shares outstanding is not decided.
3. Whenever ASICMINER issue 1 share, the 3 partners will sell 1 share of bitfountain to the ASICMINER at the price of 0.
4. ASICMINER will be responsible for the R&D cost of the bitfountain. if the money ASICMINER raised through its IPO is more than bitfountain need, there will be a special big dividend.
5. ASICMINER's share in bitfountain has a preference in the dividend distribution of bitfountain.

In conclusion, 1 ASICMINER share represents 1 bitfountain share, with some privilege.

Thanks for the interpretation. I suspect these things get cleared up when friedcat prepares his first report and/or releases the business plan to board members. My current understanding diverges a bit from yours, mainly because I see 200k shares issued on GLBSE for ASICMINER. Thus, in your language, the shares already got sold from BITFOUNTAIN to ASICMINER beginning of August at a price of 0. All 200k shares are in the possession of ASICMINER. Those shares which haven't been sold through the IPO to the shareholders should still be in the account for ASICMINER.

[LazyOtto]

This very early post discusses the issue a bit. With some clarification IMO.

https://bitcointalk.org/index.php?topic=99497.msg1088302#msg1088302
"The unsold shares may be sold later, but hopefully with a higher price if we successfully produced our first batch of chips."

--

This was what I should have found earlier when I got distracted by distribution of 'extra' shares. Which are not "unsold" shares. (The extra were the 10% and 12.5% 'discounts' for large direct block purchasers.)

The difficulty I see with just leaving these shares unsold / undistributed is their 'proxy' power. Even if Bitfountain doesn't directly vote them as a proxy and they are left to abstain, any amount less than 200,000 in non-Bitfountain hands/control gives Bitfountain a greater than 50% effective vote.

But the quote above makes this situation clearly possible. And that statement was made prior to the IPO.

[Glasswalker]

One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.

[imsaguy]

One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.

Very nice.

[novusordo]

One approach to the "who owns how many shares" challenge, (I may suggest this to Nefario if he doesn't already have something else in the works):

- Allow an asset Owner to generate a "certificate" for a number of shares. Which then become "locked" in their account.
- They can unlock the shares at any time, which would invalidate the certificate.
- The asset Owner can then distribute a public key for the certificate, allowing someone else to verify they own the certified number of shares
- If at any time the certificate becomes invalid, any "subscribers" to the certificate, would be notified. (And it would show as invalid in the web interface).

This way if someone here for example wanted a seat on the board, they could email a request to the Issuer, who in turn requests a verification certificate for 5000 shares. They respond with a public key. Then the Issuer can use the public key to subscribe to  the certificate, and issue board member status accordingly. If the user decided to liquidate their shares they could do so without any "delay" but the Issuer would be notified immediately that the certificate had been invalidated.

This allows validation of share ownership, and it also allows maintaining privacy of the shareholders.

+1 internets for you, sir.

[Nefario]

I just want to chime in on the compromise.

There was no unusual activity around the time of the attack, meaning there wasn't a large number of attempted logins.

GLBSE uses SSL from the browser to Cloudflare and from Cloudflare to the GLBSE server, cloudflare can minify JavaScript (hence the "we may change site content" in their TOS). I have a paid service with them.

I specifically told nedbert9  that GLBSE is not vulnerable to session hijacking attacks, so I don't know why he stated that it was. GLBSE resets the session ID after login which prevents session fixation. We only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

In my PM I said apart from machine compromise, re-used/insecure password, the only thing I could think of that could be the cause was a session fixation attack, which GLBSE is not vulnerable to.

A session fixation attack requires the attacker to set the cookie in the users browser so the session ID is known, once the user visits a site and logs in, if the session ID is not changed then the (known session ID) becomes a valid session, and the attacker has succeeded. This is prevented by changing the session ID on login and using SSL (GLBSE only allows SSL).

I'm not able to say what caused the compromise, but I can say what it was not.

Nefario

[DeaDTerra]

I just want to chime in on the compromise.

There was no unusual activity around the time of the attack, meaning there wasn't a large number of attempted logins.

GLBSE uses SSL from the browser to Cloudflare and from Cloudflare to the GLBSE server, cloudflare can minify JavaScript (hence the "we may change site content" in their TOS). I have a paid service with them.

I specifically told nedbert9  that GLBSE is not vulnerable to session hijacking attacks, so I don't know why he stated that it was. GLBSE resets the session ID after login which prevents session fixation. We only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

In my PM I said apart from machine compromise, re-used/insecure password, the only thing I could think of that could be the cause was a session fixation attack, which GLBSE is not vulnerable to.

A session fixation attack requires the attacker to set the cookie in the users browser so the session ID is known, once the user visits a site and logs in, if the session ID is not changed then the (known session ID) becomes a valid session, and the attacker has succeeded. This is prevented by changing the session ID on login and using SSL (GLBSE only allows SSL).

I'm not able to say what caused the compromise, but I can say what it was not.

Nefario

ASICMINER has been compromised? :O
//DeaDTerra

[phantastisch]

I just want to chime in on the compromise.

There was no unusual activity around the time of the attack, meaning there wasn't a large number of attempted logins.

GLBSE uses SSL from the browser to Cloudflare and from Cloudflare to the GLBSE server, cloudflare can minify JavaScript (hence the "we may change site content" in their TOS). I have a paid service with them.

I specifically told nedbert9  that GLBSE is not vulnerable to session hijacking attacks, so I don't know why he stated that it was. GLBSE resets the session ID after login which prevents session fixation. We only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

In my PM I said apart from machine compromise, re-used/insecure password, the only thing I could think of that could be the cause was a session fixation attack, which GLBSE is not vulnerable to.

A session fixation attack requires the attacker to set the cookie in the users browser so the session ID is known, once the user visits a site and logs in, if the session ID is not changed then the (known session ID) becomes a valid session, and the attacker has succeeded. This is prevented by changing the session ID on login and using SSL (GLBSE only allows SSL).

I'm not able to say what caused the compromise, but I can say what it was not.

Nefario

ASICMINER has been compromised? :O
//DeaDTerra

No. Some shares were lost by Nedbert9 and he tried to figure out why and came to the conclusion the only weak point must be GLSBE with a session fixation attack. What really caused the loss, no idea.

[DutchBrat]

GLBSE resets the session ID after login which prevents session fixation. We only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

I don't know exactly what you mean by this, but I have Google 2FA installed.

When I log in on GLBSE en close the tab without logging out, I can re-open GLBSE after a few hours and it will come back up with me logged in, so I don't have to re-login

I do leave other tabs in my google chrome open, so I never close chrome completely

FYI

[matthewh3]

I just want to chime in on the compromise.

There was no unusual activity around the time of the attack, meaning there wasn't a large number of attempted logins.

GLBSE uses SSL from the browser to Cloudflare and from Cloudflare to the GLBSE server, cloudflare can minify JavaScript (hence the "we may change site content" in their TOS). I have a paid service with them.

I specifically told nedbert9  that GLBSE is not vulnerable to session hijacking attacks, so I don't know why he stated that it was. GLBSE resets the session ID after login which prevents session fixation. We only whitelist certain html elements for PM's and contracts so no XSS, and we use SSL so no man in the middle session sniffing attacks. Session ID's are not predictable or unencrypted.

In my PM I said apart from machine compromise, re-used/insecure password, the only thing I could think of that could be the cause was a session fixation attack, which GLBSE is not vulnerable to.

A session fixation attack requires the attacker to set the cookie in the users browser so the session ID is known, once the user visits a site and logs in, if the session ID is not changed then the (known session ID) becomes a valid session, and the attacker has succeeded. This is prevented by changing the session ID on login and using SSL (GLBSE only allows SSL).

I'm not able to say what caused the compromise, but I can say what it was not.

Nefario

ASICMINER has been compromised? :O
//DeaDTerra

No. Some shares were lost by Nedbert9 and he tried to figure out why and came to the conclusion the only weak point must be GLSBE with a session fixation attack. What really caused the loss, no idea.

Does he use Windoze