[Cryptography] What has Bitcoin achieved?
L. M. Goodman
lmgoodman at hushmail.com
Tue Jun 24 20:04:29 EDT 2014
On 6/24/2014 at 7:13 PM, "Bear" <bear at sonic.net> wrote:
>
>TAPOS? <quick duckduckgo search> Transactions as Proof of
>Stake....
>Okay. Cool name. Hmm, I wonder which of us thought of it first.
>Could be they got it from my first article on Bitcointalk.
The white paper for TAPOS is from 11/28/2013 for what it's worth
>The attack you describe works if the attacker waits for a fork,
>then spends txout A for (say) 100 coins, in one branch of the fork
>and spends txout B for (say) 10000 coins in the other branch,
>which if accepted will 'unspend' his 100-coin transaction.
Yep
>OTOH, the prospect of discounting large transactions, even a
>little bit, to attempt to correct that problem would open up
>new avenues of attack exploiting the "correction."
Alas
>The alternative is to make sure that transactions turn the money
>over with high frequency, assuring very large transaction volume
>per block. One could structure proof-of-stake incentives so they
>work hardest when turning the entire money supply over every 24
>hours, and in that case the attacker would have to do something
>pretty amazing to overcome the volume.
The proposal in the white paper is to have "guardians" of the chain who hold large stakes (in coin-age terms) and are ready to spend it on the original chain should they detect a double spending attack. This could be automated in the clients... if you see a reorg happening, automatically start making transactions on the real branch.
>> In general, unless the weight of each block is bounded and the
>average block has a weight close to that bound, you're subject to
>this type of attacks.
>I don't buy that as a solution;
I'm not suggesting it as a fix to TAPOS, it's just a property you need to avoid this type of attack. It's a property that Bitcoin verifies for instance.
More information about the cryptography
mailing list