Only click once. House edge is as high as 25% if you click on all 14.

Thoughts on this? Now I think this is quite a good model.. You can't 51% this coin no matter how much hashpower you have, and coin generation uses PoW.

I guess we could gear mining towards "high end" CPUs, but that just leaves people with older computers out of mining.

If we go with what I proposed (coin generation is PoW, but blocks are purely minted through PoS), then botnets will not be able to 51%.

2.4% house edge for first click
4% house edge for second click
6.3% house edge for third click
7.8% house edge for fourth click
9.9% house edge for fifth click
25% (yes 25%) house edge for 14th click

Really..

Had a nice streak of luck. Thanks SatoshiCircle! Interested in hearing about the rewards program too.

How about offering your skills in the services section of this forum?

Bitcoin isn't something that you can learn in a few hours. Practically all of the mainstream media has "explained" bitcoin wrong, and this post is aimed at providing a somewhat technical read of how bitcoin works under the hood. So, let's get started!

Transaction
At it's core, Bitcoin is about transactions. Transactions simply send bitcoins from inputs to outputs. What are inputs and outputs? Let's say I have 5 bitcoins. I send 4 BTC to an address, 1GLadosEkeAsLReqS3yQ51E1R3wVtbJCDF.

There is one input. It's the transaction ID of my 5 BTC, along with a signature. The signature is like a passphrase - only the person who knows the private key (password, generated and stored automatically in your wallet) to an address can spend it. It works because the bitcoin software verifies that the signature is valid before accepting a transaction, otherwise it goes straight to /dev/null.

There's two outputs. A 4 BTC output to the 1GLados [..] address I sent to. The second output is 0.9995 BTC, to another address I just newly generated - a change address. Inputs can be only fully spent, so if I want to spend 4 BTC, I will have to spend my full 5 BTC and send the rest back to me.

What about the 0.0005 BTC? The difference between input and output sum is the transaction fee. In this case, the 0.0005 BTC goes to the miner who minted this block.

The transaction ID? It is a hash of the entire transaction. Hashes are a one way cryptography function - they're effectively a random mapping function. Two different transactions will never have the same transaction ID - really.

What are inputs? They're former outputs! If I want to spend all of the 0.9995 BTC I have left, then my input would be the transaction ID of my first transaction, plus the output ID 2. (In this case, ID 1 is my 4 BTC to 1Glados, ID 2 is my change).

So an input is sent to an output which is then later referred to as the input when you want to spend the coins.

Blocks
Blocks are simply a list of transactions. Miners run programs that tries to create blocks. They listen to the network, put the new transactions they heard about, and if they have a fee they're happy with, include it in the block they are working on. Now, to successfully mine a block, the hash (remember, hashes are basically random and unpredictable) of the block needs to start with a number of zeroes. Like this: 0000000000efc2r [..]. So a miner just repeatably tries to make a block with a hash that starts with a lot of zeroes.

How many zeroes? That is determined by the difficulty. The difficulty is automatically determined, and it's how fast the last 2016 blocks where mined. The difficulty makes sure that there's on average, a block every 10 minutes - regardless of how many people are mining for stability reasons. As hashing / mining for blocks is just luck, sometimes there might be four blocks in a minute, sometimes there might be no blocks for a hour.

When a transaction is included in a block, it gets 1 confirmations. The miner also gets a block subsidy to reward them (and distribute the remaining bitcoins), currently 25 BTC which halves every four years until it gets to zero. After a block is minted and announced to the network, miners will now try to build blocks off that block - referring to the previous block. This is how the blockchain works.

[Block 22730] -> [Block 22731] -> [Block 22732] [ORPHANED BLOCK]
...............\-> [Block 22731] -> [Block 22732] -> [Block 22733] [LONGEST CHAIN]

Huh? Let's say the latest block generated is 22730. We know it, not because it has an ID, but because it refers to a previous block (22729) which refers to a previous block which refers to a previous block... and if you go all the way back - you count 22731 blocks. That's how blocks are given numbers.

Now, the latest block generated is 22730. A miner generates 22731, with the 25 BTC subsidy going to them and transactions they heard about. Another miner also generates a block referring to 22730 as it's parent, with their own subsidy address and their own transactions they know. So now we have two blocks at height 22731. The blockchain now has a fork.

Some clients heard about the first block, while some clients heard about the second block. Now, a portion of miners are building upon the first block 22731, while the other portion is building upon (referring to) the second block 22731. A transaction included in the 'first 22731' isn't included in the other block. Some clients now see that transaction with 1 confirmation, while others see it as unconfirmed (0 confirmations).

Soon, a miner generated block 22732 with it's parent being the first block! The transaction included in that earlier block now has 2 confirmations to some users and services. Now, since this blockchain is longer (22732 > 22731), clients will now update their latest block to 22732. However - just then, another miner had some good luck and generated blocks 22732 (referring to the second block) and 22733 in less than a second. Clients see that 22733 > 22732, and moves to the second blockchain. That now becomes the main blockchain, with the first being orphaned.

So what happens? That transaction included in one block but not another? 2 confirmations to 0 (unconfirmed). Now, assume the person sending the TX is malicious, and has got a double spend (spend the same inputs, to a different output controlled by the attacker) into the second block which is now the main chain. Services or users who accepted the "2 confirmations" transaction.. just lost those coins. This is the danger with accepting transactions with few confirmations.

Generally speaking, it's safe to accept TXes with at least 6 confirmations. Of course, if you know someone personally or if it's from a reputable service, then you can accept it even when it's unconfirmed.

Done, thanks

Also, to someone else, screenshots are not OK because of how easy it is to inspect element it. In addition, obvious photoshops of a text inserted onto a scanned paper is not going to pass.

Regarding the new design: I suggest making the background gradient attached. Doesn't really good in it's current implementation.

Same fees on BF's top tier through. (0.25% every trade versus 0.5% when you sell only on BF). But that's a bit offtopic

Please do this. I'd love to see it happen.

When are withdraws processed?

Update:

I've "bailed out" btcinvest with 170 of my ASICMINER shares, which brings the NAV back up to a little over 0.1 after the Ian Bakewell default.

The structure of btcinvest has also being changed a little - please see the asset description on BitFunder. Basically, no more fixed value of 0.1 btc / bond, it will be offered at the current NAV, and we'll maintain bidwalls at 95% of NAV with profits of the spread going to the company.

Like always, a report will be published every 2 weeks (next one is in a few days). In addition, not 100% of earnings is going to get paid out as dividends.

You selling or buying?

Don't support a scammer?

Nope, missed the last part heh. Thanks Logik.

1Q8ywBC1Hz2HfNwbApjv4u8kpiC4R7o24H

Thanks

Bump, so far it's quite even..

The idea right now is to have a github and people who are interested in helping out can contribute a pull request or so.