https://github.com/Dexaran/DecentralizedEXchange

I've seen that you prefer Viper adoption on Classic rather than solidity promotion. I'd like to recommend to start with creating an analogue of Remix online compiler.

This thread preserves the history of Callisto Network launch, initial roadmap and project goals as well as provide information on its current development stage.

Links

Smart-contract auditing department of CLO & ETC (source code)

Treasury financial report

Callisto.network web page

Callisto whitepaper

Callisto original announcement

CallistoCrypto subreddit

Callisto on Twitter

Callisto Network stats

Roadmap

• Callisto core implementation. (reference)
• POA testnet launch. Callisto-TEST RPC node launch at http://testnet.callisto.network/
• Callisto-TEST support at ClassicEtherWallet. (reference)
• Callisto whitepaper announcement (whitepaper revision 1.2a).
• Warn exchanges about the upcoming CLO distribution.
• Create a snapshot of Ethereum Classic blockchain at block 5500000(snapshot repo)
• Testnet 2.0 (snapshot balances are distributed via the genesis block)
• Callisto Blockchain explorer (testnet explorer)
• Testnet 3.0 (snapshot balances are manually distributed to avoid huge genesis blocks)
• Launch Callisto mainnet (initial phase).
• Callisto mainnet implementation at ClassicEtherWallet.
• Official media resources on-chain registry (smart-contract)
• Establish an "Official Smart-contract Auditing Department" using CLO coins allocated for further development of the initial phase of Callisto.
• Deploying the registry of officially audited smart contracts. [Requires update regarding the CLO-EOS integration]
• Official security audit of the cold staking protocol implementation.
• Warn exchanges and mining pools about the upcoming CLO hardfork №1 (planned hardfork: 11 Nov, 2018).
• Callisto mainnet hardfork №1. Cold staking protocol implementation.
• Support cold staking UI at ClassicEtherWallet.
• Official security audit of the smart-contract governance system.
• Deploying the smart-contract governance system.
• Callisto mainnet hardfork №2. Smart-contract governance system and development funding proposals implementation.
• Decentralized registry for on-chain management of media resources is deployed (https://github.com/Dexaran/media-resources-registry)

After the CLO Hardfork №2, the development will be based on the built-in governance system and the proposals that will be accepted by the stakeholders.

Hello,

I found one project that proposes security enhancement to ethereum network, but I think Ethereum Classic can also benefit from this idea.
https://www.etherblue.org/whitepaper

https://gitter.im/SmartPool/Lobby
https://github.com/SmartPool
http://smartpool.io/

What should be done:

• Create and deploy smart-contracts (I will do it by my own). Link to the repo
• Mining Pool CLlient that will collect mined shares. Source here: https://github.com/SmartPool/smartpool-client
• Web UI
• Create Ubuntu distributive with installed GETH CLassic, downloaded ETC blockchain up to 4100000 block (to make sync easier), installed and tuned Pool CLient, installed miner software (Claymore, ethminer etc. etc. )

Is there any forum for discussion of upcoming research going on ETC labs?

Scope

1. DexNS Frontend contract.

2. DexNS Storage contract.

Contract overview

This contract system is an implementation of Ethereum-based naming service.

DexNS Name is a special structure that contains address of the owner, address of the destination (Name will be resolved into this address), metadata, signature (Keccak-256 hash of the name).

Contracts must provide the following functionality:

1. Register string Names.
2. Manage Name content (addresses and metadata).
3. Display Name content: destination address, metadata, signature.
4. Transfer the Name ownership from one address to another, except that another smart contract that does not implement a special function onNameOwnerChanged can not become the owner of the name as a result of the transfer of ownership of the Name.
5. Assign/unassign Names to addresses if the address is the Name owner. This is needed for blockchain explorers to display Name instead of the assigned address.

Bug bounty

$8500 for finding a critical bug.

A critical error is an error that can be directly used as a result of which:

• A Name can be registered without payment.

• Already-existing, not expired Name can be re-registered to another owner.

• Name content can be managed by the address that is not currently an owner of the Name. (Name assignment can be managed by the address that is not currently an owner of the Name)

• The consequences of the expiration of ownership of a Name could be avoided.

• Other errors that can directly violate the workflow of contracts and lead to a breach of contract operability.

$2000 for security vulnerabilities and bugs, that could not be directly exploited but can affect contracts in some specific circumstances.

Any bugs that can occur in some specific circumstances and violate contracts workflow.

$100-500 for code flaws that can not violate contract workflow.

Any code flaw reports and suggestions that can improve DexNS contracts workflow. This bounty will be paid if the suggested solution will be implemented in final version of DexNS contract system.

Participate

Submit an issue at the DexNS contracts repo: https://github.com/EthereumCommonwealth/DexNS/issues

The first person who submits the issue bugreport will be paid if the problem reported is considered to be an error.

For any questions: [email protected]

ETHLance is the future of work - a no-fee marketplace for buying and selling workforce (freelancing). Would be great having it on the ETC chain. This could eventually be extended to include the whole district0x network.

https://ethlance.com/
https://district0x.io/

Ethereum Commonwealth

Ethereum Commonwealth is open for contributions, completely financially transparent development team with a decentralized DEX token voting decision making process. The following describes terms of contributions to Ethereum Commonwealth projects, defining milestones and submitting requests for payment.

Submitting a milestone proposal to Ethereum Commonwealth roadmap.

This section is for those who have a clear vision of how to improve Ethereum Classic protocol, infrastructure, ecosystem or build a valuable DApp or service on top of it.

To submit a proposal for Ethereum Commonwealth, go to the Roadmap issues and create a new issue. Place a title and briefly describe what exactly you want us to implement. Submit a new issue and leave it open.

We will review new issues and place a milestone label on development proposals. We will pick the most important issues and resolve them one by one as soon as we will finish our ongoing in progress projects.

If you have changed your mind and you no longer think that a submitted issue-proposal is worth resolving, then you should close the github issue.

Contributing to the development of a milestone proposal of Ethereum Commonwealth roadmap.

This section is for those who have a willingness to improve Ethereum Classic protocol, infrastructure, ecosystem, solve one of the important problems of Ethereum or just to work on someone else's proposal for the sake of payment.

Look for Ethereum Commonwealth roadmap issues that are marked with milestone label. If you have enough skills and a willingness to resolve one of them then you can comment your terms of service and payment request to the corresponding issue.

If your request is accepted, you can begin to contribute and receive your payment on specified terms. In case of conflict of interests or controversial situation you can submit a DEX token voting session to resolve it according to the default DEX voting decision making process: #1

• Those issues that are marked as milestone but not marked as in progress or finished are available for picking by third party contributors. You can submit your request for payment and terms of service at this issues.

• Those issues that are currently marked as finished do not represent any opportunity to contribute to. They are currently in final stage. If you have an idea of how to improve a finished project then you can submit a new issue-proposal and discuss it at the new issue.

• Those issues that are currently marked as in progress are currently in development stage and there are contributors that are already working on them. These issues do not represent opportunities for improvements by third parties.

A full history of Ethereum Commonwealth financial operations will be reflected here: https://docs.google.com/spreadsheets/d/1-ibJXI9IfrkKloLgN6RHxoXeCbdqa9mti1afTcO1BQk/edit#gid=979560349

ethereumproject/ECIPs#41

An opt-in decentralized court. Very useful in cases where smart contracts is not enough and non-biased human decision making is needed. It's also a good protection layer smart contracts can use if there is some issue, such as with theDAO, but this time it would be explicit in the contract that humans might get involved to intervene when there are mistakes in the code.

http://ethercourt.io/#/

• 1. Merge 3.10.2 MEW updates into ClassicEtherWallet
• 2. Make ETC node a default one on CEW
• 3. Color patch for MEW and CEW
• 4. Replace "MyEtherWallet" mentions by "ClassicEtherWallet" info on ClassicEtherWallet
• 5. Add default contracts and tokens
• 6. Crosschain ENS lookup (link)
• 7. Add DexNS support to CEW / make a patch to MEW (link 1)
• 8. Add ClassicMask support on CEW / make a patch to MEW
• 9. Improve modular ENS support on MEW and CEW
• 10. Adapt new token interface.
• 11. Add a multi-currency balance display. (link)
• 12. Support adding custom tokens by DexNS token names.

The goal is:

One GETH client that will support both Ethereum and Ethereum Classic networks. It should also support all the testnets defined in Ethereum Foundation's version of GETH.

How this should work:

Source code of GETH is located here: https://github.com/ethereum/go-ethereum

Geth classic should support an additional --classic flag:

$ geth --classic

Specifying the --classic flag should reconfigure your Geth instance a bit:

• Instead of using the default data directory (~/.ethereum on Linux for example), Geth will nest itself one level deeper into a Classic subfolder (~/.ethereum/classic on Linux). Note, on OSX and Linux this also means that attaching to a running testnet node requires the use of a custom endpoint since geth attach will try to attach to a production node endpoint by default. E.g. geth attach /classic/geth.ipc. Windows users are not affected by this.
• Instead of connecting the main Ethereum network, the client will connect to the Classic network.
• It should apply all the latest Classic changes as well. For example Classic monetary policy and block reward reduction as soon as it will be decided to implement it.
• In any other aspect this should behave as the default Ethereum's geth client.

Bug fixes

• UBQ network: can not generate transaction. TypeError: hex.substring is not a function at Function.ethFuncs.sanitizeHex. Works correctly in any other network.

• Gas autoevaluation bug: replaces gas twice when clicking "Generate Transaction" if the input amount is different from the autoevaluated gas limit.

• Adjust ECNS tx gasLimit to 570000. (Working TX (570k gas) / Failing default TX (520k gas))

• Evaluates hand-typed address as DexNS name. Relevant for adding custom token.

• Requires node to be added when adding a custom token. Throws node not found error when node is not found. Replace required node property of custom token with an optional node option. When node is not established (for example on Rinkeby testnet) set node to null.

• UBIQ node is down (fixed with EthereumCommonwealth/etherwallet#19)

I am wondering if it is possible to implement smart contract that allows to set withdraw limits on per day, week, month basis as addition security? Then the address owner can set the desired limits interacting with the smart contract.
Another use case can be repeated payments (for example each month) or payment on a certain date, like in the traditional banking.

The Ethereum Commonwealth and Callisto team adheres to the policy of financial transparency.

We keep a complete financial history in an open document so that everyone can review it. Financial operations will be described at the above document. Financial operations are verifiable by transaction hashes.

Each financial operation of Callisto Treasury will be documented until an autonomous governance system is created (Planned HardFork №2).

Each financial operation of Staking Reserve address will be documented until Cold Staking is implemented (Planned HardFork №1).

Old financial report: https://docs.google.com/spreadsheets/d/12b5JgL1veCAvV1yLhmxDva80Gz3pA0OVSPw_uTf9aEQ/

New financial report:

https://cloudflare-ipfs.com/ipfs/QmbXgrCu8H21uVuQNjtqTHo4zBF8kB5NMK6GYL32JVD8qx

Deprecated in favor of Enhanced Free-of-Charge Auditing system.

DexNS, the first crosschain decentralized naming service for human-readable address resolutions and token-related services scalability improvement tool, has successfully passed the bug bounty and final changes were applied.

DexNS bug bounty reference.

DexNS final version reference.

DexNS contracts are currently deployed on ETC mainnet. We are transferring names from the trial version now. Service will be officially announced at 25 Dec, 2017.

A final service will take a fee of 0,01 ETC per Name to resolve DDOS issues. All the fee funds would be distributed according to the Ethereum Commonwealth revenue distribution process.

Announcement

Ethereum Classic address-to-address messaging system release. Messaging system represents a smart-contract basic on-chain communication service wich allows to contact any other participant of the network absolutely securely.

The Messaging System allows crosschain interoperability, which means that you can send message from ETC chain to the owner of ETH, UBQ, EXP, Musicoin, RootStock or PIRL address. ETC smart-contract system acts as the core component of the system. Messaging System supports off-chain encryption via the asymmetric encryption algorithms.

Launch date: 29 Jan, 2018 - contract deployment date.

Originally this messaging system will be implemented at ClassicEtherWallet. Initial version will include a possibility to send and receive simple text messages between addresses.

Advanced functionality, such as message encryption, public key import/export will be added at further releases.

References

Education about building of crosschain services: read this article

Original implementation of the messaging system smart-contract by Ethereum Commonwealth: https://github.com/EthereumCommonwealth/Address-to-Address-messaging

Address-to-Address messaging system code at Ethereum EIPs: ethereum/EIPs#802

Abstract

The following describes the details of the smart-contract based messaging system which aims to allow Ethereum users to directly contact the address owner without having to know who hi (she) is.

Motivation

Ethereum lacks a central messaging system that will allow to contact an address owner directly. You can send him a transaction with ASCII message attached as data but it is likely that address owner will not even try to recognize it as a text message. As the result there is no viable way to deliver a message to address owner directly.

This service is necessary in some circumstances, for example:

1. You sent someone a token, the existence of which this person does not know. It is likely that a person will spot an incoming ETH transaction, but there is no way that a person will spot an incoming token transaction or the fact that his balance of this token increases. You need to contact the owner of this address and ask to send your tokens back.

2. You sent ETC into someone's ETH address. The same situation as with tokens. It is likely that a person will not recognize an incoming transaction of an alternative currency. But he definitely can access it and send it back (or just go and sell it).

3. You spotted that someone have deployed a contract that is proven to be vulnerable. If you're a good guy then you want to contact an owner of the "vulnerable contract" and warn him that he is going to use a contract that contains vulnerability and his funds are at risk in this case.

4. You spotted that someone has hacked something. You would like to contact a hacker and kindly ask him to send everything back but the hacker likely will not respond if you will try to contact him via forums. I suppose that it is the most important case. On-chain methods of communication are the only way to securely contact a hacker or to respond if you are the hacker.

Specification

Basic address-to-address messaging smart-contract.

This is a simple smart-contract that stores messages mapped to addresses by id and a mapping that represents the last message id for each address. Last message id increases for the receiver address when this address receives a new message (there is no message at last_message_id in fact... this represents a numeric id that will be filled with the next incoming message in fact). If the last_message_id is equal to 0 then there are no messages for this address. If last_message_id is equal to 2 then there are 2 messages at positions 0 and 1 for this address.

There is no possibility to edit, change, delete messages. This contract is not a messenger or a chat. This contract is an emergency way to contact an owner of a certain address when there is no possibility to contact him off-chain. As the result, editing and deleting messages has no reason because it will still be available via history of transactions.

Basically, there is no way to encrypt message on-chain because there is no way to hide an input call data. As a result, there is an additional field for attaching a public asymmetric encryption key. If the owner of a certain address has a desire to allow someone to contact him privately, then he can publish his public key at this contract and describe what type of key he has published at the "Key type" variable (for example PGP public key or RSA 2048 bit public key). Anyone else is allowed to look at the public key in the contract, encrypt the message outside the network and send an encrypted message on this contract.

Resolution

Obviously, this contract can not guarantee that an owner of the address will receive a message. It requires to be supported by UIs. It is likely that an owner of a certain address will see a message if MyEtherWallet, MetaMask or Mist will display messages somehow (for example a certain number of last messages).

Also, it makes sense to standardize possible public key types. Ideally, UI should have a button "Send message to address" and "Send encrypted message to address" and distinguish public key, key type and then encrypt message automatically.

The ICO did not collected even a half of planned funding. As the result of this I'm proposing to extend the ICO by 1 month (until 8th September, 2017). You can vote for or against it. You should send your DEX tokens to one of those contracts that is corresponding to your position:

YES: 0x2a0f718a8977dbfab1e20fd5bf862854ae3ce427

NO: 0x572c4d25a1631f7865aad3274880ba64be141f0e

NOTE: This voting will end at 7th August, 2017 one day before the end of the DEX ICO and the decision would be made.

Scope

1. MultisigWallet.sol

2. DayLimit.sol

3. Multisig.sol

4. Shareable.sol

Contract overview

This is an implementation of a Multisig wallet smart-contract. This Wallet smart-contract is designed to store funds and restrict access to funds management.

The main goal of this wallet is to serve a storage of the official donations for the Ethereum Classic development.

Bug bounty

1. $10,000 for finding a critical bug.

A critical error is an error that can be directly exploited and violate the workflow of contracts or lead to a breach of contract operability. A critical error is an error, as a result of which the wallet owners lose access to the funds in the wallet, or the attacker gets access to these funds.

2. $2000 for security vulnerabilities and bugs, that could not be directly exploited but can affect contracts in some specific circumstances.

Any bugs that can occur in some specific circumstances and violate contracts workflow or lead to a breach of contract operability. A security vulnerabilities is an error, as a result of which the wallet owners lose access to the funds in the wallet, or the attacker gets access to these funds.

3. $100-500 for code flaws that can not cause a direct loss of funds.

Any code flaw reports that can violate the contract's workflow.

This does not apply to getter functions and comment improvements.

Participate

Submit an issue at the Multisig contracts repo: https://github.com/EthereumCommonwealth/ethereum-classic-multisig/issues

The first person who submits the issue bugreport will be paid if the problem reported is considered to be an error.

For any questions: [email protected]

Payments

The reward will be paid in ETC (Ethereum Classic cryptocurrency).

Timeframes

Bugbounty is relevant from February 12, 2018 to February 19, 2018.

https://ethgasstation.info/index.php

Longterm sustainability of Callisto platform and CLO financial model.

The initial plan was to separate core features (financial: Cold staking/ utility: Free security auditing). Cold staking should bump the price. The higher the price is, the more effective security enhancement will be.

However, this is just a conception and it is far from guaranteed. Watching the EOS cenceptions I came into a conclusion that it may turn out that we will need to increase the value of Callisto platform at our own (regardless of what is going on with crypto industry globally). Taking the EOS model into account, I can propose the following:

1. Security auditing will require a smart-contract developer to hold an amount of CLO at his balance during the auditing process.

2. The more CLO a smart-contract developer owns, the higher the priority of his auditing request is.

3. Once the security audit is completed, the smart-contract developer can sell his CLO. Thus auditing remains "free". You can buy CLO, request audit, sell CLO (+/- volatility).

This ensures volume and liqidity as well.

The following describes the process of revenue distribution for all for-profit projects of the Ethereum Commonwealth.

Pre-definition period is the period of time before 1st September, 2018. The final version of smart-contract based voting and smart-contract based revenue distribution will be established at 1st September, 2018. It may require DEX token contract upgrade!

Revenue distribution during the pre-definition period.

Each for-profit service outputs its income to the specified address (bursary). Once a month 65% of the balance of the "bursary" address will be moved to official Ethereum Commonwealth address to fund further development. 35% of the remaining funds will be distributed among the shareholders of the DEX token in proportion to their share.

Example.

The ECNS project is already finished. Unlike the ENS, it will not burn money, but put them in bursary.
Imagine that user have bidded 100 ETC for ECNS name but forgot to unseal bid during the reveal period. In this case 0,5% of the bid value will be returned to the user and 99,5% will be donated to the bursary.

Bursary receives 99.5 ETC.

Another user bidded 200 ETC for ECNS name and unsealed bid. In this case 0,5% of the bid value will be donated to the bursary and the remaining 99,5% of funds will stay at the ECNS.

Bursary receives 1 ETC.

I own 706,5 DEX of 3658.87. This means that my share is about 19%.

At the end of the month 65% will be sent to the official Ethereum Commonwealth wallet: 65.325 ETC total.

The remaining amount of 35.175 ETC will be distributed between DEX shareholders. Personally I will receive 35.175 * 0.19 = 6.68325 ETC.

P.S. I assume that percentage will change in future. I have raised a lot less that I supposed so I need to establish a self-funding mechanism for the team at the initial stage. I prefer to increase a percent of DEX holders to 70% and to decrease a percent of team funding to 30% after the pre-definition period.

Well, even filename is not compatible.
Capital letters should be avoided in most places.

The following is a proposal to define a protocol to solve a problem of a complete lack of possibility to communicate with an owner of a certain address on Ethereum CLassic, Ethereum, UBQ, Expanse or PIRL networks.

EIP 802: ethereum/EIPs#802

ECIP 85: ethereumproject/ECIPs#85

User who vote from a contract could call Withdraw, and in his tokenFallback function vote again.
This will result in loss of tokens, as deposited[msg.sender] is eventually reset.

This might be used by a malicious user to demonstrate a problem in ERC223.

As more and more updates to ETH (Ethereum) come out and additional capabilities in the blockchain are developed, who will maintain the code of the ETC chain? Will ETC move to a Proof of Stake model as well?

Abstract

Ethereum addresses are exactly the same on all Ethereum-based chains, such are ETH, ETC, UBIQ, EXP, Musicoin, SoilCoin (not sure about RSK, didn't investigated yet).

This means that you can use one account (read: private key) for all chains. As the owner of 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8, I also own an account with the same address on any of the above chains and can dispose of funds from it.

This means that if the address 0x488c9e2df11ac9d19eb07df362cb174ffd4724d8 is the owner of the name dexaran.eth in ENS, then you can perform a lookup in the ENS contract that is deployed ETH chain, but execute the transaction on any other of the specified chains.

In two words: you can send ETC to the owner of dexaran.eth and he can access them without any problems.

Proposal

I wish to create a service that will perform lookup on any of the existing ENS forks based on the name resolution. I will integrate it into ClassicEtherWallet and write a patch to MEW as well.

For example:

• .eth TLD for ENS
• .etc TLD for ECNS
• .ubq TLD for UBQ ENS
• .exp TLD for EXP ENS

If ENS integrates with ICANN, I will change the search method so that any user can artificially choose which particular naming service he wants to use.

Motivation

I believe that improving any of the Ethereum-based networks will be beneficial for the whole Ethereum ecosystem. I also believe that Ethereum Classic, UBQ, Expanse and others belong to the Ethereum ecosystem.

This is similar to how all crypto-currencies based on BitCore get benefits from updates like SegWit or Lightning.

It is obvious that the integration between chains is beneficial for both participants and increases the cost of both chains.

This is beneficial for users: each name will cost you in proportion to the currency rate of the network in which you buy the name. If the user doesn't care about the resolution he can just pick the cheapest one.

It also allows us to introduce new TLDs without affecting the original ENS.

The issue

We should came into agreement about what exactly resolutions would be assigned to each naming service. Currently, ENS uses .eth, and ECNS uses .etc. I propose:

• ENS: .eth
• ECNS: .etc
• UBQ: .ubq
• EXP: .exp
• SoilCoin dead
• Musicoin: .musicoin
• RSK: .rsk (not really sure if RootStock needs ENS, but it's not a problem to deploy it)

Ethereum Commonwealth adheres to a policy of financial transparency.

We keep a complete financial history in an open document so that everyone can see it. Each financial operation will be reflected there. Each financial operation will be verifiable via transaction hash.

The document will be updated once a week.

https://docs.google.com/spreadsheets/d/1-ibJXI9IfrkKloLgN6RHxoXeCbdqa9mti1afTcO1BQk/edit#gid=0

https://github.com/inzhoop-co/LETH

https://infura.io/

I have withdrawn ICO funds. http://gastracker.io/tx/0x525d99f39a13dfc63a652945382b3ee152cee6ebe7e7ede65801b6fd504286c4

As I said earlier, I subtracted the amount of my personal deposit from the total amount of ICO funds. My personal deposit amount was 706.5 ETC. You can easily verify it because the amount of DEX tokens that I currently hold (on this address) is equal to 706.5

Ethereum Commonwealth funds are currently located here: http://gastracker.io/addr/0x52823e725a34d42e14a1b66fb67299C30c4d8Edf

The reason of doing it is I'm currently working on projects that I've announced and I started to hire.

I've already finished the ECNS and we are waiting for MyEtherWallet to support it.

I'm currently finishing the DexNS. I'm hiring developers to work on Decentralized Mining Pool, API endpoints provider and Classic Mask.

18dew currently contributes to the Classic Mask.

ICO is not over yet. During the ICO, I will transfer funds to this address: 0x52823e725a34d42e14a1b66fb67299C30c4d8Edf

This will be used as an official Ethereum Commonwealth address in future.

Requirements

The blockchain explorer is intended to:

• Display blocks, transactions, state of addresses and provide the rest of default blockchain functionality.

• Ensure the easy addition of new networks compatible with the ETC. It is planned to support ETC, ETH, UBQ, EXP, PIRL, Rinkeby (testnet), Kovan (testnet), Morden (testnet), Ropsten (testnet), Callisto-test (testnet), Callisto chains simultaneously.

• Display a full history of transactions of the given address.

• Display DexNS names of addresses at any network.

• Properly display the signatures of known events: Transfer, bidding ENS events, NewMessage of messaging contract ( #36 ), Transfer of ERC223, ICO events of token mint and so on.

• Ensure the easy addition of new known events signatures.

• Get a history of messages of a given address by Messaging Smart-contract of ETC network: #36

• Properly display internal contract invocations.

Callisto (optional)

• Display "amount at stake" at Callisto network (CLO only)

• Display "current staking amount" at Callisto network (CLO only)

Resolution

https://github.com/EthereumCommonwealth/Galileo

Yes, let's update it.

To vote for this item, send DEX tokens to this contract: 0x56696968c23cce54dfea7349c7d5c96e41f38e77

No, leave it as is.

To vote for this item, send DEX tokens to this contract: 0xe2ddee6187d6e231ae540bd7eac2dbd83a7448d9

p.s. compiled with solc 0.4.17 + optimization.
bytecode keccak-256 hash 0x83a3636f93df74b400cf70ffe4f01835189b8c42df729068fe8695aab044eca9

Purposes.

The main purposes of this voting are:

1. Establish a trial voting system that will allow me to collect feedbacks from DEX token holders. This will also allow to detect any voting system flaws and inconveniences and fix them before launching a final version.
2. Collect feedback from DEX token holders regarding current development state and further direction.
3. Demonstrate the community a workflow of voting system.

If this voting system will succeed, then it will be used until 1st September, 2018. After this date a final version of voting contract will be deployed.

NOTE: Your tokens would not be spent during the voting. You can withdraw your tokens from vote-pool contract at any time.

Voting.

Special voting contracts will be deployed. Each contract will be associated with it's proposal. You should just send DEX tokens to a contract that is related to your desired proposal. You can withdraw your tokens from vote-pool contract at any time.

Vote pool contract source code is located here.

If you want to add any proposal to current voting session then you should deploy a vote pool contract and provide its address in comment here. Source code of the contract should be verefied also. Vote pools with not verified code wouldn't be added to the voting session.

NOTE: Keccak-256 hash of vote-pool contract runtime bytecode (with 0x prefix) is 96b45a5bb84ccbc251e6b393988f9f1e272d571d021864d9b190f0b99130bf60

The voting process will be divided into sessions. Each session will have its own timeframe and should be discussed on specified issues.

Calculating results.

The voting results will be calculated by the balance of each vote-pool contract at the specified moment of time.

Voting session #1.

Vote-pool contracts are already established. In this voting session I'd like to get feedback from DEX token holders about further development direction. I'm currently working on finalization of ENS port for Ethereum CLassic (bug bounty), DexNS adoption (EIP 668), ERC223 improvements (there is a suggestion to use ENS reverse registrars for storing fallbacks) and other improvements. I'm planning to hire developer to port MetaMask for Ethereum CLassic in near future. I'm also planning to launch a serie of tiny bounty-contests (there is already a bounty desk for this team), because of I think that ETC needs more community/public adoption.

I'd like to get feedback about what do you prefer me to focus on?

Finalize current development state first. (ECNS, DexNS, ERC223)

To vote for this item, send DEX tokens to this contract: 0x9c227bd4bbc732b9d701399fb008eb6131662a6b

PR and community activity.

To vote for this item, send DEX tokens to this contract: 0x7f16e349850e8ffc822c19fcadfffdbe6ce62a2f

Hire developers for MetaMask port.

To vote for this item, send DEX tokens to this contract: 0xdb77b8146954653782578684b5730cc1f6ecf273

Smartpool port for Ethereum CLassic.

To vote for this item, send DEX tokens to this contract: 0x98b9276c172e40e95748a9aa4159e3a1735cbff6

Focus on zk-SNARK implementation for ETC.

To vote for this item, send DEX tokens to this contract: 0xa313edba5b956e70df83a641ea11697169fc4fd9

NOTE: Requires protocol upgrades!

Focus on restoring GETH compatibility with ETH and further protocol upgrades implementations.

To vote for this item, send DEX tokens to this contract: 0x4c77a5980a6fddd4c8180be7eb1513a011eb0a88

Decentralized token exchange.

To vote for this item, send DEX tokens to this contract: 0x443df711c635b8a7dc75f7ba220e096842aed90c

Viper development.

To vote for this item, send DEX tokens to this contract: 0xe8ede33ba36343e04823b1e5c1762cba02f1f58c

I've seen this and I want to try this voting contracts but I don't care what you are going to do.

To vote for this item, send DEX tokens to this contract: 0xe6aa960e5b59ed4af028e444fc2973eb9aa9249f

Time frame.

The result of trial voting №1 will be calculated at 25 July, 2017 at 10:00 UTC.
Trial voting №1 is extended until 29 July, 2017.

good afternoon . I save etc on the classicEtherwallet purse in order to get Callistro but I did not receive Callisto. tell me please when I see Callistro on my wallet?

The main ECNS revenue is now a 0,5% comission from cancelled deeds. Note that the main amount of spent money is still burned. I mean sealed bids that were not unsealed during the reveal period.
It is technically possible to allow deeds to be cancelled after the auction will be closed. There is no need to keep deeds for more than 7 days (each auction will last for 4 days max).
We can collect the money from the unrevealed bids without any problems.

Delegated to ETC Cooperative team.

The following describes the main goals that are planned to be achieved to improve ClassicEtherWallet, the main web wallet of Ethereum Classic.

Scheduled improvements.

• Integrate IOHK Mantis public node into CEW.
• "Deploy contract with constructor parameters" functionality.
• ClassicEtherWallet release 3.11.1 fixes: #40
• ClassicMask & ClassicEtherWallet integration improvement: contract deployment support, transaction customization support for CLM, testnet support for CLM.
• ClassicEtherWallet multiple networks integration.
• Extended list of basic contracts.
• Extended list of basic tokens.
• DexNS improvement: support custom token registration.
• DexNS improvement: support Name content management.
• ClassicEtherWallet release 3.12.0: Crosschain messaging system.
• Distinguish crosschain-search by address, DexNS Names and ECNS names.
• Support additional testnet nodes at ClassicEtherWallet.
• Finalise issue #26
• Crosschain token swap UI implementation.
• ClassicEtherWallet release 3.13.0: Decentralized Name markets of ECNS and DexNS implementation.
• Address-to-Address message system implementation.
• DexNS support - Name content management.
• DexNS support - advanced Token registration.
• MEW compatibility maintenance.
• Classic Ether Wallet chrome extension.
• DexNS improvement - name timeframes visualisation/address self-identification.
• Crosschain Message system

Development requirements.

• Developers: 1 full-time developer with knowledge of AngularJS, HTMl, CSS, web3.js and smart-contract specifics
• Scheduled time frame: 1 year
• Planned payment: 5 days a week; full time at $50/hour rate
• Project budget requirement: $80,000 annually

Gastracker sucks. It is always lagging. It is displaying -2714 confirmations of 12. It doesn't display token transfers. It doesn't display comments and address reputation. It doesn't provide any advanced functionality. It doesn't support testnets.
If you want to unite the whole Ethereum-core project's infrastructure with common services then it's your chance. Common wallet will be CEW. Common extension will be classicmask. We need common blockchain explorer with advanced functionality now.

I've seen that you are closing your ico. The supply of dex token is incredibly low. May be we need to introduce proof of stake coin supply growth? It looks to be possible with erc223.

It would be the first proof of stake erc223 token on ethereum.