On the governed islands they still give gifts.  I'm pretty sure that Di leaves them empty now everywhere else.  However, if this guy is just starting out, I think you always start on one of the governed islands.  In any case, everybitbit, you won't get very much by just hitting up the statues, at the end of the day, DT is a place to gamble.

If that's the case, that US law is the criterion for what can and can't be discussed, then:

1) I'm going to shit a brick
2) Someone should add that to the official rules

I'm not supporting ponzi's or supporting the people who support them.  But I do think it's a fair point that the laws of any country are sorta arbitrary and as far as I can tell, it's the rules of the forum as established by the forum dictators which govern what's discussed here and what's not.  I think the point that bitcoin itself is illegal in some places puts a fine point on that.

Indeed.  FWIW, I don't think your wallet being open or closed has anything to do with it being confirmed, at least once the transaction is out on the network anyway.  At that point, your transaction is all in the hands of mining algorithms and luck.  Anyway, glad all resolved well for you.

And if anyone doesn't know, it should be said that Quickseller has been trolling dooglus on this forum by repeating his lies again and again whenever he can.  It's his style.  Once QS decides to hate you, he will concoct any convoluted stories he can and repeat them again and again (often using many different accounts) in order to try to damage your reputation.  He used to be so successful at this that people were actually promoting him to default trust and even trusting him with increasingly large amounts of money.  Thankfully, QS' tactics and trustworthiness were revealed when he basically had a public meltdown on the last 10 or so pages of this thread:

https://bitcointalk.org/index.php?topic=1171059.0

I'm just saying this here and now because it's important to call him out when he does this.  Every time one of the people he's attacking says something anywhere, he'll do his best to twist it into an attack onto that person's reputation.  dooglus should be able to offer an opinion on this thread without QS repeating his lies about dooglus,  but since he gets away with that, I feel the need to draw attention to the fact that it's a baseless ad hominem by a guy who spends waaay too much time repeating lies on this forum.

I honestly can't remember how long multibit will keep rebroadcasting that transaction if it's never included.  I assume that at some point you must be right.  I also imaging that the answer is somewhere upthread if you search carefully.  With respect to causes, yes, transactions compete for inclusion in blocks and including a higher fee will provide a higher likelihood of sooner inclusion.  Up until recently, though, even no-fee transaction were usually eventually included.  And yes, If I was you and I was trying to get a quick confirmation on this, I'd look at (a) whether you included a fee and whether it was high enough, depending on the answer to (a), do (b) resend a competing transaction with a higher fee, or just wait (maybe you included a good fee but are just unlucky, it can happen).

I'm glad to see DT getting some publicity.  FWIW, I'd still be willing to sell my level 8 character if I get a good offer.  Send PMs here as I rarely log into DT these days.

If the transaction has been broadcast then resetting multibit isn't going to help it get confirmations.  What you want to do if you're worried about it getting confirmed sooner is to send out a competing transaction with more fees.  To do that, I'd just import that privkey into some other wallet that doesn't know about the unconfirmed transaction and send again with a higher fee.

^^Pretty easy   Hope it helps.

Part of that brainwallet hacking "brainflayer" which was released had some bloomfilter stuff to check large amounts of keys at once https://github.com/ryancdotorg/brainflayer.  I don't know if it's something you can repurpose for whatever you're doing.  See that "hex2blf" script.

In any case, if you only need to check thousands, why not just write a loop to look them up one at a time.  This could be problematically slow if you actually want to check hundreds of millions, but I would think that thousands would be trivially quick on a modern computer.

Or, the person who won them could be smart about how he sells them and not crash the price.  He'd have to be patient, but there are actually plenty of CLAM buyers.  The trick is obviously not to overwhelm them, instead, sell off a little per day and you're fine.

Sho, is that drop on the 7th of feb where you're restarting your node to clear your mempool?  If that's the case then it seems like at least one long-time node runner (you) *is* resetting your node regularly to avoid the pileup.

Not sure if its applicable, but is it possible to give a file as an arg for you clamd clamspeech?  If so, that might avoid any tinkering by the shell/locale.

I'm rebuilding bitcoin and bitcoin-qt because of another question in this board.  I'll kick it off and run it for a while and tell you if I see something similar.  I imagine that long before then someone else who's on here and has a node that's been up for a while can chime-in about whether 225MB is a lot.  Is your memory usage still climbing on that linear pattern after 10 days?

grepping through bitcoin source, I think this may be what you want, "RecommendedNumTransactions".

tsp@computer:~/src/bitcoin/src/qt$ grep -ri recommendednum
Binary file qt_libbitcoinqt_a-transactiondesc.o matches
Binary file qt_libbitcoinqt_a-transactiontablemodel.o matches
transactionrecord.cpp:        else if (status.depth < RecommendedNumConfirmations)
transactionrecord.h:    static const int RecommendedNumConfirmations = 6;
transactiontablemodel.cpp:        status = tr("Confirming (%1 of %2 recommended confirmations)").arg(wtx->status.depth).arg(TransactionRecord::RecommendedNumConfirmations);
Binary file libbitcoinqt.a matches
Binary file qt_libbitcoinqt_a-transactionrecord.o matches
Binary file bitcoin-qt matches


Edit src/qt/transactionsrecord.h in your bitcoin source tree, line 83, change the 6 to a 12.  Rebuild.  Then send me a tip for finding that for you.

Cheers!

It looks like your Armory .wallet file doesn't even load in Armory, is that right?  If that's the case, maybe the file is corrupted?  On the other hand, it looks like it's not corrupted since that error seems like a parser wanting one thing and finding another.  It says it found a list when it expected a string or buffer, so that doesn't sound like garbage, that seems like a format that's unexpected.  Can you clarify that you made this file in Armory and now it won't load there?

FWIW, you could go into "genericpath.py" and see about printing out printing out more information of what crashed at line 18.

Another thought, since that file is called "genericpath" I wonder if it's just a matter of getting your path right.  Can you show us the invocation you used?  I wonder if there are spaces in your filepath and the parser turned that into a list.  Maybe try invoking your tool with double quotes around your path if it includes spaces (and or \ escaped spaces).  I don't know how technical you are, maybe you can just show us how this is being invoked.

There may be something going on here if you say that your stats are different from what you're seeing on other people's nodes.  In any case, it's definitely not regular procedure to be restarting your nodes every week.  Bitcoin is reasonably stable software and you should be able to get significant uptime if everything is configured correctly.  On the other hand, 80MB doesn't really seem all that large (but you're right that that linear growth is troubling), I'm guessing something's configured incorrectly here.  I think it's hard to diagnose further without more details.

Actually, when you rely on a centralized target for trust-scams like DefaultTrust, that's what makes it hard to evaluate.  If you manage this for yourself, you automatically are more skeptical of everything, which makes you safer.
Oh, like you did to me, "FunFunnyFan"    (https://bitcointalk.org/index.php?action=trust;u=519804) aka Panthers52 aka ACCTSeller, aka ....

There's no reason why "a lot of trolls/scammers/non-reputable people" will be included if you don't include them.  When you take DefaultTrust at face value, you're adopting blindly and wholesale the main target of such confidence scams as you were trying to pull around here with your shenanigans last year.  When you manage your own trust list, you add the people that you've had experience with, so, as usual, you seem to be perverting logic and turning reason on its head.  The only real question is why.  The best current answer is that you're planning or already managing a new crop of alts and trying to work your way back into position to pull off whatever exit scam you were planning with this account.

Lol.  As if the exchange rate is somehow irrelevant.  There's a very sound argument to be made that donating 50$ (or whatever 50BTC was worth at the time) and getting VIP is special treatment if today you have to donate something like a quarter of a million dollars (or whatever it is now) to get the same title.

In my opinion, forum badges are hardly worth worrying over.  But, on the other hand, it's quite clear that no one is going to pay 50BTC for a forum badge, and perhaps some people would pay 50$.  I'm guessing what's going on here is that the forum no longer needs to raise money.

I tend to think that that's the right way to start out.  Who knows, maybe you'll find someone who's feedback you trust and add them.  In anycase, the centralization of trust around the default trust list has let to mountains of scams around here.  The best thing that people can do to alleviate that is to remove default trust and build their own lists and teach others to do the same.

Wow, site profit through roof.  Sorry for starfish, but I'm glad I went offsite max a few days ago.  Myohmy.  I think that's the largest single bet yet, isn't it? (the 25K one).

By the way, what's the latest on the changes to offsite?  Are you getting rid of it altogether?