So we've all noticed the new "legendary member" status - just a post to say to all "newbies" that even us "legendary members" were also newbies once and also understand that as accounts are *sold* here don't think that just because a forum member appears to be "legendary" doesn't mean they couldn't actually be a scammer.

Before you *trust* any forum member you'd be best to check that member's posting history and also their reputation (and no - my account is not for sale).

IMO you'd be best to generally use an exchange to *move and convert funds* and then be done with it.

If you are going to "day-trade" then decide your *risk level* (i.e. how much BTC you are prepared to lose) and be comfortable with that.

Okay - makes more sense - just making sure the OP understands this also.

And agreed Bitcoin should make it simpler to solve the re-broadcasting issue (rather than having to resort to pywallet as I've had to do before).

This is not the *tone* that I picked up but hopefully the OP did (maybe just the way I am reading the posts).

I would say to the OP *don't worry, just wait and it'll be fine* and I am pretty sure that will be the case (as it has been with the other such topics).

You have been saying that a bit lately Danny but I haven't actually heard of anyone losing such an amount in this manner (and you know full well that blockchain.info will stop broadcasting the tx).

Are there really cases of people who have *lost 2+ BTC* due to not paying a fee (please give links)?

The RPC method to change the passphrase is: walletpassphrasechange (it's right at the bottom of the RPC calls listed here: https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_calls_list).

As regarding whether that matters when running a server it just depends upon whether that server is going to *use* a wallet (it is actually possible now to start up the server without a wallet at all).

If your bitcoin server doesn't need a wallet then perhaps consider using the -disablewallet option.

Although I know the input age makes a big difference mining pools don't necessarily follow the "standard rules" when it comes to tx inclusion (so although pleased I was actually a little surprised that zero fee well aged txs are seemingly always preferred over adequately aged txs with the minimum fee).

To my thinking the pools would always prefer the txs with fees than those with none (and no-one can force them to include a tx).

Agreed - I do the same and generally always see my tx appear in the very next block. Times when I have only paid the minimum I've sometimes have had to wait for well over 10 blocks to be mined before it gets included (presumably this very much depends upon who is doing the mining).

Oddly enough though if I have adequately "aged" UTXOs I can send txs (that involve a large enough BTC amount) with *no fee* and they will appear generally in the very next block!

I find for a small sized tx that if I pay 0.0002 (rather than 0.0001) for the fee it will be confirmed much faster (i.e. generally in the very next block).

@bitjoint - you are really not *getting* the whole idea of "open source".

It is not an "honor system" that has "implied rules of behaviour" - it is a model that accepts the idea that "you don't use the code itself to make money".

If Ethereum haven't figured that out properly then they simply shouldn't been doing open source at all.

I have spent at least 8 years working *full time* (sometimes in excess of 12 hours a day) for *no reward* to create the CIYAM project (https://github.com/ciyam/ciyam) and yet I am not going to complain if someone "clones it tomorrow".

What would be morally *wrong* is to clone the open source and then try and make it "closed source" (there are reports about that to do with cgminer I have seen reported on this forum).

Wow guys - I am surprised by the vitriol here - after all the *scams* from "the next big thing" project I actually think that Peter R has come up with a reasonable idea to "reign in the greed" (i.e. *stop IPOs*).

Look at Ripple - a huge amount of marketing hype filled with initial statements that "XRP are like postage stamps" to finally "XRP is going to make all the devs and investors rich" (and we all saw how that went down).

It appears to me that Ethereum is basically following the Ripple approach (maybe even less fairly) so if it all goes "belly up" like Ripple did I hope you guys are going to be taking back some of the flak that you are throwing at Peter R.

Ethereum are free to stay "closed-source" as long as they like (and Ripple did exactly that for some time - not that it helped).

Okay - good - so the issue is just at blockchain.info's end.

Hmm.. I wonder whether Bitcoin nodes should actually decide to "ignore" txs that have insufficient funds after they are older than x days in order to avoid the possibility of the network being "spammed" by txs that may never get confirmed (couldn't this effectively be an attack vector?).

I think the idea of a business whose role is to just do "cold storage" and offer insurance for said cold storage makes a lot of sense actually.

It can be quite stressful looking after large amounts of BTC (a bit like looking after a lot of jewelry or gold) and not something that most people or businesses may want to risk so I think that there will be a market for such services in the very near future.

I am a little confused - zlib is written in C not C++ and creating a C interface to a C++ implementation makes little sense (do you have any other examples of such things?).

I am very familiar with zlib (I use it in CIYAM) and am also very familiar with reworking C code for C++ (but that always tends to mean a C++ wrapper over the C code).

Why would you want a C library re-written in C++?

Well it's lunchtime where I am now and I have just noticed this - so I guess I have become "a legend in my own lunchtime". 

I'd have to agree that this seems like a very bad idea when it comes to securing bitcoins.

Here is an idea that could have some potential - there has been discussion (by Peter R in particular) about tools for creating a "snapshot" of all UTXOs for a given date range (for usage in clone coins that will end up with the equivalent distribution that BTC had at the time of the snapshot).

Offering such a service (which requires a full block chain) could be a way to "earn some extra BTC by running a full node" (and perhaps there are other such services that could be useful - such as say statistical reports).

Indeed - I don't think the temps are anything to complain about (between 20..25 C is pretty much the same range that offices and shopping centres use all around the world).

For a harsh experience try going from the middle of winter in Harbin (close to -30 C overnight) to the middle of summer in Melbourne (close to 40 C in the daytime) in a single day (I have friends that experienced that back in January this year).

I would guess the biggest problem you'd face with such an idea is "just how do you determine that someone has a full node"?

This would not be a trivial thing to do as presumably it would require some sort of separate consensus algorithm (i.e. a "proof of storage" type idea).