Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Review of "Transactions as Proof-of-Stake" whitepaper  (Read 807 times)

0 Members and 1 Guest are viewing this topic.

Offline sugarpuff

  • Newbie
  • *
  • Posts: 2
    • View Profile
Review of "Transactions as Proof-of-Stake" whitepaper
« on: March 12, 2014, 06:59:58 PM »

A few days ago I read through your TPS report (the entire thing), to get a better understanding of your proposal for solving the 51% problem.

What follows is a review of this whitepaper. If the paper is out of date, please direct me to more recent documentation on this topic.

I will be quoting sections from the paper for which I have comments, questions, and at the end will make some general comments about the paper as a whole.

Please note that in spite having read the paper, my understanding of the proposal is not complete (partly due to lack of time on my part, and some lack of clarify on the paper's part). Therefore constructive feedback on this this review would be appreciated.

To the author: please note that I will mostly be including sections that I found objectionable for one reason or another, and therefore this review might seem overly negative. Don't let that be your takeaway impression though, as there are far more sections that I liked than those I did not. For the unquoted material, you can assume approval.

Quote
In order to prevent this kind of behavior we must make it impractical for miners to maintain secret block chains. If every transaction that is broadcast contains the hash of a recent block and the block chain enforces the rule that the transaction’s proof-of-stake can only be credited in block chains that build off of that block then no one will be able to build secret block chains that leverage the coin-days-destroyed of transactions in the public chain.

This seems like a great idea to me. It also sounds like something Bitcoin could probably adopt without too much difficulty, I think.

Quote
For an attacker to perform a brute-force double spend attack they must produce 7 blocks in secret while the rest of the network produces 6 blocks.

Citation required.

Quote
Once the attack was complete, the attacker will have to wait another year before they could reuse their $1.68 million in capital to attempt a second attack.

Meanwhile they just made how much money?

And this can increase their ability to attack the network by potentially how much next time?

Quote
Another factor to Proof-of-Work based security is that for most crypto-currencies the mining rewards fall over time. When this happens the amount spent on securing the network relative to the value of the network falls. For example, assuming no changes in the value of Bitcoin, when the mining reward falls by 50% so does the security of the network. The value of the network must double to $24 billion to maintain the same level of security it has today after the difficulty adjustment.

The last sentence is rather unclear to me. Could you please explain how that conclusion is reached in detail?

Quote
Lastly, if a large double-spend did occur everyone on the network would know and in theory could cooperate to add more proof-of-stake to the weaker chain with your original double-spend.

Unlike Proof-of-Work systems, it is very easy for a few honest nodes belonging to large stake holders to act as guardians of the chain. When they see an attempted double spend attack they can use their own savings to squash the attack in minutes.

Seems like an ugly hack. If all it takes is someone super rich to create a large fork, that's approximately as useful as today's financial system.

Quote
Lastly, given the cost of a double spend attack, the reality that such an attack would significantly reduce the value of the coins, and the difficulty in performing large double spends anonymously it becomes clear that the attacker would lose more value in depreciation of their assets than they would gain if they were successful.

Anyone with that kind of money would not bother attempting a double-spend over anything trivial. Therefore, I submit that for most ordinary transactions a double spend is very unlikely and the losses from such a double spend attempt would be minimal. Furthermore, the attacker could only perform it once per year.

I don't understand how it is costly. What do they lose?

That the attacker could only perform it "once a year" is no consolation, and difficult to believe. Given the consolidation of wealth seen in today's financial system, as well as Bitcoin, it would be easy for the super-rich to perform multiple fork-creating double-spends in a single year.

At this point it looks like the criticism levied against Peercoin at the start of the paper could equally apply to this proposal: "All Peercoin has achieved is to increase the cost of attacking the network without changing means by which the network can be attacked."

We should be shooting for an actual solution that prevents double-spends completely, and not a mitigation that merely limits the actors who can attack the network in this way.

Quote
Unlike Bitcoin where your confirmation time is entirely dependent upon miners finding blocks, someone wishing to accelerate the confirmation time of one transaction can do so by confirming it with some of their own coin-days.

It's not super clear from the paper (to me) how that would work. Detailed explanation needed.

Quote
Offline Transactions would not necessarily have access to the current head of the block chain at the time they are signed. Therefore, they would be unable to verify the current head block at the time they are signed. The only coin-days that count for the purposes of the transaction are those between the output and head block included in the transaction.

I don't understand that last sentence. What does this refer to: "head block included in the transaction"?

Quote
Under our approach, transactions that migrate from a minority fork would not contribute to the coin-days-destroyed. This will insure that chain forks do not require individuals to re-issue transactions.

This paragraph is unclear to me, and a more detailed explanation would be appreciated.

Quote
The next challenge is to decide who gets to broadcast the block when all nodes could generate the new block at the same time. We propose that the owner of the single input that destroys the most coin-days of all transactions in the block is the only one who may broadcast the block. This owner will sign the block header and broadcast the block. If someone else would like to compete to decide the block they must destroy more coin- days which effectively bids up the cost of earning the right to produce the block and in the process increasing the security per block.

When does this bidding war end? How is that decided?

Quote
We suspect that there is ample opportunity for speciality algorithms to be developed that could earn block creators some revenue for securing the network with their stake. These same algorithms would likely also defend the network against double spend attacks when ever they are observed.

And those would be...?

Conclusion

Quote
The techniques presented solve the 51% attack, the selfish-miner attack, and provide protection against double-spending all while requiring no mining at all.

I am not convinced. The only claim I found somewhat believable was that the selfish-mining attack might be prevented because transactions include the hash of the most recent public block. I'm not the authority on that however, Emin would be able to give a more authoritative answer on that.

The 51% attack still appears possible, and the actors capable of pulling it off do not seem to not have fundamentally changed. If blocks are chosen based on the number of coin-days destroyed, then an actor who has a large amount of Bitshares (or w/e the currency is) would be capable of ensuring that their blocks are chosen most of the time. Further, their ability to do this would increase with time, as they would be able to double-send their coins, and prevent others from competing with them through various forms of censorship (not including rival transactions in their blocks, sybil attacks, etc.).

I mostly enjoyed the paper, thanks for writing it. There was, however, something that actually upset me about it, and that was the complete lack of references and citations. That is simply unacceptable for this type of document, and left me with a bad taste unfortunately.

I would be happy to review an updated version of this paper, should one be published (with citations and references).
« Last Edit: March 12, 2014, 07:12:25 PM by sugarpuff »

Offline biophil

  • Hero Member
  • *****
  • Posts: 814
  • Incentives run the world
    • View Profile
    • Sign up for a Bitshares account!
  • BTS: zebulon
Re: Review of "Transactions as Proof-of-Stake" whitepaper
« Reply #1 on: March 12, 2014, 08:31:41 PM »
I mostly enjoyed the paper, thanks for writing it. There was, however, something that actually upset me about it, and that was the complete lack of references and citations. That is simply unacceptable for this type of document, and left me with a bad taste unfortunately.

 +5% I agree. I understand that development is probably a higher priority than formal documentation of the ideas, but before too long (probably not before BitShares XT launches, of course) this document should be updated and significantly formalized to include a good set of citations.

Offline Stan

  • Hero Member
  • *****
  • Posts: 2865
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BTS: Stan
Re: Review of "Transactions as Proof-of-Stake" whitepaper
« Reply #2 on: March 12, 2014, 10:14:21 PM »
I mostly enjoyed the paper, thanks for writing it. There was, however, something that actually upset me about it, and that was the complete lack of references and citations. That is simply unacceptable for this type of document, and left me with a bad taste unfortunately.

 +5% I agree. I understand that development is probably a higher priority than formal documentation of the ideas, but before too long (probably not before BitShares XT launches, of course) this document should be updated and significantly formalized to include a good set of citations.

Sounds like a good opportunity for someone with that skill set to make those upgrades, add their name as an author, and become an instant international celebrity!

We need to keep bytemaster locked up in his laboratory in the Castle East doing nothing but those things that only he can do.

« Last Edit: March 12, 2014, 10:25:04 PM by Stan »
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline sugarpuff

  • Newbie
  • *
  • Posts: 2
    • View Profile
Re: Review of "Transactions as Proof-of-Stake" whitepaper
« Reply #3 on: March 24, 2014, 01:53:44 AM »
The thread linked to below includes some discussion that touches on some of the points brought up in this review, but unfortunately it appears to lack much consensus. I found myself agreeing with most of the posts that were made by Agent86:

You can mine BTS with TaPOS... miners of the world rejoice!

(When will I be able to post without having to figure out that blasted picture captcha? I can barely make it out.)

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12339
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BTS: xeroc
  • GitHub: xeroc
Re: Review of "Transactions as Proof-of-Stake" whitepaper
« Reply #4 on: March 24, 2014, 07:38:19 AM »
A little Off topic: I can offer my experiences in LaTeX to generate a professional looking paper. The advantages with LaTeX are that you can host it in github and let others contribute.

I could also create a template for the newsletters and other sheets .. if interested.

Just send my a PM, i will also subscribe to this thread
Give BitShares a try! Use the http://testnet.bitshares.eu provided by http://bitshares.eu powered by ChainSquad GmbH

 

Google+