The desync.com one is offline for me too by the way.
This one is a split IPv4/IPv6 tracker. IPv4 reachability seems to be determined by geolocation or some similar mechanism. IPv6 seems to be very reliable and long-term stable. C:\Users\2112>ping exodus.desync.com
Pinging exodus.desync.com [2607:f178::164] with 32 bytes of data:
Reply from 2607:f178::164: time=105ms
Reply from 2607:f178::164: time=110ms
Reply from 2607:f178::164: time=122ms
Reply from 2607:f178::164: time=109ms
Ping statistics for 2607:f178::164:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 105ms, Maximum = 122ms, Average = 111ms
|
|
|
|
EXCELLENT JOB! Now trick is to actually solder together VDD pins and put proper capacitors between GND pad and VDD pads connected. Then solder to central pad THICK wire - interesting how that could be done (as heat sink). Initially I thought that it must be done with hot air after capacitors soldered and chip is held.... wires would be soldered as last step as it would be hard to solder to thermal pad if you have thick wire there.
One of the ways how to do - take thick wire - say 16 sq.mm, solder it from one side thoroughly, cut (remove also insulation if any) - say leave 50mm of wire length... Then - heat wire first while holding it with pliers, then heat chip and wire togeher and connect them. Then you'll have to cool this with air and then spread copper wires and you'll get heatsink.
I've seen QFN-packaged parts soldered to the top of a thick brass/copper bolt, e.g. for a 7mm*7mm package use 5mm diameter bolt. That wasn't done for cooling, it was hand-made modification while doing a thermal characterization/calibration of a mixed-signal SoC. It looked like a high-current diode, but was neither high-current nor high-frequency, just a way to reduce the inherent internal heating of the SoC executing the boot / self-test / calibration program. Edit: Actually I misremembered, the bolts were made of phosphor bronze. I don't know how easy would be to obtain such parts. They aren't expensive, but are considered "specialty" / "non-stock" / "special order" items. |
|
|
|
No other account. Just someone who is familiar with IC design and thinks such a small chip (7.5mm^2) consisting of no more than 16k 32-bit adders on a process that yields such low clock rates (for example see: http://ieeexplore.ieee.org/xpl/login.jsp?tp=&arnumber=4253311) and high defect rates (to quote from your original link: "A grade has 16 engines, B grade has 15 engines, C grade has 14 engines and D grade has no less than 12 engines. All chips run at a minimum of 250 mhz. Higher grade chips will run up to 294mhz. The percentage distribution in each lot is 60% Grade A, 20% Grade B, 15% Grade C and 5% Grade D."). Do you care to speculate what could be the specific mistake that the BFL's designers made? For example eldentyrell speculated a while back that they made their simulations at the default temperature chosen by SPICE in absence of specific setting: 25 deg C. https://bitcointalk.org/index.php?topic=166321.0Obviously, we don't have sufficient information to make a real assesment; but I think even making a scientific wild ass guess will have some educational value for the readership of this forum. |
|
|
|
Among the EU member states Poland is one of the more liberal (less regulated) in terms of letting banks do whatever they want. This is why most Euro exchange houses have their bank accounts in Poland as opposed to the country from which they operate (the British ones being good examples of this). I'd say they Poland is probably the most alternative-finance-friendly EU country outside those that are currently undergoing fiscal implosion (eg. Cyprus, Greece & co).
Of course the non-EU, ex-Russian Federation countries are likely to be even more relaxed but there are some benefits to a little legislation. Personally I'd not want to bank in Ukraine, for example. At present Poland appears to be a happy medium in terms of aggressiveness of banking regulation.
Kate.
Thank you very much for the explanation. It agrees with what I've heard about Mt.Gox acquiring bitomat.pl: for their banking relationship in Poland/SEPA zone. |
|
|
|
Even if the UK makes legislation, even if Poland legislates against it (and I can't see that happening!!) there will always be some country and some bank which will exchange fiat for cryptocoins.
Poland? This gotta be some sort of an inside joke. Please explain it for the left-pond-ians and other readers from around other ponds. |
|
|
|
It's pretty light in here, judging by all the contracted pupils.
A very classy insult, I'm afraid I have to steal it for the later use in my repertoire. Thanks. http://en.wikipedia.org/wiki/MiosisPS. It seems that the more popular phrase is "constricted pupils", not "contracted pupils". PPS. bitcointalk continues to deliver the comedy gold. |
|
|
|
We're far beyond that point. The code needs very thorough restructuring. That can be done incrementally, even while others are adding functionality, but I think it is going to be very hard to get a consensus on the needed changes.
The consesus about the needed changes could conceivably be that the official Bitcoin client switches from the "Satoshi legacy C++" to one of the newer candidate codebases, e.g. the Java code from Hungary. For me it is good to read more and more comments about the need to stop treating Satoshi (and his legacy code base and protocol) as an inviolate revelation and more as an ingenious sketch of the future. Time for me to repost my favourite picture of an amber: It is an ambodiment of both the mess and the beauty. |
|
|
|
I'm not sure that's right; cracking passwords is quite like a lottery too. Jack the Ripper doesn't just crunch through all possible permutations for instance - it is trying to hit the needle in the haystack. What hashing does for passwords is increase the time taken to try one permutation. In an example I calculated (I wrote a blog post on it last year) the ~10,000 rounds of hashing we use on some of our passwords increase the time to try each permutation from ~1/1,000,000th of a second to ~1/250th of a second for a typical 2 GHz Xeon core In my example those thousands of rounds of hashing increasing the time taken by a hypothetical 1,000 quad-core machines to brute force a typical 8 character password (assuming you have the password file of course) from ~9 hours to ~4 years. Hardware which can crunch SHA hashes at a rate many orders of magnitude more than a normal CPU effectively removes the advantage conveyed by the many rounds of hashing. Kate. Conceivably you can treat password cracking as a lottery too. But it would be a lottery with a single winning ticket. There is one important property of password cracking: it has to be exhaustive, i.e. search all the elements of the possible password space. On the other hand Bitcoin is a lottery where the winning tickets are plentifull and constantly changing. With a still Bitcoin network there is a new winning ticket every second: the block time increments. With a live Bitcoin network there are additional winning tickets that are added every time a transaction gets propagated on the network. The set of possible winning tickets is not going to infinity because the some ticket will cease to be winning once their acceptable time window expires. And obviously the set of winning tickets has to be reinitialized once somebody mines a block and you have to change the "previous block" field and rebuild the merkle tree of the unmined transactions. Lets consider a reverse example: suppose that you have a super-fast password cracker that only checks even passwords, i.e. those ending with B,D,F,... The trivial way to defeat it would be to use a password that is odd, i.e. one ending with A,C,E,... But the above defective password cracker will be a perfectly good Bitcoin miner. That is because when mining Bitcoin you don't need to be exhaustive, you can randomly drop tickets without checking them if they were winning. All the mining infrastructure and protocols is designed around this property: keep printing tickets as fast as possible and don't care if some of them are mangled or dropped. It is a major conceptual difference and I hope I managed to convey it to you. |
|
|
|
Religious zealots, Bitcoin zealots...  Yeah, the convergence between those two groups is uncanny. Immediately after I joined the forum I was struck by how oftern the people professing themselves atheist/agnostic kept slipping into using the theological phraseology. After a while I seem to recognize the similarities in motivation: both groups seem unsecure and search for a stable foundation. The first group tends to find them in the Bible, the second in the limit of 21 000 000 coins. Both call them "set in stone", although the stone is just a language: Aramaic/Greek/Hebrew in the first case, C++ in the second. I'm going to insert the following quote just because it is a nice mixture of being both succint and sarcastic. I'm more concerned with the religion OF bitcoin. Their are FAR too many people who have near apocalyptic visions of how BTC will transform the world and bring torment an damnation upon governments, banks, Keynesians and everyone who has ever mocked them. While the BTCers will be enraptured in wealth and splendor and rule the world at the right-hand of Satoshi. Sound familiar???
And since this is weekend I can post relevant Youtube links: Tribulation by Dennis Brown http://www.youtube.com/watch?v=yUD91sG3Ut0Tribulation by Ras Nyto http://www.youtube.com/watch?v=uVG_OLd6upoBoth links are reggae, but different songs. |
|
|
|
and ran it successfully?
I think picocoin which is for bitcoin is supposed to be endian dependence free.
Yeah, "it compiles" and "it works" are two different things. Bitcoin gives even a third opportunity "it runs, but forms a separate network and blockchain than the little-endian version". Anyway, here's the link to the only publicly-known code that is endian-neutral: https://bitcointalk.org/index.php?topic=128055.0 |
|
|
|
|
Significant rewrite would be required to port Bitcoin to any big-endian architecture.
|
|
|
|
The previous poster is not entirely correct in his assumption of "The primary reason is that no know humanly usable password systems allows for passwords that have the exact binary structure of the Bitcoin block header."
The reality is that the miner chips DO NOT validate the internal structure of the header, in reality they do not give a S**t about what you feed them., they take a source string perform a function on it, then look for a result that meets a particular criteria.
Please give one example of a password system that allows only passwords that are exactly 80 bytes long. Thanks. Edit: Or alternatively: give one example of Bitcoin mining device that doesn't hardcode 640 as the inner hash bitstream length. |
|
|
|
I thought I might get a response like this.
Look, a lot of these coins are based on bitcoin. Despite the connotation you are perceiving, altcoinhub.com is open to any coin that is an alternative. It is all-inclusive and the name does not change that.
Thank you.
I completely believe that you had no intention to discriminate. Its just that this "alternative" moniker has so many negative connotations in the modern American English. Think of "alternative rock", "adult album alternative" radio format, etc. Don't just trust me, ask some friend with background in sociology. Maybe: "equal crypto-opportunity", "universal crypto-coinage" (instead of universal suffrage), there's gotta be a better name. Edit: one thing will not work "National Association for the Advancement of Colored Coins" because the "colored coins" is a Russian-designed overlay on the original Bitcoin. I sincerely wish good luck to you, no matter what you think about me now. |
|
|
|
|
Even the forum name speaks of self-marginalization.
Please, can anyone start allcoinhub.com or allcointalk.org or something else that is obviously all-inclusive?
Thanks.
|
|
|
|
Whether gang violence would be redirected, rather than reduced, is unknowable without running the experiment. With the rise of Silk Road, et al., have attacks against postal workers and facilities increased? If not, it could be because activity related to those sites is still too small to register, and it could be that the thesis is in error.
This is being currently proven in some less-overpoliced regions of Europe. Package locker facilities are getting regularly firebombed; attacks on package couriers increased despite them no longer carrying any cash. Silk Road is just the most widely known English language underground site. Mail order illicit drug sales have much longer history outside of the USA and even predating Bitcoin. Personally I think the spreading popularity of hidden-service Tor forums was the major enabler in this form of trade. |
|
|
|
I think Silk Road will do more for getting rid of gang violence than anything the police could ever do.
This is an intriguing possibility. Imagine how much the gang violence in Mexico and Central America might be reduced, if demand for the services of those gangs were reduced by access to Silk Road, et al. Non sequitur. The gang violence would be simply redirected. Currently it is directed against the competing gangs and the police. The violence would spread to include the employees of the postal and courier services. Edit: not only against employees but also against the infrastucture: mail boxes and package lockers. Net loss for the society. |
|
|
|
Currently this issue belongs to a class: "those who tell don't know, those who know don't tell". Seems like there is a significant activity and money-making opportunity to produce decent hardware dedicated to scrypt() hashing. There are however some easy points that allow to easily discover the people who write with no actual knowledge: 1) mentions of DRAM and various DRAM interfacing technologies like DDR, but no mention of eDRAM (embedded DRAM) http://en.wikipedia.org/wiki/EDRAM2) use of "cache memory" as a supposed requirement of an efficient scrypt() implementation. Point (1) is somewhat excusable because this technology may be somewhat hidden in the layers of complexity by the ASIC design tools. Point (2) is a symptom of somebody who likely has no grasp of logic design whatsoever and cannot distinguish between cache tags and cache lines. Can anyone with longer experience with Bitcoin ecosystem post his guess as to how long did ArtForz mine on the GPUs in private before there were first open-source implementations of the GPU mining? This would be relevant for comparison purposes. Obviously this is bitcointalk.org; so there is a 3rd class of people: those who know, but intentionally spread disinformation to gain some future advantage. |
|
|
|
|
Short answer: Neither.
Long answer: Bitcoin hash is approximately SHA2561.5(blah).
The inner SHA-256 is computed over 2 512-bit blocks that come from the 80-byte block header.
The outer SHA-256 is computed over 1 512-bit block that comes from the 32-byte inner hash.
Because the nonce field is in the second 512-bit block of the inner hash everyone makes an optimization and keeps the first 512-bit of the inner hash a precomputed constant, thus the inner hash is really only about half of the full SHA-256.
In addition to the above: password breaking is a systematic, exhaustive search of the space of possible passwords. Bitcoin mining is playing a lottery, no need to be either systematic or exhaustive.
So your Bitcoin miner can break exactly zero SHA-256 passwords. The primary reason is that no know humanly usable password systems allows for passwords that have the exact binary structure of the Bitcoin block header.
|
|
|
|
|
Show Posts
