|
Version 0.7.2 and later include the raw transaction API (JSON-RPC), which permits full coin control.
The upcoming release 0.8 includes contrib/spendfrom/ utility, which illustrates how easily an external utility may provide coin control capability. No GUI patching required.
|
|
|
|
If the scams go unpunished, more scams will result.
If license violations go unpunished, more license violations will result.
"playing nice" just encourages more people to break the law/license/etc.
Read the links previously posted. People with actual experience dealing with GPL violations disagree WRT playing nice. It's also just common sense, Human Relationships 101. |
|
|
|
Note: After reading through these threads it is clear this discussion/request has turned in to Political Statement about Open Source and trying to prove something.
Or free hardware requests disguised as political statements  If any of these teenagers like kano had a clue about pursuing GPL violations, they would understand that going straight to curse words and screaming accusations is logically less likely to produce the source code in a meaningful amount of time. It is also less likely to produce long term cooperation, as it creates a hostile environment at the start of the relationship. There is lots of good text and FAQs from folks with a track record of pursuing GPL violations at http://gpl-violations.org/ including http://gpl-violations.org/faq/violation-faq.html which suggests How can I help gpl-violations.org ?
Firstly by not reacting to a technical GPL violation in an extreme fashion. Secondly by checking the violation is indeed a violation.
Join the mailing lists, discuss issues there first. Be polite but firm when dealing with companies and remember that the goal is to ensure a company stops violating the GPL and does not violate it again, rather than to leave a smoking crater at the location of their HQ... at least not on the first offense.
Keep records of conversations with companies. Co-ordinate with others. A company faced with eight different stories will find it hard to deal with. A company faced with a single accurate information source can respond better.
Beware the "public shaming" bomb. It's easy to let off, but very hard to defuse if you made a mistake or the issue turned out to be minor and is rapidly resolved. In addition companies may become very defensive in such cases and decide to "tough it out". We want to build bridges and giving a company no way to avoid losing face hinders that, especially in certain cultures.
If we want to encourage Avalon to be a contributing open source community member, throwing curses and legal deadlines at the outset is the last thing you want to do. Act like a mature adult, and understand that everybody has different priorities and perspectives. Understand that these details may take weeks or months to sort out, especially if it is the first release of a new product line. Coordinate with other interested parties in the bitcoin community, come up with some positive reasons why Avalon should open source their work, open a dialogue with Avalon, work with the company to show them that open source makes engineering and economic sense. You don't want the only incentive to use open source being fear. That just encourages a company to do anything they can to minimize or avoid open source as much as possible. We want ASIC vendors to be open source friendly because it is good for everyone involved. |
|
|
|
The one thing I don't understand in all this flameage is why Jeff Garzik isn't championing the request for source from Avalon. Jeff?
After certain people made that task considerably more difficult? It is difficult to summon the motivation. Ask again in 30 days... |
|
|
|
Are you implying these are Avalon users?
No. |
|
|
|
Once upon a time in #btcguild... <KuKzz> now we have a single user with 800gh? 0_0
<Eleuthria> Yes.
<Eleuthria> Welcome to the future.
|
|
|
|
Botnets will stop bothering bitcoin when the profit goes away, or they find something more profitable to do with them.
This. Botnets are stolen resources, so anything we can do to incentivize them away from bitcoin is useful. |
|
|
|
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 |
|
|
|
Do there exist delivered ASICs from the first batch since 19th Jan. 2013 or is jgarzik's the only one?
Two units definitely known, mine and Bitcoin Foundation's, plus possibly a third in China based on vague forum posts. |
|
|
|
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.
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. 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?
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. |
|
|
|
Jeff, if you're wondering if it's heating related,
I'm not. Seems pretty clear heat is not a problem here. |
|
|
|
Yes that's how they're supposed to work. However that functionality is disabled.
What does "disabled" means? Does it means that bitcoind gives you no way to deal with nLockTime, but if some miner accepts, relays and mines them, his blocks will be accepted? Blocks only contain "final" transactions, and by definition, a transaction with non-zero nLockTime is not final. Transaction replacement occurs before miners mine blocks. Thus, to answer your question, such a miner's blocks would be rejected as invalid by all existing versions of bitcoin software. |
|
|
|
Maybe jgarzik is kinda out of touch with the mining side of things, and with the role which kano has played in maintaining and improving cgminer for us all? Kano is not after free hardware,
Where oh where did cgminer come from, originally? hmmm. |
|
|
|
|
This torrent will be updated soon, to sync with a new checkpoint in the upcoming 0.8 release.
|
|
|
|
I will offer this as a torrent and also give direct-download links to those who wish to jump-start and seed such a torrent, since my seeding speed is limited. The question is, should an official torrent going forward be a compressed file? Using the highest compression preset with xz/lzma (installed with most distros, opens with 7-zip or MacOS GUI tools) saves 2GB of downloading, so I say yes: 02/10/2013 08:44 PM 2,841,903,993 bootstrap.dat.lzma Also, bootstrap.dat is too big for FAT32, but not the compressed version. Bitcoin 0.9+ could even (feature request) open a compressed bootstrap (lzma is a stream container) directly if standardized. This would make a useful contribution to this thread, [BETA] Bitcoin blockchain torrent https://bitcointalk.org/index.php?topic=117982.0The semi-official bootstrap.dat torrent is about to be updated, as it is for each bitcoin release. The 2GB issue has already been raised in that thread, and the FAT32 4GB issue would also be a good one to raise. Ideally we would like everyone to seed the same torrent -- it's the same data, as guaranteed by bitcoin (as well as torrent) hashes. |
|
|
|
I dont' know if this question was already answered. Jeff, did you ask Avalon to provide you the source code?
Not yet, no. Yifu stated the source would be released, even before kano began his transparent quest for free hardware. No reason to disbelieve that, at this time. |
|
|
|
They've named it a PGA (PGA0) I chose PGA as the 3 letter shortening of FPGA I guess using PGA avoided having to create a new ASIC type in the API Or just google for "pin grid array" |
|
|
|
|
The spectacle of watching laymen giving themselves a promotion to copyright attorney is truly worth watching.
|
|
|
|
I'm sure Jeff can confirm these numbers on his device as well.
My review included raw numbers -- search for "cgminer status" Here is an updated cgminer status snapshot: http://pastebin.com/8mKjmTSnReaders may search for "temp" to find what I presume to be temperature sensor readings. Fan speed is also observed via "fan" data. |
|
|
|
|
Show Posts
