Blink - The most scalable alternative to blockchain - page 3.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 23, 2018, 06:02:20 AM

Quote from: Blinknet on February 22, 2018, 04:52:24 PM

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

The accounts need to wait for the next round, if the transactions are not signed by the lockers they are invalid and won't be accepted by the network.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 04:52:24 PM

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

What happens when lockers aren't available to sign for their allotted accounts?

Say we have 20 transactions from 20 accounts, being allocated to 20 lockers, and 10 of them are offline?

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 03:05:40 PM

Thank you for clarifying. As far as I can see, the first of those proposed solutions will result in a 'no consensus' result in the best case, as the account state will look to both lockers like each of them has the correct spend individually.

The second solution sounds like it will lead to all lockers being forced to sign all transactions as there is no way to tell there is going to be a double spend, so lockers from round A will have to be online to sign round B and so on and so forth.

I'm not sure why you'd think that would happen in the first solution, since the locker of the current round would only consider valid what the locker of the previous round says is the state at the end of the previous round. The locker from the previous round always trumps the one from the current round.

Both current round and previous round lockers signing on transactions would basically be an explicit version of this.

You wouldn't need to extend this to further past rounds, since honest nodes should only re-broadcast/accept transaction from the current round, or from the last x second of the last round. The duration of a round needs to be long enough so that a transaction can be broadcast to the majority of the network.

There's no way to create inconsistent transactions like this, the worst that could happen is that a locker signs a valid transaction that doesn't have time to be broadcast to the network.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 01:49:58 PM

Quote from: monsterer2 on February 22, 2018, 01:05:40 PM

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

Sorry if we may seem dismissive of criticism, especially when we're actually trying to receive feedback.
All the issues you're raising are actually addressed in those 2 paragraphs in the paper though.
There are two possible solutions to mitigate the problem you're raising: either having lockers from consecutive rounds communicate with one another, and do a passing of the account state at the end of the round, with signatures to back it up, or require that each transaction is signed by lockers from the previous round and from the current round. Both of these solutions are presented in the paper, and each of them solves the problem you keep coming to (spamming the network with transactions, until an inconsistency is approved).

I know they're not expanded on, but is it really not clear why this would work? For us it seemed enough at this point.

If you think that anything more needs to be said here, let us know, but please try to at least acknowledge the argument.

Thank you for clarifying. As far as I can see, the first of those proposed solutions will result in a 'no consensus' result in the best case, as the account state will look to both lockers like each of them has the correct spend individually.

The second solution sounds like it will lead to all lockers being forced to sign all transactions as there is no way to tell there is going to be a double spend, so lockers from round A will have to be online to sign round B and so on and so forth.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 01:05:40 PM

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

Sorry if we may seem dismissive of criticism, especially when we're actually trying to receive feedback.
All the issues you're raising are actually addressed in those 2 paragraphs in the paper though.
There are two possible solutions to mitigate the problem you're raising: either having lockers from consecutive rounds communicate with one another, and do a passing of the account state at the end of the round, with signatures to back it up, or require that each transaction is signed by lockers from the previous round and from the current round. Both of these solutions are presented in the paper, and each of them solves the problem you keep coming to (spamming the network with transactions, until an inconsistency is approved).

I know they're not expanded on, but is it really not clear why this would work? For us it seemed enough at this point.

If you think that anything more needs to be said here, let us know, but please try to at least acknowledge the argument.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 11:57:27 AM

Quote from: monsterer2 on February 22, 2018, 11:44:04 AM

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

The claim of 20K TPS is on the global state, not per account. So account consistency is not really an issue for the locker.

We've previously replied about the way lockers from consecutive rounds communicate with each other to ensure account consistency.

You've glossed over it, and the paper doesn't cover it. This is the core of your consensus mechanism. You've asked for feedback on your whitepaper in this thread, I've taken the time to read it, the least you can do is to address the concerns I've raised without glibly just directing me to re-read the paper.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 11:44:04 AM

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

The claim of 20K TPS is on the global state, not per account. So account consistency is not really an issue for the locker.

We've previously replied about the way lockers from consecutive rounds communicate with each other to ensure account consistency.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 11:37:36 AM

Quote from: monsterer2 on February 22, 2018, 11:29:23 AM

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

The lockers are always up to date with the state of the accounts they oversee. When you submit two conflicting transactions, only the first one will be signed by the lockers (the second one will be rejected). Please read the paper again.

How is that possible? With 10000 transactions per second, you can never guarantee consistency like that. 'First' is relative when you're dealing with latency.

According to the paper, lockers are chosen at random anyway, so you've got the potential for different lockers to be signing the same spend in different rounds.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 11:29:23 AM

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

The lockers are always up to date with the state of the accounts they oversee. When you submit two conflicting transactions, only the first one will be signed by the lockers (the second one will be rejected). Please read the paper again.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 07:13:06 AM

Quote from: monsterer2 on February 22, 2018, 07:06:45 AM

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

How exactly do you trick them?

By continually submitting conflicting transactions. Network latency means its very possible that I'll get two locker signatures for the same spend in consecutive rounds. Then I provide the proof, and drain their accounts.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 07:06:45 AM

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

How exactly do you trick them?

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 06:57:11 AM

Transaction fees are not the only reward they get, there is also a certain newly created amount distributed to nodes each round (if they reach consensus).

You cannot drain nodes of their stake because you cannot convince the other nodes to update their ledgers accordingly.

Why cant I? If consensus nodes are tricked into acting badly, the network's decision will be to confiscate their stake, following the rules.

Even if you print coins as the reward for achieving consensus, the reward from stealing stake is still greater than this by necessity, because tricking them has zero cost associated with it.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 06:51:10 AM

I'd argue that it is not in their interests to achieve consensus, as the reward is only transaction fees, which are small compared to the stake you can confiscate from nodes who behave badly.

Thereby, as a rational actor it is in your interest to make nodes behave badly by trying to disrupt the normal consensus, and then provide the proof, draining them of their stake.

Transaction fees are not the only reward they get, there is also a certain newly created amount distributed to nodes each round (if they reach consensus). Perhaps even more important, the nodes have a lot of stake invested, so it's in their own interest to keep the value of the coin up in the real world. Failing to reach consensus on a consistent basis would undermine the trust in the network and make the stake useless even if they keep. Rational actors behave optimal in the long term.

You cannot drain nodes of their stake because you cannot convince the other nodes to update their ledgers accordingly.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 06:39:42 AM

At page 27 of the white paper you can read about the consensus protocol. At page 31 there is a "Commitment" section. Basically, the nodes have X rounds (we didn't agree on the exact value of X yet) to reach consensus. If they don't, no reward is given to them, so it's in their interest to achieve consensus.

I'd argue that it is not in their interests to achieve consensus, as the reward is only transaction fees, which are small compared to the stake you can confiscate from nodes who behave badly.

Thereby, as a rational actor it is in your interest to make nodes behave badly by trying to disrupt the normal consensus, and then provide the proof, draining them of their stake.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: obadia on February 22, 2018, 06:29:01 AM

I do not understand the logic to use the value on a wallet instead of Processing power. The PoW will then be pretty much void of sense, in my opinion and many hacking methods can arise from that..

That's the purpose, to make PoW void of sense, so humanity doesn't use as much electricity as a small/medium size country just to make Bitcoin secure. Of course PoS protocols are much more complex and attention to details is crucial.

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 06:05:28 AM

So, when is a consensus reached? Why can't this go on forever?

At page 27 of the white paper you can read about the consensus protocol. At page 31 there is a "Commitment" section. Basically, the nodes have X rounds (we didn't agree on the exact value of X yet) to reach consensus. If they don't, no reward is given to them, so it's in their interest to achieve consensus.

obadia

jr. member

Activity: 38

Merit: 1

I do not understand the logic to use the value on a wallet instead of Processing power. The PoW will then be pretty much void of sense, in my opinion and many hacking methods can arise from that..

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 06:01:07 AM

But the consensus part is different than the tx broadcasting and lasts for more rounds. Node B can specifically request some account information from node A, e.g. he's behind with the transaction chain for that account, and update its state accordingly.

So, when is a consensus reached? Why can't this go on forever?

Blinknet

newbie

Activity: 37

Merit: 0

Quote from: monsterer2 on February 22, 2018, 05:52:33 AM

With a horizontal consensus like this (as opposed to a vertical chain of consensus, like a PoW chain) it is possible for the consensus to stall completely due to inability to reach an agreement. You've allowed a maximum of two rounds of consensus to occur, so what happens when both of these fail to reach an agreement? Why can't that happen?

The two rounds limit refers to the amount of time nodes accept transactions through broadcasting. So if node A tells node B about a transaction from the past (more than 2 rounds ago), node B will ignore it.

But the consensus part is different than the tx broadcasting and lasts for more rounds. Node B can specifically request some account information from node A, e.g. he's behind with the transaction chain for that account, and update its state accordingly.

monsterer2

full member

Activity: 351

Merit: 134

Quote from: Blinknet on February 22, 2018, 05:44:44 AM

"The protocol assumes the nodes are not necessarily up to date with the state of all the
accounts, but they should be when it comes to those accounts for which they are
supposed to act as lockers. To achieve consistency, the nodes that are lockers for the same
account in consecutive rounds will communicate with each other. The old locker will
pass on the state of the account to the new locker.
Should the network have a low trust in lockers, at the expense of a small increase in
bandwidth and CPU usage, transactions can also be signed by the lockers of the current
round and also by the lockers of the previous round. This would ensure that no
transactions could ever be invalidated when lockers from consecutive rounds are not in
sync"

This part could probably be better emphasized.

That's hardly an analysis. This is core of your consensus protocol, you can't gloss over it with a throwaway paragraph.

With a horizontal consensus like this (as opposed to a vertical chain of consensus, like a PoW chain) it is possible for the consensus to stall completely due to inability to reach an agreement. You've allowed a maximum of two rounds of consensus to occur, so what happens when both of these fail to reach an agreement? Why can't that happen?

Topic: Blink - The most scalable alternative to blockchain - page 3. (Read 1058 times)