[Cryptography] Securing cryptocurrencies

Natanael natanael.l at gmail.com
Fri Mar 13 05:39:36 EDT 2015

Den 13 mar 2015 05:45 skrev "Ray Dillinger" <bear at sonic.net>:

> I have dreamed up a potentially workable protocol variation
> which hybridizes proof-of-work with proof-of-stake, addressing
> some of these problems.   It uses transactions as proof-of-
> stake, but addresses the replay attack by having each transaction
> 'stake' a recent block in the block chain it is contributing
> security to.  Transactions are not valid in any block chains
> in which the staked block does not appear. Thus, an attacker
> cannot replay transactions that staked a block he wants to
> disappear in a reorganization, into the same chain he intends
> to replace it with.  The 'stake' of a  block chain branch (ie,
> the sum total of txouts that existed before the fork and are
> used in tx that are staked in a block after the fork) are
> used for choosing between branches in a proof-of-stake
> determination.
> The downside of this, of course, is that now staked transactions
> are annihilated by any chain reorganization that occurs before
> their staked block.  But it should be very hard to achieve such
> a reorganization without relying on the replay attack to get
> stake support from other users' transactions and also unable
> to manipulate the 'stake' generated by your own spends by spending
> them earlier or later or more times in one branch vs. another.
> This makes it impossible to prepare a *long* attack chain in
> secret - everybody else will be staking all transactions in
> the chain they can see, so unless you have a substantial
> fraction of the money, your would-be attack chain will have
> stake that's pathetic by comparison to the total volume
> everybody else is doing.
> But it's not so good for preventing *short* reorgs, because
> spending is, in the very short term, a lot more bursty and
> occasional than the constant, steady effort of hashing which
> remains nearly constant at the miner's capacity.  As a
> result, using spends to determine branch priority is very
> sensitive to the exact timing of large spends.  When combined
> with the possibility of annihilating staked transactions by
> removing the staked block in a reorg, this opens the field
> to a class of short-term timing attacks that are better
> prevented by proof-of-work systems.
> So this type of proof-of-stake protocol could work at large
> scale (where the law of large numbers smooths out the volume
> of transactions or the rate of flow of money to something
> steadier) but in smaller scales would have to be part of a
> hybrid protocol with proof-of-work.

This is typically called TAPOS. Already thought of. One of the problems is
that nothing stops you from chaining many unconfirmed transactions in the
same block to inflate stake. There's also the problem that you can more
easily disrupt the network by pumping out forks, getting other users to
reference different conflicting forks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20150313/52e10ac5/attachment.html>

More information about the cryptography mailing list