You just don't get it do you? Bitcoin is a consensus system and we don't yet know how to create diverse implementations that meet the incredibly strict requirement of every implementation acting exactly the same way. For now, specifying the "Bitcoin standard" as source code is unfortunately the best we can do, and even that is difficult.
Oh, I assure you that I get the "old money" vs. "new money" split in the Bitcoin millieu really well. I can even commiserate with the plight of the "old money" people like you: you've staked everything on the support of the proof-of-concept quality code, and things aren't looking good. https://bitcointalk.org/index.php?topic=101686.msg1113732#msg1113732https://bitcointalk.org/index.php?topic=14382.msg1147050#msg1147050  Bitcoin Airlines 2012 Annual Report: 1) The founder and CEO had split and we are still unable to locate him. Interim CEO is in charge until then. 2) The original paper plane has been covered in many layers of varnish and we have declared it fit for the regular service. 3) We've sold many passenger tickets for our Airline and the regular scheduled flights have started. 4) Unfortunately the cruise speed of our planes is barely above stall speed. The engines are weak and we cannot upgrade to the professional state-of-the-art engines that other airlines use. None of our mechanics know how to maintain them and we don't have money to hire some help. 5) Moreover the oxygen supply on our planes isn't working right and the passengers are passing out while onboard. Frequently the conscious passengers rob the passed-out passengers. Sometimes even the plane crew takes into temptation and plunders the unconscious passengers. 6) Fortunately the in-flight entertainment systems on our planes are the best. No-one else is even getting close to what we have to offer: neither on the land nor on the sea nor in the air. 7) Unfortunately almost all the fuel and engine thrust goes into powering the in-flight entertainment systems. So getting back to the question in the title: RFC protocol for Bitcoin does exist. But in order to operate effectively it has to gain the "economic majority". The current "economic majority" already has the title to over the half of the real estate in the Bitcoin-landia. Do you think that they will give the single bird in their hands for the promise of a share of two birds in the bush? |
|
|
|
You appear to be claiming that I misquoted RFC 6716. You do realize that I wrote (and revised in many subsequent revisions) that section of the RFC, right? It's not clear to me specifically how you're misunderstanding that sentence but what it's saying is no different there than what we might say about Bitcoin: only the code that defines how a node responds to a block is normative, not the code that actually authors a new block. I'll consider accepting an apology— but after all the other times you've been a jerk spewing adhominem and vague allegation about subject matter you were totally wrong about you're going to have to phrase your apology very nicely. Actually you are 100% right when you say that I'm "too vague". I definitely need to elaborate on how half-defined standards are used for the purpose of gaming benchmarks and competition. Lets start with an example that turns out to be mostly good. TCP/IP is a reasonably well-defined protocol with an not-well-defined "congestion avoidance" algorithm. This opening is well-publicised and there are many choices available: Tahoe, Reno, Vegas, BIC, CUBIC, etc. Even Microsoft has its entry: Compound TCP that has been ported to Linux. http://en.wikipedia.org/wiki/TCP_congestion_avoidance_algorithmIn the above example there is a scope for gaming benchmarks by calling everything "the TCP/IP", but underneath using "TCP/IP X" or "TCP/IP Y" depending on the results you want to get. But probably close to 50% of benchmark readers are familiar with the fact that there's no single "TCP/IP" and will ask further questions. Now lets step into the pits. The perceptual compression codecs are good candidate to "less-than-half-define": just standardize the decoding algorithm and leave the coding side open-ended. Ostensibly the open-endedness will allow further gains in efficiency. But in practice it will be used to confuse the users/developers and game the benchamrks. Someone wants to show "MPEG from vendor X is slow?" Crank up all the compressor settings! Someone wants to show "MPEG from vendor Y is low-quality?" Pull all the compressor sliders down! If a benchmark reviever proclaims: "That was unfair!" then the answer is: "It conforms to MPEG standard!" Market for MPEG encoders is particularly problematic in the way described. But many others have caught on their way and are getting good at gaming comparisons by using various "hidden features" in the "authoring" portion of the "standard-conforming" implementation. Please learn to watch for it. So what is the moral of the story above? Standards are tools (like axes), they can be used for good and bad purposes. The good question to ask yourself is: 1) is the particular vendor interested in interoperability and promoting the market by encouraging diverse implementation? or 2) is the particular vendor known for promoting exclusivity, discouraging alternatives and always hyping his own implementation? Please take your time to review the posting history and make a smart choice. |
|
|
|
The Bitcoin wire protocol is a cake that can be defined in plain text like RFCs, but the requirement that it has to converge to the same internal state at every node (that is ultimately the UTXO set) is a non-trivial algorithm that likely needs creative ways of standardizing including using programs to define. An RFC would be perfectly capable of documenting the protocol rules, it would just be very hard to do, and very hard to gain confidence that you got it right. In RFC6716 we went the route of using source code as the primary normative specification: "For the practical reasons of compatibility and testability, it would be advantageous to give the reference implementation priority in any disagreement. The C language is also one of the most widely understood, human-readable symbolic representations for machine behavior. For these reasons, this RFC uses the reference implementation as the sole symbolic representation of the codec." Opinion's differ on this being the best thing to have done for RFC6716, but the argument applies much more strongly for Bitcoin— where even the smallest disagreements can break the software for everyone in the world, not just the users of the oddball software— than a multimedia codec. It may be the case that future refactoring, cleanups, and modularization eventually end up segregating the protocol rules part of the reference client into isolated parts that seldom change (only when changing the rules!), and then they'd act (either internally or pulled out and stuck in a digital-dead-tree) as better specifications than we have today. Quoted for future reference. I'm not going to bold the "eventually" in the last paragraph for emphasis. It is a raw quote. I just wanted to point out that gmaxwell is again spreading FUD and false information. Only the decoder portion of this software is normative, though a significant amount of code is shared by both the encoder and decoder.
Q: How are you?
A: SSDD.
Q: ?
A: Same shit, different day.
Almost any discussion where gmaxwell makes a statement takes the same trajectory. Here is the example of discussion about Stratum&Mining vs. getblocktemplate&longpoll: https://bitcointalk.org/index.php?topic=131035.msg1403446#msg1403446You may have missed it because it was hidden in a relatively less oftern read subforum about mining software. |
|
|
|
2112,
You're still missing the point. As I've said in other threads -- I get a sense that you know what you're talking about, but you provide nothing actionable -- only criticism. Yet, threads like this would benefit from actual experience and advice you might have instead of just criticism. I'd like to have a rational conversation with you, but I can't because the only tool in your toolbox is for insulting people's intelligence.
Here's how this thread could've gone:
etotheipi: Hey, how's this database structure look?
2112: Have you considered using a relational DB engine instead of LevelDB? It looks like that's what you're trying to recreate and LevelDB isn't production quality.
etotheipi: Possibly. LevelDB has properties A,B,C,D and E all of which fit perfectly into my app. My use case is simple enough that I don't mind the lack of relation-handling.
2112: You really shouldn't use LevelDB because it's a toy. Take a look at SomeDB1, it's got properties A,C,D, and E, and also adds F and G
etotheipi: But I really want property B for some reason, and G is not that important to me
2112: Try SomeDB2, it has properties A,B,C,E,F. You could change your structure to storing blocks like <> and headers and merkle roots like <> and you'd have everything you want.
etotheipi: I've never heard of SomeDB2, I'll look into it. Thanks!
See how pleasant that is? No one has to be insulted, and you're experience/expertise is pleasantly communicated in a way that I don't have to lose face to even begin to agree with any of your points. It's not that avoiding "losing face" is my number one priority, it's that your writing style (which I still can't tell if it's intentional or not) immediately turns the whole thread hostile. You seem to want to insult more than help. You could have a constructive relationship with the users on this forum that you are trying to help.
But I did provide an actionable advice: I know that you have a copy of Visual Studio and you theoretically could prototype your design using the dirty, grimy, foul-smelling, ...ugh... relational ...ouch... SQL database engine really quick.
Of the "alternative clients" category I see only grau (and his supernode) as the only developer with the broad familiarity of the database technology. Maybe take a look at his code if you don't want to prototype with the Visual Studio? Database abstraction layers aren't a recent invention. They are well known, many of them are available, there's a plenty of places to look for inspiration and discussion of pros and cons.
In other words: you cannot get married to any database engine this early in the project. Any advice to the contrary would be a misdirection. You need to find either: 1) a database abstraction layer for Python that suits your style and needs 2) define your own abstraction layer in Python after prototyping using 1 or 2 (maybe 3) schemas/databases. Either solution will work. I'm actually not familiar enough with your needs to give you definite answer. For Java I used JDBC. On Windows and for prototyping I used ODBC & ADO. I like using Windows for prototyping because the intense competition on that market facilitates making rational choices even if the real target isn't Windows. Most of the time I used solution (2) because of the existence of the domain-specific standards for database interface and I did my implementations in a mixture of C/C++/domain-specific languages, not Python. Consider this hypothetical discussion: etotheipi: Hey, I've choosen Intel GMA for Armory display engine. Any comments? 2112: Dude, prototype first, then make a choice. etotheipi: Die in a fire! AMD, NVidia, Intel or GTFO? 2112: No really, there are abstraction layers that will allow you to make that selection last, once you exactly know and can measure your needs. etotheipi: OK, I hear ya. Qt looks like a decent layer that will isolate me from the vagaries of graphic display market. It looks like pain it the neck, but I need to learn some way of not painting myself into the corner. 2112: Hurray! Honestly, I've never been so deep in the rabit hole that I've seen the firmament as only a single star. Even when I was in a hole I knew that there is more than one star in the sky and if I can get my nose away from the grindstone I'll see at least couple of stars, not just a single one. I've both: (a) seen the sky with my own eyes and (b) in the school they told me that there's a plenty of stars to choose from. |
|
|
|
LevelDB is very simple, the code has a permissive license and can be bundled directly into the codebase, and it creates very space efficient databases that are encapsulated in isolated directories that are easy to bundle and move around. And it's also damned fast. Accessing the data in key-sort order is about twice as fast as I have been able to achieve with raw, low-level operations. Some benchmarks with favorable performance. (though, while looking up those links, I see some benchmarks for BangDB which are even better, but it sounds new and I've never heard of it) I'm not saying other DB engines can't do that. I'm saying that LevelDB meets my needs and has all the properties I want. The fact that it isn't relational doesn't bother me because I don't really need it -- the data it is storing is rather simple. So, instead of simply criticizing my ideas and telling me how inadequate I am at developing applications, why don't you make recommendations for how you would do it? If you are familiar with other DB engines that have a permissive licence, will not result in terrible linking problems, create nice encapsulated DBs in directories, and still has very good performance, I'll look into it. You seem awfully good at criticizing, but you'd be much more credible & useful if you actually contributed to the discussion. It is too bad that you've activated your "reading between the lines" skill and started writing emotional responses. I never called you "inadequate". What you are doing is the mistake of looking at the benchmarks of speed. When storing financial data the interesting benchmarks should include things like "time to detect & recover from a bit flip error". With your 32GB non-ECC RAM machine you've already encountered this problem. I would be normally calling those mistakes "novice", "beginner" & "naive". But sometimes they aren't any of those. There may be some other, hidden, motive to choose to hard-code a toy database engine. For the outsider it may look irrational, but once the hidden motive is known they are rational. I admire Gavin Andresen for stating it plainly why the core development group wont fix this problem in the Satoshi's client: https://bitcointalk.org/index.php?topic=120753.msg1170970#msg1170970You certainly have an adequate (or better) skill in choosing the level of general-purpose programming language. Your way of splitting Armory between the C++ & Python shows that you know how to make tradeoff between the execution speed and the programmer speed. On the database programming language level you've made a choice that is an equivalent of programming in the assembly language. From the emotional tone of your last answer all I can say that there is some sort of unstated motive for this choice. Of the "alternative clients" category I see only grau (and his supernode) as the only developer with the broad familiarity of the database technology. Maybe take a look at his code if you don't want to prototype with the Visual Studio? Database abstraction layers aren't a recent invention. They are well known, many of them are available, there's a plenty of places to look for inspiration and discussion of pros and cons. I've made an attemt to share my significant experience with programming in the data-integrity-is-the-king sectors like finance, medicine and gambling. You've choosen to call my attempts an "insult to people's inteligence". What else can I do besides shrug my arms and say "fare thee well?". https://bitcointalk.org/index.php?topic=108989.msg1193260#msg1193260This is a public forum, for each 1 person posting there will be approximately 10 who will just read and understand it. Of those 10 people there will be probably 2-3 who can learn on other people's mistakes and use that knowledge in their current or future projects. |
|
|
|
I actually have no clue what you're talking about. Storing transactions comments for display in the transaction ledger is completely unrelated to this thread. That was a case of something that was really simple, turning into something still really simple, but the code wasn't optimized for the worst case. I'm not going to bring in bulky, complicated relational database engines just to store some tx and address comments when I didn't need it for anything else.
Actually it is 100% relevalnt. What you were doing with Inaba and what you are doing right now is designing a network-model database schema using a k,v-primitive storage. So you are approximately in 1970-1980 as far as database technology evolution went. Relational-model databases and abstract query languages were invented to decouple the database schema from the application. If you had data-bound control over relational-model database in Armory the whole problem posed by Inaba would be about 15 minutes of work: create index on comments and hook it up to the appropriate column in the Armory's window. As for the comment that a relational database engine might be good -- well yes, that is a valid suggestion. And one I'm not oblivious to. There's a lot of value in keeping things simple, and dependencies to a minimum. LevelDB is remarkably fast, and its databases are extremely efficient (space-wise), maintained in standalone directories (easy to zip/tar and distribute), and the source code can be bundled directly into the project. These are all very valuable properties for me. There is some relational nature to the data being stored, but it's really not that complicated, and I'd prefer the fine-grained control using a DB engine that is simple and I know how to optimize for it.
On the other hand, if there's a good reason to believe that it won't work, or that there's so many other reasons a relational DB engine would be preferred... I would appreciate that discussion. But within the scope of what I've describe, the theoretical capability of LevelDB is perfectly fine. As long as there is not some underlying vulnerabilities/problems with the implementation that will cause heartache later.
There isn't anything wrong about what you wrote above. You are just going to retrace the evolution of database technology from the last century. If this is your itch then you are free to scratch it, and I'm the last person that will be trying to dissuade you from that. So if your goal is to spruce up your resume before applying for a job at a NonSQL shop then go ahead. On the other hand if you just want to develop an useable Bitcoin client then you are definitely on the wrong path. You are working alone. Google has hordes and they can afford parallel development by throwing one-coder per possible schema; code them all and pick the best. When the requirements change: demote the former best coder and promote the one with schema matching new requirements. The iteration time on schema redesign will drag down a lone programmer like you. Beacuse you really don't know how the Bitcoin will evolve you can't rely on one fixed schema. The "view" concept from relational-model is a crucial prototyping tool. I'm positive that Google has such tools internally for their BigTable DB. LevelDB was just a toy to allow people to experiment with k,v-primitives without having to run the distributed farms where the k,v-databases shine and are really needed. So what that LevelDB has sufficient theoretical capability? Single-tape Turing machine has it too. It is the programmer iteration time that matters. By the time you actually implement your network-model schema and profile its storage access patterns the relational-model developer could implement and profile hundreds or thousands. With that knowledge the relational-model developer can shift from rapid prototyping to implement the known-best-relational-model with the network-model tools for added performance. |
|
|
|
So how can I further improve this? Am I missing use cases? Am I crazy?
About two months ago you had this discussion with Inaba: https://bitcointalk.org/index.php?topic=56424.msg1387216#msg1387216The two of you have gotten really close to reinventing the data-bound control from Visual Studio. When you were talking about search & filtering functionality it sounded like you wanted to reinvent the visual query builder from Microsoft Access or Microsoft SQL Server. I know that you have a copy of Visual Studio and you theoretically could prototype your design using the dirty, grimy, foul-smelling, ...ugh... relational ...ouch... SQL database engine really quick. I also know that this wasn't a feeback you are looking for, therefore I voluntarily jump into your "ignore" file making the "plonk" sound while hitting the bottom. I just need to say things once to be able to say "I told them so" in the future. Relevant posts from about half-a-year ago about playing the open-source poker at the NonSQL table: https://bitcointalk.org/index.php?topic=94453.msg1046848#msg1046848https://bitcointalk.org/index.php?topic=94453.msg1046473#msg1046473 |
|
|
|
|
So in the interest of history: who was working on OpenCL/CUDA mining for scrypt() and/or solidcoin v2?
My recollection is that there were two broad camps centered around very vocal persons: BitcoinExpress and RealSolid. Both were threatening to "rape" the coin of the other camp. Both offered some sort of bounty for development of the GPU mining software. The bounties were both defensive (mine "our" coin) and offensive (mine "their" coin).
How many people have gotten close to collecting those bounties? How many closed-source implementations existed before ckolivas finally included scrypt() mining into his software?
|
|
|
|
Plus his reasoning for using scrypt with those parameters were posted months before Litecoin launched, and people have looked over his reasoning and no one came out and said anything against his reasonings.
This is quite true in my case. The first time I took a look at scrypt() was only on the day that Litecon was launched: https://bitcointalk.org/index.php?topic=47417.msg572019#msg572019It took me about a month to read about and understand scrypt(): https://bitcointalk.org/index.php?topic=48863.msg620106#msg620106You can also have a laugh at my suggestion of an OpenCL-resistant coin amongst the Solidcoin v2 trollfest about a month before Litecoin launch: https://bitcointalk.org/index.php?topic=44423.msg537010#msg537010The only thing I disagree would be "people have looked". In my opinion the trollfest was so intense and emotional that almost nobody tried to make any rational reasoning. Again: too bad I decided not to keep the IRC logs from my idling on the relevant channels. In a way you can see the failure of scrypt() parameter selection reoccurring right now in the casascius' thread about BIP 0038: https://bitcointalk.org/index.php?topic=129317.0This time there's no trollfest to distract. But there's only one publicly posted scrypt() implementation. And there's a strong motivation to hurry up and just bruteforce to win the competition instead of really analyzing the possible ways of implementing it. |
|
|
|
Well, the feedback from the gentle readers 2112's post sounded awfully cryptic
and not-so-gentle readers Quoted, because it seems like you actually believe that detailed information about TSMC's processes exists in the modded cgminer.
is that my "Teach yourself IC design,fabrication&test in 21 minutes" lecture is too hard and sounds like black magic. I'm going to quote single linear thought from my post to maybe make it easier to follow. I'm not sure how much TSMC values the non-disclosure about the manufacturing node that Avalon used. But before they had their chips manufactured by TSMC they had to sign something about obeying reasonable care to avoid disclosing TSMC-proprietary and whoever-else-proprietary information. SHA-2 is an example of a self-testing structure, something akin to the test structures used in the manufacturing process testing and calibration.
When Avalon is going to disclose their voltage regulator and clock synthesizer programming information it will allow competent people to obtain very detailed information about TSMC process used. I don't think that theres much commercial value in that, but it is the intentions that count. Avalon signed not to disclose, but allowed disclosure through carelessness. TSMC aren't going to be thrilled about it and will drive harder bargain when Avalon tries to order the 2nd batch. I'm not expecting somebody from Chronicle Technology open the account to post "Thanks, suckers.", but maybe some of the Avalon competitors will do that.
The technique I'm talking above is called "yield estimation using test data". SHA-2 is 100% self-testing and trivial to reverse-engineer. Competent semiconductor manufacture engineer can with the help of changing clock frequency and supply voltage obtain a highly proprietary data in a completely non-destructive way (no chip desoldering, decaping, etc.) An observant reader may ask "why neither Intel nor AMD seem to care about chip with unlocked clock-multiplier and voltage identifier". The answer is "binning". A large manufacturer will do an extensive test of their chips and sort them into bins. When they sell the "enthusiast-grade" chips with unlocked clock they sell them from the "fastest process corner" bin. All other bins are clock-locked and sold cheaper into OEM market. By "bin sorting" the manufacturer can completely obfuscate actual process parameters and make competitive yield estimation pointless. On the other hand Bitcoin ASIC vendors cannot afford detailed chip testing, both because of financial and time constraints. Any chip that passes quick needle-test on the wafer prober will be packaged and mounted in the shipping product. This situation gives the analyst the sampling of an entire defect/yield curve for the fabrication process. As far as I know the most commercially/competetively interesting information is obtained by testing the worst chips, those from the bin nearest to the "trash bin", the ones that barely met the specifications. In fact the content of the "trash bin" is quite valuable to the competition and therefore each fab carefully destroys the chips that failed the acceptance tests. I hope that the above addition my posts will look more like grey magic than black magic. Please do some web searches about "yield estimation chip" and read the freely-available information. |
|
|
|
Without a proof, I view those conspiracy accusation as pure FUD.
I don't know, maybe somebody still has the IRC logs from the channels frequented by Lolcust & Artforz. I didn't keep them, although I idled on all of them for a while: GeistGeld; Tenebrix/Fairbrix, Realcoin, etc. The discussion there was really lively. Many people were more burned by the biting sense of homour of both Artforz & Lolcust; more so than by the premine that Lolcust designed into Tenebrix. In this way the origins of Litecoin are realy murky: one could say it is a Tenebrix-clone but without the trolling and sarcastic humour that was associated with them. It seems that nobody had though to even question or discuss the choice that Artforz had dictated. For a while this forum was full of posts by BitcoinExpress (and others like bulanula) regarding mining and attacking various coins. I think most of them are deleted now. If somebody is hell-bent on obtaining the proof maybe theymos or other administrators would give them copy of the deleted posts from this subforum. Personally, I don't need the proof: I read the Colin Percival papers and presentations about scrypt & tarsnap. He shows how to choose the optimim parameters for each implementation technology. Artforz had choosen much lower values: so low that they would fit in the on-chip BRAM of Spartan-6 FPGAs. |
|
|
|
Are you actually complaining about the GPL license? kjj is absolutely correct. Avalon took GPL source, modified it, and failed to offer the source. That is a violation, plain and simple. It doesn't matter if they promised to release it later. It doesn't matter if they are giving up trade secrets to release it. If they don't like the terms of the GPL, they shouldn't have used GPL source. But they did use GPL source, and they have violated the license.
What I'm pointing out is that kjj is preaching from the Free Software Foundation bible in the church of Hardware. The actions that make sense in software business are frequently suicidal in the hardware business. This is because of the cost structure: hardware is mostly front-end-loaded, whereas software is mostly back-end-loaded. Yes, Avalon made a mistake by using a code requiring GPLv3 compliance. They should've designed a separation layer like many hardware vendors that support Linux. But the Avalon team is young and inexperienced and they didn't design for that. My position is that rational supporters of Bitcoin would attempt to come up with some middle-of-the-road solution to safeguard the existence of viable competition of multiple vendors in the Bitcoin ASIC business. What I see is almost exact opposite: they are asking Avalon to nearly commit suicide for the sake of an ilusory freedom. Ilusory, because for the gain of few pages of source the whole Bitcoin ecosystem is paying the price of severely disadvantaging one of the ASIC vendors, to the point that in the next iteration we could have a monopoly. The rational behaviour would be probably along several possible lines: a) disclose the code only to Jeff Garzik. He's professionally involved in Linux kernel development and may be able to offer some useful advice on how to both comply with GPLv3 and TSMC/whoever-else NDAs. b) offer to escrow the code with Bitcoin Foundation and have a programmer at B.F. to produce an obfuscated code that complies both with GPLv3 and NDAs. There are already multiple precedents in escrowing the information with Gavin Andresen, but thus far the escrow was security-related. c) I personally think that the "binary blob" workaround isn't viable here for purely technical reasons. But I may be wrong. Maybe somebody willing and able to sign the NDA could help Avalon to develop such a solution. d) take a chill pill and make Avalon folks pinky swar that they disclose the required information after the competition shipped and after the subsequent batches are locked in with TSMC. But this thread isn't about being rational. It is about militancy, a very short-sighted militancy of playing open-face chinese-rules poker at the traditional-rules poker table. Think for a moment: What would Richard Stallman do if he had a single tapeout to his name before he received his MacArthur Fellowship? We wouldn't have a Free Software Foundation. We would have maybe a Free Logic Foundation or Free Computation Foundation or something else. But I believe that we would be better off: maybe we could have open-source processors and disk drives in our open-source computers. |
|
|
|
Having done lots of sub-nm ASIC designs,
You should just license your Zeta-Reticulian technology to us Earthlings. We would be really grateful and give you in exchange almost anything you'll ask and build temples to commemorate your revelation.  |
|
|
|
Does it have a design flaw?
It isn't as much flaw as deception. Litecoin used the same scrypt parameters as Tenebrix. Artforz had gamed almost everyone involved in the scrypt()-based coins. He had choosen the set of parameters that made GPU mining possible, but made claims that the design is GPU-resistant. Then he proceeded to mine all the scrypt()-based coins (Tenebrix/Fairbrix/etc) on his GPU farm that was significantly more efficient than the CPU miners. |
|
|
|
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.
Click & snap again. I mean kjj is kinda lost-cause here, he isn't even aware that he's at a poker table and laying your cards for all to see is not a winning strategy. But I know that this board is read by many young people who are capable of learning. Hardware development is like a poker: you keep your cards close to the chest, maybe drop some and add some, place your bets and wait for the showdown. If you show your cards to other players before showdown you are going to lose (or at least you aren't going to win anything). And if you lose all your stake you will not be allowed to sit at any table. If you wont be able to front the money for the cheapest table you'll be just a beggar waiting for handouts from the real players at the casino's entrance. I'm not sure how much TSMC values the non-disclosure about the manufacturing node that Avalon used. But before they had their chips manufactured by TSMC they had to sign something about obeying reasonable care to avoid disclosing TSMC-proprietary and whoever-else-proprietary information. SHA-2 is an example of a self-testing structure, something akin to the test structures used in the manufacturing process testing and calibration. When Avalon is going to disclose their voltage regulator and clock synthesizer programming information it will allow competent people to obtain very detailed information about TSMC process used. I don't think that theres much commercial value in that, but it is the intentions that count. Avalon signed not to disclose, but allowed disclosure through carelessness. TSMC aren't going to be thrilled about it and will drive harder bargain when Avalon tries to order the 2nd batch. I'm not expecting somebody from Chronicle Technology open the account to post "Thanks, suckers.", but maybe some of the Avalon competitors will do that. So Avalon is now in between the hammer of GPLv3 and the anvil of NDA with TSMC. This concludes this my short lecture. If you plan to ever in your life play in the high-stakes game of hardware development: learn the rules. Otherwise you'll be forever fighting over the table scraps and leftovers: like Raspberry Pi where Broadcom/Alphamosaic Videocore GPU boots and controls the ARM CPU sandbox to let the kids play with their open cards poker game. |
|
|
|
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. |
|
|
|
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. |
|
|
|
The kernel stuff is GPLv2. Only cgminer is GPLv3, AFAICT. Definitely a difference there, and there is plenty of de facto precedent for binary-only gadgets in the kernel -- even if hardcore Debian-legal denizens disagree with that legal interpretation/result.
Well, I'm thinking that Avalon people didn't have time to write a proper firmware and device driver. They are probably using the generic drivers from the Linux kernel. Then all the initialization/control/stabilization code is in the modified cgminer, which is all GPLv3. Avalon probably heavily modified the AMD/ATI fan control code from the GPU miner and USB-interface code from the FPGA miner. There are any number of existing bytecode solutions that could be employed, to provide a sort of "firmware" that is executed by the host CPU. Modern ACPI functions like this, as does http://en.wikipedia.org/wiki/Open_FirmwareOf course, that tends not to be performance-heavy code, but instead critical bootstrapping and initialization functions. The easiest it would be if only fan-control is used after initialization and voltage and frequency settings are hard-coded in the factory. But if they have the fully dynamic clocking like eldentyrell does in his tricone FPGA miner then it would be nearly impossible to split all that functionality into a binary blob or whatever else. ACPI folks had years of experience with their technology and build up on the past experience with PnP etc. And even they still freqently can't get it right. |
|
|
|
The spectacle of watching laymen giving themselves a promotion to copyright attorney is truly worth watching.
This is minor leagues kind of fun. The real fun would (or will) start when the people involved could afford a real legal counsel. Imagine what would happen if a successfull preliminary injunction would get filled against importing Avalon units into USA. That would be like real fireworks. Obviously I'm very curious what is in the unreleased source code in the Avalon driver. Fan-speed control is probably nearly open-source. But the voltage regulator programming and clock synthesizer programming may hide real secret information. Even if the code gets released the people involved may regret the ultimate results of the disclosure. 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. Anyone here has any constructive suggestions how to make the hardware driver detail disclosure non-adverse? Some sort of obfuscation scheme with programming a multitude of non-existent regsters with multiple pages full of hex values? Is there a quick way to distinguish which registers are real and which are fake? |
|
|
|
|
Show Posts
