|
Quick question... Will the first dividend be paid to the winners?
|
|
|
|
in the GPU/FPGA days, a malicious entity could have developed their own ASICs and relatively easily performed a >50% attack. once asics are widely available, it will be much more difficult.
Precisely. So long as ASICs are widely distributed, the chance of an attack occurring dwindles significantly. The question then becomes what will eventually replace an ASIC (if anything) that is much more powerful? Nothing. Purpose-built ICs are the end of the line. Or rather, better ASICs replace the early ASICS, and eventually will be replaced by even better ASICs. |
|
|
|
|
100 shares @ 0.38 each
Hopefully the 5000 guy now understands that he doesn't need to keep bidding his own prices up.
|
|
|
|
|
It shouldn't matter much. As long as the chips make good contact with the heatsink (thermally speaking), all subsets of 4 spots should be nearly equivalent. I'm sure that some are measurably better, but not meaningfully.
If the heatsink is mounted at a fixed height from the PCB, the matter is mostly aesthetic. If the heatsink is floating on the chips (hopefully with a compressible pad) then you want the 4 corners to evenly distribute mechanical stress. NSEW would be just a tiny bit worse.
|
|
|
|
I think, all order info and shipping info is received from Walletbit. So, what have Walletbit is what will have Avalon. IMHO.
Avalon collected the info using wordpress. The payment link went to walletbit. The walletbit page provided absolutely no information other than the amount. Walletbit may have that info, but so far I haven't seen any reason to believe that anyone involved has both the shipping info and the payment info. All shipping info were included in URL, when Avalon redirected to Walletbit. I don't have that browser in front of me, so I can't check my personal URL history. I remember a token and an amount for sure, don't particularly remember a shipping address. In this specific case, I hope they have it. But in general, I don't think that a store should be sharing my personal information like that. Walletbit has no reason to know my name or address. |
|
|
|
I think, all order info and shipping info is received from Walletbit. So, what have Walletbit is what will have Avalon. IMHO.
Avalon collected the info using wordpress. The payment link went to walletbit. The walletbit page provided absolutely no information other than the amount. Walletbit may have that info, but so far I haven't seen any reason to believe that anyone involved has both the shipping info and the payment info. |
|
|
|
If they didn't like the conditions, they didn't have to use any of it. Not releasing their changes is just shitting on the community, and as I mentioned before, pointless.
That would only be true if Avalon said they will not release source code; but they have always maintained that they will release source code. At least that's what I was told. Based on that, the only question is the date of release, and by extension, the patience level of forum posters  They were in violation of international copyright treaties the moment they shipped. The GPL doesn't say that you must intend in the future to release the source code, it says that the physical product must be accompanied by either the source code or a written offer to provide the source code. By default, there is no right of distribution. They only way to get that right is through a license. The GPL provides an automatic license to people that comply with the terms described. Failure to comply with those terms = copyright violation and termination of license. Section 8 provides ways to restore the license, but it does not excuse a violation and does not give a grace period during which violations are acceptable. At any rate, I don't really care much about violations. I had two points, the first being that 2112's notion that the GPL is an evil thing, strangling poor projects in their crib is nonsense, and the second that there was not, is not, and never will be, a good reason for Avalon to have failed to provide the software alongside the physical product. Again, I'm just quoting for future reference because this board allows ulimited message editing/deletion. This is an example of how defense of international software copyright treaties kills competition in hardware business preventing the startups from recouping the NRE costs. The biggest enemy of Bitcoin aren't banksters or whatever else powers-that-be. The enemies are the hormone-laden cholerics that simply cannot think on the horizon longer than a month or (rarely) year. Why would I edit or delete my posts? You are the insane one here, not me. Heh, ok, calling you insane might be a bit over the top, so I may edit that to a nicer term later. They used software that requires disclosure of changes. No one forced them to use it. They made the decision voluntarily. They had the right to write their own software and keep it secret. Hell, if they really wanted to, they could have tracked down all of the authors and negotiated a different license for the same software. I'm no fan of copyright as applied to non-commercial distribution, or even merely copying, for that matter, but it is the world we live in. And in this world, I support the rights of authors to game the system to preserve freedom, and I care a hell a lot more about that than I do about "competition in hardware business". You are the one with the short thinking horizon here, not me. You seem to care more about next year's products than about the next generation's freedom. I think I've clarified my position on this sufficiently now. The products/freedom issue is what divides the open source people from the Free Software people, and I think it should be plenty obvious which side both of us are on. |
|
|
|
I understand that Avalon simply had no time to develop a proper firmware layer to isolate themselves from the results of adverse disclosure. They may be just another project snuffed by the situation where GPLv3 turns virulent and kills the host.
Bullshit. There are no secrets here. SHA is totally known. Bitcoin mining is totally known. USB is totally known. There is absolutely fucking nothing in an Avalon unit to be protected by secrecy. The hard part here is actually making the damn chip, not the LOL-programming they use in the FPGA that manages them. Moreover, your notion of GPL "turning virulent" and killing the host is bullshit too. If they didn't like the conditions, they didn't have to use any of it. Not releasing their changes is just shitting on the community, and as I mentioned before, pointless. I'm just quoting for posterity. This is a perfect example of a supporter that is worse than an enemy. Not understanding hardware is not a problem. Not understanding hardware and pretending to understand it is the most serious problem: for example the overclockability curve can be used to estimate manuafacturing yields. Involvement of the people like kjj is the reason why so many hardware-related open source projects fail: they inadvertently disclose all the competitive information because they simply don't understand the manufacturing technology and planning: front-loaded NRE costs rule. The competition can run circles around them: a knowledgeable competitor using proper analytics would know more about their manufacturing than the ostensible project managers do. This isn't a software business with no barrier to entry and where the costs are back-end loaded: mostly in the maintenance. Even if you don't understand this now, just copy this and paste it somewhere for the future reference. There is also a lot of similar discussion from they days where various people from around Linux Torvalds discussed merits and demerits of various licenses. In Bitcoin you have all that distilled to just a handfull of projects. Oh dear god, not the manufacturing yield! Anything but the manufacturing yield! Seriously dude, get a grip. The mining programs already spew FPGA bitstreams as opaque blobs provided by the manufacturer. If the Avalon is using an FPGA for management, that blob is either on a ROM chip on the board, or in the filesystem of the control board. No one cares. What we do care about is knowing what they did to cgminer (GPL!) so that it could talk to the management module. Plenty of us want to throw out the crappy wifi router they are using and connect our units, when we get them, into our existing infrastructure. If there are big secrets in the patches they made to cgminer, then they fail because now that they have distributed it, they are required to disclose those changes. If they didn't like that, they should not have used that software. |
|
|
|
If they didn't like the conditions, they didn't have to use any of it. Not releasing their changes is just shitting on the community, and as I mentioned before, pointless.
That would only be true if Avalon said they will not release source code; but they have always maintained that they will release source code. At least that's what I was told. Based on that, the only question is the date of release, and by extension, the patience level of forum posters They were in violation of international copyright treaties the moment they shipped. The GPL doesn't say that you must intend in the future to release the source code, it says that the physical product must be accompanied by either the source code or a written offer to provide the source code. By default, there is no right of distribution. They only way to get that right is through a license. The GPL provides an automatic license to people that comply with the terms described. Failure to comply with those terms = copyright violation and termination of license. Section 8 provides ways to restore the license, but it does not excuse a violation and does not give a grace period during which violations are acceptable. At any rate, I don't really care much about violations. I had two points, the first being that 2112's notion that the GPL is an evil thing, strangling poor projects in their crib is nonsense, and the second that there was not, is not, and never will be, a good reason for Avalon to have failed to provide the software alongside the physical product. |
|
|
|
I understand that Avalon simply had no time to develop a proper firmware layer to isolate themselves from the results of adverse disclosure. They may be just another project snuffed by the situation where GPLv3 turns virulent and kills the host.
Bullshit. There are no secrets here. SHA is totally known. Bitcoin mining is totally known. USB is totally known. There is absolutely fucking nothing in an Avalon unit to be protected by secrecy. The hard part here is actually making the damn chip, not the LOL-programming they use in the FPGA that manages them. Moreover, your notion of GPL "turning virulent" and killing the host is bullshit too. If they didn't like the conditions, they didn't have to use any of it. Not releasing their changes is just shitting on the community, and as I mentioned before, pointless. |
|
|
|
That entire heatsink on each card is saturated at 50C! Holy hell on a crutch!
Are those IR pics accurate? That seems excessive... if it actually is 40 - 50C, what's going to happen to them in hot weather?
Maybe Jeff can heat up a room to 85F or so and let it run to see what happens.
Even better, get a sheet of IR-transparent plexiglass and put it where the missing side of the case should be so that the fans can generate proper airflow, and then take the thermal images again. |
|
|
|
Where do I find the 'Host Address'? Is that my wallet address?
That is the IP address of the server running bitcoind. If it is on the same server as the website, it is almost certainly 127.0.0.1 (or "localhost") instead of the actual IP. |
|
|
|
Oh god, this thread again? Suppose we divide everyone in the society into two corporate A and corporate B, (or similar to an island with only 2 people), each year banks loan out 1 Billion to A and 1 Billion to B, and they do production and consumption and trade with each other. They need to return the loan plus interest. Since the money supply is only 2 Billion, where is that extra interest come from?
Obviously, it can only come from the previous savings of A and B, so if this process continue, sooner or later A and B's saving will be depleted. Of course bankers will also spend their earned interest to buy products from A and B, but since everyone have also the need to save, it can not balance itself Here is the answer to your question. The money moves through time. All of the notes loaned out will be paid back, and a portion of them will be spent again, and paid back to the banker a second time, what we call the interest. The net effect is that some fraction of the value is transferred to the banks, in addition to the money. No magic is needed, no exponential or permanent growth. Google Steve Keen if you'd like to see a fully developed mathematical model of the exact situation that you are talking about. |
|
|
|
|
For a multichip design, you must use a thick thermal pad, something like thermagon t-flex. You can't just use paste (including the pre-applied paste you see on OEM coolers).
The reason is that the chip tops will not be planar. Based on the colors of the BFL board pictures, it appears they may be using ENIG with good pad planarity, which is good, but variation in the solder thickness will still leave the chips at different heights and slightly different angles.
In these circumstances, you need spacers to properly position the heatsink surface a fixed height above the PCB, and a compressible thick pad to deal with the different heights and angles. You can see this on a lot of video cards. A Radeon 6870, to pick an example that I know fairly well, uses a thin film paste on the main GPU, because it is a single planar chip, but all other chips needing cooling (RAM and VRM, I think) use a ~1mm thermal pad to contact a second heatsink held at a fixed height over the PCB.
|
|
|
|
I haven't found a good one yet, but I'd really like it. I sold something to a user on this forum, and I walked him through using the Bitcoin-Qt debug console to generate a 2-of-2 multisigaddress.
I r super-idiots: would you be so kind as to walk me through generating a 2 of 2 and then a 2 of three? I don't want to buy anything but walking me through doing a 2 of 2 and 2 of 3 would accelerate my learning significantly. That is an example of multisig and offline signing. Gavin wrote it up when we were testing the signrawtransaction fix. I believe it is 2of3 only, but 2of2 is easy enough to figure out from it. |
|
|
|
Not very long and I'm back with more questions. I've learned quite a bit about Bitcoin through my pursuits on here and now I have more technical questions. Right now I'm studying the scriptSig of the input portion of a transaction and the scriptPubKey of the output portion of a transaction. I've found some answers and understand aspects but others I don't. Pertaining to the scriptSig I see the two aspects, public-key and the signature. I a m comfortable with the public-key aspect. When you try to spend BTC you refer back to the output of the previous tx and the program hashes your public-key thus finding the your address and since the preceding output sent the BTC to your address it is verified you have the key. That seems simple to me, now at least. When it comes to signature portion of it I'm lost. I know that somehow your private-key you provide verifies your public-key through hashes. This makes sense, I understand how that happens. My question is how do you provide your private-key to the input of your tx to process it and find a line-up with your public-key without putting your private-key in the record? Does the process just use the private-key but do nothing else with it? Also I know you sign a hash of the tx and I get how the hash is made from the tx. But what exactly is that signature? Is it a hash of a combination of a your private and public-key? I found this information: "The script contains two components, a signature and a public key. The public key belongs to the redeemer of the output transaction and proves the creator is allowed to redeem the outputs value. The other component is an ECDSA signature over a hash of a simplified version of the transaction. It, combined with the public key, proves the transaction was created by the real owner of the address in question. Various flags define how the transaction is simplified and can be used to create different types of payment." here: https://en.bitcoin.it/wiki/Transactionsand I'm trying to understand the italicized part. Look at the picture on that page. It shows that the transaction signature includes both the signature and the pubkey that verifies the signature. We then hash the pubkey and compare it to the hash embedded in the prevout. The wikipedia page explains, in a way, how the signature is actually calculated. The OP_CHECKSIG page on the bitcoin wiki goes into some detail on the simplification stage. |
|
|
|
|
I must be getting old. The longer I look at those pictures, the more they look like renderings to me.
Anyhow, they do appear to be built for a backplane. That should be the white connector on the back of each board. The white things at the top and bottom appear to be just guides.
More interesting, they are built for vertical airflow. Either they are planning to put a fan module at the top of each stack, or they are built for a datacenter with ducted cabinets.
Looks like 40 or 48 chips per blade, and using the PCB for heat conduction, which fits with the QFN package shown earlier. Or the ASIC is on the side under the heatsink and we are seeing a rectangular grid of something else. It is hard to tell from these angles.
|
|
|
|
You can add a second stage to that loop, if you need bitcoind to be not just running, but close to being current. Note that bitcoind does not reliably report that it is current, so if you are starting from scratch, this will end while bitcoind is still several hundred blocks behind. But, it appears to be the best you can do without consulting an outside service to find the proper block count. # Waits for bitcoin to catch up
STATUS=`$BITCOIND getwork 2>&1`
P1=`echo $STATUS | grep -o "error"`
P2=`echo $STATUS | grep -o "download"`
CNT=`$BITCOIND getinfo | grep blocks | cut -d : -f 2 | cut -d , -f 1 | cut -d " " -f 2`
while [[ "$P1" = "error" || "$P2" = "download" ]] ; do
echo -n "Waiting for local bitcoin node to catch up "
if [ "" != "$CNT" ] ; then
echo -n "($CNT)"
fi
echo ""
sleep 13
STATUS=`$BITCOIND getwork 2>&1`
P1=`echo $STATUS | grep -o "error"`
P2=`echo $STATUS | grep -o "download"`
CNT=`$BITCOIND getinfo | grep blocks | cut -d : -f 2 | cut -d , -f 1 | cut -d " " -f 2`
done
|
|
|
|
|
Show Posts
