1>------ Erstellen gestartet: Projekt: DuckOS, Konfiguration: Debug Any CPU ------
1>DuckOS -> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\netstandard1.5\DuckOS.dll
2>------ Erstellen gestartet: Projekt: DuckOSBoot, Konfiguration: Debug x86 ------
2> Invoking il2cpu.exe "DebugEnabled:True" "StackCorruptionDetectionEnabled:False" "StackCorruptionDetectionLevel:" "DebugMode:Source" "TraceAssemblies:" "DebugCom:1" "UseNAsm:True" "OutputFilename:C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\DuckOSBoot.asm" "EnableLogging:True" "EmitDebugSymbols:True" "IgnoreDebugStubAttribute:False" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Core.Plugs.Asm.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Core.Plugs.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Debug.Kernel.Plugs.Asm.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.HAL.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.System.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.System.Plugs.dll" "References:C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\netstandard1.5\DuckOS.dll"
2>C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Build\VSIP\Cosmos.targets(39,5): error : Error occurred while invoking IL2CPU.
2> Executing command line "C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Build\IL2CPU\IL2CPU.exe" "DebugEnabled:True" "StackCorruptionDetectionEnabled:False" "StackCorruptionDetectionLevel:" "DebugMode:Source" "TraceAssemblies:" "DebugCom:1" "UseNAsm:True" "OutputFilename:C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\DuckOSBoot.asm" "EnableLogging:True" "EmitDebugSymbols:True" "IgnoreDebugStubAttribute:False" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Core.Plugs.Asm.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Core.Plugs.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.Debug.Kernel.Plugs.Asm.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.HAL.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.System.dll" "References:C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Kernel\Cosmos.System.Plugs.dll" "References:C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\netstandard1.5\DuckOS.dll"
2> Working directory = 'C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462'
2> Loaded : DebugEnabled
2> Loaded : StackCorruptionDetectionEnabled
2> Loaded : DebugMode
2> Loaded : StackCorruptionDetectionLevel
2> Loaded : TraceAssemblies
2> Loaded : DebugCom
2> Loaded : UseNAsm
2> Loaded : OutputFilename
2> Loaded : EnableLogging
2> Loaded : EmitDebugSymbols
2> Loaded : IgnoreDebugStubAttribute
2> Loaded : References
2> Loaded : AdditionalSearchDirs
2> Loaded : AdditionalReferences
2> Executing IL2CPU on assembly
2> Detecting fields for type 'Cosmos.Debug.Symbols.FIELD_INFO'
2> Detecting fields for type 'Cosmos.Debug.Symbols.FIELD_MAPPING'
2> Detecting fields for type 'Cosmos.Debug.Symbols.MethodIlOp'
2> Rings: Start check
2> Rings: Assembly 'Cosmos.System'
2> Rings: Ring = System
2> Rings: Dependency 'Cosmos.HAL'
2> Rings: Ring = HAL
2> Rings: Assembly 'Cosmos.Core.Common'
2> Rings: Ring = Core
2> Rings: Assembly 'DuckOS'
2> Rings: Ring = User
2> Rings: Dependency 'Cosmos.System'
2> Rings: Ring = System
2> Rings: Dependency 'Cosmos.HAL'
2> Rings: Ring = HAL
2> Detecting fields for type 'Cosmos.Debug.Symbols.AssemblyFile'
2> Detecting fields for type 'Cosmos.Debug.Symbols.Document'
2> Detecting fields for type 'Cosmos.Debug.Symbols.Method'
2> Error: Exception: System.Exception: Assembly 'DuckOS' is in ring User(3). It references assembly 'Cosmos.HAL' which is in ring HAL(1), but this is not allowed!
2> at Cosmos.IL2CPU.AppAssemblerRingsCheck.Execute(ILScanner scanner, Assembly entryAssembly) in C:\Users\Administrator\Cosmos\source\Cosmos.IL2CPU\AppAssemblerRingsCheck.cs:line 105
2> at Cosmos.IL2CPU.CompilerEngine.Execute() in C:\Users\Administrator\Cosmos\source\Cosmos.IL2CPU\CompilerEngine.cs:line 199
2> Loaded assemblies:
2> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\Cosmos.Core.Plugs.Asm.dll
2> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\Cosmos.Core.Plugs.dll
2> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\Cosmos.Debug.Kernel.Plugs.Asm.dll
2> C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Build\IL2CPU\Cosmos.HAL.dll
2> C:\Users\Alexander\AppData\Roaming\Cosmos User Kit\Build\IL2CPU\Cosmos.System.dll
2> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\Cosmos.System.Plugs.dll
2> C:\Users\Alexander\source\repos\DuckOS\DuckOS\bin\Debug\net462\DuckOS.dll
2> Errorred
2> IL2CPU invoked with DebugMode='Source', DebugEnabled='True',StackCorruptionDetectionLevel='{NULL}', TraceAssemblies='{NULL}', IgnoreDebugStub='False'
2> IL2CPU task took 00:00:12.1252890
2>Die Erstellung des Projekts "DuckOSBoot.Cosmos" ist abgeschlossen -- FEHLER.
2>
========== Erstellen: 1 erfolgreich, 1 fehlerhaft, 0 aktuell, 0 übersprungen ==========

I get this error everytime I try to build my project. But I tried to change this ring thing but it doesn't work.

This is my Kernel.cs:

using Cosmos.Common;
using Cosmos.HAL;
using System;
using System.Collections.Generic;
using System.Text;
using Sys = Cosmos.System;
[assembly: Ring(Ring.System)]

namespace ExampleOS
{
public class Kernel: Sys.Kernel
{

    protected override void BeforeRun()
    {
        // Any code here
    }
    
    protected override void Run()
    {
        // Any code here
    }
}

}

I don't know how to set this ring. Please help me!

You can register TLDs as separate shards, like the “.com” shard, and have experiments on various DNS rules, while still having the same unified system, if we have shard discovery.

Include notes on solving Zooko's triangle, emphasis on how it's better than NameCoin because you can allow for mutability and query for the current value now using the application-state merkle-hash, and Tendermint light-client SPV.

GnuClear IBC differs from ILP's original whitepaper spec in a few ways...

• Token centricity, as you say. IBC is also about general packets, but it's also got optional packet confirmations. IBC also drops the whole thing about hashlocks, because hashlocks are cool but IMO it should really be its own thing. I could be convinced otherwise. IBC packet acknowledgement can also handle multihops, although the GnuClear whitepaper doesn't specify it.
• ILP's oracle mode as far as I know doesn't handle oracle-set (validator-set) changes, nor arbitrary weighting.
• IBC is more Tendermint specific in many respects, from the binary format of the vote, to the fact that it's signing block-hashes.
• GnuClear is much more about how everything ties into the hub, which maybe can be viewed as a specific application of ILP's oracle mode.

clarify role of abci for applications and in the context of ibc mechanism.

what does an app dev need to do to plug in?

also, what about the mess of client software that will need to be coordinated for different shards

It's a chunk of text that may get in the way of understanding the gist of GnuClear.

It should be possible to write a TMSP app that blocks until an IBC Commit tx gets an ACK or a tImeout.

It should also be possible write a non blocking IBC Commit call.

We need clear way to find all the specs that comprise the Hub.

Some requirements:

• Tendermint spec should stand on its own in tendermint repo
• Go-Wire should stay in Tendermint - the SDK spec can refer to it and must include the prefix bytes for all its types
• Complete specification for the Hub should be in the SDK repo, where the modules will also be.
• This repo simply needs to guide folks as to the above

This includes:

• go-wire encoding - needs to be updated for go-wire:sdk2
• Tendermint
  • Blockchain
  • All reactors
  • P2P networking
  • ABCI use (!)
• Hub tx, state, account structure (ie. how it will use the SDK), including SendTx
• Staking and Fees module (ie. what's been "gaia" until now) and all Txs: see first draft spec.md and refactor for clarity spec2.md
• Governance and its Txs
• IBC and its Txs - see Frey's papers, need to be translated to simple markdown spec
• Additional constraints (AiB vesting, launch parameters, etc.)

Software Development

• Tendermint
• Gnuclear hub: Governance
• Gnuclear hub: IBC
• Application Integrations: Ethereum
• Application Integrations: ZCash
• Application Integrations: Bitcoin
• MerkleEyes, or Patricia-Trie integration
• Burn/donation EVM contract

Security

• Continuous bug bounties

Deployment

Documentation

Legal

• SEC analysis
• CFTC analysis
• FinCen analysis
• Document that burners/donators must sign
• Constitution

YubiHSM2 mentioned in https://github.com/cosmos/cosmos/blame/master/VALIDATORS_FAQ.md#L239 as one of the methods to handle key management. But I can't find some instruction how to bind YubiHSM and Cosmos.
How can I do it?

Upon such an exploit, the validator and delegators will become inactive, HackPunishmentRatio (default 5%) of everyone's atoms will get slashed, and HackRewardRatio (default 5%) of everyone's atoms will get rewarded to the hacker's bounty address. The validator must recover the remaining atoms by using their backup key.

Who is "everyone" here?

Document slash ratio, most issues of validators shouldn't end up with 100% slashing, esp if due to bugs or exploits.

Do an analysis in terms of security offered vs slash %.

Eventually I imagine this % will inch higher, as the technology becomes more mature. But we're just not there yet, and we can probably do better by being a bit more forgiving.

Might be a selling point for Cosmos:

https://bitcointalk.org/index.php?topic=1319681.msg17096880#msg17096880
https://bitcointalk.org/index.php?topic=1739268.msg18057128#msg18057128
https://coinreport.net/tree-chains-vs-side-chains-controversy-explained/ (archived) ← merged mining is incentives incompatible insecure
#47 ← ditto insecurity of any “fraud proofs” between separated consensus shards or chains

Excuse me, I am not supposed to post here. Thought I'd share and then leave again.

P.S. if you can't solve the homework problem, you'll find the answer in section "7.2.6 Unbounded Transaction Formats Without Forks" of my whitepaper whenever it is published.

Cosmos now refers to the entire ecosystem, not just the hub.

In the whitepaper in the intro, it says

See FIGURE (TODO) for details.

I am getting MongoDb-API- Operation exceeded time out exception on performing aggregate operation on 1 million documents . I has given through put of 100000 RU's. Still giving the same exception.
I has enabled Aggregate pipeline and wire protocal as well in preview.

But same query is working with normal mongodb.

Some of the text can be condensed and included in the whitepaper.

http://tendermint.com/blog/critique-merkle-dao-democracy/

Includes a justification for a market (not necessarily a deep or actively traded market) for gnuts.

This predetermined validator set sounds sketchy as hell. Who gets the validators, and why are they immune from being kicked out by someone who is staking more?

PoS already has distribution issues, but crowdsales are pretty well accepted at this point and you can just distribute coins with one of those. But I think that you will mostly face criticism about these genesis validators. Why not just let anyone stake who wants to, and kick off those people who don't have enough staked?

The fact that you need an arbitrary numerical limit on the number of validating boxes seems like a major weakness also. Might be interesting to look at some softer limit where those with less money staked get left out of the process sometimes?

I know ripple act like a intermediate currency to any other crypto or fiat currency, but what the difference between ripple and cosmos?

Let governance reassign foundation status to new entity.

Also document what happens when consensus breaks.

Hi,I'm a beginner of blockchain,interesting int cosmos.But I feel difficulty and misty at concept,couldn't find some install or development documents below to run a demo.Can you give me a favor?Hi,I'm a beginner of blockchain,interesting int cosmos.But I feel difficulty and misty at concept,couldn't find some install or development documents below to run a demo.Can you give me a favor?

In our docs and communication, we should use weight instead of voting power for validators participating in consensus.

That's because voting power could be confused with governance's voting power.

• weak synchrony vs asynchrony
• why better than pbft (currently this seems to be spread through previous work)
• clarify accountability, inability to hold liveness attacks accountable
• slashing 1/3 may not be enough to stop a massive double spend, but once the fork happens the network will stop and reset without those validators

(thanks amiller)

I was discussing this on slack last week and ethanfray suggested that I raise an issue here.

I'm looking for an effective way to have my own Blockchain(cosmos zone) implemented using proof-of-stake. Will there be any library/frameworks made available for proof-of-stake protocol that is being implemented by Cosmos? Is the protocol even finalized so that I can implement a library or is it still in works?

Also, I would like to understand how to distribute my own token without any ICO. I was thinking if I should use a hybrid method- first use proof-of-work and then shift to proof-of-stake when such a library is ready from Cosmos. Is this a recommended approach by the Cosmos team? Or, is it mandatory that I issue some token before the genesis of my blockchain?

I would like my blockchain to be public and distributed.

Here's my understanding of DEX order matching: the design described in the DEX whitepaper uses centralized exchanges (CEX's) to facilitate order matching in a way where users can choose which orderbook to use, without giving any third parties direct custody of the funds. When a user submits an order, the CEX replies with a signed receipt including an incrementing sequence number. If the CEX ends up processing orders differently than they committed to in the receipt, the user can prove the fraud by broadcasting the receipt and the CEX's collateral will be slashed.

However, there is an issue as this still allows CEX's to choose the transaction order in a way that benefits themselves (a practice known as front running): the order of recent transactions can be chosen before the CEX creates and signs the receipt. For example, if 50 buy orders are submitted to the CEX in the span of 1 second, the CEX can place its own buy order before the others knowing the price will be pushed up, then afterward create and sign valid receipts. Since it all happened it 1 second, the users don't think anything fishy is going on because they got their receipt in a timely fashion, and no fraud can be reported because the CEX followed the order it committed to in the receipts.

I'd like to propose a simple change to solve this issue: the user first submits a blinded order to the CEX, e.g. the hash of their buy or sell order, then the CEX creates a receipt based on this without knowing the contents of the order. Once the user receives a valid receipt, they will send the unblinded contents. Since the CEX commits to an order before knowing what trades users are making, it has less information and is less able to front-run.

AppendTx -> DeliverTx

https://cosmos.network/whitepaper

• Include some text on top that shows the version, and how the whitepaper is expected to change much over the coming weeks, so the user checks the whitepaper for updates, e.g. weekly
• Include more detail in the roadmap, e.g. about what code needs to be written still
• Link to existing code where it exists. Governmint is too bit immature to link, imo.

There are three problems that I see, and possible changes:

1. The Bitcoin issuance is slightly flawed, in that the Bitcoins given to the GnuClear foundation can be recycled to get more Gnuts, thus centralizing the ownership to the GnuClear foundation. This can be mitigated with transparency showing where the money is being spent. If the bitcoins are clearly misused, the gnut holders can vote to change the foundation address.
2. There isn't enough funding in the genesis for the foundation. I mean, can get by only on salary for two or three people, but it would help to make additional hires as well, and to do that we need a bit of capital infusion.
3. There ought to be a pool for bounties, so non-foundation individuals and entities can help with various work loads.

For points 2 and 3 I suggest we have a bit of premine for the foundation, with the expectation of transparency, say of 15% of the total allocated gnuts on genesis day, to get diluted further by bitcoin issuance, where 2/3 goes to early funding of the foundation, and 1/3 goes to bounties over time. What do you think?

From: http://tendermint.com/blog/on-thedao-and-blockchain-governance/

Satoshi Nakamoto wrote that Bitcoin can handle up to 1⁄2, but that only works because clients are suppose to wait on the order of an hour for confirmation, thereby allowing the network to be modeled as a (slow) fully-synchronous system.

Problem 1

Reading the wiki, I see the following statement:

It can be shown that if n is the number of generals in total, and t is the number of traitors in that n, then there are solutions to the problem only when n > 3t and the communication is synchronous (bounded delay)

That last bit, "and the communication is synchronous", seems to stand in contrast with the statement made in the blog; i.e. indicating that even a synchronous environment can only handle 1/3 byzantine actors.

Problem 2

There's a fundamental difference between BFT/PoS consensus systems and PoW, at least in how they think/talk about/model consensus. One is based on % of _actors, while the other is based on % of _computation. Those are very different things, and that difference is what leads to the number 51% in PoW, and 67% in BFT/PoS.

See discussion in PR: #80

Items needing decisions:

• various parameter values
• use Urgent or not
• deposit recovery
• software upgrade process
• structures in storage

The spec itself should also be refactored somewhat to provide clarity re the stored data structures and the transactions

• write about non-validator nodes, importance
• write about forks, slashing, effect on shards, insurance, etc
• write relationship between hub validators and shard validators
• economic estimates (?)
• should source shards use set rates or tranches (???)
• maybe change the inflation schedule to be exponential
• document procedure for crowdfund referrals.
• TODO

e.g. 80%.

The original 20% may be a bit too high esp considering the unbonding period.

After running the init command I edit the config.toml file to configure the block interval. It does not look like it changes anything. The empty blocks are still being created every second.

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?

1. "Miners" are now generally public, known individuals rather than anonymous individuals.
2. Secret attacks are no longer possible
3. Alternative chains are not possible
4. 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

No commits in a while—looks like the project is dead, no ?

@jaekwon @ebuchman

Building a decentralised exchange is obviously a very ambitious and challenging project. I think the whitepaper does a good job explaining the limitations of AXC transactions and the obvious problems with centralised exchanges in general.

I am missing one thing however: A comparison between your approach and the one the Waves platform is taking with their attempt of building a (sort of) decentralised exchange with centralised matching and decentralised settlement. In the Cosmos Plan it says: "The Cosmos DEX provides fast centralised matching with distributed custody of funds", which sounds quite similar to me.

You mention the strong network effect in the exchange world. If Waves is successful at creating their DEX (which is scheduled to be ready for release in the coming weeks I believe), what will the Cosmos DEX offer that would incentive traders to change exchanges? As far as I understand both projects claim that they are going to offer all the benefits of a centralised exchange (especially in terms of speed and using trading bots).

In order to add a new currency to the Cosmos DEX each currency would need its own zone connected to the Hub. In order to compete with Poloniex in terms of coin variety you would currently need around 80 zones. What would be the timeframe for that? Some of those zones also might not be used much and therefore not be very profitable for validators. How can you make sure those zones are still supported when there is a plan to loosen regulations regarding the validators choice which zones to support.

In order to transfer value between shards using the HUB, users on the Shard will generate an IBC packet to the HUB transferring the value to another shard. This IBC packet must contain a proof or collision to an internal state of the shard so that the Hub can verify that the IBC packet represents a valid transfer of value. This will impact both the validation work of the HUB and the minimum internal state that the shard must maintain.

Track work on designing this specification in this issue.

Hi:
can I install the whole cosmos with the code in github, do you have some Installation document?

thank you.

Apologies in advance if this has already been discussed else where and please do link me to any such prior discussion.

I've read:

https://github.com/cosmos/cosmos/blob/master/PURPOSE.md
https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#the-hub-and-zones
https://github.com/cosmos/cosmos/blob/master/WHITEPAPER.md#inter-blockchain-communication-ibc

As I understand it, transacting between blockchains requires the source (sending) blockchain to confirm the transaction. This must be the case because there is no total order amongst all blockchains.

Thus afaics, censorship in the source (sending) blockchain can censor (hold hostage) the ability to make the transaction to the destination (receiving) blockchain. Am I correct?

Afaics, the conceptual problem is that to the extent this is being proposed as a sharding-like scaling solution, this security flaw kills the fungibility of shards. So you can't fungibly implement side-chains where the same token is transferred between blockchains. My intuition has always been (many posts at Bitcointalk) that side-chains are a fundamentally insecure concept, afaics recently I got confirmation of that for PoW, and I have the same intuition w.r.t. to implementing them with some PoS BFT as is the case here. Btw, my original generative essence intuition was that a fungible token is itself a total order, thus it should be impossible to shard it into partial orders without a total order on finality (of ordering).

It is not sufficient to argue that if a user moves the token off to a side-chain, then it is fungible when they move it back to “main-chain”, because there is no main-chain and also because the source blockchain could even double-spend if the ²/₃ of the validators are malevolent. Thus the attacker creates inflation of the money supply. Afaics, conceptually side-chains reduce the security of all the blockchains to the security of the most attacked side-chain.

So this is not the same category of fungibility weakness alleged against Bitcoin due to lack of anonymity and thus the theoretical ability of authorities (or 51% attacker) to enforce black/white/red-lists. The vulnerability I'm alleging here is the internal security against double-spends. In effect, the risk that each hodler's tokens haven't been double-spent is reduced to the security of the weakest side-chain. So it is much more catastrophic (more on the order of a scorched earth total destruction because anyone can attack the entire system of side-chains from any weak side-chain) than the anonymity fungibility issue which is an external social, political issue. This affects side-chains only (i.e. Cosmos and Blockstream's side-chains proposal), not Tendermint nor current version of Bitcoin.

Tangentially I am sure you know (and please do correct me if I have any of the details incorrect), but I will mention it for the benefit of other readers that if ¹/₃ or more of the validators are malevolent they can censor some or all transactions but afaik if the faulty validators are less than ²/₃, they are statistically identifiable but less reliably so as approach ²/₃. IoW, if ²/₃ of the validators are malevolent, they can censor and it is not objectively provable they are doing so, only circumstantial evidence can be supplied, which afaics means in that ²/₃ malevolent case your community hardfork proposal is unambiguous and subject to manipulation.

_{Sorry to drop a bomb on your project. I seem to have a habit of doing that whether it be shooting down the anti-jamming blacklist idea for CoinJoin in 2013 (incongruence: blacklist ≢ anonymity) or other examples hence.}

_{Btw, I think I have a secure solution to the scaling problem, which is what brings me around to your project while I am writing my whitepaper.}

There is an opportunity to very briefly identify Tendermint as related to PBFT solutions (http://tendermint.com/blog/tendermint-vs-pbft/) and provide external academic references to blockchain network architectures intermixing BFT and PoW from that field of research (e.g., http://vukolic.com/iNetSec_2015.pdf).

From my understanding, this is a BFT/PoW/PoS network architecture.

If this understanding is correct, I would make this clarification in the motivation section that opens the paper.

Also, I think the external Vukolic reference provides valuable context for the reader.

If you agree, I'll make whichever changes and issue the pull request.

@jaekwon @ebuchman

The Cosmos Plan describes atoms as "a tool, like Bitcoin miners are a tool". Delegators who do not have enough atoms to become validators themselves have to delegate their atoms to one of the validators in order not to be affected negatively by the high inflation (1/5 of the total number of atoms every year acoording to the Plan - or 1/3 according to the Whitepaper). Either way this is a huge number that in my opinion deserves an explanation on why it was chosen and the expected impact it will have on the Cosmos ecosystem. Is it likely that Cosmos will expand accordingly (especially if we are looking at it long term)? An expected yearly growth of 1/3 or even 1/5 has the potential to put immense pressure on the project.
The Whitepaper also does not yet clarify if that 1/5 or 1/3 of atoms will be distributed across the year (daily, weekly or monthly) or at one single point after 365 days.

I assume one of the reasons for choosing this system is to encourage atom holders to actively participate in the network as the unwillingness to do so would result in their share diminishing significantly each year. This brings up a handful of questions however.
The Whitepaper does not mention the plan of creating an infrastructure for delegators to find out reliable information on validators or other delegators (who want to become validators). Will there be a system that gives the typical atom holder (with no chance of ever becoming a validator due to financial and technical limitations) the chance of finding out information on the current validators? (F.i. how they have voted so far, if they have been penalised in the past etc.) In other words, how can the average delegator find out whom to support and trust? Without such a system people will most likely tend to delegate their atoms to the biggest validators, as this feels safe, giving those validators even more power in terms of dominating the direction of the Cosmos project and potentially changing the rules to their favour (via proposals on changing the constitution). The current situation at Lisk gives a good example of how messy something like that can become.

It also sounds like a delegator will constantly have to monitor the work of the chosen validator, as the delegated atoms will become inactivated and eventually unbonded if the validator is either replaced or penalised. This might not encourage people with smaller amounts of atoms to get involved.

The following dependency:

vendor/github.com/ethanfrey/hid/hid_darwin.go

contains overflow errors. Particularly, the error messages while calling glide install are:

github.com/cosmos/gaia/vendor/github.com/ethanfrey/hid

vendor/github.com/ethanfrey/hid/hid_darwin.go:40: constant 18446744073172681404 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:42: constant 18446744073172681405 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:44: constant 18446744073172681406 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:46: constant 18446744073172681407 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:48: constant 18446744073172681408 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:50: constant 18446744073172681409 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:52: constant 18446744073172681410 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:54: constant 18446744073172681411 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:56: constant 18446744073172681412 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:58: constant 18446744073172681413 overflows C.IOReturn
vendor/github.com/ethanfrey/hid/hid_darwin.go:58: too many errors
? github.com/cosmos/gaia/cmd/gaia [no test files]
make: *** [test] Error 2

https://bitcointalk.org/index.php?topic=1607111.msg16156259#msg16156259

Good white paper.
I can read your Ambitious hope, center of whole chain.

Anyway,

"The full details of the protocol are described here". link has broken. easily correting .

Hi,

I installed Cosmos User Kit with .NET Framework 4.6.2 pre-installed but when I look in target, it shows me .NET Standard 1.5 and I don't know what I am doing wrong.

I agree with @zooko's recent issue on ZCashFoundation's repo that anything on GitHub will not be read by 99% of the population.

I'm maintaining aib-data which contains markdown and JSON content that is directly used (via the GitHub API) for cosmos.network, tendermint.com, and allinbits.com. Content on our websites are much more accessibly by the general populace and I strongly support making as much of cosmos/cosmos accessible via our web properties instead of letting them languish in obscurity here.

I propose moving over anything that we want to post on our websites over to that repository. For example, I had to painstakingly clean up VALIDATORS_FAQ.md for use on the website. The new copy is stored here. Let's delete the VALIDATORS_FAQ.md here in favor of that.

I can take charge of this reorganization initiative if no one else wants to. I think the papers written here need to be published in a more user-friendly format.

This issue is a subcomponent and is related to #73. Once this repo contains Cosmos Hub, all of the papers here need to be vacated anyway.

What is the relation of genesis validator member set to the 67-member validator set? (More specifically, are any of these 67 total validator spots occupied by anyone other than a genesis validator member?)

How is validator set membership managed over time?

Just a sentence or two addressing the mindset behind these (without technical details) may be sufficient to address these questions.

Getting this error

ERROR: checkTx failed: (65545) === ABCI Log ===
Codespace: 1
Code: 9
ABCICode: 65545
Error: --= Error =--
Data: common.FmtError{format:"cosmosaccaddr1gv5vj5men6r8r73aywdzadafy9y06tvfwmvy fx", args:[]interface {}(nil)}
Msg Traces:
--= /Error =--
=== /ABCI Log ===
https://www.screencast.com/t/6KhJ6LMa90B

Following this document : https://cosmos.network/docs/validators/validator-setup.html#running-a-validator-node