[discussion] dpow2.0 "wishlist"

[Alrighttt]

I am opening this issue as a place to discuss dpow2.0(for lack of a better name). Some of us had begun work on a potential replacement. You can find this here https://github.com/ssadler/zeno . It seems development of this "zeno" will not continue.

I would like to hear feedback on the community's current perception of dpow, what could be better, what needs rethinking, what is worth keeping, etc. I would like this to include not just the technical aspects of dpow, but also NN elections, easy mining, KMD consensus rules regarding notary nodes, long term implications, costs, etc.

No matter how infeasible or unlikely an idea may be, please share it as it may not be as outrageous as it initially seems(like dpow itself 😄). The first post will be my "wishlist". To clarify, it is unlikely all of these ideas will be implemented. It is meant to facilitate discussion. My "wishlist" are my personal views and mine only.

[Alrighttt]

"wishlist"

autonomous - something we can "unleash" that can live autonomously for years without constant maintenance to codebase

an arbitrary amount of people able to participate - possibly tiers, NNs elected with anyone being able to contribute; the idea being if you are participating, you know it is honest/genuine
    How would we prevent sybil attacks? elections? deposits? POS-esque?

a "synchronous"(as scott would say) solution - ie, in KMD->BTC situation, KMD tx is not even created until BTC is confirmed
    much slower, but actually lives up to "BTC level security"

either no regions or no region disparity

no "freeloading" 
    pay per notarization
    or pay per <performance metric>

VOTE elections are sub-optimal because you hardly need "skin in the game" to acquire large amounts of VOTE
    place a large buy the day of snapshot
    immediately dump after snapshot 
        do we really want people without any long-term stake in KMD to influence the election?

No "please don't do this _or else_" kind of rules. These have proven ineffective time and time again. Optimally, we would have no rules other than code. 
    We have often had issues of subjective rules being selectively enforced.

[TheComputerGenie]

VOTE elections are sub-optimal because you hardly need "skin in the game" to acquire large amounts of VOTE

more like: VOTE elections are sub-optimal because a single large stack of millions sways the elections every season

[ptyx11]

Just some random thoughts:

• Komodo’s blockchain security 2.0 should be
  1. Easy to integrate
  2. Easy to approve for security or remove the need for a security check when onboarding an external blockchain
  3. Self-funded with an automatic function that would remove blockchains that don’t keep their dpow address funded
  4. Cheaper
  5. A source of benefits for the Komodo community. Possibly direct rewards to KMD holders for every dpow’d chain.

[phm87]

Draft ideas to reduce BTC costs to notarize: Now, each notary is spending one utxo when he notarizes, it requires each notary to burn BTC funds and there is a risk that one notary is able to steal BTC funds.

Considering elected notaries, using komodo & bitcoin multisigs, we can create one multisig address per region with addresses of notaries of the region. At each BTC notarization round, each region (EU, AR, NA, SH, DEV) must send one BTC UTXO (into the same tx as usual) to have a valid notarization. The notarization points (if notarization points/counts are needed) will go to the notaries who signed the multisig tx. Risk of steal of funds by one or 2 notaries is also reduced. Other groups of multi signers are possible but with these example numbers, BTC cost can be reduced of 13/5 = 2.6 https://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses This can extend funding for dPoW considerably but it needs HF all smartchains, komodo and all 3P coins. I think that it is worth it since it reduces risk of steal of funds and dPoW project lifespan will be multiplied by 2.6.

A possible better alternative of this idea is to use the new "multisig scheme" of bitcoin Taproot, Schnorr, MAST, I need to read more about it but I think that it can allows to have 13-of-64 multisigs, it can reduce BTC cost of 64 ! I'm not sure, I need to verify this. Updating bitcoin to recent code will reduce risk since recent code is more code-reviewed than 0.15 and 0.15 won't have security fixes forever. Maybe we should explore alternative implementations of bitcoin wallet to avoid core reference implementation (I heard good about Knots).

Maybe another alternative of this idea is possible with MUSIG or using an alternate chain or mempool as layer (similar to dexp2p tech).

Another idea already discussed on discord is to use P2SH or Bech32 addresses. In order to estimate the fee reduction, maybe we can try on bitcoin testnet with createrawtransaction and compare fees.

[TheComputerGenie]

BTC cost is kinda moot as there's no logical reason to continue to use BTC in a fully new system. Cost increase is ingrained in the concept of BTC in order to push the concepts of "layer solutions", we all know this and pretending that it isn't true is counter to any "cheaper" notion. The more adoption BTC gains, the greater the cost of using BTC no matter what it's "reduced by" before then. Imo, it's pointless to keep trying to figure out how to save minor amounts in comparison to the overall savings of moving to something else.

[imylomylo]

Would a notarizer into Cosmos or Polkadot be effective and cost less? Using BTC is already effective & can be re-introduced in another era.

The blockchain adoption of smart chains for projects would still rely on KMD as the first security checkpoint.