let me know if we need other options besides these
- eldentyrell suffers from OCD- eldentyrell suffers from OCPD- eldentyrell should watch "As good as it gets" - eldentyrell should take a marketing class - eldentyrell should take a library science class - eldentyrell should socialize with some business school students |
|
|
|
While IBM offers eDRAM up to 10? Mbit per ASIC, i doubt if the savings in chips space will compensate for the (much) lower cycle time.
Maybe yes, maybe no. scrypt() was designed by Colin Percival to intentionally interleave the memory access for blocks with Salsa20/8 block-mixing. There is even a parameter "r" describing how many Salsa's to apply (which ArtForz set to 1). So the ultra-high-bandwidth with ultra-low-latency memory may be an overkill for scrypt() brute-forcer which does several scrypt() computations in parallel. The key to good performance is to avoid register spills to memory when doing Salsa rounds. |
|
|
|
It would perform better with a huge L1 cache, from what I understand. Using cache memory is just a waste of power and die space, primarily because cache is a combination of CAM (Content-Addressable Memory) and SRAM (Static RAM). What one would need is eDRAM (embedded DRAM, http://en.wikipedia.org/wiki/EDRAM). The other obvious savings are: 1) paging MMU: significant saving of power and huge gain in overclocking headroom. Segmented memory would be just fine, up to 4GB on x86 with paging disabled. 2) no need for TLB when paging is disabled 3) because scrypt is 100% predictable all thats really required is a huge pipelined read buffer, write buffer is much less important 4) when going off-chip the pipelined read buffer would need to be combined with narrower bus to avoid transfering useless data 5) when using on-chip eDRAM one can completely dispense with the need to have separate refresh circuitry and refresh cycle stealing. scrypt() is guaranteed to keep the dynamic memory regularly refreshed I'll say that there's a lot of room for improvement when implementing scrypt() on FPGAs and ASICs and in comparison with the general purpose CPUs and GPUs. |
|
|
|
I would expect that both sides of the network would compute the next block with different difficulties, and when they reconverge,
1) Why just "both"? Consider a multi-way split. Edit: even in the 2-way split the majority can get unlucky and minority lucky. The difficulty doesn't simply follow the majority after the split. 2) Game theoretic issues are: when building next block do I trust myself or do I trust the blocks of unknown provenance after the split? Which branch is going to be more profitable? Is there a profitable way of feeding "bait" blocks to the split-off portions of the network? 3) Control theoretic issue is: reconvergence may take very long time, more than the default 6 dekaminutes and involve oscillations (flapping in the terminology of BGP route convergence). |
|
|
|
"Ok ok but what if there is a world wide electric shutdown for about 10mins... What would hapen to bitcoins...?"
Depends on position of the 10 minute window in regards to the 2016 block retarget cycle. For most of the 10-minute gaps the global network would reconverge with no problem. If the 10-minute gap is carefully synchronized to occur just before a retarget then we will have interesting problem in both game theory and control theory. Also, instead of 10 minute the gap should be somewhat longer such that the the competing blocks would actually be found and there will be actuall conflict of interest between the competing branches of the blockchain. |
|
|
|
I'm inserting a full quote just to assure against further edits from jojkaart. 1) BIP Wars? There was a lot of noise, I can agree with that. But that's all it was. Blown completely out of proportion. The whole thing is comparable to first deciding to paint the bikeshed and then having a long and noisy argument about which color to paint it. Only, in this case the whole community needed to agree on the color for the painting to happen at all so it became quite a messy affair after another color was proposed. Almost everyone agreed that the new functionality should be added. The argument was about semantics of exactly how to accomplish it.
The checkpoints are very different. Choosing a checkpoint that isn't already a part of the current longest chain is something that will fork the chain. Even then, the fork will only happen if a significant portion of the mining power also chooses to adopt the checkpoint. The users have the choice of which fork to use. Gavin can prepare the fork but it'll only matter if enough users decide to use it. This is why I call him a rubber stamp here.
2) Everyone can verify that the network rules have been followed, the accounts are public afterall, even if not easily linkable to their owners. I take it you are saying that's not enough to qualify as an audit?
To sum up. Gavin is nothing even close to chief treasurer of Bitcoin. Such a person does not exist. That's what's so revolutionary about Bitcoin. It's a distributed consensus system. For something to happen in this system, a consensus is needed.
I don't expect this to remove the problem of not fitting in with the stock exchange rules though. I'd be really surprised if those are applicable at all to a system without someone responsible for accounting. So, in that respect, I do understand why you'd want someone to be the chief treasurer.
(I should probably disclose that I have no knowledge of the rules the stock exchanges use. So, unless you or someone else fill me in, I'll be completely clueless about them.)
OK, willful myopia. That reference to bike-shedding from FreeBSD settled it. Thanks. This problem of what is Bitcoin vs. what is Satoshi Bitcoin client maintained by Gavin and friends) was discussed several times, both here and elsewhere. The good jumping poing for people interested in understanding is probably the following thread and post: https://bitcointalk.org/index.php?topic=45104.msg538561#msg538561Edit: Actually I just realized that jojkaart is probably a software developer (from the rather obscure FreeBSD reference). Therefore he will probably be also capable of understanding the idea of BIP 2112 (from my signature) where I talk about cryptographically signed digital prospectuses. |
|
|
|
Labeling him as a chief treasurer for signing the checkpoints strikes me as seriously odd. He's nothing more than a rubber stamp for the blockchain here.
EDIT: Also, all the accounting happens in public, so it's auditable by anyone wishing to do so.
Two non-sequiturs in one post? I'm not sure if you are naturally myopic or willfully myopic. 1) Recall the BIP wars from around April. If you call that rubber stamp then I'll call it rubber-stamp bazooka. 2) Blockchain works as a ledger only if the address ownership is published. I recall only one case where Mt.Gox published one of their addresses after the hack to prove the control of funds. Nothing like that happened ever since despite the added RPC call functionality that was designed for just that purpose. |
|
|
|
|
this movie needs to be made as soon as possible.
In fact, I'm already thinking about a well-known bitcoiner who is known for Kubrick-ian levels of perfectionism. He doesn't have a long directing resume, but he is know for simultaneously working on many projects. I think he could also commence on "Blockchain Orange" and "2112: A Crypto Odyssey" to quickly catch up.
|
|
|
|
Such ETF would be immediately in violation of the rules for the stock exchange trading and therefore a waste of sponsor's funds used to form it. You could create a corporation that aims to maintain the parity of its stock with the exchange value of bitcoin. And such corporation could trade on pink sheets bulletin board system. The main problem seems to be Gavin Andresen who continues to sign the checkpoints the bitcoin code: https://github.com/bitcoin/bitcoin/blame/master/src/checkpoints.cppIn effect he acts as a chief tresurer of Bitcoin yet he never signed off on an audit. He even closed his own private Bitcoin company before it could accrue enough liability to go under the generally accepted accounting principles. |
|
|
|
I usually answer with:
Why do screwdrivers have value? What backs the value of a screwdriver?
Because they're useful and it takes effort to create them.
Bitcoin has value for the same reasons.
I had a good luck with the following summary: Bitcoin is backed by the lack of faith in government. People who value bitcoin have more faith in a "distributed zero-trust cryptographic-currency" implicitly give negative credit to their local governmental and banking institutions. |
|
|
|
Maybe it is caused by RFI (Radio Frequency Interference)? Try putting some ferrite chokes on the power and USB leads very close to where they enter the metal case of the mining devices. http://en.wikipedia.org/wiki/Ferrite_bead |
|
|
|
I was somewhat disappointed that pretty much nobody had dared to speculate beyond the year 2013 on this subforum. Thus I decided to open with my own thread. 10) The competition for better ASIC will produce hash race. 20) After the NRE (Non-Recurring Engineering) costs are recovered the marginally cheap ASICs will lead to overhash. 30) The newly manufactured ASICs will be installed but not pointed at any mining pools under the doctrine of Mutual Assured Double-spend (MAD). 40) Under the above doctrine all new mining rigs will be quipped with Permissive Hashing Links controlled by hashing briefcases in possesion of the presidents of the major mining companies. 50) The grassroots movements will force the presidents of mining corporations to meet at the Strategic MIning Limitation Encounter (SMILE) in Helsinki, Finland. 60) The further pressure of public opinion will cause the stockpile of fabricated, but not deployed mining rigs to be destructed under the aegis of Strategic HAshing Munition Eradication (SHAME) treaties. I decided to use the increment of 10 on the above list to allow quick insertion of further items that refine the timeline. Please share your refinements below. |
|
|
|
There can be no ASIC-proof coin. If general purpose CPU's or GPU's can do a thing so can ASIC's.
Actually there CAN be. It was even discussed on this forum several times under the names of "licensed mining" or "block rating agencies". The discussions in the past even showed how to implement those in the distributed fashion using the public key cryptography or web-based services. However the solutions weren't specific to the ASIC-mining problem, they were described more in terms of "Good Minekeeping Seal of Approval". These types of activities would probably cause either hard-fork or soft-forking; and produce at least a two sub-chains: 1) Crim-coin, Sin-coin or Anarcho-coin chain based on the "might makes right" rule; 2) Law-coin where the 51% majority of voters voluntarily decide to uphold the rule of some law. I think this neatly reflects the current observed split in the so called "Bitcoin community". |
|
|
|
Its only hyperthreaded? Thats kinda pointless altogether.
It is both superscalar (2-way) and hyperthreaded (4-way). Another quote from the same manual: 0x00 0x16 INSTRUCTIONS_EXECUTED Number of instructions executed (up to two per clock)
0x00 0x17 INSTRUCTIONS_EXECUTED_V_PIPE Number of instructions executed in the V_pipe. The event indicates the number of instructions that were paired.
0x20 0x16 VPU_INSTRUCTIONS_EXECUTED Counts the number of VPU instructions executed in both u- and v-pipes.
0x20 0x17 VPU_INSTRUCTIONS_EXECUTED_V_PIPE Counts the number of VPU instructions that paired and executed in the v-pipe.
As mrb said: Mining is an embarrassingly parallel workload, so an implementation can be adjusted to fully exploit the ALU resources of Xeon Phi,
but hyperthreading should make the "adjustment" work easier. The threads will not be fighting for cache lines, which is the most common cause for not gaining the performance in hyperthreaded processors. Anyway, we'll see. I'm not really up to downloading Intel compilers, compiling the code and analyzing the assembly. Maybe in winter? |
|
|
|
I see why you are confused. 2112 meant superscalar, not hyperthreaded, as pointed out by others.
I think the confusion runs deeper that just me. Here's the quote from the "Knights Corner Performance Monitoring Units"; Intel's document number: 327357-001 2. 4-Way Threaded: Each Knights Corner core is able to process 4 threads concurrently.
|
|
|
|
This thread is to announce the impending fork of Freicoin. It is my observation that the creators of Freicoin are alienated from the society in which they are living and in which they grew up. Freicoin, created by NASA engineers Mark Friedenbach and Matt Everingham and photographer Aaron Blumenshine, uses a version of the Bitcoin software with one key difference - all account balances are charged a 4.4 per cent annual fee, which is distributed to all of those running the software.
The key differences for the Tithe-o-coin are: 1) 10 per cent instead of 4.4 per cent 2) the fees are "freewill offerings", not an involuntary obligation 3) the miners who receive the fees need to provide cryptographic proof-of-state-of-grace. This coin is not meant to be used by any garden variety heathens or Swedish Smörgåsbord pastafarians. I'm not soliciting any pecuniary contributions from anyone, because personally I'm not yet in the state of divine grace. This cryptocoin development is not meant do discriminate against any creed. I've already informed and I'm awaiting the blessing from the representatives of Vatican, Jerusalem, Mecca and other holy lands. Last moment news: I've already been contacted at my door by the two aldermen representatives from Salt Lake City, UT. Deseret-coin is a go! |
|
|
|
Freicoin is too German-sounding for US users.
Whats that supposed to mean? Or in Deutsch-English mixture: Mining macht frei.Or in English: Mining liberates.I apologise in advance for the reductio-ad-Hitlerum, but some jokes just write themselves here. |
|
|
|
Open liquids (coffee cup) in an electronic assembly room??? Seriously???  I don't know about you, but if I am paying up to $30k for a piece of equipment, I EXPECT it to be assembled professionally. I once worked in a cordless phone factory, that produced phones that at a max went for around $80, and all the above protocol was used. I just wanted to chime in with some wisdom from the former CEO of my company who actually had a long experience managing assembly lines in the electronic industry. The neatnik streak as displayed by dreamwatcher, especially the anti-ESD propaganda, is just a cover for the real management issues: 1) theft, both occasional and organized. 2) sabotage, especially when temporary labor force is employed. 3) anti-union or other political/labor issues, e.g. drug distribution amongst the people doing monotone work. 4) need for managerial control of positive factors: tracking of the good workers for possible promotion. 5) need for managerial control of negative factors: locating and investigating of workplace accidents and incidents. 6) saleability, state of being visibly spotless, mostly in case of consumer goods. 7) ESD is nowadays mostly a human factor, not a technical precaution. When people are repeatedly zapped their productivity goes down and it increases the chance of accidents. Really, please think a bit about the history of the USA. Messrs. Hewlett and Packard probably should consider themselves lucky that nobody was there in their garage to make a snapshot of the sweat on their backs as they assembled the first laboratory oscillator that they sold to Walt Disney. |
|
|
|
Which means it'll actually boot an OS. Dont know if you cant boot your own though. Can't imagine why you wouldn't be able to though.
Yeah, after further thought I now assume that calling it a co-processor is just an artificial market segmentation. Intel probably has an agreement with Cray, SGI, etc. to let them announce their supercomputers as first standalone systems using Xeon Phi. Then maybe later the second-tier vendors like Microway will announce single/dual/quad Xeon Phi workstations. This is very clearly a product targeted for the OpenMP market. |
|
|
|
Well, the real problem is, they want to be able to boot existing x86 code on it. Not merely run, but boot.
Well, I was thinking of coprocessor as something directly accessible through the QuickPath that doesn't require an OS at all. For example what AMD does to support FPGA in Opteron sockets over HyperChannel. Such co-processor wouldn't need to boot in the classic OS sense, more like it would need to support "reset" without resetting the neighboring CPU. I'm thinking they're this: Atom-like cores, dual issue, in order execution, no x87 FPU, and a 512 bit SIMD unit that does both integer and fp, 32?kb of L1, and a small amount of L2.
Now, given that sounds shitty, but if I can run normal threads on those instead of lockstep thread clusters and the SIMD units support booleans (512 of them at a time) or chars (64 at a time), this could actually end up with surprisingly fast mining.
I think Knight had granted your wishes, mostly. There's still support for legacy FP, but XMM & YMM registers are replaced by ZMM. There's no support for chars, but there is for Int32 and Int64. If you were thinking of bit-slice parallel implementation for miner then those Int* types will allow that. Multiprocessing and miltithreading is all compliant with OpenMP. The docs for architecture are near the bottom of this page: http://software.intel.com/en-us/forums/showthread.php?t=105443The instruction set is supported by the recent Intel C/C++ and Fortran compilers. The GNU port was just to compile the Linux kernel and doesn't really support the new instructions. |
|
|
|
|
Show Posts
