RHOC2REV process alternatives evaluation

[jimscarver]

Greg asked the community to reevaluate the planned rhoc2rev airdrop plan. A final decision is needed ASAP. Please join this issue if you can help.

Lead: @alex-coinfund

goals:

• [x] Accounting of rhocs held in contracts
• [ ] Estimate of number of users impacted by alternatives (spreadsheet)
• [ ] An evaluation of rhoc2rev alternatives insuring we are serving the community the best we can.
• [ ] A potentially improved rhoc2rev process. steps:
• [x] discord rhoc2rev channel for discussion.
• [x] evaluation process log and notes
• [x] transcript of Greg's rhoc2rev discussion from the debrief
• [x] draft rhoc2rev trade solution
• [ ] [ ] review
• [ ] [ ] evaluation Estimated Budget of Task: $[TBD] Estimated Timeline Required to Complete the Task: [days/weeks] two weeks max! Info about the air drop must be actively communicated if that option is selected.

How will we measure completion? [example: pull request merged] The coop announces a final decision

See CONTRIBUTING.md for details on budget and reward process.

[alexbegun]

So at the end of the hangout I am glad that Greg and Jim had the discussion about REV to RHOC conversion. I generally lean towards the Snapshot approach as described by Greg, however my main concern is about what happens to the RHOCs after the Snapshot of the Ethereum block chain is taken. There will be people dumping the now worthless RHOCs on the market and there will be some who will purchase them thinking that they still hold some kind of value. This I think is a really bad outcome for the RChain community, because these unsuspecting people will be tricked. So if nothing else I think it's very important to let everyone know that after the snapshot RHOCs will have no value.

[Phistr90]

x-post from my discord comment:

I agree that the dump of rhoc after the snapshot and uninformed buyers is the major concern in a simple snapshot at block X approach. I just want to throw out a mechanism to disincentivize the sell off, it is for sure not perfect but maybe worth a thought - and honstely havent thought it through totally by myself :D

Proposal: Snapshot block height is Y, whereby Y > X, X announced but Y unknown until 'shortly' before launch

Instead of announcing that the exact block at which the snapshot is taken, it is announced that at some block height after block X the snapshot is taken. But the exact block remains unknown . Similarly like the exact genesis block for the Ethereum blockchain was unknown as it depended on the input of the testnet block X. Such that one would provide a script that generates the the genesis block but the the input which snapshot block is taken is revealed just a short period of time before the launch of the project by providing a source of randomness.

Cons:

• Increase complexity of the transition
• does not solve the problem of ppl not being aware of the transition at all
• (cant be that shortly before launch in order to give the opportunity of the community to review)
• (harder to communicate - okay one simply can say move funds to normal address until block X, dont move afterwards)

Pro:

• Desincentivize sell off at least to a point relatively close to the upcoming launch
• gives the chance (literally) to move the funds out of a time lock contract in time for ppl that move funds after block X
• bootstrapping would require social consensus on that random input -therefore it would be a truely community driven process - thus reducing the risk of the coop beeing held liable for rchain as the network

[alexbegun]

Yes I like this!

[entropee]

Here is a Google document with the transcript. The transcript is readable but might be cleaned up a bit with punctuation and removal of stammering (thinking outloud. ) Rhoc to Rev discussion during May 6, 2018 debrief

[alex-coinfund]

@jimscarver did you mean me, above? I'd be happy to help by reviewing/commenting, but probably don't have a ton of bandwidth. Would I be paid for this work? Thanks.

Having read the comments above, my immediate response is that a snapshot when the contract can't be frozen (a la what EOS did) is a bad bad idea. Why not simply create an exchange mechanism, where a simple contract on ETH can receive and burn the RHOCs and the wallet from which transaction was sent is registered as the wallet that will receive the REV on RChain? This way RHOCs registered to receive REV are permanently removed from circulation. The downside is, of course, the fact that you have to manage the distribution process on the RChain side and can't just encode all the holdings in the origin (root) transaction. However, this is much better from the community standpoint, it would seem to me.

[jimscarver]

@alex-coinfund yes we would be paid for whatever effort you put in including the hours already spent. We just need to set a reasonable budget and vote rewards everyone who help in the effort.

As you requested I have fleshed out the wallet approach a bit in this collaborative document. https://docs.google.com/document/d/1ujtjJQgjnWpyYv7V65T1hshGw5kXCtnpGTj5Yl_fE4U/edit# Please review/contribute.

[jimscarver]

Yes @alex-coinfund you will be paid for whatever effort you can put in here. We just need to set a reasonable budget once we can estimate it and vote rewards for the month for people who participate in the issue.

As you requested I have flushed out the rchain wallet rhoc2rev alternative we discussed.

Anyone interested in this issue please review this alternative and provide feedback. Thanks.

[Phistr90]

x-post from my discord post:

I see and understand your concerns and your intentions @jimscarver and I assume that everyone in the RChain community wants to see the conversion happening as smooth as possible happen without anyone left out.

Unfortuntaley I either dont understand your proposed mechaism for conversion correctly or in the case I do it provides IMO a huge attack surface which threatens the rchain project as a whole.

1. In your proposed x-chain conversion the conversion takes place mainly after the launch of the rchain network. That means this leverages the failure costs by a lot if something with the conversion tools / smart comntracts or in genereal provided mechanisms for the conversion would go wrong. On the other hand the airdrop balances can be audited beforehand by the community. The bootstrapping of the network would reuqire some social consensus that these balances are the chosen ones. This reduces the liablity for the coop a lot.

2. How would the x-chain verification on the rchain side look like?

a) Would it be centralised / trusted oracle/ datafeed (maybe provided by the coop). In this case the coop would have a huge liablity and one should ask the question if one really would like to have such a centralised coordinator within a distributed system as it would be a SPOF.

b) On the other hand if the verification mechanism on the rchain side would be decentralised how to resolve the following problems:

• non-determinism would introduce attack possiblities such as double spend and other coordinated attacks.
• one would have to implement a similar solution like in Ethereum the BTC bridge. That requires Ethash PoW validation on RChain, merkle proof validation and mechaisms (some challenge response mechanisms) to ensure that this conversion tx is in the longest chain within the Ethereum blockchain. These contracts and mechaisms provide a huge attack surface and would be painful to be audited.

3. Your proposed solution/ articles above describe tools to listen to events or tricker certain actions after a given event takes place on the Ethereum blockchain. The major difference to our conversion problem is that these tools are supposed to be used within the Ethereum ecosystem. That means you are running a node by yourself and therefore can verify the integrity for you (tx validity, fork choice etc). We dont want to have a direct dependency on a third party network esp. we dont want to see RChain security would depend on the security of the Ethereum blockchain and that would be the case if the integrity of REV - that means the staking tokens - would depend on the security of the Ethereum chain.

4. I hereby propose that everyone who is interested in figuring out want the best way forward is and everyone who could provide some technical inside jump in a zoom call. Anyone interested?

---

Jim proposed the Jun 13 8am pst for a zoom meeting (6853551826).

Possible agenda and doc for minutes ( please add points) for the upcoming zoom call as well as minutes of the discussion so far can be found in the doc initiated by Jim: https://docs.google.com/document/d/1a31XRB_WnQsNix8ct2daQlNdP2-To9h2XI9ctJG3fj8/edit#

[alex-coinfund]

Having read the document and the above discussion I propose the following much simplified approach.

RHOC2REV conversion proceeds in two stages.

Stage 1. Before RChain is launched. There is a smart contract on Ethereum launched by the Coop that will accept RHOCs. RHOC holders who send RHOCs to the contract will be included in the root of the RChain and their REV will appear in their wallet (same as ETH address) from launch.

The rest of REV is in custody of the coop and will be distributed as follows.

Stage 2. After RChain is launched. The same smart contract on Ethereum will receive RHOC. There will be a batch process on the RChain side managed by the Coop either indefinitely or for a given amount of time (1 year?) that will mirror the transactions that send RHOC to the contract onto RChain distribution of REV back to the same address.

Notes.

1. The ETH-side contract is multi-sig and RHOCs that get distributed on the RChain side as REV get burned after the distribution is confirmed ensuring that there is no event (such as loss of control over the ETH contract) that will bring them back into circulation.

2. One issue with RHOC2REV is hardware wallet support. Some members hold RHOC in hardware wallets. Without sufficient support for those wallets by RChain, access to REV will be restricted until such support is available. It is my recommendation to provide hardware wallet support from the get-go, because you REALLY don't want community to expose their private keys to an online wallet and getting hacked for large amounts of REV.

If you want my additional help here, I'd recommend scheduling a discussion. Please email me directly if that is of interest.