[Whitepaper] Incorrect claims around BitShares

Hello there,
I recently went through the cosmos whitepaper and am quite impressed by your work. Adding collateral to block producers is a great idea to keep them honest. This is certainly an improvement over DPOS as used in BitShares. However, I would like to request correction of the nothing-at-stake problem you claim exists in BitShares, because it does not. Here is why:

The Nothing At Stake problem assumes certain properties of POS based upon the Peercoin design.
It is impossible for DPOS to produce an alternative longer chain without collusion of 51% of the delegates.  With 51% collusion you are back to the 51% attack that all systems are subject to.
In this case the delegates also have something at stake:  their job.
So how has DPOS changed the game?

"Miners" are now generally public, known individuals rather than anonymous individuals.
Secret attacks are no longer possible
Alternative chains are not possible
In the time it takes Bitcoin to generate 1 confirmation (10 mins on average) dozens of witnesses would have confirmed a block in BitShares/DPOS already

Some more details
Thus, the claims in the whitepaper:

By using and improving upon proven BFT algorithms developed at MIT in 1988 [20], the Tendermint team was the first to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by first-generation proof-of-stake cryptocurrencies such as NXT and BitShares.

and

Though BitShares achieves high performance (100k tx/s, 1s latency) in ideal conditions, it is subject to double spend attacks by malicious witnesses which fork the blockchain without suffering an explicit economic punishment -- it suffers from the "nothing-at-stake" problem.

... are inaccurate. Besides that, you correctly noticed that forks are restricted to a certain maximum length by means of TaPOS (Transactions as proof of stake) by referring to the blockhash in each transactions.
Furthermore, there has been made a rather easy change that affects the whole discussion immensely and should maybe added to cosmo/tendermint aswell and that is irreversible block. Basically, once 2/3 (66%) -- or 75% if you want -- of the block producers have signed a block (by adding a block ontop of a particular fork) then the block is called irreversible. The software cannot revert/reorg the blockchain beyond this point. This makes an irreversible block become a checkpoint (in terms of bitcoin). If you compare pow with dpos, then you see that while bitcoin's pow generates 1 confirmation after 10 minutes (on avg.) which makes a reorg unlikely after 6 confirmations (60minutes), BitShares' DPOS makes a reorg impossible after ~60 seconds (30 witnesses, 2/3 makes it 20 witnesses, 3 seconds per block). A "fork" can thus be at most 60 seconds old. A double spend is only possible within these 60 seconds then. We have a similar recommendation to the "wait for 6 confirmations" on bitcoin which goes like this: "Use the irreversible head block to be on the safe side".
(Also, it is the committee that can change blockchain parameters, not the delegates.)
While I understand that you paper wants to highlight the improvements of cosmos/tendermint over existing blockchain technologies, I would kindly request to consider correcting the whitepaper for the sake of correctness.
Kind regards and thanks for reading my issue
-- Fabian

"In this case the delegates also have something at stake: their job."
A job isn't very tangible and says little about what is at stake. Did they pay $10,000 for that job and now will lose the money they put in due nefarious activity? That seems to be an important part of having something at stake...

xeroc the white paper I am composing now will refute you. I can't make the entire white paper open source right now, and I don't have time to figure out which portions I could extract to make public now to try to convince you. Instead I will endeavor to make my project open source asap. Apology.

@tomtruitt
Witnesses will lose their position as well as accompanied income (block validation reward) and never get voted back again. They also put much efforts to become witness sometimes financially as well, which become their reputation in the community.

When the Tendermint whitepaper was out, in early 2014 it described how to incorporate a classical BFT algo into a blockchain to ensure that validators can come to agreement about the next block, safely with tolerance for up to 1/3 of Byzantine nodes, prior to signing commit votes that finalized the block.  To become a validator, nodes have to post significant collateral, and there would be an unbonding period prior to the tokens being transferrable.  The solution split the problem into short range and long range problems and provided a solution for the first, and a way to circumvent the second.
While Tendermint was published, Bitshares DPOS had no BFT algo nor unbonding period.  The only thing at stake, as you said, was the job of the 101 chosen delegates, which you could get by paying a small application fee, and getting voted by the token holders.  The problem with such a scheme is that general users of a platform don't have much information to go by in voting for or against candidates, and in fact I recall that quite a few of the chosen delegates were chosen by virtue of advertising some incentive for users to vote for them.  Users didn't have much at stake either, regardless of who they vote for.  And as I just mentioned, the application fee to become a candidate was low, only to prevent spam.  So, strictly speaking, nothing much was at stake.
The second paragraph you quoted was referring to the graphene system.  You mentioned something about irreversible blocks, I'd like to see a reference to a spec for that, if it applies to graphene.
Every block in Tendermint is final.  We can get finality on the order of 1 second, depending on the number of validators.  Each validator can have huge collateral behind it, and it does not get punished for as long as it follows the rules of the protocol.  You can't get these properties without building around a solid BFT algorithm that can provide you with absolute fork accountability.
If you want to protest, please first post a link to a proof of safety and liveness, and the minimal conditions in which a fork or halt would happen.  And finally, a proof of fork accountability, so proof that you can determine who are responsible for a fork or halt condition.

@xeroc I'd like to help find language for the white paper that you think is more appropriate. I don't fully understand your critiques, but it seems like

there is some disagreement on what should count as a solution to the "nothing at stake" problem

and

it's not clear there is agreement on what "subject to double spend" means.

Can you suggest some clarifying edits that preserve what Jae is trying to say?

@tomtruitt, that is true. No funds need to be put upfront to become a witnesses. Though it only changes the incentives and costs of a witnesses and thus the economics, not the security. Today, the fee involved in getting a witness account is some $150 that are removed from supply and don't give the witness a guaranteed ROI
@jaekwon, back in 2014, we were running BitShares in version 1.0 which had exactly the problems you described. Today, with Bitshares 2.0, we have proxy voting. It allows shareholders to direct their voting power to another account which then has more total voting power. This allows to establish a group of arbitrary size to be able to react quickly shall it be necessary (e.g. fire a witness)

You mentioned something about irreversible blocks, I'd like to see a reference to a spec for that, if it applies to graphene.

Goo point, we should probably have a spec about it somewhere, until then, I can refer to a forum thread of the devs: https://bitsharestalk.org/index.php?topic=18720.0

Each validator can have huge collateral behind it, and it does not get punished for as long as it follows the rules of the protocol. You can't get these properties without building around a solid BFT algorithm that can provide you with absolute fork accountability.

I don't fully understand your statement. You mention that each block is final, yet you tell me that you have accountability for forks. How does that fit together? How can you have finality in blocks just because you can "claim" the collateral of the validator? If I can make more money from creating a bad block than I loose as collateral, can I do that attack? Obvisouly not because you would need to do a double spend which your protocol certainly doesn't allow. It's the same thing in graphene, the validators cannot possible do anything except validate or not validate transactions. The worst thing that can happen in both cases is that validators can censor transactions if they all collude. correct?

If you want to protest

I don't mean to protest against the security model behind cosmos or tendermint at all. I'd like to request an update of the claims around BitShares and Graphene in the whitepaper.

please first post a link to a proof of safety and liveness, and the minimal conditions in which a fork or halt would happen.

This leads me to one of the major problems with DPOS that we haven't fixed for years now: There is no whitepaper that describes it thoroughly and that is also the reasons why I am posting here to make sure the documents that refer to DPOS are accurate.

And finally, a proof of fork accountability, so proof that you can determine who are responsible for a fork or halt condition.

Let me tell you about a feature that we had in one of our Graphene-based forks called STEEM. In Steem, validators are paid in SteemPower which is vested for some time and cannot be withdrawn immediately. This is similar to collateral except that they can earn their collateral. Now, we had a feature that allowed you to claim all the collateral if you could just proof that a witness has signed a block twice (since witnesses are order and have certain slots, this can easily be identified). However, it wasn't received very well mostly because a length-1 fork allows to claim everything already why not presenting any harm to the network. However, given that witnesses are required to be highly available, they happen to run two machines at the same time when upgrading the software which can lead to length-1 forks easily if not done right. It sounds inappropriate to claim all their stake due to length-1 forks that don't mean any harm to the network.
So, what I want to really say is that if you want collateralized witnesses, you can easily do so even with DPOS and even though it is not widely used among existing blockchains.
@MikeSofaer

Can you suggest some clarifying edits that preserve what Jae is trying to say?

Do you want me to send a Pull request?

@shelby3
I don't mean to start a massive discussion here but let me try to clarify on the points you published on bitcointalk

0:40 - "witness are under control of the shareholders". Incorrect. They can do whatever they want until they are replaced by an election.

There is no such thing as an election. Shareholders can vote at any time. If they don't have the resources to do so, they can redirect their voting power to a proxy.
Votes are tallied every 24h (a period that can easily be modified by the committee, whose members are shareholder approved aswell)

0:45 - "actually more secure than Bitcoin". Incorrect. I explain why in my white paper.

Can't comment much here, but the claim is at most inaccurate. It should go like this:
DPOS is more accurate than POW under short to medium time constraints, e.g. for 5-60 minute old transactions
The proof is quite obvious if you read about irreversible blocks in the opening post.

0:48 - "proof-of-work is ... burn most money is most secure ... proof-of-stake ... is also a scarce resource". Incorrect.

Well, stake in BTS is at most 3.7B, so it is limited and thus scarce.

1:40 - "all systems are vulnerable to 51% attack ... no such thing as avoiding 51% attack". Incorrect. PoS is economically vulnerable to double-spends, Bitcoin is not. I explain this in my white paper. Correct that all systems have some form of 51% attack, but PoS has additional 51% attack vectors.

You are mixing up two things here. One is 51% attack, the other is double spending. The claim you quoted is correct because that is the definition of "consensus".
Not sure what you mean by additional 51% attack vectors. That makes no sense to me -- either you have 51%+ of the stake, or you don't.
I would love to read your proof about why POS (and we are talking about DPOS here, btw) is "economically vulnerable to double spends" (what ever that even means).

2:10 - "where we get the advantage over proof-of-work is that the cost of acquiring the 51% is much higher in proof-of-stake". Incorrect. Much easier to borrow or rent 51% stake than to rent 51% of mining farms. The mining farms have too much at stake. The shareholders have nearly nothing-at-stake because of their shares being an undersupplied public good. Worse yet, it may be more profitable for the whales to double-spend and short, than to sell their stake straight up.

Whales cannot double spend. And the fact that the share price of a given DPOS-driven chain is low, doesn't mean you can easily acquire 51%+ of the stake.

2:20 - "because DPoS uses deterministic manner of producing blocks, we don't have to rely on random chance". Incorrect. He fundamentally does not understand resiliency and liveness. I explain this in detail in my white paper. Thus he doesn't understand why Graphene will never scale up to the world. Dunning-Kruger-esque.

Oh, it seems you need to read up on DPOS block generation process. Let me give you a quick TL;DR;
A set of witnesses is approved by the shareholders. Each witnesses can produce one block in a round. Once the round is finished, a new round with randomly ordered witnesses starts.
The randomness is pseudo random as it uses data from the chain to derive the new sorting. That makes it 'deterministic' as every participant knows who is going to produce the next block.

3:30 - "get non-linear growth in the ability to achieve things when you concentrate capital". Incorrect. He is touting the concentration of nodes to 110 witnesses as being some advantage, because he never figured out how to otherwise solve the propagation scaling issue that plagues an unbounded number of nodes. But it doesn't follow that a concentration, bounded, and permissioned, provides resiliency and liveness. He is conflating.

The number of witnesses has indeed been constraint in BitShares 1, but is no longer in BitShares 2. It is yet another shareholder voted parameter that could go from 11 up to 1100 (arbitrary number). The scaling constraints are in fact the time it takes for packages to travel around the world. If you had all the validators in one room, you could easily scale to billions of transactions with block confirmation times of less than 1sec, but a publicly distributed and decentralized network is located around the globe with worst case scenarios of 1-2secs for a roundtrip of packages.
Did you notice how I distinguish between the scaling problem being a latency thing and the concentration problem being a shareholder thing?

@xeroc I feel like this thread is picking up a lot of scope for a Github issue on Cosmos. Maybe a pull request is the way to go, so we don't get too distracted by high-level approach questions. No one wants to say things about Graphene that aren't true, but there are distinctions that we want to highlight.

@xeroc, first of all, thanks for coming here and opening the discussion.  This is exactly why we have our whitepaper on Github.

@tomtruitt, that is true. No funds need to be put upfront to become a witnesses. Though it only changes the incentives and costs of a witnesses and thus the economics, not the security. Today, the fee involved in getting a witness account is some $150 that are removed from supply and don't give the witness a guaranteed ROI

What happens to a shareholder when a witness that they "approve" (delegate voting power to?) happens to launch an attack?

@jaekwon, back in 2014, we were running BitShares in version 1.0 which had exactly the problems you described. Today, with Bitshares 2.0, we have proxy voting. It allows shareholders to direct their voting power to another account which then has more total voting power. This allows to establish a group of arbitrary size to be able to react quickly shall it be necessary (e.g. fire a witness)

So can we change the wording to the following?

By using and improving upon proven BFT algorithms developed at MIT in 1988 [20], the Tendermint team was the first to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by first-generation proof-of-stake cryptocurrencies such as NXT and BitShares-1.0.

It's hard to make any statement about BitShares-2.0/Graphene, without a spec.  But I'm interested in learning more and discussing.

Goo point, we should probably have a spec about it somewhere, until then, I can refer to a forum thread of the devs: https://bitsharestalk.org/index.php?topic=18720.0

It seems that the design decisions of Graphene is still in flux.  Is that true?  (If so great, we might be able to help).

Each validator can have huge collateral behind it, and it does not get punished for as long as it follows the rules of the protocol. You can't get these properties without building around a solid BFT algorithm that can provide you with absolute fork accountability.
I don't fully understand your statement. You mention that each block is final, yet you tell me that you have accountability for forks. How does that fit together?
How can you have finality in blocks just because you can "claim" the collateral of the validator?

It's the other way around.  We can have huge collateral because we can have finality of blocks & fork-accountability.  The latter two come from the consensus algorithm.

If I can make more money from creating a bad block than I loose as collateral, can I do that attack? Obvisouly not because you would need to do a double spend which your protocol certainly doesn't allow. It's the same thing in graphene, the validators cannot possible do anything except validate or not validate transactions. The worst thing that can happen in both cases is that validators can censor transactions if they all collude. correct?

Validator == witness in Graphene?
Double-spends are always possible, even in Bitcoin.  It's just a matter of what it takes to perform such an attack.  In Cosmos/Tendermint, a fork is not supposed to happen, but it can.  And when it does, we can determine who is responsible.  It seems that this term is confusing, because in Graphene, forks are allowed as long as it comes after the most recent "irreversible" block.  When we say "fork", we're referring to the violation of "irreversibility".  Does that make sense?

If you want to protest
I don't mean to protest against the security model behind cosmos or tendermint at all. I'd like to request an update of the claims around BitShares and Graphene in the whitepaper.

Ok.  Lets make corrections, and thanks for the contribution.

please first post a link to a proof of safety and liveness, and the minimal conditions in which a fork or halt would happen.
This leads me to one of the major problems with DPOS that we haven't fixed for years now: There is no whitepaper that describes it thoroughly and that is also the reasons why I am posting here to make sure the documents that refer to DPOS are accurate.

It's really hard / impossible to have a discussion about something that doesn't have a defined spec, because most likely it means that the spec is in flux.  So I'm happy to refer to BitShares-2.0 as being different than BitShares-1.0, but we can't make any definitive statements about it.
And finally, a proof of fork accountability, so proof that you can determine who are responsible for a fork or halt condition.
Let me tell you about a feature that we had in one of our Graphene-based forks called STEEM. In Steem, validators are paid in SteemPower which is vested for some time and cannot be withdrawn immediately. This is similar to collateral except that they can earn their collateral. Now, we had a feature that allowed you to claim all the collateral if you could just proof that a witness has signed a block twice (since witnesses are order and have certain slots, this can easily be identified). However, it wasn't received very well mostly because a length-1 fork allows to claim everything already why not presenting any harm to the network. However, given that witnesses are required to be highly available, they happen to run two machines at the same time when upgrading the software which can lead to length-1 forks easily if not done right. It sounds inappropriate to claim all their stake due to length-1 forks that don't mean any harm to the network.
So, what I want to really say is that if you want collateralized witnesses, you can easily do so even with DPOS and even though it is not widely used among existing blockchains.
I'd like to modify the second contested quote, quoted below for convenience:

Though BitShares achieves high performance (100k tx/s, 1s latency) in ideal conditions, it is subject to double spend attacks by malicious witnesses which fork the blockchain without suffering an explicit economic punishment -- it suffers from the "nothing-at-stake" problem.

But first I need to know a few things, like, whether shareholders have anything at stake for backing the wrong witnesses.  Is a validator a witness?  And proofs of safety/liveness/accountability, as mentioned previously.  I mean, otherwise, maybe the best we can do is to say that we don't know about BitShares2.0 because it isn't spec'd yet.  The if that's true, we can help you construct these proofs, which would be good for BitShares.

What happens to a shareholder when a witness that they "approve" (delegate voting power to?) happens to launch an attack?

Nothing. No penalties what soever. I think I can see where this is heading. The point your trying to make is probably that there is not much incentive for shareholders to actively participate in monitoring witnesses. Together with voting apathy, we either end up in a setting where witnesses can act as maliciously as they can (which is basically just censorship) without having to fear any consequences in the short term. Fortunately we have proxy voting which adds a competitive political role to the game (as big proxies have more influence on witnesses and committee members).
I think, BitShares could benefit from requiring collateral from witnesses to add an extra layer of incentive to act honestly.

So can we change the wording to the following?
By using and improving upon proven BFT algorithms developed at MIT in 1988 [20], the Tendermint team was the first to conceptually demonstrate a proof-of-stake cryptocurrency that addresses the nothing-at-stake problem suffered by first-generation proof-of-stake cryptocurrencies such as NXT and BitShares-1.0.

Absolutely

It's hard to make any statement about BitShares-2.0/Graphene, without a spec. But I'm interested in learning more and discussing.

We desperately need more documentation about the consensus mechanics on bitshares! In the meantime I will try to answer all your questions!

It seems that the design decisions of Graphene is still in flux. Is that true? (If so great, we might be able to help).

There is graphene which is mostly a toolkit and there is BitShares (2.0) which builds on top of Graphene. Steem is another blockchain that builds ontop of graphene. BitShares is currently not much in flux as shareholders asked for more stability in the protocol while Steem is in constant flux due to it's less crypto-centric community.
However, the foundations of DPOS/TaPOS are not changing much (except for the financial aspects of validation).

A block is "created" as soon as it gets signed by over 2/3 of validators (by voting power) such that the block is immutable.

Oh, I missed that part. Would it be correct to say that in Tendermint, the validators first agree (by at least 2/3) and then build an (irreversible) block, while DPOS witnesses build blocks which become irreversible after 2/3 of the witnesses in the round have approved it (e.g. built a block after it)?
If so, then I would go as far as saying that if you only look at irreversible blocks (which we recommend to everyone doing transactions with medium to larget stakes), DPOS is pretty similar to the consensus scheme behind Tendermint (except for the incentives of the witnesses, e.g. collateralization vs. job position)

Validator == witness in Graphene?

Yes. More accurately, validators = block producing witnesses

Double-spends are always possible, even in Bitcoin. It's just a matter of what it takes to perform such an attack. In Cosmos/Tendermint, a fork is not supposed to happen, but it can. And when it does, we can determine who is responsible. It seems that this term is confusing, because in Graphene, forks are allowed as long as it comes after the most recent "irreversible" block. When we say "fork", we're referring to the violation of "irreversibility". Does that make sense?

It does make sense and is accurate. I should have said that double spends are not possible if you only look at blocks that are irreversible (again, a recommendation). In fact, the BitShares software has a so called delayed node that comes after a regular node and only carries the blockchain up to the irreversible block. From that point on, double spends are impossible. The blockchain (e.g. the software) prevents forking the blockchain prior to the irreversible block (that's why it is so similar to a checkpoint in bitcoin, except that there is an actual protocol about how to deal with those checkpoints and that they are not made up arbitrarily by the developers like in bitcoin).

It's really hard / impossible to have a discussion about something that doesn't have a defined spec, because most likely it means that the spec is in flux. So I'm happy to refer to BitShares-2.0 as being different than BitShares-1.0, but we can't make any definitive statements about it.

That would be great!

A proof of safety will prove that if one person sees an irreversible block, then everyone sees that irreversible block. "This will indicate that said block has been confirmed by 66% of all witnesses and is clearly irreversible." What if a witness built off of a block that isn't a descendent of said block? Why is that impossible? "After 2/3 of all witnesses have signed, they cannot "go back"." Why can't they go back? Is this a rule enforced subjectively? What if one witness saw 2/3 sign after said block, but due to network latency many others witness doesn't see those 2/3 and decides to go back?

In fact, there is no they, there is only the one witnesses that is supposed to build the subsequent block (deterministic order of validators). It happens from time to time that latency to the subsequent validator is higher than the block confirmation time, but it rarely happens that latency is higher than 2 or 3 block confirmation times. This means that if I don't see my previous block (due to latency), I can still build a block based on the block before that and broadcast it to the network. In the mean time, the other witnesses see the signed block and the notice that the witness linked to the wrong block (as they had lower latency) and neglect the signed block. The witnesses that comes right after signs a block and links to the original block making the high latency witnesses miss his block.
Does that make sense to you?

A proof of liveness will prove that the network will always make progress (eventually). We only care about fully committed "irreversible" blocks, so the proof needs to show that more "irreversible" blocks will be created. I can't comment more without learning more about the questions I asked above, but usually what happens is, people forget to take into account network problems / subjective views, and end up designing an algorithm that can come to a deadlock, e.g. because no witnesses can make a move that won't punish them.

Given that we don't have punishments, every witness can produce blocks as long as the software doesn't break.

A proof of accountability will prove that when the blockchain fails due to malicous actors, that those actors (or a significant portion, like 33%) can be determined, and thus can be punished. All blockchain consensus algorithms can fail (e.g. double-spend an immutable block) if enough actors are malicious. The trick is proving that when it happens, there's a way to make the attackers accountable for their actions. Here it's important to prove that honest behavior cannot result in being wrongfully framed. Only then would rational agents want to participate && post large amounts of collateral.

The question to me here is: what is an attack, actually. If you take a look at the blockchain starting at genesis up to the irreversible block, then all transactions/operations in that blockchain are valid per definition. Thus, attacks can only happen after the irreversible block and they will only result in forking blockchains that are shorter because the honest witnesses won't sign blocks that increment the attackers blockchain due to invalid transactions.
Of course, if enough actors are malicious, (e.g. >66%), then they can double spend, but only after the irreversible block!

But first I need to know a few things, like, whether shareholders have anything at stake for backing the wrong witnesses. Is a validator a witness? And proofs of safety/liveness/accountability, as mentioned previously. I mean, otherwise, maybe the best we can do is to say that we don't know about BitShares2.0 because it isn't spec'd yet. The if that's true, we can help you construct these proofs.

A validator is a (block producing) witness (non-block producing witnesses are witnesses that don't have sufficient approval by shareholders and can thus not sign blocks).
I would like to provide that proof to you, but am not sure what form it should take. Is the above rational description sufficient or do you need something else?

@xeroc wrote:

There is no such thing as an election...Votes are tallied every 24h (a period that can easily be modified by the committee, whose members are shareholder approved aswell)

Semantic shell games doesn't refute my correct statement, “They can do whatever they want until they are replaced by an election.”

0:45 - “actually more secure than Bitcoin”. Incorrect. I explain why in my white paper.

DPOS is more accurate than POW under short to medium time constraints, e.g. for 5-60 minute old transactions
The proof is quite obvious if you read about irreversible blocks in the opening post.

DPoS due to TaPoS is more final in the medium-term. But you are incorrectly conflating finality of consensus with security.
DPoS it is less secure than “one chain to rule them all” PoW for numerous reasons which I cover in my white paper. An additional excerpt is:

6.8 Less Secure
As previously explained in the  sub-section 4.1 Selfish Mining Example, a mining cartel controlling a majority of the hashrate in PoW which is mined on non-repurposable ASICs has a disincentive to double-spend. Whereas, as previously explained in the  sub-section 5.7.2 Security, a cartel of coordinated whales controlling a majority of the stake may find that double-spends (possibly combined with shorting) are more profitable than any loss of liquid value of their stake. If there is a significant enough transaction ecosystem, it might conceivably be the most liquid means for a whale cartel to exit their investment.
Even in the case where there is no cartel of coordinated whales controlling a majority of the stake in order to maintain tight control over the witnesses, a majority of the witnesses could collude to double-spend. And previously mentioned in the section 2. Byzantine Agreement vs. Proof-of-Work Consensus, if more than ²/₃ of the witnesses collude to double-spend, it can be structured in such a way that the honest minority can’t even prove which witnesses are colluding to double-spend.[DPoS_cost]
In another form of insecurity, participants can lose value in other insidious ways due to malevolent witnesses as explained in the sub-section 6.7 Debasing and opportunity cost losses due to resiliency and liveness issues due to lack of asynchrony.

@xeroc wrote:

Well, stake in BTS is at most 3.7B, so it is limited and thus scarce.

If you don't even comprehend the link which was provided, then why bother to reply?

You are mixing up two things here. One is 51% attack, the other is double spending.

Sorry you are the one who is confused. A double-spend is achieved with a 51% attack. 51% collusion/control of the stake can select ALL of the witnesses and thus can double-spend at will.

I would love to read your proof about why POS (and we are talking about DPOS here, btw) is "economically vulnerable to double spends" (what ever that even means).

I included above the excerpt from my whitepaper which explains that.

Whales cannot double spend. And the fact that the share price of a given DPOS-driven chain is low, doesn't mean you can easily acquire 51%+ of the stake.

By whales I meant collusion/control of 51% of the stake. I am not referring to acquiring 51%, rather to liquefying the illiquid 51% of the stake (held by the upper 1% due to power-law distribution of wealth) by double-spending and shorting the coin. What you don't seem to appreciate is that stake is a power vacuum that over time will always trend to a winner-take-all cartel or control. This is economics. And you do not seem to be very knowledgeable about economics (given you apparently did not comprehend the link you were provided).

Oh, it seems you need to read up on DPOS block generation process. Let me give you a quick TL;DR;
A set of witnesses is approved by the shareholders. Each witnesses can produce one block in a round. > Once the round is finished, a new round with randomly ordered witnesses starts.
The randomness is pseudo random as it uses data from the chain to derive the new sorting. That makes it 'deterministic' as every participant knows who is going to produce the next block.

That is irrelevant.  Propagation hiccups. Witnesses end up out-of-order, malevolent, etc.. There is no way you can model resiliency and liveness of a naturally asynchronous system with a synchronized (synchronous) round-robin witness model. It is fundamentally broken. Will never scale up reliably.
Please don't presume I don't understand. You might start to consider that you don't understand.

The number of witnesses has indeed been constraint in BitShares 1, but is no longer in BitShares 2. It is yet another shareholder voted parameter that could go from 11 up to 1100 (arbitrary number). The scaling constraints are in fact the time it takes for packages to travel around the world.

The entire design is fundamentally flawed.
You'll understand better when my whitepaper is published.

@clayop wrote:

Witnesses will lose their position as well as accompanied income (block validation reward) and never get voted back again.

How can they lose their block validation reward if they remain elected for years? You mean you never pay them until they quit. (obviously not) You mean they lose some short-term portion of their rewards, but if they can do more damage (e.g. short the coin, while they drop transactions or fail to generate blocks messing up the speed and reliability) than the reward, then they don't care about the reward.
You don't always know who you are voting for. The witnesses can be Sybils or political hacks.

@jaekwon wrote:

The second paragraph you quoted was referring to the graphene system. You mentioned something about irreversible blocks, I'd like to see a reference to a spec for that, if it applies to graphene.

Afaik, this is primarily due to TaPoS (transactions as proof-of-stake). Over time this provides irreversible finality and solves the long-range nothing-at-stake problem. I was one of the people who helped Dan refine the initial design of TaPoS. This is cited in my whitepaper and I explain why it is secure.

@shelby3, I appreciate the desire to debate, but your comments are out of the scope of this issue. Feel free to link to say a bitcointalk thread.
More importantly, we don't tolerate insults.  E.g. calling someone naive, or telling people to take classes at a university.  This is your only warning.  Please keep it civil.

I didn't appreciate his implied insults saying that I am mixing up things, etc.. You are free to ban me. I will speak how I speak. If you can't tolerate free speech, then make your own closed system jail.

Goodbye!
We welcome the debating of ideas.  Criticism should not be about the person, but the ideas expressed by that person.
The only rule here is that you can't be overtly rude.  Sexism, racism, etc also won't be tolerated.
Cheers,

Jae

@MikeSofaer wrote:

there is some disagreement on what should count as a solution to the "nothing at stake" problem

The NaS term has been used to describe many different attacks which result from the fact that stake is self-referential. In my prior comments, I have mentioned the long-range chain rew

Criticism should not be about the person, but the ideas expressed by that person.

Why are you introducing unnecessary noise into a technical discussion. You are imposing your apparently (Millennials?) politically correct culture on me. Please respect that I don't come from your generation. I have my own value system. I respect competence. When incompetent people make incorrect statements about economics and repeat them over and over again.  I (and Paul Sztorc) don't have time to teach every person who thinks they are an expert on economics but aren't. Sometimes people need a little hint to please do their homework.
If you want to discourage participation then fine I will leave.
The Bitshares' people came into your Issues tracker and made incorrect accusations.  And their replies to you in this thread and their replies to me continue to reflect a hubris which exceeds their breadth of understanding. They didn't even comprehend what you are trying to say about the fact that with a BFT protocol then there is no finality. I just see the discussion as a comedy of errors and you are being far too accommodating. They don't even have a specification.
But if you think it benefits your project to kick out the experts and cow-tail to the the noise makers, then by all means, I am gone.

I think there's value in helping people articulate their objections clearly so they can be addressed to everyone's satisfaction. If we avoid being brusque then this thread will be a better resource for people who make the same objection in the future.

@MikeSofaer I agree but perhaps you have more time and patience than I do. So I will leave so as to not offend. Perhaps we can do this a different time when I have more free time.

@shelby3
I regretfully agree.  But these are surely not the worst offenders.... and worse still, while I agree with you, many who share your and my point of view do so out of a desire to be assholes.

Hello everyone, I would like to take a moment to address this discussion and commend everyone involved for their efforts to describe technical details of DPOS. I have come to believe that much of the confusion comes from a combination of definitions and understanding the true sources of security in a consensus system.
In this thread the term "witness", "miner", "validator", and "producer" are used in imprecise ways. So let me include an excerpt from a paper I am writing:
Block Producer
A block producer is responsible for grouping transactions into a block and broadcasting it to the network.The number of block producers per confirmation period is limited by block production frequency and incentive structures.
Block Validator
Anyone running a full node is a block validator. A block is considered valid if and only if it follows the open source rules of the blockchain. It does not matter how many block producers collude, a block validator (and the rest of the world) will reject all blocks that fail to conform to internal consensus. In theory there are an unlimited number of block validators, limited only by the desire of individuals and businesses to independently verify block producer behavior. This motivation is often to prevent a business from being defrauded by following a fork that violates the consensus rules.
Last Irreversible Block
A block that has been widely acknowledged as being valid and immutable. This block must be accepted by all validators you trust and confirmed by the majority of block producers.
Now that those terms are out of the way we can conclude that the act of producing a block is independent of the act of validating a block. Under DPOS every produced block can be viewed as a proposal and nothing more. This is similar to the first step in a multi-party block producing process such as Tinderment or Ripple.
Under DPOS every subsequent block is both a confirmation of multiple prior blocks and a proposal for the next block. The set of blocks between the last irreversible block (confirmed by 2/3 of producers) and the head block is like a pipe-line of pending block proposals.
By using a pipeline approach, DPOS has an average latency until irreversibility of  2 * BLOCK_INTERVAL * WITNESSES / 3.  Which for STEEM is 40 seconds. While the latency for a single transaction is high, the pipe line allows for higher throughput where new transactions are made irreversible every 3 seconds.  Furthermore, the pipeline gives everyone variable probability of irreversibility as blocks grow from 1 signature to 2/3 of required signatures.
What we can conclude is that the last irreversible block is identical to advancing blocks in Ripple and Tinderment in that it is a proposal accepted by 2/3 of block producers.
Security Provided by Non Producing Validators
The act of producing blocks means nothing if the produced blocks are not accepted by everyone else in the world. There can be 100,000 independent validators all talking with each other (relaying blocks and transactions).  Each of these validators is running a state machine that will not allow them to roll back past their own perception of the last irreversible block.
If the majority of the block producers collude to produce a longer chain in an attempt to fork beyond the last irreversible block, then no exchange, block explorer, merchant, or other validator would switch to that fork. The entire world will agree on the "first fork seen".
This means that the only way to effect a double spend / reversal beyond last irreversible block is to isolate your victim and partition the network + collusion of producers.  With a small amount of non-consensus changes it would even be possible for a particular node to require proof of TaPoS from a majority of non-block-producing trusted peers that periodically broadcast transactions. Under this model, even colluding block producers who isolate one victim will not be able to incorporate transactions from the other parties.  TaPoS does this organically, but it could be made explicit.
In terms of Collateral
A Job has a net-present-value equal to the value of the future revenue stream combined with a sunk cost of campaigning. Losing the job has a real economic cost. Getting fired has an even greater loss due to value of reputation.
If there was any way for the majority of block producers to collude and cause actual harm to someone running a full validating node with good, long-standing, connections to a large number of peers then I could see the need for additional collateral. But considering every peer is able to independently verify that they and everyone they do business with is on the same irreversible fork, then there is no ability to deceive a single node.
There are two things a block producer can do to "harm" the network:

not produce a block
skip the block producer before them (this will likely orphan the attacker rather than the attacked)

As a group the block producers can prevent the advancement of the last irreversible block until one of the potentially reversible forks is able to elect a majority of block producers who then advance the last irreversible block.   This means that absent a clear majority, any minority of producers can successfully hold an election and keep the last irrevrsiible block advancing.
Aside from halting advancement of the last irreversible block, the majority of block producers can also:

Ignore all minority producers and effectively increase the average block interval by 50%
Ignore / censor transactions / hinder election process

In all conceivable attack scenarios, there is no potential for a double spend of a traditional transfer. Users are only ever at risk if they face financial loss due to the censorship of their transaction. This risk applies to every blockchain and is therefore pointless to consider.
Security, Accountability, and Liveliness
I believe I have proven the the block producers cannot defraud 1000's of independent validators without partitioning the network and while physical network partitions may be possible, logical network partitions defined by non-consensus TaPoS trust links cannot be partitioned. The most that could be said is that TaPoS trust links are not currently deployed as a pro-active defense against a network partition attack.
The only reason for bonded block producers is to enforce a penalty for the network partition attack. If it is possible to prevent it in the first place by TaPoS links then no bond is necessary.
The network of 1000's of validators provide accountability through the ability to detect and report production of fraud chains. The probability of getting caught is 100% and the consequences involve both job loss, reputation loss, and potentially legal consequences of theft/fraud (because the parties are known and the double spend involved and off-chain business transaction).
The blockchain will remain live (advancing the last irreversible block) so long as at least 1 block producer is able to process enough pending transactions to elect a new set of witnesses who then start producing the last irreversible block. Even a loss of 100% of block producers will not prevent the network from advancing assuming a hard fork to enable one witness to hold a new election.
Conclusion
There are no known strategies by which a well connecting full validating node can be defrauded and the damage any individual block producer or even collusive majority group can do is so insignificant that a bonding requirement beyond job/reputation loss is unnecessary.
Do bonds actually make a platform more secure? They act as a barrier to entry that keeps block production (and therefore censorship rights) in the hands of the rich. The power to censor is far more valuable than any microscopic probability for producing two alternative chains in an effort to defraud an isolated victim.

I have some questions and concerns with the previous post's section on "In Terms of Collateral," specifically with your use of majority.  Could you comment on how 'majority' still achieves a solution to the Byzantine Generals Problem?

A 51% majority is unable to advance last irreversible block, that requires a 2/3 majority. In that section I am referring to attempted attacks with any majority being ineffective other than censorship.

Maybe we should clarify that the requirement for the irreversible block to advances is that 2/3  *NUM_BLOCK_PRODUCERS different block producers produce blocks. That means that if 1/3 of all block producers go down at the same time, then the irreversible block will not advance, even though the blockchain does grow from the still running block producers!

Hi Bytemaster, and everyone from the BitShares community,
Thank you for the writeup, lets dive in -- happy to discuss.
I want to first point out that our design principle is to account for network partitions, so that needs to be taken into consideration when proving safety.
On TaPoS
I would argue that TaPoS can't be used for finalization of blocks.  The objective is to create a block finalization (e.g. irreversibility) algorithm, and in our case (3 seconds) or BitShare's case (e.g. 40 seconds), the time is not sufficiently long to settle anything with transaction volume or coin-days-destroyed.  TaPoS is fine for dealing with successful attacks or long range attacks and figuring out how to recover, nothing wrong with that.  But for the sake of near-term block finality/irreversibility, TaPoS should not be discussed.  In addition, during a network partition, it is also true that not all transactions will be visible, so it can't help there.  In any case, I hope we can agree to put TaPoS aside, when we're discussing finality/irreversibility.
Next I want to bring up safety and liveness with regards to the BitShares scheme.
Safety and Liveness in BitShares
My understanding is that there is a designated signer for every block height, and that if the designated signer is not available, that height may be skipped.  Please correct me if I'm wrong.
It's fine to say that every validator, locally, will compute and hopefully progress their "irreversible block", (which for specificity I will refer to as "local irreversible block"), and that it requires 2/3+ of different block producers to produce blocks.  What's important is to prove that up to some tolerance threshold, no matter the network circumstances (e.g. partitions or not), that when one signer increments its "local irreversible block", that it is guaranteed that everyone else will also (eventually) increment the exact same "local irreversible block".  That is required for liveness, for otherwise there may be situations where the network deadlocks, and is unable to progress any further.  In otherwords, liveness is not guaranteed.  And by liveness, I'm not referring to additional blocks being proposed... I'm referring specifically to the "local irreversible block" progressing.  The only thing that matters is the progression of the "local irreversible block", and that there is consensus about what that chain looks like.  (Thus making "local irreversible block" == "global irreversible block")
In order to analyze this for Bitshares, I need to first ask,

When a block signer signs a block Bzero for height H, is it OK for this block signer to, at a later time, sign a block Bx for height H+x where that block does not include Bzero in the chain?

I assume that the answer is yes, for otherwise it would be really easy for a signer to end up in a deadlock scenario.  So then the followup question is,

Due the nature of the internet, and especially given the desired block finality time of 40 seconds, it is not safe to assume that all block signers will see all the blocks proposed.  So we need to take into account network partitions and really any strange network behavior.  Given this, what is to prevent block signers from switching back and forth, and end up deadlocking by ending up with different "local irreversible blocks"?

Given the scheme that I know so far for BitShare's PoS algorithm, and assuming that the answer to (1) is yes, then I can construct a situation where the "local irreversible blocks" diverge and result in a deadlock, without any block signer being malicious at all, and only due to network circumstances.
For example, lets say there are 4 signers, S1, S2, S3, and S4.  And 3 signatures from 3 different signers is required for a block to be irreversible.
For example, ideally:
B1(S1) -> B2(S2) -> B3(S3) ->B4(S4) -> B5(S1)
And in this case, if everyone had seen B5(S1), then everyone would have B3 as their "local irreversible block".  On the other hand, if S4 was offline for B4, then B2 would be everyone's "local irreversible block".
B1(S1) -> B2(S2) -> B3(S3) ->B4(nil) -> B5(S1)
Now, lets assume everyone starts with B0 as the "local immutable block", and network irregularities causes the following to happen:
B0 -> B1(nil) -> B2(S2) -> B3(nil) ->B4(S4) -> B5(S1)  # B5 seen by S1 and S4
B0 -> B1(S1) -> B2(nil) -> B3(S3) ->B4(nil) -> B5(nil) -> B6(S2) # B6 seen by S2 and S3
S2 signed B2 but didn't see B3, B4, or B5.  Then, S1/S4 will have B2 as the "local immutable block", whereas S2/S3 will have B1 as the "local immutable block", and the network has gotten deadlocked.
What prevents such a deadlock in BitShares?

Thanks for putting so much thought into our algorithm and presenting an example for consideration.
For starters, I have mapped this example out sequentially and concluded the following:
Block 5 signed by S1 proves that S1 chose to switch from his prior fork where he produced B1 to the fork produced by S2 and that presumably S2 decided to switch to the fork started by S1.  This particular case would never happen by nodes running the default algorithm because nodes only switch forks when they see a chain that is longer (skipped blocks don't count).
Given presented order S1 would see  B1(S1)->B3(S3) first and not switch to B2(S2)->B4(S4) because it is not longer.   Likewise, S2 would not switch because he would also see two forks of the same length so would not switch (preferring the first fork he saw).
So we can conclude that the pattern you demonstrated would only be possible under the condition of colluding malicious producers who broadcast B5(s1) and B6(S2) at the same time.  Under that situation half of the observers would switch to one fork and half would switch to the other fork.
For simplicity I will rename your producers to A, B, C, and D  (S1, S2, S3, S4).  I assume round robin scheduling so B0 is produced by D.
Half would see DBDA and the other half would see DACB which would cause them to each advance to different local irreversible blocks. Because you only have 4 producers 2 of them being bad can cause a lot of harm.  The required percentage of confirmation in order to advance the last irreversible block ends up rounding up for low numbers of producers. I may even be convinced that we should change it to 66% + 1 from 66%.  It certainly wouldn't hurt to be extra conservative and say 75% + 1.
Assuming we keep the constraint that all trusted peers must agree on advancement then the attack I presented where two producers collude to broadcast at the same moment in an effort to split the network would fail. Half the nodes seeing peers on a different fork would result in them failing to advance their local LIB until there was a clear winning chain.
With respect to TAPOS.... it works if additional validators are broadcasting every 30 seconds and validators are configured to expect and respect those trusted validators in addition to the producers.
In effect, the consensus used by the validators need not be restricted to the block producers.

Hi Daniel,
B0 -> B1(nil) -> B2(S2) -> B3(nil) ->B4(S4) -> B5(S1) # B5 seen by S1 and S4
B0 -> B1(S1) -> B2(nil) -> B3(S3) ->B4(nil) -> B5(nil) -> B6(S2) # B6 seen by S2 and S3

This particular case would never happen by nodes running the default algorithm because nodes only switch forks when they see a chain that is longer (skipped blocks don't count).
Given presented order S1 would see B1(S1)->B3(S3) first and not switch to B2(S2)->B4(S4) because it is not longer. Likewise, S2 would not switch because he would also see two forks of the same length so would not switch (preferring the first fork he saw).

I'm assuming that S1 never saw B3,6 and S2 never saw B4,5; due to network conditions.  Sorry if that wasn't clear.  So, everyone is acting honest, and yet S1 and S2 switched chains.

@jaekwon If you don't mind, can you cross-post on Dan's Steemit post?

I can't sign up because it won't accept my phone number.  You can do it for me though!

@jaekwon thank you for your persistence in pursuing this, it is my hope that we can resolve this issue.  I hope you don't mind me switching notation to simply imply producers ABC and D. I use '-' to indicate a missed block.  Each time a Witness switches forks I start a new line to indicate the change.
Witness A: D A
         : D - B - D A

Witness B: D - B
         : D A - C - - B

Witness C: D A - C - - B

Witness D: D - B - D A

So the question at hand is what witnesses, if any, advanced the last irreversible block. What we can see here is that for witnesses A and D they have the sequence DBDA while B and C have DACB.
Edge cases can be problematic, so lets clarify that a block cannot confirm itself. The first block A only has 2 confirmation (C and B) and the first block B only has two confirmations (D and A).
The chains will remain forked producing DADADADA... and BCBCBC... until connectivity is restored at which point the two chains will eventually look like this:
1] DA-C-B--BC--BC--BC        <-- Length 10
2] D-B-DAD--DA--DA--DA       <-- Length 11

Once this happens the the peers on the shorter chain switch and you get
1] DA-C-B--BC--BC--BC        <-- Length 10
2] D-B-DAD--DA--DA--DAB       <-- Length 12 and LIB advances one block

Then you get:
2] D-B-DAD--DA--DA--DABC       <-- Length 13 and LIB advances 8 blocks (to last D)

Because the witnesses are shuffled every round we are guaranteed not to get stuck in an alternating pattern between two forks that never out grow the other.
After reviewing this example I have inspected our code and identified that Steem needs to swap two lines of code to prevent this theoretical edge case.  We will incorporate this fix in the next hard fork.
All of that said, this contrived example assumes some very unlikely things:

Only 4 witnesses and an even number (against protocol spec) at that
Very sporadic and intermittent connectivity among all witnesses (complete down time more likely)
Perfectly timed swap among two witnesses

After several years of operation of BitShares and 9 months of Steem, neither network has ever actually experienced this theoretical hick up and if it were to happen then at most ONE block would be mistakenly advanced.
I have taken a few other thoughts from this discussion:

In the nominal case (99.99% of the time, maybe higher) every block ends up confirmed
In extremely rare case this is not sufficient, you need to wait 40 seconds

Fortunately we have an additional metric that is applied, witness participation rate. In the nominal case this is 100%, in every network disruption event this number falls due to missed blocks. Each and every one of our nodes is configured to reject transactions if there are no confirmations in the last 8 seconds (2 full blocks).  This means the P2P network will not relay transactions if there is a high probability that a node is on a minority fork.  When the network is operating normally missing two blocks is a red flag and users are automatically protected because the chances of missing the 3rd is very high.  Obviously, getting a single block allows propagation again so this system is mostly an early warning indicator of lost connectivity.
This is a design tradeoff... in theory each of our nodes could require 2/3 of witness signatures on every block before any witness will generate a new block. This would require network traffic equivalent to 5 transactions per second sustained (assuming 14 signatures every 3 seconds). This extra data wouldn't actually need to be recorded in the blockchain, because it is implicitly recorded like it is today.  It would merely have to be maintained on all blocks that don't meet the current LIB standard.
Steem and BitShares accomplish 99.999% of the security for 93% reduction in network overhead when looking at 3 second confirmation.  With 40 second confirmation you have equal security / immutability guarantees.
What About Bad Producers
Now that we have established a stable protocol under honest conditions, what happens if nodes misbehave.  Assume 2/3 of producers collude to exclude the other 1/3 and then produce 2 chains in parallel.  Due to TaPoS all transactions would be restricted to which ever fork a node happened to be on.  The network would split and two chains with different LIB would emerge. It would require manual intervention via checkpoints to resolve this attack.  Note that this is also true of all federated systems.
The solution is to elect new block producers and fire those who attempted double production. There is ample cryptographic evidence available to prove this kind of behavior.  In fact, the original STEEM protocol had an operation that would enable such a witness to be fired if proof of producing two blocks in the same time slot were provided. This limited each witness to 1 vote per scheduled time slot. In this event the witness would lose their Steem Power which acted as a bond. Because witnesses are paid in Steem Power and it takes months to liquidate it, you could say that all witnesses were effectively bonded by 13 weeks of pay, they just didn't have to front the money.
So should we restore the operation to fire witnesses who double produce... maybe.  It may be overkill.  Even a large bond would not preclude the profit of pulling of a double spend by 2/3 of the witnesses. The best protection is actually to have the clients detect the double production and halt the advancement of the LIB until the double production stops. In this situation everyone is protected because double production has the same impact as lack-of-production.  It effectively nullifies a block confirmation if there are two competing blocks for the same time slot.
Thanks again for engaging in this discussion and challenging my assumptions.  I hope this process has been as educational to you all as it has been to me.

After reviewing this example I have inspected our code and identified that Steem needs to swap two lines of code to prevent this theoretical edge case. We will incorporate this fix in the next hard fork.

BitShares unaffected?
Also, I think in BitShares, the shareholders could technically vote for an even number of witnesses, am I correct?
Bad Producers
Another way of dealing with "bad producers" is to add the requirement of having at least 1 block per round be solved via proof of work. The current STEEM design has a slot reserved for a POW block, such that a POW miner can obtain a single-use ticket into the active set of witnesses at a specific time in the future. All those POW miners are managed in a POW queue. Once you are on the top spot, you basically become a witness for a single round. However STEEM does not require a pow block to be produced in that slot, it the miner misses to produce the block then the next regular witness would continue.
This setup has the disadvantage that the subsequent witness could ignore the block produced by the pow-miner and censor any transaction that comes with it.
If you required that a pow block was produced every round, you remove that disadvantage but get another disadvantage and that is an unpredictable and possibly abusable delay when the round is going to end and the blockchain needs to wait for a miner to produce a block. The network would need to go through the entire mining queue and try to obtain a pow block from everyone in there until (in the worst case) the mining queue is emptied (in the mean time, no new pow-tickets can be obtained because no block is generated).
This would make the network entirely censorship resistant (assuming POW achieves that) but it comes with a massive drawback of irregular block times

Edge cases can be problematic, so lets clarify that a block cannot confirm itself. The first block A only has 2 confirmation (C and B) and the first block B only has two confirmations (D and A).

Ok, I've changed the example so you need 1 more confirmation.
B0 -> B1(_) -> B2(B) -> B3(_) ->B4(D) -> B5(A) -> B6(_) -> B7(_) -> B8(D) -> B9(_) -> B10(B)
B0 -> B1(A) -> B2(_) -> B3(C) ->B4(_) -> B5(_) -> B6(B) -> B7(C) -> B8(_) -> B9(A) -> B10(_)

A: saw B0, signed B1, saw B2, saw B4 (switched chains), signed B5, saw B3 late, saw B6, saw B7, signed B9, made B1 local-immutable
B: saw B0, signed B2, saw B1 late, saw B3 (switched chains), signed B6, saw B4 late, saw B5 late, saw B8 (switched chains), signed B10, made B2 local-immutable
C: saw B0, saw B1, signed B3, saw B6, signed B7, saw B9, made B1 local-immutable
D: saw B0, saw B2, signed B4, saw B5, saw B8, saw B10, made B2 local-immutable

Only 4 witnesses and an even number (against protocol spec) at that

It's possible to extend any of our examples by e.g. saying, each letter represents many signers.

Perfectly timed swap among two witnesses

I admit it looks contrived, but maybe this is because we're only discussing 1 concrete contrived example.  I think there are other sequences that arrive at the same deadlocked outcome.

Thanks again for engaging in this discussion and challenging my assumptions. I hope this process has been as educational to you all as it has been to me.

Thank you too.  I hope you take a look the Tendermint spec too: https://github.com/tendermint/tendermint/wiki/Byzantine-Consensus-Algorithm

@jaekwon thank you for continuing your efforts, it takes a lot of work to contrive these examples.  I only wish that you would contrive an example with an odd number of produces and immutability of 4 out of 5 or 2/3.  One thing is certain, it isn't easy tracking all of this manually.
For the sake of argument, lets assume we have some nodes with the sequence: DBDADB  and the others with the sequence DACBCA and therefore the bold block is considered immutable.
This means that half of all nodes will end up on a chain with CACACACA and the others with DBDBDBDBDB.  In this case the last irreversible block (local) could not advance for either chain until one of the producers intervened to resolve the issue.   The odds of getting stuck must be astronomical given the 10's of millions of blocks produced without deadlock in real life.
It is my belief that with 4 nodes you need 4/4 to avoid deadlock in the byzantine case. You require 1/1,  2/3,  4/5, 5/7, 6/9, 8/11, 9/13,  10/15, ... 14/21... in other words greater than 2/3 and an odd total to avoid deadlock in all cases.  If you have an even number then you need more than 75%.
I will take a look at tendermint and see what I can learn.  Thanks again for the engaging discussion.

I have reviewed the tendermint algorithm and see that +2/3 are required to advance consensus and that 1/3+ can halt the consensus process.  This property appears to be shared between DPOS and TBCA (Tendermint BCA).  I would be suspicious of any algorithm that could operate with less than 2/3.
The next thing I see is that there are designated proposers that must propose within a timeout window.  In DPOS our timeout window is 3 seconds which accounts for propagation delay and network latency in the majority of cases.
Given that pre-vote and pre-commit messages are propagated on a P2P network we can assume they share similar latency issues with similar timeout requirements.
Correct me if I am wrong, but I would guess that TBCA takes at least 5 seconds to agree on a block on a distributed network?
Overall I would say that the algorithm looks solid and has no immediate faults.

I have reviewed the tendermint algorithm and see that +2/3 are required to advance consensus and that 1/3+ can halt the consensus process. This property appears to be shared between DPOS and TBCA (Tendermint BCA). I would be suspicious of any algorithm that could operate with less than 2/3.

It's an immediate consequence (or should be, rather) from Lamport, Shostak, and Pease's paper on the Byzantine Generals Problem that any consensus mechanism would have to require 2/3 majority to advance the process.

@jaekwon thank you for continuing your efforts, it takes a lot of work to contrive these examples. I only wish that you would contrive an example with an odd number of produces and immutability of 4 out of 5 or 2/3. One thing is certain, it isn't easy tracking all of this manually.

To make it work for an odd number, just do something like this...
Replace each A, B, C, D with sub-signers, like A = (A1,A2,A3), B = (B1,B2,B3), C = (C1,C2,C3), D = (D1,D2,D3,D4).  Notice that D has 4 signers in its group, so overall there are an odd number of nodes.  And imagine that when A "sees" a block, it means all A1, A2, A3 saw it, and when A "signs" a block, it means A1, A2, A3 signed in order.
B0 -> B1(A) -> B2(B) becomes B0 -> B1(A1) -> B2(A2) -> B3(A3) -> B4(B1) -> B5(B2) -> B6(B3) and so on.
This satisfies your conditions: odd number of producers (13), with immutability greater than 2/3 (actually 9/13).

@jaekwon consider to make a post on steemit with an introduction to cosmos whitepaper. Many of us will upvote it to say thank you for your above contributions/brainstorming and your project will be well promoted overall.

If you read the thread, you will easily find the following tidbit of valuable information ...

I can't sign up because it won't accept my phone number. You can do it for me though!

I have provided a final opinion here: https://steemit.com/blockchain/@dantheman/the-problem-with-byzantine-generals
My conclusion is that the LIB algorithm is similar to the 6 block algorithm of Bitcoin.  If you adapted the rule to require 100% witness participation and 21 confirmations then you would never get stuck and would have finality within 63 seconds.
Lastly I have concluded the Cosmos algorithm to be vulnerable to deadlock with 33% failure where as DPOS continues to function with extremely high probability of confirmation (far better than Bitcoin).  Likewise, DPOS enables a stakeholder election to replace failed generals and return to 100% production.
Pick your threat:  double spend, network partition, malicious minority, etc and I am confident that DPOS provides sufficient guarantees and protections with 2 confirmations and 100% participation.
Meanwhile, attacks that would be annoyances on DPOS would result in complete failure on COSMOS (requiring a hard fork to change the generals).

Hey here's a thought:  Why not simply work on making tendermint chains talk with graphene chains?  Having used both, I've got to say that while there are big implementation differences, most of those are due to the language used to implement, and not the actual purpose of the software.  Both Tendermint and Graphene help people create fast, permissioned blockchains.  Graphene has a well-developed quasi-democratic aspect to it, while tendermint lacks one.  I think tendermint is a bit easier to develop against, but this is nothing that is impossible to fix.
Make love not war.

Let’s teach everyone about Byzantine fault tolerance and especially the DPoS people need an education:
https://busy.org/blockchain/@anonymint/consortium-blockchains-e-g-dpos-and-tendermint-can-t-internet-scale
https://medium.com/@shelby_78386/most-of-what-you-have-written-has-been-holistically-refuted-in-my-newest-blog-which-i-plan-to-also-747fcb9f3e6b
I’m not coming back for a debate. I’m busy. I’m hiring.


[Extensibility enhancement] Pages 343 and 1871: Need to add own field into the check.

Hello.
We add our own FlowField to table 37 (that will go into a TableExtension), and need to include it into the fields in Page 1871 "Credit Limit Details", and affect the totals.
Can you add extension to pages 343 and 1871 so that we can have our field within the PopulateDataOnNotification and InitializeFromNotificationVar functions?
We also need a new function in Page 1871 to set the new field from additions in calls in Page 343.
Pictures of how we are currently doing this below (but maybe you have a better way of solving this?):
Page 1871:
1: New Variable:

2: New function:

3: Changes in the Notification functions:

4: The variable added to the ContentArea:

Page 343:
5: Handle the same value as in Page 1871 in Page 343.CalcCreditLimitLCY:

6: Add the field to function SetParametersOnDetails:

I hope this is clear enough, and that I am placing this request in the correct place.

Hi @KristjanGaukur . Just for better understanding of what and how will be implemented, take a look at the code below. This is simple example of two fields from customer should be populated on credit limit details page.
tableextension 50101 CustExt extends Customer
{
fields
{
field(50101; Field1; Decimal)
{
Caption = 'Field1';
InitValue = 123.45;
}
field(50102; Field2; Decimal)
{
Caption = 'Field2';
InitValue = 45.67;
}
}
}
pageextension 50101 CreditLimitDetailsExt extends "Credit Limit Details"
{
layout
{
addafter(GetInvoicedPrepmtAmountLCY)
{
field(Field1; CreditLimitExt1)
{
Caption = 'Extension Field 1';
}
field(Field2; CreditLimitExt2)
{
Caption = 'Extension Field 2';
}
}
}
trigger OnOpenPage()
begin
    GetExtensionAmounts(ExtensionAmounts);
    ExtensionAmounts.Get(1, CreditLimitExt1);
    ExtensionAmounts.Get(2, CreditLimitExt2);
end;

var
    CreditLimitExt1: Decimal;
    CreditLimitExt2: Decimal;
    ExtensionAmounts: List of [Decimal];

}
codeunit 50101 CreditLimitTransfer
{
[EventSubscriber(ObjectType::Page, Page::"Check Credit Limit", 'OnAfterCalcCreditLimitLCY', '', true, true)]
local procedure MyProcedure0(var Customer: Record Customer; var CustCreditAmountLCY: Decimal; var ExtensionAmounts: List of [Decimal])
begin
CustCreditAmountLCY := CustCreditAmountLCY + Customer.Field1 + Customer.Field2;
ExtensionAmounts.Add(Customer.Field1);
ExtensionAmounts.Add(Customer.Field2);
end;
[EventSubscriber(ObjectType::Page, Page::"Credit Limit Details", 'OnAfterPopulateDataOnNotification', '', true, true)]
local procedure MyProcedure1(var CreditLimitNotification: Notification; var ExtensionAmounts: List of [Decimal])
var
    ExtensionAmount: Decimal;
begin
    if ExtensionAmounts.Get(1, ExtensionAmount) then
        CreditLimitNotification.SetData(Format(1), Format(ExtensionAmount));
    if ExtensionAmounts.Get(2, ExtensionAmount) then
        CreditLimitNotification.SetData(Format(2), Format(ExtensionAmount));
end;

[EventSubscriber(ObjectType::Page, Page::"Credit Limit Details", 'OnAfterInitializeFromNotificationVar', '', true, true)]
local procedure MyProcedure2(CreditLimitNotification: Notification; var ExtensionAmounts: List of [Decimal])
var
    ExtensionAmount: Decimal;
begin
    Evaluate(ExtensionAmount, CreditLimitNotification.GetData(Format(1)));
    ExtensionAmounts.Add(ExtensionAmount);
    Evaluate(ExtensionAmount, CreditLimitNotification.GetData(Format(2)));
    ExtensionAmounts.Add(ExtensionAmount);
end;

}

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. We will update this issue with information about availability.


Error handling & Broken pipe

Hello,
I'm working on stream resiliance and I would like to inform my users when the stream is down.
When I'm launching stream on Facebook, if I stop (or delete) the stream from Facebook, the librarie logs indefinitely this informations :
E/RtmpConnection: Caught IOException during write loop, shutting down: Write error: ssl=0x6fc0e10408: I/O error during system call, Broken pipe
V/NativeCrypto: Write error: ssl=0x6fc0e10408: I/O error during system call, Broken pipe

According to this issue : https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/issues/329 the error should be appear in onConnectionFailedRtmp but my breakpoint is never called inside.
The onDisconnectRtmp is also never called.
I'm using the v1.7.2.
What is the best way to make a good error handling ?
Thanks

This was a bug. Fixed here:
https://github.com/pedroSG94/rtmp-rtsp-stream-client-java/commit/6470ff39207d957456a92b3a6b8f5cbae0799ac9
You can compile this version if you need use gradle:
implementation 'com.github.pedroSG94:rtmp-rtsp-stream-client-java:6470ff3920'

Thanks I will try it asap :)


Localhost Based GUI to help build a Kirimase Application

From kirimase created by arvind-iyer-2001: nicoalbanese/kirimase#157
Is your feature request related to a problem? Please describe.
Kinda frustrating to specify models and stuff using the CLI tool.
Sometimes, we need to make changes on the go to stuff like this and having a GUI can really help make it easier.
GUI can be like the Drizzle Studio and can really supercharge the experience of developing.
Fulfils the purpose of generating boilerplate code to build upon much easier and while being a Rails-CLI type Next.js App Builder.
Describe the solution you'd like
Process that would be like

Create a Kirimase App
Open GUI using npx kirimase studio
Configure all Models that are required.
Basically make it look like a CMS that helps build a Next.js Application.

Hi,
Expanding upon this, see Gii for Yii2 https://www.yiiframework.com/doc/guide/2.0/en/start-gii
This made developing PHP apps with Yii2 super easy. The whole CRUD, with input fields and filtering out of the box, in seconds based upon the model.
Matt


One script to bind them all (apologies to Tolkien)

We need a high-level script that automates as much as possible a vanilla checkout - configure - build.

I think this issue is at least fixed for now. I'll probably open an issue on GEOS-ESM/ESMA_env for upgrades needed.


feat!: v0.22 updates

[x] Contract broadcast method rename publish
[x] Indices must be named
[x] Add contract update tutorial

Close in favor of #14


Create LICENSE

@Simn here also is the issue, but there is no license mentioned in any file, so it is just a proposal.

I'm happy to MIT-license all my code, so yeah this is fine.


Rework the description of exceptions for Svinval

Restructure the listing of exceptions raised for SINVAL.VMA, HINVAL.VVMA, and HINVAL.GVMA, as follows:

List exceptions that occur absent the hypervisor extension first.

Replace obscure "when V=1" with "in VS-mode or VU-mode".

Add that attempts to execute SINVAL.VMA in VU-mode raise a virtual instruction exception.

Yeah, this reads a little better.  Thanks.


Delete all the things

[ch160]

This is WIP because if Travis doesn't pass I'm going to rebase it so that each removal is in its own commit.
We can also push a tag for each of the the CB and ML removals.

Ready for review. Travis ran as expected. This leaves us with 5 matrix builds: lwc_local, mimir, mongodb_3_4, mongodb_3_4_13, and mongodb_3_6.

I think we can also drop the old mongo 3.4 build and only retain the latest 3.4.x (x ≥ 4). So that'll drop us down another matrix build.

For posterity, here's what I ran to delete backends from the .test files:
$ find . -type f -name "*.test" -print0 | xargs -0 sed -i '' -e '/\S*"mongodb_read_only.*$/d'


Really REALLY fix Windows SDL dll copy

Tested with a clean configure and no vcpkg.

Haha cursed vcpkg! Thank you.


How to getStats() using FairPlay on Safari

Have you read the Tutorials?
yes
Have you read the FAQ and checked for duplicate open issues?
yes
What version of Shaka Player are you using?
version: 3
Please ask your question
Hi, may i know how to get statistics for nerds using FairPlay on Safari as we know that we can use getStats() to get statistics on Chrome. Please advise. Thank you.

Hello,
If you're playing HLS content on Safari, we default to using native src= playback. When doing this, we don't have much info since the browser handles playback. You can use MSE playback on Safari by setting the configuration 'streaming.useNativeHlsOnSafari' to false, but you can't do this for FairPlay content.


Examples supported sync connect families.

Codecov Report

Merging #537 into master will increase coverage by 0.25%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #537      +/-   ##
==========================================
+ Coverage   84.49%   84.74%   +0.25%
==========================================
  Files          41       41
  Lines        6185     6366     +181
==========================================
+ Hits         5226     5395     +169
- Misses        959      971      +12

I'm actually not understanding why multiple threads are needed here.
What's causing the deadlock when a single thread is used?

What's causing the deadlock when a single thread is used?

Ok, let me explain.
The examples *_both.cpp contains both client and server. They use one io_context ioc;. At the end of the code, ioc.run() is called.
After I updated async_connect() and (sync)connect(), connect, tls handshake, and websocket handshake are processed synchronously. The old behavior is all of them are asynchronous.
And the example code uses connect(), not async_connect(). Because it is simpler.
If the client calls synchronous API such as handshake, then the code is blocked until the server finish server-side handshake processing. However, the client and server share the same io_context. So server had no chance to process server-side process.
So I introduced the new io_context iocs; and call iocs.run() from the server thread.


Update common issues to highlight the ECS Show

Show Column work-around for ECS

Hi @lancedMicrosoft, I have submitted some minor changes to your draft. Feel free to let me know if any questions. Also loop @tapanm-MSFT and @KumarVivek here for any suggestions.

@lucciz01  looks good


Inclusion & Exclusion Criterion and IPD

A late Phase 3 review comment. Added here so as to no let it be forgotten

Thinking about use case of generating Important Protocol  Deviation Listing using USDM,  following are the topics that I wanted us to address :-

Are there any plans to break the identifier field into something like IPD code (example EX for Exclusion, In for Inclusion) and IPD subcode
Ability to add more IPD types (like Missing data, Received wrong treatment or incorrect dose, etc) and process them using USDM.

Goal would be ability to generate IPD listing using digital data flow.

Initial response from @BSnoeijerCD

It seems this is just another coding system that can be used. We had more requests for aligning to specific coding systems.
The USDM is in principle aligning with CDISC CT. This enables the users to transform their information from one CDISC standard to another (for example the SDTM trial domain mapping).
In addition, we can enable aliascodes where needed. So that we can link to any other coding system that is required by the user. For example, based on the public review comments we enabled the alias code for frequency, route and units.
Also, please note that we do not collect the actual trial data (like missed dose, wrong treatment etc) so that kind of information and corresponding coding is not applicable here.


feat(material/chips): add focusLastChipOnBackspace to MatChipList

By default, when pressing backspace when the input is focused and empty, the last chip (if exists) would be focused.
This makes is so that when people delete the content they wrote, they will eventually start deleting chips.
This PR puts this behavior behind a flag (which is turned on by default, to preserve current default behaviour)
When the flag is turned off, the last chip will not get focused when backspace is pressed.

Fixes: #18659

I've looked into the material design spec for chips, and I've not found any spec regarding behaviour related to the input, so this wouldn't be a change that would be against any spec.

@gioragutt in your issue, you say:

This something that may be problematic for some users in some cases

Can you elaborate on why this would be problematic? Can you point to examples of other chipped inputs that don't use backspace to delete chips like this?

@jelbourn This is coming from a use case a friend of mine has (well, had).
Say you write something in the input, and you decide to delete it.
A normal user would just delete it and stop. But what if someone just long-pressed backspace?
It'll eventually delete everything, passing the focus to the chips, and deleting them (by the time the user figures out what he's done).
It's not much of a technical ability or visual ability, but one the comes to address behaviours people often have.

@gioragutt Thanks, I can totally see the need for this, in fact I would say this should probably even be the default behavior. However, I do think with respect to  implementation it would be better to make it part of MatChipsDefaultOptions, as it's likely a setting people would want to change application-wide, not on a single instance of chips. Also note that we have an mdc-based version of the chips that would need to be updated as well.

@gioragutt Thanks, I can totally see the need for this, in fact I would say this should probably even be the default behavior. However, I do think with respect to implementation it would be better to make it part of MatChipsDefaultOptions, as it's likely a setting people would want to change application-wide, not on a single instance of chips. Also note that we have an mdc-based version of the chips that would need to be updated as well.

@mmalerba It's great to hear such feedback about the feature, I'll look into what changes are required to meet your request.
The changes to MatChipsDefaultOptions are trivial, I assume.
The changes are new to me, tbh idk how did I miss @jelbourn 's talk in ng-conf 2019 about this, but I'm gonna see what's involved in this. Any general direction you'll provide would be great, but I think I'll manage anyway.

We can keep the default behavior the same in this PR and then change it in a different one. That should make this PR easier to merge.
The MDC-based one can also be done in a separate PR since that's still in experimental.
Thanks for contributing!

@mmalerba
I'm running into several issues in my local machine:

the bazel version specified in the repo is 3.1.0, but I can't find a way to downgrade mine from 3.2.0 (using mac).
for now I've changed it locally to 3.2.0 in .bazelversion, seems to work.
I tried running yarn approve-cli, and it failed because there's no bazel command in package.json (it tries running yarn bazel run ...).
Here too, I've made local changes to make this pass, but obviously the CI will run it with correct configuration.

One thing that I think would be a bit problematic, I don't quite know what's affected by this warning, is this:
There were tests whose specified size is too big. Use the --test_verbose_timeout_warnings command line option to see which ones these are.
INFO: Build completed successfully, 1 total action

I assume that it's chip-list.spec.ts since I'm running yarn test material/chips, and there's only one more small tests file other than this one.
If there's something I can/should do about this warning, let me know

@gioragutt are you interested in repurposing this PR to implement the solution discussed in https://github.com/angular/components/issues/18659 or should we close it?

@mmalerba Lets close this one, I'll start from scratch.


⚠ Bofrost.de has degraded performance

In 4ea2a31, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 854 ms

Resolved: Bofrost.de performance has improved in 3bf34a2 after 17 minutes.


Add auto-author and auto-label to github workflow

Closes #64

Proposed Changes

The same as this PR for phys2bids but implemented for this repo
All I did was change the directory locations in the .github/labeler.yml file, otherwise the files are the same as the phys2bids files

Change Type

[ ] bugfix (+0.0.1)
[ ] minor (+0.1.0)
[ ] major  (+1.0.0)
[ ] refactoring (no version update)
[ ] test (no version update)
[x] infrastructure (no version update)
[ ] documentation (no version update)
[ ] other

Checklist before review

[x] I added everything I wanted to add to this PR.
[ ] [Code or tests only] I wrote/updated the necessary docstrings.
[ ] [Code or tests only] I ran and passed tests locally.
[ ] [Documentation only] I built the docs locally.
[x] My contribution is harmonious with the rest of the code: I'm not introducing repetitions.
[ ] My code respects the adopted style, especially linting conventions.
[x] The title of this PR is explanatory on its own, enough to be understood as part of a changelog.
[x] I added or indicated the right labels.

[ ] I added information regarding the timeline of completion for this PR.

[x] Please, comment on my PR while it's a draft and give me feedback on the development!

@smoia ready to review but pre-commit is not happy

@RayStick pre-commit is failing because it is not yet configured for this repository.
After #67 is merged then this could be merged as well, since it's already integrated to phys2bids (although order shouldn't matter).

@maestroque ah great, thanks for the context! Will wait for #67 then

@RayStick #67 is now merged! You could now pull from the master branch, and this should be ready to go

Thank you @maestroque!

:rocket: PR was released in 0.4.0 :rocket:


Questions about differentiable augmentation

Dear,
Thank you for your great work. I am planning to use your method to my small dataset with DCGAN. But there are two questions about the differentiable augmentation.

In your paper, you mentioned that “DiffAugment” T requires to be differentiable since gradients should be back-propagated through T to generator.  So do you mean that any augmentations on images are differentiable and we do not need to prove this?

In your code 'DiffAugment_pytorch.py', you use two transpose, before and after augmentation respectively, but I don't the reason. So could you please explain it and can we directly use augmentations without transpose.

The augmentations you use do not include flipping and rotating. Could you please tell me what's wrong with them?

Best regards
Rui Guo

Almost any augmentation can be made differentiable with proper implementation.
It's used to convert between channel-first (NCHW) and channel-last (NHWC) format. So please confirm the format you are using and select the right version.
We directly apply flipping to augment only the real images since it rarely changes the target distribution. Rotation can be helpful but not always (maybe too strong), so we want to keep the simplicity.

Thank you very much for your explanation. It's clear now.


Google.EarthPro version 7.3.4

[x] Have you signed the Contributor License Agreement?
[x] Have you checked that there aren't other open pull requests for the same manifest update/change?

[x] Does your manifest conform to the 1.0 schema?

Note: <path> is the name of the directory containing the manifest you're submitting.

Microsoft Reviewers: Open in CodeFlow

Wrong format for the version number


KCL-294 - upgrade to MAPI v2

Motivation
Fixes #50 and #53

[x] Merge URL Builder
[x] Validate Elements values in language variants in tests
[x] Try to remove custom custom serializer - covertToDynamicObject, DynamicObjectJsonConverter (#29 - works in Management v2 - validate with strongly typed models)
[x] Add collection identifier
[x] Remove SiteMap from SDK (incl tests) - it is deprecated
[x] Transform dynamic element to Strongly type models (value based on Generic element, reference object is a POCO class)
[x] Cover all endpoints from #50

I think these three are still missing (see https://github.com/Simply007/kontent-migrations-boilerplate-net/blob/master/Migrations/05_SampleMigrateAuthors.cs#L25-L31)

GET /{project_id}/types/{type_identifier}/variants
GET /{project_id}/types/{type_identifier}/components
GET /{project_id}/types/{type_identifier}/collections

It might be nice to mark methods with the URLs somehow for better coverage verification

[x] Adjust Model Generator
[x] Modify ModelProvider to be able to work with rich text, multiple-choice, and URL slug elements
[x] Walk through the differences among MAPI v1 and MAPI v2 (at least from here https://docs.kontent.ai/changelog/product-changelog?show=mapi&breaking=true#a-changes-to-management-api-v2)
[x] Revalidate namespaces for Kentico.Kontent.Management.Models.* - specifically  Kentico.Kontent.Management.Models.Items -> Kentico.Kontent.Management.Models.Identifires and revalidate everything else.
[x] Backup project a9931a80-9af4-010b-0590-ecb1273cf1b8 and replace the local backup in the repository (2 new elements added to article -> Rating(NumberElement) + SelectedForm(CustomElement))
[x] Finish complex elements support: assets, multiple-choice taxonomy, linked items a rich-text
[x] Think about unifying all Identifiers to Reference
[x] Do we want to have strongly typed elements in RichText elements property? -> #77
[x] Cover searched value for custom element
[x] Rename ContentItemVariants to LanguageVariant as in https://github.com/Kentico/kontent-management-sdk-js/blob/master/lib/models/language-variants/language-variant.models.ts#L19
[x] Match method names with JS SDK: https://github.com/Kentico/kontent-management-sdk-js/blob/master/lib/client/imanagement-client.interface.ts
[x] Fix test extended in https://github.com/Kentico/kontent-management-sdk-net/pull/67/commits/a480e281335eef44e8e6551ccb4ec5c8dbfd7301 (Options is Enumerable for Multichoice element)

Checklist

[ ] Code follows coding conventions held in this repo
[ ] Automated tests have been added
[ ] Tests are passing
[ ] Docs have been updated (if applicable)
[ ] Temporary settings (e.g. variables used during development and testing) have been reverted to defaults

How to test
If manual testing is required, what are the steps?

We won't transform dynamic elements to strongly typed models as of now. We keep them dynamic and use some kind of workaround in order to be able to access them by codename.

Closing the pull request draft.
We will work on vNext branch until the version is stable and ready for the final release.
All issues to be covered in this version is in vNext milestone


Getting user access_hash

Hi
I'm developing some customer service bot. People send Telegram messages to the service and the service needs to auto reply. But these people are not in the contact list of the service so I need to use TLInputPeerForeign to send a message to them. On receiving a message I can see the user_id but not the access_hash. How can I get the access_hash of a user?
Thx

Hi. How i can convert TLAbsUpdates to Dialogs

Hi. How i can convert TLAbsUpdates to Dialogs
What dialogs?

Can you please send me compiled working code to my email<EMAIL_ADDRESS>I shall be grateful to you

Hi,
How can we get channels messages without joining it  (and so it wouldn't be added to the user's Dialogs)?
It's possible in the telegrams' apps, when you click on a channels username any where (@channel_user).

How get access_hash for supergroup via bot?


Fix done button color in the dark mode

This is related to #46
fix the  Done  button text color in the dark mode state.

The fix should rather be to replace Button with NiaFilledButton[https://github.com/android/nowinandroid/blob/main/core-ui/src/main/java/com/google/samples/apps/nowinandroid/core/ui/component/Button.kt#L54]. Button(colors = ...) and Text(color = ...) also needs to be removed. NiaFilledButton has the correct colors for disabled state.

The fix should rather be to replace Button with NiaFilledButton[https://github.com/android/nowinandroid/blob/main/core-ui/src/main/java/com/google/samples/apps/nowinandroid/core/ui/component/Button.kt#L54]. Button(colors = ...) and Text(color = ...) also needs to be removed. NiaFilledButton has the correct colors for disabled state.

I changed to NiaFilledButton

Thanks! Can you please confirm it looks okay now with a screenshot in dark mode / button disabled?

Thanks! Can you please confirm it looks okay now with a screenshot in dark mode / button disabled?

Sure, I will take screenshots in light mode and dark mode.

Please run spotlessApply on your code to fix formatting errors!

@JolandaVerhoef Done


Keys not binding

(I got it to work about 2 minutes after posting this)
I am having an issue where the pop-up comes up, but I cannot set a key binding.  It does nothing when I press any/many keys.  I put it into windows borderless mode and removed all overlays, my anti-virus shows no events related to Cyberpunk.

how u managed to make it work?


Extension Installation issues (multiple) on IPython 3.1.0

sorry for this noise but I hope it might help...
I’m using IPython 3.1.0-dev
I’ve been working with installing the IPython-notebook-extensions
I have run into numerous issues, some of which I have worked through and some not.
Normally I’d try to open specific one by one issues but in this case I think this format may be better?
The doc in the wiki incorrectly refers to IPython-notebook-extensions-3.x as a directory name. It should be IPython-notebook-extensions. unless the helper function works (not for me)
There is a helper function in IPython that will do this automatically for you:
import IPython.html.nbextensions as nb
ext= 'https://github.com/ipython-contrib/IPython-notebook-extensions/archive/3.x.zip'
nb.install_nbextension(ext)
This command fails with a security error Permission denied: '/usr/local/share/jupyter'
I don’t see a way to run sudo for this.
The python-markdown extension suggest modifying ipython_nbconvert_config.py which I cannot locate. It also suggests In order to have nbconvert show the preprocessed output, copy thepymdpreprocessor.py file to a location in your PYTHONPATH however if my path has '/home/tom/ipython/IPython/extensions' is this not suffecient?
I was completely unable to get the graphical config working:
Instructions:
Add the following lines to your 'ipython_notebook_config.py' file (inside your profile directory, e.g. ~/.ipython/profile_default/):
I have no ipython_notebook_config.py file….?
So.. since this does not work, I cloned the branch repo and placed it in both the /home/tom/ipython/IPython/extensions and /home/tom/.ipython/nbextensions
Surely only one of those is right!
I have gotten Python Markdown running and Hide input going in the notebook (the doc refers to hide_input_all which does not seem to exist which is fine by me) but can't get the nbconvert to incorporate for printing (export to Latex)

Slowly, I have worked through it all or at least mostly. Some of the comments may or may not help someone to clarify the docs? I'm not quite up to it...

I found that using nb.install_nbextension(ext,user=True) helps with that permission denied error. This installs to the user's local dir instead of system wide in usr/shared/juypter