Sounds good, maybe you can give it a try. Enough Reddit gamble for me today. =)

This is just in r/Bitcoin though... preaching to the choir there. =) I think we should go for r/technology which is - if I remember correctly - also in the set of reddits that appear on the reddit.com frontpage, so if we make it there we have a chance of reaching the frontpage. Here is an attempt at a submission:

http://www.reddit.com/r/technology/comments/g9lnw/what_is_bitcoin_professional_animated_video/

Edit: I didn't remember correctly, r/technology is not part of the Reddit frontpage. Well, still a fitting and large reddit to post it in. Maybe r/videos would be a place to post it to reach the frontpage? Let's see how it is doing in r/technology.

Edit2: I deleted my submission again, I felt it wasn't going to well. Anyone else feel free to give it a try, if you like.

Very nicely done video, indeed. It's great to see this kind of quality work around the Bitcoin community.

That said, I will be pessimistic here and predict that this video will not go viral. Because it fails - in my opinion - to communicate the most important characteristic: that Bitcoin is a decentralized system. Sure, it's mentioned in the beginning, but that's more or less it. I mean, who is the target audience here? I think it's mostly early-adopter geeks. Average Joe won't trust his money to the Bitcoin system before all his friends do. So as a early-adopter geek I naturally want to understand how this thing works. And all I hear is "Bitcoins are created at a limited rate" (I'm thinking: if it's decentralized, how can that possibly be enforced) then later I hear "a transaction is verified by a miner" (I'm thinking: how is it verified? if anyone can be a miner, what is that verification worth? why does it even need to be verified? [having just heard of the system, I will probably not immediately think of the problem of double-spending]).

So in effect the video just claims in a number of pretty pictures that Bitcoin "is changing finance" and I'm left wondering: how does it work? Then I have to read the white paper or what? I'm sorry, this is the age of ADHD - I'm watching the video, because I don't want to read some technical paper.

I'm realizing that all this is very, very hard to communicate, so I can totally understand why they went for a more "simplified" route. I also don't really have a better way of explaining it in a short amount of time. But I think it's necessary for a video to go viral. It's the difference between "aha, ok, nice claims" and "wow, this is a brilliant concept, I need to forward this to my friends".

But I hope I can be proven wrong by having this video hit Reddit, Digg & Slashdot soon. ;-)

I agree, it's very difficult to distribute fair in a decentralized manner. Maybe even impossible (?). Because even that crazy toe system doesn't actual solve it, does it? How do you make sure that a person who finds a block actually holds such an auction? They could just make up a new private key - claim it came from one of those toe DNA machines you are describing - and transfer the money there. Essential you would need to be able to verify for every coin that a unique toe cutting event happened for it - even with that video you were mentioning it would probably not be feasible to make sure that it is actually a new video instead of just a slightly modified copy of one of the millions of videos already recorded.

To distribute fair you need to be able to establish unique identities. I would think there are just two ways of doing that: Have a central registry (think government issued id cards) or have a web-of-trust. So maybe the Ripple system is a better fit for those people who want their "fair share".

But really, I find this whole complain that the distribution of Bitcoins is not fair pretty ridiculous. It's simply first-come-first-serve, a principle which is in effect in many places without people complaining. Do these critics also come to a concert late, and then complain how all the best spots are already taking and the whole concert is just sooo unfair?

This website has snapshots of old Reddit frontpages: http://redditsnapshot.sweyla.com/ .

Great, yet another centralized solution. With the corresponding drawbacks: If that mining cartel verifies that it has received a transaction, then it must consider it valid and will work on including it in a block. But maybe it only includes transactions with a certain minimum transaction fee. So I guess you have to pay the fee, if you want fast transaction... you want to opt out? too bad, all the merchants now only accept fast-lane-bitcoin-transactions because it's more convenient.

Competition drives down prices, but a verification service of this type requires you or your cartel to control 50% or more of the computing power. So naturally there can't be a competitor with lower prices. I'm not sure I like this outlook.

For bitcoinmonitor.com I also run bitcoind directly. I'm using a VPS from prmgr.com. Currently I'm on their 256 MiB offer - as Gavin said, the daemon doesn't need many resources.

But I think you listed pretty much all the possible options. And you are right that for your typical PHP-only webhosting the options are a little limited right now. But options 2) and 3) are probably your best bet there. For mybitcoin.com you write that you have to "install/compile/run something". I haven't used the API myself, but I looked briefly at it and I think you are overestimating the amount of "installing" involved there. It is basically just some code that goes on and does that 'constructing/posting a URL' that you mentioned. If you really wanted to, you could probably construct those HTTP requests yourself, but then you would just reimplemented what the API package already provides. So if you are saying that their API gives you everything you need, then I would suggest to have a closer look at it again.

Interesting in many ways. In principle they are just a competitor to PayPal & Co., but try to obfuscate that with their image-of-a-real-bill gimmick to make it seem has it is somehow a new idea. And that might actually pay of - perception is everything. Competitive pricing helps as well: No transactions fees; only fees on withdraw and possible when buying WingCash. And ties to the social networks - a must have these days, isn't it? =)

They will have a rough start though, coming late to the game and now having to build a network of exchanges and getting businesses to accept it. We'll see if they can do that. Wouldn't be the worst thing if they succeeded, because WingCash to Bitcoin should be much easier to do, seeing as WingCash has no chargebacks. :-)

The Bitcoin Monitor now switched to a logarithmic scale, which is definitely better suited. A bug in the graph library I am using didn't allow me to switch sooner, but that is fixed now. In the meantime more market data has been added as well. Now the markets Mt. Gox, Bitcoin Central, BTCex.com and Bitcoin Market are tracked.

In the last days I haven been looking into the option of using a mobile payment processor like Zong, where people could pay with their mobile phone. It seemed like a good fit, because mobile phones are actually used a lot to buy various forms of (centralized) virtual currencies - like Facebook Credit for example.

I was in touch with somebody from Zong, but it didn't go anywhere. He immediately said it would be a problem that you can exchange Bitcoins back for USD and that the carriers would not like that. Apparently it needs to be a closed system where you can only pour money in and then have to spend it on things.

Maybe I'll go and talk to some other payment processors in the mobile space, but I guess I won't have much luck there either.

Even more monitoring sites compiled here: http://bitcoin.witcoin.com/p/75/bitcoin-monitoring-sites---lets-compile-a-list :-)

One way would be to resize the partition before cloning. I like this live CD for system tasks: http://www.sysresccd.org/ . Boot from SystemRescueCd, start GParted and resize the partition to something small. Then clone the disc the way casascius mentioned above. The cloning will probably throw an error at some point about running out of space, but it doesn't matter as long as the complete partition has been copied.

That website claims 66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC46 is the hash version.
What exactly is being calculated there? I wrote my own decode58 code and I get this value:
1B66FF9F63ACE537B537BE1F7F0CB585649C226C72EEFF43D59FAC4677BE50CA

Represented in binary the blockexplorer hex is only 215 bit, whereas my hex is 253 bit. Add another 3 leading zeroes and you get 256 bit.

Here is the Haskell code I used to decode the string:


import Maybe

decode :: [Char] -> [(Char, Integer)] -> Integer
decode s mapping = worker (reverse s) mapping bases
    where
    bases = iterate (58 *) 1
    worker :: [Char] -> [(Char, Integer)] -> [Integer] -> Integer
    worker [] _ _ = 0
    worker (c:cs) mapping (b:bs) =
        (fromJust (lookup c mapping)) * b + (worker cs mapping bs)

main = do
    let chars = "123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz"
    let mapping = zip chars [0..]
    print $ decode "2qy6pGXd5yCo9qy3vxnN7rALgsXXcdboReZ9NZx5aExy" mapping

I currently live in Denmark and my understanding is, that electricity prices are actually sometimes negative here (!). That's because Denmark has a lot of wind energy and at peak times they just don't know where to dump all that energy. Well, I guess you have to be some sort of high-volume costumer to get these rates and can't just get them as an individual. But with renewable energy sources becoming more and more widespread, that will probably change pretty soon as well. Since it will actually be pretty important for the stability of the energy grid that individuals start to adjust their usage to the amount of energy available. I guess mining is a perfect fit here: "Oh, let me take all that excess energy of your hands... I can turn it into money!". :-)

The client code was a little bit wasteful in how many old data points it would keep in memory. I just deployed a new version which should free memory somewhat more aggressive. Hopefully this helps!

Many important discussions in this thread. :-) Some more thoughts:


What you are proposing is definitely a nice way of using Bitcoin's feature of additional constraints for transactions, I like it. But your suggestion really just boils down to depositing money somewhere. Either at the grocery store itself or a third party, mybitcoin-like service. And the whole (trust) problem with depositing money has been pointed out before.

I find it worth repeating though ( :-P ): I'm still not convinced that a mybitcoin-like payment processor is something to look forward to. I agree that having it backed by Bitcoins and being easy to audit is a step in the right direction, but that only solves some of the problems with today's central payment processors. You just have to look at the current situation: Even if PayPal was backed by Bitcoins (in theory not too far-fetched), it could still shut down accounts at random and be a headache to deal with. And to those who argue that there could be several mybitcoin-like services which interact with each other: There is also no reason why Google-Checkout couldn't also accept Amazon Payments and then just transfer any outstanding differences directly between Google and Amazon. Doesn't happen though. As soon as a payment processor is big enough, it rather tries to compete than to cooperate.


I have been thinking the same thing, that 10 minutes maybe really is just too much on the conservative side. I mean in terms of money flow the current situation could be kept (seems to work fine right now, so no reason to change it). But instead of 50 BTC per block, there could be 5 BTC per block and then a block every minute. It would allow for a more fine-grained decision on how many confirmations one need. If you want the old level of security you would then just have to wait for 60 blocks.

I guess the block rate has been discussed before frequently and there are many good arguments for the different sides. What this really makes me wonder: Is there even a chance of this ever changing? How would it change? Someone with access to the official repository committing it and releasing it? and would that result in an immediate fork from people who think it's a stupid idea? I wonder if Bitcoin needs some sort of democratic organ to make a decision like that.

Maybe another example of why a node should be suspicious of blocks that contain transactions it hasn't seen before. I thought joe had a good suggestion in this regard:


This sounds like an interesting idea to me. It would change the rule 'nodes work on the longest chain' to 'nodes work on the longest chain which doesn't include transactions they consider invalid' (with the important exception mentioned by joe that a chain that is 6 blocks longer can convince the node that the transactions are in fact valid).

What are possible problems with this? I guess it would make the network vulnerable to an attack which slows down block creation: Different parts of the network could be fed conflicting transactions and the block chain would then start to split up as nodes only work on what they consider the valid transactions. This would continue for a while as now 6 blocks are needed to break the tie and a single part of the network needs to produce all of them. Pretty big vulnerability I guess - any way around this?

[Edit: Didn't mean to ignore Hal's response, only saw it after posting]

I can also move my gold around today. But my salary is paid in a currency that isn't backed and so is everyone's salary around me, so the gold doesn't really help in preventing a crash.

I guess Nefario has a good point about audits being easier with Bitcoins and that is definitely and advantage compared to gold. But it also requires a bunch of people to be vigilant and to understand all the pitfalls of money systems. I'd much rather see these protections against money creation baked into the system that will actually be in use by everyone.

Thx for your input! A few comments and questions (sorry, long post):


Aw, I see, I wasn't aware of that. Is there a reason why they don't relay those transactions? Would it hurt if they did? (provided that they make sure to first relay valid transactions). It seems this way it's indeed fairly likely to not see a bad transaction until it is in a block.

In the case where nodes don't relay bad transactions, it would actually hurt to sent the transaction out, as it creates a sort of 'wall' just around you and you are fairly likely to not notice anything else. So I guess it would be better then to not send out anything and instead only listen. And even when you receive the transaction, you don't send it out, but wait until _all_ of the nodes you are connected to have relayed the transaction. If - after some time - some of your neighbor nodes haven't done so, you can deduce from that, that they must have heard a conflicting transaction first and are therefore not forwarding the other one. Doesn't help you with Hal's attack though.


Ok, yes. But when the attacker doesn't have much CPU power he needs to rely on other nodes to include the bad transaction. The more nodes that will be working on that, the better the chances. So in that sense the race across the network is off some importance as it will make it more likely that the transaction wins, which the attacker would like to win.


I don't find this the "best way" at all. How is this different from a world where everyone has gold, but to allow for fast, instantaneous payments you allow some payment processor - let's call them a bank - to move numbers in their system around instead? And then at some point the whole "gold-backed" thing is conveniently forgotten.

Isn't the whole point of Bitcoin that you can move the _actual_ Bitcoins around. If you are going to give that up, what have you won?


Ok, that sounds like a pretty realistic attack scenario that isn't too difficult to pull off. So anything that can be done about that without waiting around for 10+ minutes? Maybe something with timestamps? My understanding is that blocks are timestamped and there are some checks regarding the timestamps (https://en.bitcoin.it/wiki/Block_timestamp). However pretty wide time periods seem to be valid. In a world with with high-speed networks, couldn't that be made a little tighter? So that a 'precomputed' block would quickly become invalid?

One way I look at the Bitcoin network is this: A bunch of nodes want to establish a 'shared reality'. This 'shared reality' says who has how many bitcoins. They find that consensus by - in a way - voting and the more CPU power a node has, the more votes it has. If you look at it from this way, shouldn't there be more mechanisms to ensure that every node knows what is being voted about right now? I know this is hard in a best-effort network with nodes constantly joining and leaving, but might have a lot of potential. I think nodes shouldn't so readily accept a shared reality which contains decisions (transactions) that they haven't even seen before and thus weren't able to vote on.

Scenario: You, as a merchant, would like to allow for quick payment with Bitcoins - for example at a supermarket - and therefore can't wait around for one or several confirmation blocks. Instead, you receive the transaction, broadcast it to nodes you know and wait for a couple of seconds to see if you notice any double-spend attempts. If not, you accept the payment right away.

I know that this scenario has been discussed already to some extend in the snack machine thread (http://bitcointalk.org/index.php?topic=423.msg3647#msg3647) but it went a little off-topic there I thought, with people suggesting central or semi-central solutions to accomplish this. Central solutions are what we have today, they are not the answer. Whatever is needed to do fast transaction confirmation will need to be decentral.

In any case, I would like to hear your thoughts and attack scenarios on the procedure outlined above. How high is the risk of accepting transactions in this way? My assumption is, that the attacker does not have more than 50% of the CPU power of the network available to him, but might be able to control a large number of IP addresses.

Once the transaction is broadcasted to all nodes, they will start working on including it in the next block. The attacker can not outpace that (see assumption) so his only chance is to get his double-spend transaction to spread through the network faster and thus have more nodes working on including his second transaction. In that case though, I - as the merchant - will also receive the second transaction in a matter of seconds and notice the double-spend attempt. So I can only think of one attack scenario: The attacker controls a large number of IP addresses and - after waiting for a while - hopes that I am only connected to nodes controlled by the attacker. The attacker is now free to selectively forward transactions from the rest of the network to me and thus be able to prevent me from seeing the double-spend transaction too early.

Is this really the only attack scenario? Am I missing other risks that I would expose myself too?