Although perhaps a tad long I think the emails nail it pretty well - as a suggestion you might want to put the link for the Wordpress announcement as I think having another company singing the praises of Bitcoin and its benefits will be more convincing.

The main problem with downloading the blockchain is not so much just the speed of the disk but a combination of bandwidth, CPU and I/O (and using a slower CPU such as on a typical laptop it is this that is the bottleneck).

That being said of course an SSD should improve the I/O side significantly.

If project P is given the tx id for each specific contributor C then it shouldn't be very hard to get each contributor to "prove" they own at least one of the input addresses in the tx (by signing with the appropriate private key) and this should be enough to safely decide that they qualify for whatever reward.

If you didn't want P to deal with that then of course you could ask the CFS to confirm this for you (although to be sure you'd probably want to check this yourself).

BTW - CIYAM will soon be launching its open source project which provides a whole new twist on project funding - PM me if you are interested to know about some of the details.

I am pretty sure that tx "updates" will be required whenever a blockchain re-org occurs (which is not uncommon).

Understand that if two new "solved" blocks are broadcast at around the same time then your client will initially decide to use the first block it sees, however, if the next block you see connects to the "other" solution then all the tx's in the block that was first accepted now have to be considered as invalid. It is likely that many of those same tx's will be now included in the new blocks (thus information such as the "hashBlock" would need to be updated).

Okay - think I'm understanding a little better what you are getting at and IMHO describing how a block is "added" to the blockchain is probably actually essential for a developer to understand the safety of the Bitcoin system (if you try to omit how Bitcoin protects against double-spends then you have omitted any chance of them understanding the security).

I don't think that finding a "nonce" that when hashed along with other information provides a value with "x" number of leading zeros is really very difficult to understand although I guess you could use "hashcash" as a simpler implementation of POW (I have some C++ source code for this if interested) that doesn't involve a "chain".

Hmm... still not quite clear as IMHO getting hacked is really nothing to do with your (lack of) understanding about Bitcoin but a general problem with computer security (with the simplest answer to that one probably being - "Use Linux").

I guess multi-sig might be of interest in regarding securing funds although I'm guessing that's probably going to be more technical than what you are wanting to communicate.

Wouldn't it just be simplest to show examples of using the RPC to send bitcoins (if you wanted to also show generating an address first then this would amount to two or maybe three RPC commands)?

I am a little confused as to exactly what kind of developers you are aiming at - ones that will just use bitcoind or ones that are going to write their own alt-chain (from the recent appearance of new alt-coins I think the latter kind of devs need no help at all)?

Yes - any BTC sent to that address can be redeemed by the holder of the private key (which therefore needs to be securely held with as much attention to the security as you care for the BTC it can unlock).


It's not really a password but is simply the "key" that is required in order to create a transaction to send the funds from the public address to another (to do this typically you first would import that private key into a wallet).

Most importantly:

1) If any person or (more likely) any spying software has seen your private key then it is not secure and the funds can be stolen.

2) Print out the private key and lock it in a safe and/or encrypt the private key (with a secure password created by some software such as "lastpass") and keep backups of it.

3) Do not lose the private key or your way of recovering it (be it by paper, password or better still both) as funds *cannot* be recovered otherwise.

Bitcoin addresses have no need to be stored in a database although in order for you to conveniently use Bitcoin the wallet will automatically generate private keys and determine their public key counterpart and from that show you an address that you can use (an online wallet service does the same). Most Bitcoin clients and most online wallet services also allow you to import private keys.

So the key point to understand is that a Bitcoin "address" is mathematically derived from a private key (which in the case of Bitcoin is a 256 bit number) so the only information that you need to keep to construct a "wallet" (assuming your concern is just the funds and not things like address labels) is the private keys (which need to be random numbers with a very high level of entropy).

You might find it helpful to have a play with https://bitaddress.org and click on the "brain wallet" tab - as you will see you can create a valid bitcoin address by supplying a pass phrase (which is then turned into a 256 bit number by using the SHA256 hash of the pass phrase).

There are a few threads that discuss the fact that the chances of two 256 bit random numbers (assuming that it *is* random) being identical is significantly less than getting hit by lightning immediately after winning the lottery via a ticket that was given to you by a stranger you would never have met unless you happened to have a car accident after answering your phone and finding out that the person on the other end was Mick Jagger.

That sounds correct for a "compressed key" (am pretty sure it is output in base58 which is the same set of characters used for the addresses).

You might be interested to have a play with http://brainwallet.org (the page can be saved for offline usage) - even if you aren't wanting to create a "brain wallet" it is quite useful to help visualise the various parts and formats of bitcoin addresses and raw transactions.

Danny was referring to the "private keys" (each being effectively a 256 bit "random" number that is used to derive a single bitcoin address) which are not visible in bitcoin-qt at all.

A private key can be "exported" using "bitcoind" and the RPC command "dumpprivkey" (assuming you have added server=1 into the bitcoin.conf file in order to run bitcoin as a server) although this is perhaps a little more advanced.

At the very least make sure that you have tested "restoring" your wallet from backup to be sure it is okay and maybe as far as keeping something on paper you might want to do this with your password (because if you ever forget it in the future then you will have lost all your bitcoins).

If you delete the wallet.dat in the data directory then next time bitcoin-qt is run it will indeed create a new "empty" wallet and for keeping the blockchain up to date I see no problem with this approach (although I guess if paranoid then you will want to not just delete but "shred" your real wallet on the machine you are doing this with).

As well as the private keys, transactions and address labels the wallet file also keeps a record of the last block that was checked against its owned addresses.

Therefore there should be no problem in swapping back in your "real" wallet when you are wanting to transact (or re-check your balance) although you will need to wait for a little while (depending upon hardware) for all the newer blocks (since the wallet was last used) to be checked for new tx's.

I agree that Bayesian filters have pretty much defeated the spam problem (I only get a few spam emails per week these days when I used to get over 20 per day years ago) so I think the idea of an email "stamp" paid for in BTC (or using hashcash or some other means) is not likely to ever take off.

The idea of paying a "deposit" in order to join and immediately qualify to post in a Forum may be of some benefit - although another approach (which I am thinking I will be using with my software system) is to simply require a GPG encrypted email to be sent (and then a password sent back) in order to "join" (as I really don't think that the spammers are going to go to that much scripting effort just to end up with an account that will be very quickly shut down).

Currently spammers only send so much email because it is so cheap - if a price per email were to be set at even .001 BTC then I'd be very surprised if the amount of spam would not dramatically decrease (as the cost of sending 1,000,000 spam emails would now have had to increase by at least 10,000 USD - still think people would do that?).

In my upcoming software platform the Email package will actually have support for hashcash (not that I really expect anyone to use it - I included it as more of a tip of the hat to one of the origins of Bitcoin than to be anything practical) and using my fairly average powered laptop it generally takes a few seconds to find an SHA1 hash with 20 leading zero bits (which I think was the "difficulty" that they had last suggested when it was active).

I would guess that if the CPU was more like that found in a typical smartphone then the sending of an email would probably have to occur as a "background" task (and would likely result in your phone getting quite warm). I guess that the creators of hashcash may not have foreseen the emergence of smartphones way back then.

I think the whole "impatient" users thing is a problem with the idea of using email "stamps" (which is a term coined for this suggestion in the past) - unless the process is totally automatic then people aren't going to be bothered to use it (regardless of actual costs).

You might want to look into "hashcash" (which is where the whole "proof-of-work" concept in Bitcoin came from).

It doesn't require anyone to spend money but just to solve a "proof-of-work" problem (which spammers won't be able to afford to do when you are talking millions of emails) - unfortunately though the idea (as far as being used by any known email clients) never took off (probably mostly because "bayesian" algos have been so successful in filtering spam).

So if no-one could be bothered with using something would address this problem that was free of charge to use then I think that the chances of making money out it would be rather low.

Once you've done the above the idea is to only use the Watchlist after that (i.e. don't click on "Show new replies to your posts" again).

Yup - that's seems better to me - I've sent a report message to the mods (not sure if that's actually the right protocol though) - hopefully one of them will notice and move this for you (perhaps best to also post a link to this topic in the Whitelist Requests topic).

Good stuff!

I think this has been very well worded - but I would maybe consider removing the "undermine" part (just sticking to the facts and technicalities should be enough).


Cheers,

Ian.

The correct answer to your question is mu (please read G.E.B. to find out exactly what that means - and I hope you enjoy the experience as much as I did as it is IMHO one of the best books ever written).



For the lazy: