I don't think bitoin-qt has such a feature.

Understand that you can use sites like "bitaddress.org" and "brainwallet.org" *offline* (by saving the web page) so if you have an "offline" computer and a USB flash drive that you trust then simply copy the offline "web page" to the USB and use it in the offline computer to create your wallet.

Thanks for the link - don't know how I missed that.

http://blockchain.info/block-index/378457/00000000000001aea0dbcf76505cba633639210ddbcaca13dbac43869e09327d

Check the "hash" on the top right (or just in the URL itself) - as you can see - there is a lot of room left.

In short no - to understand this better you need to try and fathom exactly how big 2^256 is (there are other topics about it if you are keen to search).

If it were *only* the nutters - unfortunately the majority of people are racist and do look for simpler explanations (thus the success of religion and politics).

I haven't detected very much racism (although there is a lot of trolling and attacks on individuals and some groups) but this forum does *pride* itself on *not censoring* (although links to SR apparently are less acceptable than any anti-*insert whatever person/organisation you hate* diatribe).

Unfortunately racism is one thing that *is* pretty much universal (luckily some people at least are educated and/or intelligent enough to be above that).

Assuming that your client is connected to the network then you already *are* part of the network (if you want to help out more then make sure your port is accessible from the outside).

(btw - bumping so quickly after posting is not considered good form - patience is rewarded)

Each confirmation takes 10 minutes (on average) so you should not expect 6 confirmations in much under an hour (and can take a fair bit longer).

Bitcoin uses OpenSSL to do the crypto (and that is in C/C++) - I wouldn't expect you'll find the source code easy to understand though (although being very skilled at C++ the crypto math is not something that I can really grok).

So basically I think what you are saying is that if anyone gets >50% we are screwed no matter what (so therefore why try and mitigate anything) - correct?

(am willing to accept that there may be nothing we can do about it but it of course does leave some concern if we simply have no defense at all)

Thanks for the link - well it does seem that although not so worried about it (as perhaps I am) Gavin has thought that this might be something that should be addressed.

Yeah - I don't think the thread title was really the best way to start any sort of dialog - but at least a few interesting posts have followed.

Actually CIYAM is also a "programming environment" (although you *can* generate web apps easily also) - my point being that the next generation of programming is going to look a lot more like what I've demonstrated (I would also recommend looking at Intentional Software).

I am pretty sure that the future of software is "software manufacturing" (although maybe not my particular way of doing this of course).

Can you create a complex website as easily as this with it: https://ciyam.org/slideshow.html ?

I must admit I hadn't thought about SPV clients although if all headers of all blocks (including those of a fork) were available then couldn't an SPV client also decide to ignore new headers that it decides are too old (i.e. they still have the timestamps for every header they are using don't they)?


Any link to where this has been discussed in depth before (maybe I am not searching on the right thing)?

Your scheme sounds interesting (and is actually better than my idea I must admit) - the automatic convergence is something I don't really see as being a good thing at all (as I stated before if you have been using a fork for 100s or more importantly 1000s of blocks then such convergence whilst able to occur automatically would would not occur without a hell of a lot of complaints).

I would first try starting bitcoin-qt with the "-rescan" option just to see if that helps.

If it doesn't make any difference (and the 0 confirmation tx remains) then you'll probably need to use pywallet (https://bitcointalk.org/index.php?topic=34028.0) to delete that tx from your wallet (after that do another "-rescan" and all should be fine).

Well consider coinbase rewards - you can spend them after a certain number (is it 100 or 120?) more blocks are added to your chain but if you were mining on the losing fork then such blocks are going to be discarded - if you have already *spent* those funds in the meantime then someone is going to be rather unhappy.

If Bitcoin thinks that 100/120 is the *safe* point to allow spending from coinbase then I would be proposing a figure that would be closely related to that (making it no more subjective than the limit already in place).

I understand (and respect) the need to be conservative and I guess in the end maybe it is not much different to having checkpoints every now and again but it just seems that disallowing a new longest chain (due to containing blocks that are too old) would be a more elegant (and automatically ongoing) way to prevent such a major reorg from occurring.

Also if I were (well actually I am) in China and had been running on a separate fork for the last year or so then I don't think I'd want to see my fork merged at all (so it may as well stay forked forever).

In the scenario above the fork has already happened *before* trying to apply my solution (i.e. as soon as the miners became separated you have forked) - but yes with my solution those forks would not be able to be rejoined (I think if they were big enough you'd still have a hell of a mess so the current system doesn't really help that much).