lappa

A smart contract is a contract that can be executed with the trust parameters you set, these parameters are less limited than typical contracts have since they don't have an inherent necessity to trust a government or even a counterparty.

Some contracts don't require anyone's trust. The most basic "smart contract" is a Bitcoin payment, the contract says "pay this to anyone who can produce a signature corresponding to the public key I have hashed in this contract"[1].

The less used smart contract involving cryptography can be "pay this amount to anyone who can find any sha256 collision"[2], or "flip a trustless N-sided coin and pay someone based on the outcome"[3], or in the future we could play more complex games and trustlessly pay the winner as long as we can create a trustless proof that the winner is in fact the winner.

There are also possible smart contracts that may allow individuals to move their money to another system, be they trustless like a sidechain or lightning hub, or trusty like Open Transactions, which has federated trust between a set of individuals.

Another form of trusty transaction is multisig escrow, where you can have individuals vote on who gets the money. Unlike giving an intermediary money they can run off with, you give an intermediary or set of intermediaries a vote on where the money ends up[4]. With multisig combined with nlocktime you can have money spendable by you if you verify your identity (usually through email) to an authority. If the authority refuses to let you spend, then you can get your funds back when your nlocktime transaction expires. They cannot spend your money though[5].

In short, when you have programmable money you can create a smart contract that allows funds to be redeemed by getting information from trusted external sources or internal trustless cryptography.

[1] https://en.bitcoin.it/wiki/Script#Standard_Transaction_to_Bi...

[2] http://lists.randombit.net/pipermail/cryptography/2013-Septe...

[3] http://arxiv.org/pdf/1402.3698v1.pdf

[4] https://en.bitcoin.it/wiki/Contract#Trust_minimization:_mult...

[5] https://en.bitcoin.it/wiki/GreenAddress

Surely they verify the PoW, otherwise it would be trivial to create a long chain and attack them.

>Of course consensus is, by definition, whatever the majority is doing. So now it's a battle of dev's trying to cajole enough hashpower into enforcing the rule, or somehow backing off the change. With every new block mined on each head, there's more money at stake for which way the decision ultimately falls. For Bitcoin to survive, "There Can Be Only One".

Consensus is what everyone is doing. That is why the terminology used here would be "split consensus". The purpose of the devs trying to get the hash power back into the correct blockchain is so consensus can be re-established.

Leap hours are probably acceptable, but at the point that you're only deviating by an hour every few millenia, can't it be safely accepted that the time has a different meaning and between generations it be accepted that 8PM means night time in the summer rather than 9PM? I doubt that we will even be using the same system by then anyways.

>It's pretty standardized, especially compared to the mess that is daylight savings time, where changes can be announced only a few days in advanced (e.g., Egypt) and possibly even retroactively.

It clearly isn't since the original post highlights three different ways people adjust the time making all these organizations lack consensus on the time.

>How is that different from what's being done now? There is a standardized way of determining when leap seconds are going to happen (they always happen on June 30th or December 31st when the deviation reaches about 0.6s)

It's different because you don't have to keep track of what an authority is saying or deal with the actual time adjustment except once in a century. Once in a century is acceptable since we will only deviate by around a minute at our current rate.

As long as we have a standardized way of determining when leap seconds are going to happen, some authority determining and announcing, there shouldn't be problem. Leap years are predictable, but leap seconds can be accounted for a decade after an event disrupts the pattern.

Also, given all that variance and the fact that we only seem to be shifting around 1 minute per century at the current rate, we probably could get by having a leap minute every few decades when necessary.

This works fine for any system trying to interact with other computers and humans while keeping consensus on the time. Any system that is trying to determine earths yaw would no longer be able to rely on F(time), but that is only a minor inconvenience.

This seems to be something that would benefit from standardization and modularity...

Pausing for a second, going back a second in time or changing how long a second is all are hacks that are bound to cause some edge case failure somewhere. I'd like to see a minute have a 60th second just as February has a 29th day.

You can cite industry improvements in the manufacturing process that companies say will effect the price at a certain point along with scientific developments and in general claims made by actual corporations.

I'm not sure I agree with the placement of debt. It is often the case that you can you off the debt, but the money invested properly could increase faster than the debt increases.

$10k+ isn't "only" $10k.

You check 3 characters, not 1, but like I said, 80^3 still isn't good.

They may be storing the three characters as a hash separately, not that that is much better.

It seems that people lost because they were either speculating blindly or had an algorithm that was working poorly. I don't see reason for these algorithms to be outlawed.

I've explained stake grinding attacks. Your response was redefining the system opening a new attack vector.

Yeah, these work great out of consensus systems. Please consider that you're working on a consensus system though.

"Simultaneous" has no meaning. There are no means of instant communication, there is latency. There also is no proof of time without a consensus system.

So what is the proof that I committed my 0 or 1 value before they revealed? Well you could trust a central authority to maintain that timestamping, or you could even use Bitcoin for your timestamping. In fact, your PoS system could probably work if it piggy backed on Bitcoin completely.

If that's too abstract for you, consider that I say I'm ready to commit, everyone sends me their commits, I construct a block with all their commits and a ton of other possible commits and then once I have created a seed that allows me to win and control the network permenantly.

Yes, it is pointless for me to argue about an undefined system. If you mean to say that 67% of the validator set must sign every block, then you shouldn't argue with the premise that 100% must sign every block.

>all validators must sign every block.

Well now you're defining a new system. You can't expect me to explain the security of an undefined system, so I am sticking to the system defined in your paper which states that not all validators need to sign every block.

>seed(block) = hash(seed(block.parent) + block.proposer.address) No grind capabilities at all. No matter how many times you try, you will always generate the exact same result. The randomness basically comes from absentee proposers, so the only way to influence the outcome (not proposing) is costly as you sacrifice your reward and all other influence over the block beyond signing / not signing it.

That is trivially grindable. If the seed is your address then you create an additional address such that the next winning address is yours.

>Sure, the addresses for the validators should be reused. The more it's used the better.

That's not at all what I said, but this is besides the point.

>t's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin.

And you whitepaper allows for block creation with absent validators which makes it trivial because you have total control over the seed determining the next set of valdators. Even if you changed that, it would be trivial because you would only need to have last input into the seed one time to grind and generate a signature such that you are the exclusive validator.

You continue to assert the attack isn't feasible, but you aren't actually paying attention to what the reason I have told you twice now.

"It's not [feasible] for a traitor to pretend to be all the generals <no explanation>, say there are [arbitrary example]. Given this configuration it's infeasible for the attack to be performed <no explanation>. <Repetition of facts that are part of the reason stake grinding works including it's determininsticness>."

If you aren't aware of what stake grinding allows, it is an attack where you calculate the deterministic results of many many signatures (seeds) and finds signatures that result in you winning, allowing you to perform the attack once again.

>Depends on the application and the purpose of the blockchain, but the paper isn't explicitly premoting address reuse.

It defines a system in which addresses are reused.

>Users don't consider blocks committed until they've seen +2/3 of commit signatures, so a fork implies that the victim has evidence of double-signing.

No it doesn't, unless you have a severe misunderstanding of information theory and think everyone know all information everywhere (including attacking forks not published). Your security assumption shouldn't be that the attacker is dumb enough to announce that he's attacking and giving up his money by broadcasting forks.

>Not sure what you mean -- Maybe an analogy will clarify. Is this a problem that isn't present in Bitcoin? How can a brand new Bitcoin user securely join the network for the first time?

It worries me that you can't answer this and you're working on a cryptocurrency. They can achieve consensus because they can be supplied a proof by any of their peers of the transaction-output database. Not allowing reorgs allows a peer to give you a proof that prevents you from achieving consensus.

>For example, if my phone wallet hasn't synced with the network in a while (longer than the unbonding period) then it should warn me the next time I connect, and perhaps ask me to validate a fingerprint of the blockchain via outside channels.

The purpose of a blockchain is to achieve consensus without trusting anyone. If you trust that group, you probably would get along just as well with them managing a centralized database of transactions for you.

>I'm aware of how checkpoints prevent reorgs in other protocols like PeerCoin. That's not how Tendermint works.

I never mentioned checkpoints. The paper basically said it wouldn't allow large reorgs when it said it could prevent long range attacks and ignore the fork.

>Stakegrinding is less of an issue in Tendermint because of the deterministic round-robin algo for choosing the proposer, and the fact that the remaining validators need to commit.

The entire reason stake grinding is possible is because the selection of the next blocks winner is deterministic. The previous winners can change the seed over and over again until they win.

>and the fact that the remaining validators need to commit.

This is not relevant, you can wait until the end or ignore theri validations completely.

>Check out the DLR algorithm first, "Consensus in the Presence of Partial Synchrony (1988)"

This paper is fine, but it assumes 1/3 generals aren't traitors. Your system makes it trivial for a traitor to pretend to be all of the generals.

>I agree with you that the random number generator in tendermint isn't good enough. I am going to add one I have put in a different cryptocurrency before. Each validator gives the hash of a secret, and later gives their secret. All the secrets are XORed to find the random seed.

Tendermint doesn't have a random number generator at all. You cannot have consensus on random numbers, or else they wouldn't be random. It is a fundamental problem that you are determining the next blocks winner based on numbers that can be influenced by previous winners.

Critique follows

>They propose a modification to the Bitcoin protocol such that it can tolerate colluding groups that control up to 1/4 of the mining power – less than the previously assumed bound of 1/2 of Byzantine mining power which requires an honest mining majority that follows the prescribed protocol.

Selfish mining is tolerable but unideal. It is a bit misleading to claim that 25% block withholding attacks are as critical as 51% attacks.

>Users keep an account in the system, where the user’s account is identified by the user’s public key or address.

Promoting address reuse isn't a good idea.

>When a validator signs duplicitously, a short evidence transaction can be generated by anyone with the two conflicting commit-vote signatures

The assumption that an attacker will tell you he is attacking isn't a very strong one.

>A user can avoid long-range attacks by syncing their blockchain periodically within the bounds of the unbonding period.

This security assumption means means that no one can safely join the network and perform an initial sync. It isn't explained how they prevent long range attacks, but it can be assumed that they do it through disallowing reorgs.

Disallowing reorgs allows another consensus breaking attack. The entire purpose of reorgs is to maintain consensus, so if an attacker can create a blockchain of length bond-period, they can trick you so you don't achieve consensus with the "main" blockchain.

Another thing that is worrying about this whole idea is that 2/3 of validators must come to consensus on what block to use. If you choose a block and broadcast your signature, you cannot sign again. So how do the validators solve the Byzantine Generals Problem? How do they determine which block they will sign? They could go with the first block they see, but that leaves you open to sybil attackers running many nodes and sending validators different blocks in order to trick them into splitting their vote. These are the fundamental problems that consensus systems are meant to solve, consensus systems shouldn't have to have a 2nd consensus system to support itself.

>There are three types of votes: a prevote, a precommit and a commit

It seems the paper is attempting to solve the previously mentioned problem, however the most fundamental explanation for the problem with this is explained by Byzantine Generals Problem. The problem essentially involves you sending a message of "I'm ready to attack" back and forth, but because you cannot know they received the message, you cannot attack. If they reply with a "okay, we got the message" message, they don't know that you received the message, so they don't know whether to attack. Whether there is 1 back and forth, 3 as in a "prevote to attack", a "precommit to attack" and a "commit to attack", or 100 back and forths, you aren't achieving consensus, you're skirting the issue.

The next few sections explain the mechanism, but not how it actually solves Byzantine Generals Problem. with additonal assumptions based on things that require consensus including "If there are less than 1/3 in Byzantine voting power and at least one good validator decides on a block B, then no good validator will decide on any block other than B"

>Each round has a designated proposer chosen in round-robin fashion such that validators are chosen with frequency in proportion to their voting power

If the pseudo-random seed for the next round validators is information that can be decided by "previous" (or not so previous) validators, a validator can choose themselves. With a high number of validators, it may take a few thousand blocks for, say, a 3% stakeholder to randomly be selected for a sufficient number of votes to choose the next seed, but once they have ground[1] their first block and made themselves a majority of validators, they can repeat over and over and control the blockchain.

> Say that some good validators locked on block B and round R, and some good validators locked on block B0 at round R0, where R < R0. In this case the proof-of-lock from R0 included in a proposal by a good validator will eventually unlock those validators locked on R allowing the consensus process to continue.

This "solution" helps prevent 33% deadlocks, I agree, however now you can seed your stakegrinding attack with an incredibly small validator/voter %. Depending on the parameters of the system, you may only need to become a validator once to control the entire blockchain forever.

The system of voters has somewhat obscured it, but stake grinding[1] is still a major problem, in fact, it is probably the simplest and cheapest attack vector on the system defined in this paper.

In conclusion, this system has severe sybil problems, consensus problems, centralizations problems (in that one person could control the entire blockchain cheaply), structure problems (address reuse) and usability/security assumption problems (no one can safely sync with the network after the first bonding period is up?).

[1]Stake grinding is the process of changing data in a block to create a large number of new seeds (sometimes billions or trillions) until the seed designates you as the "winner", or in this case majority of validators.

My post wasn't an ad hominem. You don't know what ad hominem means. And no, it isn't just me, I can see there are many others you add to "your list" and incorrectly call out as being fallacious.

Once again, here is your (incorrect) logical fallacy naming game.

That isn't a refutation of the paper, it is a proposal for an unworkable idea along with mumbo jumbo (weak subjectivity) justifying adding centralized mechanism.

The fundamental reason his punitive system doesn't work is because of the nothing at stake problem. More specifically, in this case he assumes that he can punish people making forks, but you cannot punish people who are no longer part of the system (or have anonymized and separated themselves from their funds) nor can you punish someone who makes a fork and attempts to attack, but is unsuccessful and doesn't broadcast.

Once again, this isn't a refutation. A refutation would involve going through the logic of the nothing-at-stake paper and saying why it is wrong.

Bitcoin wallets can have their source code audited. A blockchain that you accept regardless of the fact that there is a taller one is not audited by definition.

>Ah I see, you consider the current PoS systems that rely on getting the initial state for a new client from some trusted source to be "centralized".

No, that component is just broken. If anyone trusted is a bad actor and gives you a bad blockchain, you are not in consensus, thus any system using this cannot be considered a consensus system. The centralization I was referring to was other mechanisms commonly employed by PoS systems.

>Though you'd probably argue there's no debate, because someone disagreeing with your position isn't a "real researcher".

No, someone not doing real research isn't a real researcher. Someone who understands consensus and security (not Vitelik) and creates a paper describing a system and its security model clearly is a real researcher.

It isn't my fault that that hasn't happened yet.

>The paper you referenced from early 2014 isn't really considered very relevant anymore

It is relevant and discusses fundamental problems with PoS, it is a very strongly reasoned paper and there hasn't been anything reasonable countering it so far.

It isn't considered relevant to scamcoiners, of course, since their goal isn't making a secure cryptocurrency, rather transferring money from a fools hand to theirs.

>t's kind of hard to have an argument of this subject with you, given that you seem to be complaining about PoS when ethereum 1.0 will be a 100% PoW system

So because I complain about PoS, I cannot argue that software is broken for any other reason? I don't have a specific complaint, they have such a complicated system that I have a myriad of complaints including Ethereums multiple consensus implementations, ASIC resistance, incredibly small block times, using insecure crypto in their illegal IPO, their system being basically useless, etc.

>The PoW guys will keep complaining that the PoS systems "aren't secure enough" and the PoS guys will happily use them anyway.

Since "PoS guys" appear to be fine with centralization and the obvious harmed security from that, they probably will be happy with other forms of broken security.

>Clearly I'm a PoS fan and don't think that'll happen.

There is basically no debate among cryptocurrency researchers that PoS doesn't work, it is mostly promoted among noobies and scammers. You can be a "fan" of it all you want, but it isn't like being a fan of Republicans or a fan of C++, it's like being a fan of md4 for cryptography.

>The concerning part of Vitalik's posts is that right now they build unproven ideas on top of other unproven ideas

Not only are they unproven, but there are mounds of evidence that it isn't possible.

>it seems kind of unfair for knocking a guy though for trying to analyze them anyway.

I'm knocking him because he is dangerously misinformed and is implementing and promoting broken cryptographic systems.

>However, in 2015, with the launch of Ethereum 1.0 and other competing systems, we'll get a lot more hard data than ever to find out which of these kinds of ideas are good- Both because these systems themselves test these ideas, and because they allow ideas like this to be built on top of them.

We already have seen that amateur cryptographers cannot make their unworkable ideas workable. You don't need another broken altcoin (Ethereum) to know this, you need to understand what the blockchain accomplishes to know this. I'm sure once Ethereum fails there will be a new next big thing and people will get sucked into another broken system, but you can actually understand what is a good idea if you try to understand the blockchain. You don't need to cross items from the near-infinite list of possible bad ideas to know what's a bad idea.

I'm not sure what you mean by "Ideas like this to be built on top of them." If you already have Ethereums PoW consensus system, what the hell would having a PoS consensus system on top of that accomplish?

>but they are not "fractal" and we will know in the near future with empirical data which ones need to be tossed away.

They are certainly fractal. One could recursively say why each of those fixes have problems, and eventually you would end up with a fully centralized system that masquerades itself as being decentralized and PoS or a completely broken system that is attackable for near-free.

Vitaliks games aren't amusing. A blockchain has fundamental limitations that prevent PoS from working, namely it must be costly to make a fork[1]. Complexity is the enemy of security.

Bitcoin solved the consensus problem with it's relatively simple incentive scheme. This post starts off by proposing a flawed system, making slight changes to the flawed system (punish attackers, trust someone when downloading the chain, assume economic incentives will cause people to update their software after an attack, etc) and recursively point out ways to "fix" those problems while at the same time either introducing more subproblems or more centralization.

This is similar to what is being done with Ethereum. Instead of one clear problem, there are many small unclear problems caused by trying to fix problems caused by a fix of a fix of a fix of the fundamental problem.

In short, this is Vitaliks Fractal.

[1] https://download.wpsoftware.net/bitcoin/pos.pdf