Hello, I'm interested in buying up broken/unusable S9 boards, mostly for the heatsinks. I'm wondering if there are significant quantities of these floating around out there. If your board is fixable you will get a better deal having it fixed -- I'm not trying to compete with the repair shops and not offering enough for that. On the other hand it seems that if a single SMT land pad on the PCB is damaged even Bitmaintech's authorized warranty repair center will refuse to fix it and declare a total loss. So it seems like there is a good chance that there are quite a few unfixable boards floating around out there, and as time goes on that pool will grow. Still determining pricing, but probably in the ballpark of $210/miner or $70/board. Less if the board has been lit on fire, more if I can get a large quantity in a single transaction. Feel free to post below if you have any perspective on the market for these unfixable boards. If you have a serious offer involving a significant number of boards, my email address is in my profile. Please don't PM me, I don't read those. |
|
|
|
Europractice serves only European countries plus some culturally related territories, like ex-Euro colonies or ex-USSR. PlanetCrypto is based in US, so you will only qualify for MOSIS.
That is definitely not true. I have a chip I designed and fabbed through Europractice sitting in front of me right now and neither I nor my company have any connection to Europe. For a while TSMC would not let them quote US customers, but that restriction was for that one fab only and it has since been removed. The only thing Europe-only is the academic discounts. Europractice's IMEC team in Belgium (the ones who do UMC+TSMC tapeouts, but not GF) are absolutely top-notch, outstanding people. |
|
|
|
if Core developer community agree, it will be integrated into Bitcoin (remember, it's only software and can be updated)
Kind of like how the ownership of your coins is only data and can be updated by the "Bore developer community"? Oh wait, it's not so simple... Bitcoin has never accepted consensus on a breaking change opposed by more than $60k worth of entrenched interests. Tens of millions, maybe even a hundred, have been sunk into SHA256 PoW. |
|
|
|
If you had $9 million USD would it be crucially important to get another $9 million USD?
Maybe. If I had $9 million I could afford to make a 22nm chip. ... and if I had $18 million I could afford to make one mistake  |
|
|
|
|
I've got a cryptography project shaping up that could benefit from renting lots of idle FPGA miners. Specifically Spartan-6 LX150 chips (*). If you have a lot of these, and can put them online, please contact me through the email link in my profile (do not send forum PMs). Let me know how many chips worth you have.
Just to be clear, we're not interested in actually taking physical delivery of the miners or chips. You'd give me a login on some junky linux box that has JTAG or similar access to the boards, I'd pay you weekly in BTC. You pay the electric bill, but obviously we're offering more than enough to offset that. You're free to bail out at any time.
There are still a few things that need to happen for the project to go forward, one of which is finding enough compute power. So if you don't have a fairly large installation that's ok, let me know anyways, but I'll probably put you on the wait-list for after we get the first few big contributors going.
Thanks,
(*) It *might* make sense to add support for other FPGAs, but only if you have a truly gigantic quantity of them (like 1,000+). If you think this might be you, let me know what you've got.
|
|
|
|
So basically you are posting because....?  Because bitcoin. |
|
|
|
|
So, it turns out that Bitcoin founded both the CIA and NSA.
Yes, it's true.
|
|
|
|
|
Hrm, apparently I am legendary too.
Maybe there could be an option to voluntarily elect "infamous" instead?
|
|
|
|
|
Very interested to know if btc-e did or did not receive a subpoena, and if so what their posture is.
I know they use Deutsche Bank for outwires so they may not be able to ignore it.
|
|
|
|
if this was a bitcoin economy then google just crashed it
No, if google crashed anything it was the "app" economy. Stop outsourcing the administration of your computer, especially to organizations (like google) that you aren't even paying money to. |
|
|
|
(still need to catch up on last few posts but this is relevant/breaking news): 15-Apr: it has begun
and much sooner than I thought. |
|
|
|
Worse, N/(lookup gap), so for lookup gap 4 this map will take only 256 bytes.
What is a lookup gap? That was smolen's remark, not mine:-( So sorry. I hate the bitcointalk web interface. Why did we ever get rid of Usenet?
. |
|
|
|
Proof-of-X for X!=Work is largely off-topic for this thread. Only POW serves as an origin of scarcity anchored to something physical (computing devices).
The scarcity of BTC and POW systems has nothing to do with the POW algorithm and everything to do with the social contract of the nodes. Well, you and I clearly disagree about that. This thread, being about POW innovations is really aimed at network security in the most decentralized manner possible.
"Security" is a vague enough term that it's hard to disagree there. You don't think someone could build a special-purpose motherboard / CPU designed to minimize overhead costs around the DRAM?
Sure; in fact, I expect them to. But the whole point is to pick a POW algorithm where the returns of doing this diminish long before the "special-purpose motherboard"'s cost gets anywhere near a quarter or so of the cost of the DRAM. You think large warehouses of case-less, power supply-less, liquid cooled, over-clocked, modules would not make mining at home unprofitable?
I think that the people who design pretty cases for miners will find other jobs. I think that unpowered modules are pretty damn useless. I think that overvolting DRAMs will actually DECREASE the number of operations in their lifetime before they fail. I think that water-cooling DRAMs without overvolting will not even double their performance. I think that moving SHA-256 from a GPU to an ASIC has already produced a 1,000-fold increase in performance-per-square-millimeter-of-silicon. You think bulk buys cannot make it significantly cheaper for these large factories?
Nope, not significantly. DRAM is already a razor-thin-margin business. That's why I picked it. The reality of POW is that security is proportional to economic cost and whether the attacker is spending $500 M on SHA256 ASIC or $500M on dedicated hardware the result is the same,
I don't think you've been reading this thread. This makes dedicated hardware a disadvantage. If you increase the cost-per-hash with memory-hard POW, you will get fewer hashes but the same level of security and only the most efficient operations will be able to mine profitably.
Yeah, you definitely are not reading the thread. Go back and read the part that says "has a cost-of-ownership dominated by silicon rather than electricity". Don't take it personally, but I tend to stop replying to people who aren't at least trying to follow the discussion... |
|
|
|
So glad you actually wrote a whitepaper. I'm still going through the paper (should finish this weekend) but just one nitpick for now: Okay, I was able to make a first pass. I want to call out three really awesome contributions you've made: 1. Identifying cycles as the structure to be sought (this is a big deal, more on this later) 2. Making the memory size be (at least the high-order part of) the difficulty. This avoids having to pick magic numbers like "16GB" out of the air. 3. Using siphash() -- very cool, I've updated my initial post to mention this. Typo: second page, "proof-of-work system. which". I think the period should be a comma. Disclaimer: I didn't read the paper on cuckoo hash tables because your description of the proof-of-work (an undirected cycle of length >L in the graph of the converse composition of two hash functions with disjoint ranges) made sense right away. Let me know if I missed anything as a result. Or if I misunderstood the POW, but I think I got it. One thing that nagged me was that the size of the proof scales with L. Since the proof has to go in the block headers, which even SPV clients need, it's the most space-sensitive part of a cryptocoin. Could one look for a cycle instead in the graph of a hash function postcomposed with "modulo N" where N is the targeted memory size? Then you can prove a cycle of length L>L min by giving any element in the cycle, and a verifier can check your proof with O(log N)-memory and O(L)-time. This is partly why I'm excited about cycles as the proof. Also, in a sense this is what scrypt is, except that it asks for a path rather than a cycle and the hash function is H(n)=salsa^n(0) (where salsa^0(x)=x and salsa^(n+1)(x)=salsa(salsa^n(x))) -- the write-phase is a sort of Ackermann construction. (okay that's not exactly scrypt -- the read phase maintains an accumulator which gets xored in before each salsa20/8). The cycle-in-a-single-hash-function scheme proposed in the previous paragraph is best implemented with N-many log(L max)-bit words of memory, so it sort of assumes something close to the "liveness bitvector" approach like Dave used in his comments on the cuckoo cycle
it isn't so much an attack as the intended implementation. It can't be effectively parallelized since the amount of data you'd need to communicate is proportional to the amount of computation (total)
the communication ends up costing more than the computation you're parallelizing. But the real drawback is that the memory accesses are not in any way serial. So the ideal hardware looks like a tiny loop running the hash over and over, blasting addresses at a custom memory. The memory always writes a "1" to the address given, and reports "hit" when a "1" is written over an existing "1" (memory initializes with all zeroes). So there's perfect pipelining between the memory and the computation. That's a big problem. I suspect the way around it is some Ackermann-like construction. The other reason I'm excited about cycles is that they don't yield well to divide-and-conquer. Two halves of an L-cycle are an X-path and Y-path where (X+Y=L)
but long paths are so commonplace that the coordination between two parallel path-finders to see if any of their paths form a cycle is likely to be as expensive as just looking for the cycle. |
|
|
|
Then the ideal mining device looks like a very cheap (~$50) backplane full of commodity DRAM DIMMs.
Wouldn't separate DRAM chips with independent buses be more effective? No, because the operations are serially dependent. You don't know the address of the next read until the current one has finished, so having parallel access to two halves of your memory is no help. |
|
|
|
Economies of scale (EOS) is a barrier to entry... proof of work always benefits from EOS
Fortunately there are parts of our economy -- like computer DRAM -- that are much bigger than cryptocurrencies. In order for the bitcoin mining industry to be as big as the DRAM industry each BTC would have to be worth $25,000 each. And that's only until the next halving, at which point the price has to be $50,000 each. Proof-of-X for X!=Work is largely off-topic for this thread. Only POW serves as an origin of scarcity anchored to something physical (computing devices). |
|
|
|
I think what you call a word is a 128 byte block.
Sure, it's a 1024-bit word. I think of it that way because it's the word size of the memory on the ideal hardware for scrypt(N=1). Whatever order you generate could be trivially stored in a map of N indices,
so you could still leave out alternate blocks and use the map to find the block from which to generate a missing one?!
True, but only if the word size is much larger than the memory's address size -- otherwise the "map" takes more memory than you save. So, therefore, make the memory have 2^N words where N is the number of bits read or written in each memory transaction. So, for example, 2^32 entries each being 32 bits. Or 2^16 entries of 16 bits each. Then the "backward pointers" cost as much space as they save. Worse, N/(lookup gap), so for lookup gap 4 this map will take only 256 bytes.
What is a lookup gap? |
|
|
|
|
Show Posts
