Could probably just make Armory check the binary's directory for a config file first, and if not found, then reference %appdata% for everything, and if found, then use the binary's directory as %appdata%.

This is how uTorrent works, in order to be portable on a removable drive.

-- Smoov

I tend to think of it more as a loan, which you get paid back with bonus(interest).

Ya want ownership of sorts, you're better off investing in stock in a mining company.

-- Smoov

How are you going to handle the payouts to a different address?

-- Smoov

Yeah, how messed up is that! Twice in the same day. That just doesn't happen.

Should mark it on your calendar, and have an anniversary party next year to remember this day.

-- Smoov

The only 'risk' part with insurance, would be the cost of the coverage.

Since the only thing he is asking for, for the coverage, is that the insuree uses one of their referral codes, and nothing out of pocket, the cost to the insuree is zero. Hence, "no risk."

The exception for the coin being declared illegal, is obvious, since if it was declared illegal, and he would pay off the value of coin, since the coin would be illegal, he would be breaking the law paying them off, basically redeeming them. With them being illegal in this case, they would essentially be worthless.

Any risk someone would have, by taking advantage of the service they offer, would be the same risk they would still have, by not taking advantage of it. The risk level has nothing to do with them offering you insurance, and odds are, we joined using someone's referral link anyways.

I see no risk to using his insurance. What risk do you see?

-- Smoov

Greetingz...

One of the things I've read, having to do with the no-transaction-fee branch, and some of the other comments about how unpredictable fees can be sometimes, and my own experience sending out transactions made of small inputs, let me to a feature I would like to have available.

Being able to have some control over a transaction being sent, or not sent, due to the fee, is something I can see the end user as well as a commercial user needing to have, when using 'bitcoind'.

As it is right now, you can sendtoaddress, and as long as you have the balance to cover the fee it chooses to add onto it, it just goes, with no query approving the fee being added on. We need some control over that.

I would suggest allowing in the <amount> field, a format such as "##.###[+#.##][-#.##]"

+#.## would be the maximum fee the command is allowed to add, and if it exceeds that, then it fails.

-#.## would be the minimum fee to add, if someone wants their transaction to have a higher priority and wishes to force the fee on it.

Used together, a command such as "bitcoind.exe sendtoaddress 1blahblah 1.2+0.001-0.0002" would be interpreted as

I want to send 1.2 btc, but if the fee is going to be above 0.001, then don't send it through, and if the fee is going to be less than 0.0002, send it with a 0.0002 fee anyways.

The exact method can be changed around to something more easily parsed, but as long as we can at the very least, specify a cap on the upper range of the fee to be allowed, then that would give us some measure of control over what we're going to be charged as a fee, and then we could more easily predict a fee expense, say, for a business purpose.

I would carry this over to the other send coin methods as well.

I think this would address some of the concerns I've seen other posters have had, including how the inputs are selected randomly, since you're stating the max/min fee permitted, in the same command, it could be part of the same transaction check.

If the transaction fails, include what the calculated fee would have been in the error/failure message.

Then we would have the option, of increasing the allowed limit on our next attempt, or just wait until later to try again if we suspect our inputs need to mature more.

Any automatic expenditure that we don't explicitly approve of, should have some measure of our approval before it is just tacked onto the coin we intend to send. How much or how little it is, really isn't all that relevant, the principle of the matter remains.

Somehow, even by making a pre-approval in this manner, we have to have the ability to say yes or no to a transaction.

Thank you for your time.

-- Smoov

ps: no, I can't code it myself, I'm way way way too rusty

Just to clarify, he means, add one of MY servers as a backup.

(hint, hint)

-- Smoov

um... did I see someone in here several posts back, with popcorn? and, can I get some of that?

-- Smoov

No need to bring race into it...

-- Smoov

Kinda funny how, it seems so far, that the only one who is putting out concrete information so far, is the hacker...

just sayin'...

-- Smoov

Why would someone backup to something with the word "virtual" in the name to begin with? Might as well call it a virtual backup.

What they needed was an _actual_ backup.

Sure, backup to the virtual one, but immediately when it is done, get a copy transmitted to somewhere else that isn't 'virtual'...

just askin' for trouble.

-- Smoov

I dunno... if the records about who had which BTC has indeed been deleted, I imagine those same records also kept track of how much USD/EUR/etc was in everyone's accounts too.

The fact that they even bothered to put up a claims page at all, suggests that they have no idea at all who is supposed to get what. Otherwise, there would be little reason to put up a claims page since they'd still have the records of who gets what.

-- Smoov

And, you guys weren't able to just put the post up on your own home page, and post a link to it here, instead?

Guys, I've stayed pretty quiet through this whole mess, but, ya keep dropping the ball, and don't seem to be trying very hard.

So the post was long.

Post it somewhere else, and link to it.

Break it up into a couple parts, and post it that way.

There are ways to do it. Just giving up, with a "limited in our capacities", is starting to speak more about other capacities that you are limited in, that have nothing to do with forum limitations.

I'm sorry folks, but this is becoming a circus, and you're going to have to do better than this.

-- Smoov

Isn't that what I just said?

-- Smoov

It is important to have good people contributing good code to a project, absolutely.

It is also important to have other good people tossing around well thought out (and even mediocre) ideas that may spark an improvement the devs haven't yet thought of.

It is just as important for both of those groups of people, to have the rest of us common folk, poking sticks at it, to see if there are any creepy-crawlies still hiding inside.

It is a symbiotic relationship, which in the end, results in a more solid product.

Embrace us!

(oh... and don't forget to bring a stick)

-- Smoov

Would you be cool with adding a link, to give us an unfiltered page, with the amount in question, so we could laugh at them?

(and by them, I mean me, too, since I'm a micro-donator also )

-- Smoov

Alright... off to the corner for a half hour, for sticking a bunch of math into the middle of our silliness...

-- Smoov

I like that one...

Say I am telling someone to send me 9 BTC I'd just say

Send me ⊍9⊍

-- Smoov

GUIminer, for me at least, doesn't seem to like to remember the port I want it on in between runs, putting it back to 8332 when I run it again. Did it do that this time?

Should be 9332

-- Smoov