[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