Nice idea. It means the foundation must be 100% operative.
The use of the coins should be clearly stated and transparent.
I propose 50% to charities, 50% to development and advertise.

The more you use them, the more they grow in value (advertise and development), the more you help the World. Wow!!!!

How would you do that? Apart from that part your new proposition is equivalent to the charity/donation proposition you saw some problems with. I'm especially concerned with (2), as it essentially centralizes the metacoin. How could I be sure that the foundation does not dilute the metacoin at some stage? Also I do not understand why meta-coins should have a fixed rate as trading between IXC and the metacoin is build-in into the Counterparty protocol.

Friction, I found a tool by which you can easily create the required "snapshot" (i.e., balances of all addresses at a certain time):
https://github.com/znort987/blockparser
The size of the text file of all addresses with a balance for bitcoin  half a year ago was 2.7GB (text file), so the equivalent file for IXC organized to a database can't consume more space than a few tens of megs. And I remind you again that the database needs to be accessed only when a new "activate" transaction is parsed.

[Edit: It also occured me that we could require the "activate" transaction to have a fixed output IXC address with a required amount of fee (similar to all Mastercoin transactions) . This would be a way to get some money also to the IXC community (for bounties etc). ]

I did a review of the code on github for the A1 driver. It appears that improvements were made to the delays scanning. However I am having this information confirmed as driver coding is not my strongest area. I asked a few more questions on improvements of the driver since the first version was made available. This might be helpful for us in getting these cards working. Since there is not alot of documentation (well none at all) on the AMT variants of these cards, this is alot of trial and error and guess work. I dont know what the result will be, BUT I am hopeful we might get some results and answers. Even with a single fried chip, it should be possible to bring the cards up partially unless they are chained in a way that brings the whole card down.

This is one hell of a learning experience here for me FYI. I know linux and am getting deep into hardware areas I never did before like drivers. So wish me luck. If I get a working miner/card tonight I will post an early alpha for testing. Once the initial step is done (zombie cards) I will work on features like a web interface and such which I will add later or someone else can. My plan is just a simple working base setup. I am going to call this project zombie lol. Seems like an appropriate name to get these miners back from the dead.

Hey AMT,

I've sent a bunch of emails your way and called a few times letting you know I was going to reach your office today. I'm outside now and was wondering if you could have a representative bop on over here so I could discuss my order face to face.

Thanks again,
Allen Myers

At least the lawyers MIGHT tell you why. Chances are they won't...attorney/client confidentiality and all that. Dont expect much on that route. I think behind the scenes a shitstorm is brewing. My guess is whatever it is things will be settling, but again very little of it to our favor. If AMT has little we are screwed. I haven't gotten any replies either (I got some occasionally when I needed tech help). Its likely pretty bad though...they could be undergoing a full audit now. Which might give the plantiffs a better idea of what is going on and what we all get....if the class is now a full class then all of us otherwise just the original plantiffs walk away either whole or with more than they were supposed to get which means our money as well. This could actually happen. But as I am not a lawyer I don't know. At this point all I want are 2 replacement miners to address the issues with the current ones.

Contact them.  White & Williams LLP.

You don't need any master address. As I outlined, "activate" would just prove (signing) that at the time of the snapshot it was in control of certain IXCs (i.e. unclaimed transactions). There are also other ways (I think) to implement that. Check the spin-offs chain I linked.

No, that's not the case (although I myself misleadingly used the word "split"). The reason is that IXC and meta IXC would be independent and could not be used in place of each other. meta IXC can only increase value of IXC. Why would someone value IXC less after launch of meta IXC: no use/properties of IXC are removed and IXC and meta IXC are not competing with each other?

[Edit: there is an other way to think this. CounterParty (with the spin-off metacoin) does not need any permission to be launched (that's why some call these "parasite" coins). Anyone can do it on their will. If your premise that it would decrease the value of the original coin would hold, then it follows that you could destroy the value of bitcoin by simply launching infinite number of CounterParty implementations.]

I do believe that I'm going to send my equipment that needs to be RMAed to Josh care of his lawfirm and send it directly to their address with printed pictures I took of the damage. As I got a unit with manufacturing issues then I am due a new working unit and would be happy to talk to josh or his lawyers on how they would like to go about that.

That's not the only alternative. I explained another one, but you seem to ignore my comments (which is kind of sad considering that I donated 5000 IXC to you to do this job).

Let me rephrase my proposal if my previous explenations were unclear. So the idea is to create the necessary metacoin similar to how the spin-offs are planned to be created: we would bootstrap the distribution of the new metacoin (IXCP) with IXC blockchain (of certain heigth). Implementation in CounterParty would be rather straightforward: you take the snapshot of the IXC, and in the protocol instead of the "burn" you would have something like "activate", which would first check if the IXCP address exists, and if not, credit the equal (or proportional) amount of the IXCP as the address was holding IXC in the snapshot.

In my case, I assume it was the hardware for the most part. However, the software didn't quite know how to handle the "issue".

All except the issue with the starting, booting and resetting, which, for me, is still spotty.

There needs to be a longer delay between booting stages. It just pukes-out stage after stage, and obviously, some components are not actually ready, when it attempts to talk to them. (Namely the cards and the network.)

This, again, is where a multi-stage delayed-boot sequence would help. Allowing the devices to become powered-up and ready, before attempting to communicate with them.

The "reboot" in the settings, for the password-change and "target temps" (Not sure why those are both on the same page.), and also on the setup for the pools, is buggy as hell. (It is also annoying that it defaults to "balanced load" and not "failover". You do NOT want to run in balanced-mode, unless you are connecting to three separate servers, for some reason. You want failover, so when one pool fails, it attempts to go to the next one.) However, I do not change pools often, so that is just an annoying thing.

When changing the servers... "Save and reboot", does not actually reboot... it soft-boots... However, mine ends-up showing hashing like 12GHs and 45GHs per card after that... until I physically reboot by killing power to the PSU, since no-one has figured out how to turn off the unit unless you unplug the whole unit.

My biggest issue is that the miner does not connect to http connections for solomining. It demands "stratum+tcp" connections only. (Pools)

I was wrong before, about it hashing, but not reporting hashing... It does "get work", it just doesn't hash with it?!? Not sure how that got glitched. Pools are the worst thing to mine into, unless you have no choice, due to difficulty being high. However, coins I want to mine do not have high diffs, and pools are all in foreign-lands. (Too far, so lots of thrown-out share credits and valid work.)

If you could add some start-up delays between the start-up sequences... I am about 90% sure that will help resolve a lot of the issues where it simply gets "stuck" on the "Monitor" stage. Which is the last stage just before the network connects. (Or it is getting stuck on the network stage, and thus, does not refresh the screen, making you think it is stuck on the "Monitor" stage.)

one of the rigs i have had a dabble with lost a chip due to changing the vridiff in a pool from 512 to 128 as soon as we clicked change diff it went poop. i would believe it could be due to the voltages as the card drops into free spool the volts rise say from 0.84-0.86 . my advice is putty into it type killall cgminer than go back to the web interface. then you should be safe as its not a hard hang

Well, One card seems to have stopped responding...

Just after setting the target-temp from 60 to 65...

Have gone through the excruciating process of turning the unit on and off, about 50 times now, (only resulting in about 6 actual boots that don't get stuck at the "MONITOR" point... All with the same result... Only two modules detected...

Killing full power had no change. (Since cutting power at the switch still keeps power active on the +5v on many PSU's. For the USB device and backup power.)

In any event... It looks like it is software related. The delays are not great enough between detection's, and not long enough, or not even present, to "Write new data" when making changes. I don't think it even checks to see if the settings actually got saved. It just assumes they were a success. (IN my case, I don't think they were even finished writing, when I hit the reboot button. Thus, corrupting the write?)

Also the sequence for detection may be too fast... Not letting the cards get full power, before trying to detect them... Thus, failing at the monitor stage?

The radio shack variety silicone based stuff works just fine. In the end though it likely is not that at all. There are clear electrical issues with the hardware. I am taking a look at the broken cards again and checking to see if there is any soldering issues or anything out of place that could have caused a short or a failure. I haven't had time to look at them. I am essentially sitting on two bricks I might not get a replacement for. I reached out to AMT to just replace these. Still have not heard back. Altho they could just show up on my door step at some point too unannounced. I guess we will see. The lawsuit probably has them on full gag so they may not even be able to talk to individual customers either. Least thats my thought.

That is an interesting bit of info, which supports my hypothesis. You switched pools THEN it went dead. I had a similar problem. Since the PI, backplane and daughtherboard still work, I am going to compile A1 support tonight for cgminer and see what happens. Right now I just have the pi plugged in by itself for purposes of getting the distro up and cgminer installed. After that I will plug all the hardware in (tonight if possible) and post results. Knock on wood and hope this was a software problem with SOME of the cards (I am only sure one card is dead). We are running a pretty old version of cgminer on the AMT/Bitmine systems. Updating to 4.3.3 MIGHT address some of this as the driver code is newer from what I saw on github.

Zombie miner project is a go...

Oh and if it works, I will post the image up for use. I am going just make it a general image for any hardware. Compiling support for various products. I would rather contribute to the community in that sense. While vendors are far more conservative with their firmware, its not always feasiable. But be aware this is at your own risk! I will test it best I can, make sure its stable. But any mods beyond my changes are on the user. I will post it in the software section later and link it here. Depending on how well things go tonight I may or may not get it up tonight. Either way tho it will happen this week. At the very least the distro will be up even if it does not fix our problem.

The only recommendation I have is make sure there is some kind of airflow on the last card that has the little heatsinks....I used another fan to blow air on that because I was concerned that would blow out. But as ISAWHIM noted they get really hot. So it might not hurt to get some better heatsinks. I am looking into that and will make a recommendation once I find something that works.


That was the case on one of my miners which fried. That is the card that wont allow the system to power up. I have 5 others that can be plugged in but do not show up. I am hoping vainly that its a software issue but my guess is its not. This is one reason I am building the linux distro I am for these things. It could in all likelihood be a driver issue as the driver has been updated previously.

Now the million dollar question is how to bring the "dead" boards to life....Having 6 boards that are totally dead (one board preventing the system from even powering on). Any thoughts? Thanks again for all your help and contributions.

Just for the record, I have received a 5-card unit, without a PSU, within a tower case.

(snip)