Okay, Gavin was helpful and explained it precisely.

The problem occurs when someone attempts to use his stake to generate blocks in more than one version of the blockchain. 

With proof-of-work, you are required to use a resource (kilowatt-hours) that cannot be used to extend more than one chain.  With proof-of-stake, your stake exists in both chains, and on the assumption that whichever chain isn't eventually given consensus simply "doesn't exist" there's no remaining evidence that you were trying to cheat. 

I think that this can be addressed.  But clearly it cannot be done on the basis of "orphaned blocks/chains simply don't become part of the shared history."  Orphaned blocks/chains need a way to be sucked back into the main chain, at least insofar as they represent sets of transactions not conflicting with one another.

But coinbase and other chain-specific transactions are by definition going to conflict, so the merge can never be total.  I will have to think about it a bit.

Okay, I may be dense here, but I'm not seeing what there is about a Proof-of-stake system that makes this attack any easier. 

I don't want to launch a crapcoin that dies to a protocol disaster in the first few days, so I really do need to know exactly what threat I'm defending against here. 

The whole point of a double spend attack is reusing coins (reusing stake).  There's no penalty for making the attempt in Bitcoin nor any other Proof-of-Work chain. 

And the way I've outlined it above, there is no need for anyone to even have all the claimed transactions in a block to reject it if it's bogus, so there's no way to attack bandwidth.  All you have to do is check the coin address that the payout would go to, the hash of the last block, and the claimed nonce.  Make a single hash, see that it doesn't meet the target or match the claimed hash, and reject the block.   In fact, the signers can reject invalid blocks more cheaply than the attacker can create them (because the attacker is also constrained by bandwidth). 

So .... just not seeing a DoS problem here that's worse than with any other coin.

So there are vague notions that it is unsafe but nobody has a specific reason why?

The initial distribution is the biggest problem, I think. The thing about a proof of stake system is that until someone has coin, nobody can get coin.   It operates more like interest than pay for work.

I do not really have a solution for that.  But rich get richer really is how the world works.

Anyway I'm open to all the suggestions people come up with, but most of the obvious ideas fail in the presence of sybil attacks. All that it has to be is  verifiable via software and not farmable. And there is nothing that requires that there be only one giveaway.

PeterSiddle98 posted the following for '8836' and right over a signature ad for an online casino. 



sniff sniff.  I smell a spambot.  If you're googling for images using a number, but you can't be assed to actually look at the images to see whether they contain the number or not, you're probably not human.

Anyway, here's 8871:

I want to make an altcoin that runs on pure proof-of-stake.  That is, with no significant "speed contest" for solving hashes or scrypt. 

The desired result I have in mind is that each public key representing more than one coin that's been held more than a month is eligible to mine, where each attempt at mining has a chance of success proportional to the product of

The amount of coin that the key represents
The amount of time (in seconds) since the most recent block was found.

The mechanism for doing this would be that you multiply these things together, then multiply by the current 'difficulty', and that's your target.  And this means you have to find a positive nonce less than the target which, when concatenated with the coin key and the signature on the most recent block, hashes to a value with some (fixed) small number of leading zeros.  The 'difficulty' would be adjusted periodically to keep the rate of block generation consistent, but depending on the amount of coin that a key represents, you would have an opportunity to mine on that key (ie, a new nonce becomes acceptable for that key) once per hour or minute or second or whatever that the system goes without finding a block. 

Anyway, if you mine successfully, you then need to collect some (four? six?) signatures from coin addresses that depend on the hash you found, so you don't get to pick people you're colluding with.  Each 'signer' would be signing to the effect that yes, it is after the time when the nonce would become valid, and no, no other block with a lower nonce has been seen yet at the current block height. The signers would get a small share of the block reward.  Any two blocks at the same height would be decided in favor of whichever hashed using the lower nonce. 

There would be a series of giveaways to put coins out there in the universe to bootstrap the process; one thing I'm thinking of would be to pick a date in the bitcoin blockchain, then give people a fixed amount of time (maybe six months) to prove they owned a certain amount of bitcoin on that date and collect a proportional amount of the new coins.  (no, there is no need to send any bitcoin anywhere, no need for an "exit address", no need to pollute the bitcoin blockchain with tiny transactions to prove ownership of the coins they come from, etc.  Just demonstrate that you can decrypt a message encrypted with the key that represents that bitcoin, and that is enough.)   

Does anyone see an obvious problem that will result in such an altcoin becoming unusable? 

Authentication that is based solely on secrets which can be compromised is better than you can otherwise do with strangers.  But it is still subject to eavesdropping by anyone else who shares that secret. 

Using DH over a channel secured only by a cert key means that an MITM in possession of that cert key can impersonate each side to the other, negotiating (separate) DH keys with each side.  Then he can see any message someone sends, modify it if he wants to, and send it on.  IOW, in the presence of a leaked cert, it does not secure the channel from a MITM attack.  It secures the channel from passive eavesdroppers, even those who have a copy of the cert; but anyone capable of a MITM attack is not inconvenienced by it in the slightest. 

Securing the channel using DH over interlock guarantees that even if more than one person has that cert key, your conversation will *not* be with more than one person.  IE no one can eavesdrop or selectively modify messages; any interference by an MITM has to take the form of all-or-nothing impersonation with no "help" or ability to pass your requests for information on to your intended correspondent and see the results. 

Authentication is a separate problem.  Using the cert key to authenticate and doing DH via Interlock is unconditionally better than just using the cert to authenticate.  Although any MITM who has the cert key can still impersonate the intended correspondent, he cannot eavesdrop on a conversation between you and your correspondent nor modify your communications with your correspondent.  That is a guarantee that is strictly better than you can do by using the cert key alone to secure the channel. 

A cert key, although not trust-free, is the best you can do for authentication, but a cert key alone only secures the channel from active attackers or passive eavesdroppers who don't have the key; DH over a channel secured with a cert key additionally secures the channel against passive eavesdroppers who do have the key.  DH over interlock on a channel secured with a cert key additionally prevents eavesdropping or modification of messages in flight by active attackers who have the cert key.

When dealing with a centralized authority, you have to deal with the threat model that says centralized authority has been compromised.  I recommend a protocol that gives you more guarantees in the presence of a compromised central authority than you could otherwise have.

I'm the "proposer" and I know exactly what the interlock protocol does.  It flatly prevents a MITM from altering your communications with someone else while allowing you to communicate at all.  That is what I said, and that is what it does.

The MITM has to make an immediate choice when faced with Diffie-Hellman over Interlock Protocol.  He can either try to impersonate one or both sides of the conversation completely (refusing to allow you to communicate at all) or he can allow you to communicate, whereby he immediately loses the ability to eavesdrop on or interfere with your communication at all except by cutting it off.

Good protocol for secured channels works like this: 

1) All Protocol negotiation via Interlock protocol to ensure that you are talking to exactly one endpoint  (which may be an MITM, but if so will definitely *not* be communications from your intended endpoint as altered by an MITM).

2) Diffie-Hellman Key exchange via Interlock Protocol to establish a private key (thereby cutting out potential eavesdroppers).

3) Authentication via shared secret to make sure that the endpoint you are talking to is in fact the endpoint you want to be talking to, ie, not the MITM. 

Protocol security (steps one and two) secures the channel.  Authentication (step 3) is not addressed by securing the channel; it is addressed by a shared secret.  It might also be addressed by 509 certificates to the extent that people trust them. 

What I said about SSL is that we ought not rely solely on the keys in those certs for securing the channel.  SSL is a hybrid monster that conflates securing the channel with authentication, and they are two separate jobs. 

SSL, trusted third parties and all, is a better method than any zero-trust protocol for authentication between strangers.   Knowledge of the private key corresponding to the public key in an SSL certificate is not quite as good as a shared secret due to CA trust issues, but by definition you can't have a shared secret with a stranger, and it's a pretty good proxy for knowledge of a shared secret.  We can use it for that, and I'll have no objections.

But using SSL to secure the channel (ie, trusting the keys in those certs _and_nothing_else_ to prevent eavesdropping or alteration of messages in flight) is a method inferior to zero-trust protocols, and I *will* be upset if using SSL authentication reduces us to using SSL to secure the channel.

It's far simpler, if you want to motivate whomever finds the block to acknowledge the rewards due earlier miners, to simply award tx processing fees on all the 'mining reward' transactions in the block.   I mean, on the same basis as any other transaction, the 'mining reward' transactions would occupy space in the blockchain, and therefore should require tx fees proportional to the space they occupy.  Seriously, as I described it, their reward for finding the 'block' isn't in any way diminished by the rewards due people for finding 'near-misses', so why wouldn't they?

The thing that becomes probabilistic is the number of coins awarded per block.  But this is regulated, as always, by adjusting difficulty targets as needed. 

Gweedo, I think you're being rude.

Until you're willing to put up time and effort developing code, don't harsh on someone who does.

That said, I don't think Bitcoin needs SSL for any security purpose, and should not rely on it for any security purpose.  If we need it at all, it's for purposes of making it easy for websites to accept bitcoin payments using a system they already know how to use and already have set up.  But I don't see how we can do that unless the communications are otherwise unsecured (ie, insecure), so I don't really think it's a good idea.

Short answer; I don't think you'll be able to order things directly from Amazon.com using Bitcoin until this is done.  But if we have it at all, I don't think you'll be able to order things from Amazon.com with any security greater than it provides now.  And, in fact, even less, because if you use it with a bank, credit card, etc, you can always reverse bogus charges.  With Bitcoin that isn't, and won't, be possible.  

Because Bitcoin has a higher security requirement in the first case, due to its non-repudiability, I don't think that SSL is adequate to secure Bitcoin payments.  It's okay for payments you can challenge or reverse, but it's not okay for Bitcoin.  The right answer is that Amazon.com and company need to man up and accept some genuinely secure protocols to process payments.

Bear

There, that's a dozen with no trains or lego.  Now you can go back to those and it won't feel weird.

Multiple rewards do not necessarily imply reducing the variance in an unfair way.

For example, you could simply maintain two different targets; one is good enough to get a reward, and another good enough to end the round and start a new block.  It would be simple enough to have a rule that the reward target is always ten times the block target, thus on average you'd have ten rewards (including the one that hit the block target) per block.  Same logic applies if you have a hundred rewards instead of ten.

The bigger miners enjoy rewards (at a lower variance) still exactly proportional to the number of hashes they turn in, not greater.  The round ending target is completely unaffected, and someone else still has the same chance of getting it even if the bigger miners turn in all of the other reward blocks that round.

It is also possible to use an SSL channel at the lowest level but then layer protocol security on top of it, so that even someone with the SSL keys and a priveleged position on the backbone still won't have an opportunity to eavesdrop or modify messages.   

This buys you everything SSL buys you (linkable identities / CA-level authentication) and yet, can still be a secure protocol even if SSL is compromised (in which case SSL wouldn't buy you anything, so no loss).  Also, protocol security can be used over TCP/IP or even UDP, without loss of anything else.  Note that UDP is enabled by default because any protocol that detects and corrects for MITM message modifications will also detect and correct for line noise; we don't actually need the TCP layer, let alone the SSL layer built on top of it, unless we want linkability to SSL-authenticated identities.

You'd need to ignore all the insecure payment processing crap and protocols that have been built up assuming that SSL is itself a secure channel, and build better ones.  No security model works if the assumptions it's built on aren't true.  But now that we know what we know about SSL, EVERYBODY needs better protocols to use over those channels, not just Bitcoin users.