Blocks are anonymous.  How do you propose to figure out the distribution of hashing power?

Just because you keep saying something doesn't make it a fact.

Actually, yes, I did.  I'll repeat it here for you now.  Listing a few of your invalid assumptions is the polite way to say that your arguments are stupid.



A lock, sure.  But bitcoin is not a lock.  The metaphor is not the reality, it is an imaginary construct.   In reality, security is not provided by the block reward.  Security is provided by the network forcing an attacker to accumulate over 15 trillion hashes per second of computing power, and this is for a trivial attack of no consequence.  A meaningful attack would require several times that, and we can trivially extend the margin from a multiplier to an exponent if we ever want to.  The block reward provides an incentive, only.


This analysis is still based on a ton of assumptions.  Some of these assumptions have been shown to be false, and the rest are at best unproven


I never said that it was inequitable, I said that it was stupid.  Stake is meaningless.  Proving it is doubly meaningless.  Basing a system on a meaningless expression of meaninglessness is stupid.

A Howard Johnson hotel accepts bitcoins?  That was the biggest surprise in the article for me.  Anyone find a reference for it?

You didn't read his post.  You are still thinking in terms of what mining does for you.  Read it again.


Your personal decision to mine or to not mine is of no consequence to anyone but you.

Your assumptions are invalid.  I'm not talking about your stated assumptions, but your unstated ones.

First invalid unstated assumption:  The ratio of block reward to total BTC supply is meaningful.  You actually do state this assumption, but you do it in a way that makes it look like an established fact, and not the baseless assumption that it is.  Rather than give it a cute and emotionally charged name like security, I prefer to name this ratio cerulean.  Do you have any reasons to believe that anyone should care about this ratio?

Second invalid unstated assumption:  The current value of cerulean, or security as you may still prefer to call it, is the correct value, even though this value is an accident of time.  If you had written this post a day earlier, or even 10 minutes, or for that matter 10 minutes later, the value of the ratio would be different.  Not by much, if the interval is small, but by a lot if we get into months.  What was special about yesterday that make that day's value correct?  How did bitcoin even get this far, since a month ago, the ratio was different by 3%, and a whopping 38% a year ago?

Third invalid unstated assumption:  Bitcoin needs to be the best store of value, or the best medium of transaction.  This is a false dichotomy.  There are other things it can do, and even if it were only used for those two things, it wouldn't need to be the best at either of them to be successful.

I would keep going, but in your second scenario, your thoughts get very non-linear, and I can no longer follow you.  In particular, your sentence "This doesn't sound sound [sic] like much until you think about how much BTC will be worth under this scenario." could be replaced, with no loss of clarity, by "This doesn't sound like much until you think about a unicorn appearing right in front of you.".  I think that we are supposed to assume that the name of the unicorn value of bitcoins is so horrible, in some way, that you can't even speak of it.

Here are some things you should think about.

1)  Bitcoin does not need to replace VISA.  VISA does things that bitcoin cannot do, such as providing a way to roll back a transaction.  In a bitcoin future, VISA will still exist, and still do the same things it does today, just with one more currency.

2)  Even at $4.00, a bitcoin transaction is still far cheaper than several entire classes of financial transfers, like bank wire transfers.  These types of transfers currently do happen today in the real world, even though they cost at least an order of magnitude more than $4.00.

3)  Transaction fees do not cause security any more than ATM fees do.  People with an interest in the security of the system will continue to work on the chain, to at least some extent, even if the reward is zero.

4)  Proof-of-stake is still stupid.  I'm sorry that there is no nice way to say that.  I think that you start to go off the rails when you think of proof-of-work, which is also pretty stupid when looked at in positive terms.  If you think that proof-of-work as something that the network should reward you for, then nothing else in the system makes any sense.  What you need to do is think in terms of proving that someone else has to do an infeasible amount of work to roll back the clock.  We don't care about anything else, really.

The wiki page isn't very good.  Actually, were I in a less charitable mood, I'd say it sucks donkey balls. Took me several reads to "get" it, and that was only because I've read the forums extensively and was able to put the pieces together.

Summary:

Basically, they hide the namecoin block hash in the coinbase transaction of the bitcoin block, and if a hash is found for the bitcoin header that meets the namecoin difficulty standard, the namecoin chain can use the entire bitcoin header to extend the namecoin chain, even if the bitcoin difficulty target was not met.  It does not extend the header size, but it does extend the coinbase script field, which isn't a very big deal because it wasn't a fixed size to begin with.

This is just a restatement of the notion of supply and demand.  We pretty much accept it as an axiom that prices will go higher, lower or sideways if supply is increased, decreased, or maintained, when demand is held constant.

Your real argument seems to be that some portion of the people selling bitcoins are doing so in error.  They would be better off, in your opinion, if they would only stop doing things than they think are right, in their opinion.

Be careful when thinking that you can make decisions better for everyone else than they can for themselves.  There are horrible things lurking down that road.


Liquids don't really compress.  The pressure would be infinite unless the tank burst, and you don't need a pint for that, even just a drop will do.  Pedantic, I know, but this post got me in the mood.

I can see one flaw.  It is pointless.

I know you aren't looking for more ad hominem arguments, so I won't say that the whole proof-of-stake concept is stupid, but I will say that you are suggesting massive changes, making the system vastly more complicated than it is already, and threatening pretty much all of the key features that everyone (nearly everyone) likes about the current system.

And for essentially no real gain that I can see.  The only gain I can see is to you personally.  Not that I think you stand to profit from the new system necessarily, but personally in the sense that you seem to have a subjective preference for this convoluted and ridiculous system over the simple one that we already have.  And I mean ridiculous as a mere statement of fact that it has been ridiculed, not as a value judgment.

Hmm.  And I was thinking that this was going to be an off-topic bitcoin cheerleading thread.

You can't echo $DISPLAY from a SSH session, you have to do it from inside the GUI.

You can try setting your DISPLAY environment variable.  You can check it by starting a terminal in the GUI and running
My scripts write it into a file for use in non-GUI stuff.

Yeah, don't use base_convert().  Big red warning on the man page.

Try hex2bin() instead.

I stand corrected.  SSL implementations that ignore all the SHOULDs and warnings in that section do actually have the option to use their private keys directly.

Reference?

Already answered in the post just above yours.

But only if the minority block is transmitted within seconds of the majority block.  In your system, the reversal can happen several minutes later, and it can cause a reorg of not just 95% of the network, but 100% (minus the attacker's mining node).

No, it isn't.  In SSL, the client encrypts the premaster secret (a number used to derive the symmetric session key) using the server's public key.  The server decrypts it using the private key.  At no time does the server ever emit anything directly derived from its private key.

SSL uses symmetric encryption for the payload.  PKC is only used to securely exchange that session key, and the entire exchange protocol was designed to protect the server's private key from re-use.

Like the signature?  Are you going to quibble that the ECDSA step isn't technically an encryption because it can't be reversed?

How about this then: In SSL, the server's private key is not used for encryption, nor for hashing, nor for any other operation, cryptographic or otherwise, of anything that is released to any other party.