Gratitude

Firstly, I have thoroughly enjoyed the 4+ years of being a part of the ETC community, seeing it grow, take form, and riding the roller-coaster with my internet friends and acquaintances. We were pioneers and have unquestionably left a positive mark on the blockchain industry and open source software. My time we here has given me rare insights into decentralization and leaderless organizations and an amazing opportunity to develop next generation technology with brilliant like minded people.

Why I’m Leaving

As many of you know, ETC has always been a volunteer/passion project for me. My pursuits here have to be balanced with my other obligations in life. This pattern was easier to maintain in pre-covid times and when the project was in incubation. I want to enjoy the last few years of my children’s childhood. My wife, and love of my life Jen, has always supported me in this pursuit also, but my time at ETC has always come at the expense of some family time. The calculus on the value of those hours has changed in the last year. I no longer want to be tethered to my phone arguing with strangers online during diner and homework time. And I want more freedom to have time to explore new and exciting technology as well.

The Road Ahead

Unquestionably, ETC and I are both in better places than when we started. The network and its participants are coming to a fork in the road. The treasury conversation we’ve had off and on for 4 years may be coming to a resolution in the next few months. if not obvious until this point, I will not be participating and will try hard to refrain from any further intervention either way. ETC has always been a managed chain like all public projects with shared goals. That is what a community does and how highly specialized technology is maintained. The conversation now is whether it is to be semi-autonomous or supported with a superfan helping it grow. Both are very valid models that are in keeping with the history and spirit of ETC. I am neutral now and look forward to seeing the peaceful split of communities or emergent governance that develops.

Selling assets

I think there are several possibilities of future states for ETC. I have privately informed Terry(etc labs), Charles(iog), and Bob(Coop) last week I will be selling the rights to the domains I have in my possession to whichever is the highest bidder by November 30th. If none of them can find a way to value it, the domains will go to public auction. This bidding is not any indication of someone buying the chain ETC itself or a corporate takeover, though it will likely be framed as such by the non-winners. The community should make their voice heard on this as well. All three love ETC and have valid roadmaps and development plans. I don’t want the burden of having to be king maker if a chain-split is the best path for growth.Especially as I plan to disengage from actively participating. Managing a domain or repo has been an honor and the community will be fortunate with any outcome.

Transition

As i spin down, I will be making this hopefully as seamless as possible.

-I will keep kotti validator running until a replacement operator can be transitioned in properly.

– I am happy to remain in a non paid advisory position on boards until a their natural resolution.

– I will continue administrative duties on the github repo until the community finds a replacement.

– I will retain my community wallet keys and gladly use them to unlock funds when needed

Farewell

I am forever grateful for the people I have met, the debates we have had, the amazing community that exists, and the memories I’ll always have. I look forward to cheering from the sidelines as ETC embarks on its next exciting phase of the amazing journey. But for me, this is where Peter Pan must leave Neverland.

Semper Fi,

Cody (DontPanic) Burns

---

There is a new startup in the Ethereum Classic space that has caused a bit of a stir with their initial actions and I would like to take a few minutes to comment on them. For brevity, there is no distinction made between etclabs, the “startup incubator” and DFG, the desperate speculator group. Some may remember them as they made presentations at the ETC summit and they have held themselves out to be a new development team in the space and hopefully they can recover from their recent missteps and join the other dev teams working in the space. Since they are struggling and need some air time, I am writing this open letter to ease the on boarding process.

---

How Git Hub Works

For clarity sake, github is the system many open source projects use for coordination and version control. It is one of about 5 systems in the CI/CD pipeline that are used to ensure distribution ETC related software. Individual repositories(repos) contain projects, and they are consolidated into organizations (orgs) for easy of search and moderation. There are two roles that are part of a github org, member and owner. “Owners” have the ability to add members, add/del new repos, and change members status (even removing other admins status), and more importantly add CI/CDapps and web integrations, You broke all of those because you are incompetent, please ask if you don’t know what you are doing. There are infact, and have always been, several ”ETC” orgs. IOHK, Parity Tech, BCRD, ETCDEV, etc. In the past, they work on code in their parent org and then merge it with the main branch in the ethereum project org for easy of coordination. Owners do not “own” open source orgs(google: foss), members do. Members are allowed to submit and merge code. Should the new dev group, ETCLABS, have been made members, absolutely! In fact anyone who wants to contribute can and should be made a member. After they foolishly removed all admins from the ethereumproject repo and lost control of the krykoder account, I added them as members to the back up organization ethereumclassic. I have transferred all of the projects I had created to the new repo and the chain moves on. Currently there are 4 “owners, and I will direct you to the volunteer page to see the new requirements that no admin can remove other admins without consent of all to prevent accidents like what had happened to the last org. We are more than happy to add more “owners” if the need arises. But you will need to actually produce work and be active in the community, money doesn’t matter.

---

ECIP process
ETCLABS has express concerns about not having a voice in the process of improving ETC. The first resource they should use is https://ethereumclassic.org . It will answer many of your noob question regarding testnets, wallets, dapps, etc. If your only concern is about price, I canât help you there other than saying ethereum systems work better when the price is closer to zero than 1 million, but as a speculator group you should have looked into that before losing everyone’s money. For anything else that can improve the ecosystem or network, you need to follow the Ethereum Classic improvement proposal process. This is the common way to make suggestions, you don’t need to strong arm a development team or even ask permission. The repo is located at github.com/ethereumclassic/ECIPs now that the ethereumproject repo has been deprecated. You may be interested to know that another development group with actual chops has proposed a universal set of status codes, I had proposed op code compatibility changes(which should be coming sometime after the Constantinople fork opcodes are tested in January), and several other exciting things that maybe etclabs can even try to help with.

---

In conclusion

Welcome to Ethereum Classic ETCLABS! I look forward to the day you actually produce anything other than bizarre press releases. Also, please try to refrain from using my name in your revisionist history unless it accurately reflects my contributions to your work. Aside from once conference call with the other development teams, in which you profusely apologized for screwing up the git org, I have never been in contact with you. Feel free to ping me on literally any social media channel as dontpanicburns or email me if you need anything.

Modern blockchain technology relies on different principals than previous generations of blockchains, known as UTXO or generation 1.0, and allows for more robust transaction execution. An introductory stateful blockchain can be expressed as a game of correspondence chess.

The rules of chess are understood by all participants in the network and, as such, it is understood that a knight has a certain series of functions, or moves, it is able to perform. The same holds true for the other pieces of the game.

Genesis state

The genesis state of a traditional the game is presented in figure A. Both participants have a series of pieces that they are able to use and have agreed on the current positions of each. This is conceptually similar to smart contracts on a blockchain. Each contract has a predefined set of functions that are controlled by rules just as each piece as a predefined set of moves it is allowed to make in game play.

Consensus

In the correspondence chessboard network our consensus mechanism is set as such: each member must make 1 legal move per block. Once the player decides on the move, it must be submitted to a judge. Unlike modern blockchains, the chess game also requires each participant make their move in proper order. The dark pieces are forbidden from sending a transaction until the light pieces have made their commitment. When the light side player submits their move to the judge, it is visible to everyone and unable to be changed. Once both sides have made their commitment to a move, the block is captured as a list of moves (state changes) in PGN format and numbered from the genesis state.

The blockchain and the state

An example of a possible valid block number 1 could be: 1 d4 ♞f6. The

“blocks” are just a list of the moves that were made, not the actual pieces. This can be translated as the light side moving the pawn from d2 to d4 and the dark side moving their knight from g8 to f6. Both are valid moves and arrived in the correct order, so per our consensus rules this is a valid block. Each player will update their board with the new ‘state’. Players are only concerned with the current state, which contracts they can interact with, and what move they want to make next.

Syncing and Validating

As the game progresses, it is possible for any outside participant to validate the current state by reading through a the PGN list of moves from genesis and recreating the game. In the blockchain space this is known as syncing a node. If one of the players needs to take a break or knocks over their board, they are able to sync their board to the current state by reading the move list. A faster way of syncing would be to take a snapshot of the current state and send it to the validator along with the PGN. They would then have the current state and can validate it as needed. This allows for seemingly complex chess games to be replayed and studied by a broad audience.

State size and the evm

In a stateful blockchain system such as Ethereum, all of the rules from above still apply. Each node keeps a copy of the blockchain so they are able to validate their current copy of the state and the state began at a commonly agreed upon genesis block. By viewing the state, a participant is able to see contracts on the system in the same way they would see all the chess pieces at any state in the chess game. Similar to each chess piece, each smart contract has a series of rules and permissions associated with it. that govern its behavior. In contrast to the chess game, participants in the ethereum network are able to add valid contracts at any time in the form of a transaction. They will send the transaction to a node responsible for creating valid blocks. Once a series of transactions have been validated, the block of transactions is sent to all the participants who then update their local state. Participants only care about the current state, which contracts they can interact with, and which transaction they want to make next. As the state is shared between all participants, it is important to minimize the amount of data stored on leaf nodes of the states Merkle tree

In an ethereum system, all accounts follow the same formatting scheme and are mapped by their unique account address. Both user accounts and contract accounts are stored in the same manner. Each account has:

• The nonce, a counter used to make sure each transaction can only be processed once
• The account’s current ether balance
• The account’s contract code, if present
• The account’s storage (empty by default)

Each node stores a list of all accounts that have ever made a transaction on the system and maintains the Merkel root of all accounts. When a transition arrives in a block, the new state root is computed and validated against the blocks state root.

For more info on ether trees check out: https://blog.ethereum.org/2015/11/15/merkling-in-ethereum/

---

The Zcash value proposition is in private transactions, however, private transactions are not the default and many users simply do not know how to initially create shielded (private) transactions, aka a “t” => “z”. In simple terms, it is important to have a large pool of shielded transactions provides for a larger anonymity set for private transactions; it is harder to pick out any one zebra in a large zeal than it is to point out a single animal in a small cluster. This process, and having more people familiar with it, provides greater value to my work on cross chain atomic swaps (x-cats in zcash speak) so I have attempted to unravel the apparent mystery below. No math, dark magic, animal sacrifice required.

Side note: If you would like to contribute to the greatest good, while exerting minimum effort for the zcash ecosystem, hold you coins in a “z” address. this benefits everyone using zk transactions and increases the size of the anonymity set. Currently, as shown below, this is an uncommon practice.

How

The general process for shielding ZEC is as follows:

1. Generate both a “t” address and “z” address

The “t” address works the same as a bitcoin address. When you send from your transparent address the change from the transaction will be sent to a new t address you control and all the transactions will be visible on block explorers. “Z” addresses are the private ones and you will only be able to see the balance in the wallet. When sending to and from a Z address, only the exact amount (minus fees) is sent, the change remains with the same “z” address. No one observing the transaction will see any information about the “z” address, except during shielding and deshielding.

2) Fund the “t” address

Funding your “t” address means sending ZEC to it. Zcash can be traded for or purchased many places. Gemini allows US customers to purchase ZEC with US Dollars.

3) Send from your “t” => “z” using a zcash wallet such as zcashd or winzec

It is actually as easy as that sounds. Sending from “t” to “z” or “z” to “z” or “z” to “t” is all the same procedure. This step is overlooked in the zcash documentation because it is so trivial. Maybe they will add it in future versions to avoid confusion. https://github.com/zcash/zcash/wiki/1.0-User-Guide

Notes

“t” addresses send change to new accounts, “z” notes do not

do not send from “z” => same “t” or the change account, always use a ‘clean’ “t” address when deshielding

avoid sending the same amount into and out of shielding transactions. While 10 zec in and out is less traceable than 2.3123 zec, 10 zec in and a random amount of zec out is better

Methods

Hard

0. Get zcashd running

Get the latest copy of zcashd (https://github.com/zcash/zcash/releases) or use a docker container (docker pull bcrd/zcash)

1. Generate “t” and “z” addresses

To generate a t address you use the commands

$ ./src/zcash-cli getnewaddress

To generate a z address use the command:

$ ./src/zcash-cli z_getnewaddress

2 . Fund your t address

Send ZEC to the t address created above

3. Send many

If you are like me, you hate typing or even pasting long inscrutable numbers. In linux you can save strings with shortcuts like this:

TADDR=”yourAddress”

But actually type or paste your address. after that you can recall it by typing the letters with a dollar sign in front of it:

$TADDR

So assuming you funded your t address with 1.001 zec the `z_sendmany` command will allow you to shield that value:

$ ./src/zcash-cli z_sendmany "$TADDR" "[{\"amount\": 1.0, \"address\": \"$ZADDR\"}]"

Be mindful of the quotes and backslashes, they matter.

This will return you an opid code which is used in your wallet for tracking the shielding process. You can check the progress using:

$ ./src/zcash-cli z_getoperationresult

Status success is what you are wanting. After you get a success you can verify the funds using:

$ ./src/zcash-cli z_listreceivedbyaddress "$ZADDR"

Easy Mode

0. Get winZec

Download the “unofficial” windows version of zcash. It can be found at http://winzec.com/

1. Create addresses

click the new T (transparent) address button

click the new Z (private) address button

2. Fund

Fund your “t” address

3. Send

On the send cash tab, select your funded t address. enter your z address in the destination address and the amount to shield.

Click send and watch the progress bar to see when it completes

That’s it!

Note: When you are sending, there are two fee boxes. The first is the network fee, you must pay this to have your transaction included in a block. The second is the wallet dev fee, this is an optional donation to ralfstx to support the windows and mac wallet development. If you have used both methods, you will quickly realize the importance of gui and its continued funding. Open source development is often a thankless process, so money is always nice way of saying thank you.

---

Tips:

zchbDpcotZTCScgwa2HU2hxhn62yebYphrwDhpK43YAeo158Mo5R8ACiJY1nFjeeMUBf6JYGCoH4Yx4b8YvDW7r5dKtGWnv

The Ballad of Saint Hodl

Inactivity strikes us as intelligent behavior. Neither we nor most business managers would dream of feverishly trading highly profitable subsidiaries because a small move in the Federal Reserve’s discount rate was predicted or because some Wall Street pundit had reversed his views on the market. Why, then, should we behave differently with our minority positions in wonderful businesses? — Warren Buffet

In part 1 of the series we learned about conditionally locking contracts that allow for two parties to transact value on an ethereum chain using a secret hashed password funds could be kept in public view and then retrieved at a future time. In this article, we will allow a user to send coins to a contract for safe keeping until some point in the future. In crypto trading terms this is know as “Hodling” and is an optimal strategy in investing in general( see: Warren Buffet)

The History of Hodl

In 2013, a user named GameKyuubi posted a now infamous, admittedly drunken, post on his poor luck as a trader.

I AM HODLING

I AM HODLING

I AM HODLINGbitcointalk.org

GameKyuubi understood the importance of holding assets long term as a value investor, however, they lacked the strength of will to do so with the ease of trading options that were available. It is by this example that we will work on a chaincode that will allow the block chain to do the hard work “Hodling” for us.

The Saint Hodl Contracts

Saint Hodl
              '-._   ```"""---.._
           ,-----.:___           `\  ,;;;,
            '-.._     ```"""--.._  |,%%%%%%              _
            ,    '.              `\;;;;  -\      _    _.'/\
          .' `-.__ \            ,;;;;" .__{=====/_)==:_  ||
     ,===/        ```";,,,,,,,;;;;;'`-./.____,'/ /     '.\/
    '---/              ';;;;;;;;'      `--.._.' /
   ,===/                          '-.        `\/
  '---/                            ,'`.        |
     ;                        __.-'    \     ,'
jgs  \______,,.....------'''``          `---`

TL;DR

Send funds, get later. All of the following contracts will be made available for use on SaintHodl.com for ease of access and are also available as an open source resource on github. You can use your Jaxx.io,MEW, or any Ethereum Classic wallet to interact with them, for free!

The Most Important Part

A time locked contract cannot be opened early. You cannot negotiate with the blockchain, your locked funds are safely tucked away until the predetermined amount of blocks have passed. No backsies.

So in the time locked contract (TLC) this variable is made public and is listed first. Anyone viewing the contract should easily be able to view this number and know what they are getting into ahead of time. In sainthodl’s contract it is written as:

uint public freezeBlocks = 20;

This sets the contract freeze time up for 20 blocks, which is ~280 seconds or 4.67 minutes. Not a long time, but enough for testing. (There is a 2 million block option on site if you are looking for something more 😉 )

Lockers

In part one, hash boxes were publicly view-able. The same will be true with our TLC contracts. Each ‘box’ will consist of 3 details: the owner, how long to hold coins, and how many coins are being held.

struct locker{      
    uint freedom;
    uint bal;    
}    
mapping (address => locker) public lockers;

Every address will now be mapped to a unique locker.

Sending funds to a Locker

Whenever anyone sends coins to our TLC contract we want it to add funds to their locker and set the freeze time to some block in the future. To do this we will be using the fall back function in the solidity contract:

function() payable public {        
    locker storage l = lockers[msg.sender];
    l.freedom =  block.number + freezeBlocks; 
    l.bal = l.bal + msg.value;
   }

The locker will be identified by the user sending funds( locker “l” is the locker of the message sender). We then use the latest block.number and add the predetermined number of freeze blocks to get our “freedom block”. The lockers balance will be calculated from its current balance (0 normally) and the value that was sent with the message. If you use the abi from the github with MyEtherWallet.com you will now be able to see everything in the locker (Balance will be in Wei)

The Second Most Important Part: Withdrawing

Finally, the urge to panic sell has passed, and you can now safely be trusted to get your funds back. Unlike the hashlocked contract where anyone with the preimage could claim the funds, only the owner of a locker is able to withdraw their funds from the TLC. A word of caution; when allowing strangers to withdraw from a contract it is important to avoid opening up to recursive calls. The Dao contract failed because of this design flaw. This would work by someone calling the withdraw function from a contract that had its fallback function set to also call the withdraw function. To avoid this we will set the lockers balance to zero before we send any funds; this way if a contract calls back it would only be able to withdraw zero.

function withdraw() public { 
    locker storage l = lockers[msg.sender]; 
    require (block.number > l.freedom && l.bal > 0);
   // avoid recursive call 
    uint value = l.bal; 
    l.bal = 0; 
    msg.sender.transfer(value); 
}

Similar to the first function, locker “l” is the locker of the message sender. We then require that both the current block number be greater than the lockers freedom block and that the lockers balance be greater than zero. If either of these conditions are not met, the function will ‘fail’ i.e. not do anything. If both conditions are met; the lockers balance is saved as ‘value’, the original balance is set to zero, and then value is sent to the locker owner.

Events

If you read through the contract you will notice two “events” that show up:

event Locked(address indexed locker, uint indexed amount);    
event Released(address indexed locker, uint indexed amount);

These events are displayed in wallets that watch for events and can be used to trigger things like posting to twitter.

Conclusion

With this simple contract anyone is able to commit and retrieve coins on the chain for as short or as long as they like. Part 3 will combine the functions of part 1 & 2 to create a hash-time locked contract to do some really cool things!