Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Write spec for Harmony Mining #3672

Closed
nathan-at-least opened this issue Nov 14, 2018 · 173 comments

Comments

@nathan-at-least
Copy link
Contributor

commented Nov 14, 2018

From Announcing Zcash Blossom and proposed feature goals:

Harmony Mining

  • What is it? A dual-proof-of-work scheme, where one algorithm is backwards compatible with current mining equipment, and another is designed to work well with GPUs on a temporary time scale.
  • Who does this affect? miners
  • Why is this a goal? By attracting distinct mining userbases (ASIC & GPU owners) we aim to make the Zcash ecosystem more resilient by spreading issuance and political influence among distinct kinds of stakeholders.

Close Criteria: Close this ticket when there are well-specified precise requirements for this feature goal.

@zookozcash

This comment has been minimized.

Copy link

commented Nov 22, 2018

I'm delighted to find out that Grin had already independently decided to do a "dual PoW" scheme, including the distribution of mining rewards changing incrementally over time: https://www.grin-forum.org/t/cuckatoo32-feasibility/1199

John Tromp told me that they've already had it running for a month on testnet4.

@tromp

This comment has been minimized.

Copy link

commented Nov 22, 2018

@tromp

This comment has been minimized.

Copy link

commented Nov 22, 2018

Btw, this thread seems to be missing the "PoW and mining" label?!

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

I'm concerned about the security of dual PoW against 51% attack, relative to single PoW. (There are also various attacks requiring less than 51%, and the discussion below mostly applies to them as well, but for simplicity I'll assume >50% as the threshold.)

Suppose that:

  • the solution rate of the network in NP Sols/s for each PoW algorithm P.
  • the solution rate of an adversary is AP Sols/s for each PoW algorithm P.

In single PoW with algorithm W, the adversary's probability of getting each next block is AW/NW.

In dual PoW with algorithms X and Y, it is not obvious how to split the work of finding blocks for each algorithm in a way that maximizes attack cost. The problems are best seen if we assume that one of the algorithms, say X, is weak. This could be either an unanticipated flaw in the algorithm, or just inadequate decentralization; in either case we assume that AX > NX/2.

Let's consider several possible dual PoW protocols.

Alternating

If the algorithm alternates between X and Y, then everyone knows which PoW algorithm will be used for the next block, and only mines on that algorithm. NX and NY might be higher in this scenario if it is possible to retarget the same hardware to mine either X or Y, but maybe not much higher if X and Y are efficient on disjoint hardware. The adversary's probability of mining a block alternates between AX/NX and AY/NY.

This isn't very good: if the adversary has dominance in X and is lucky in Y, then it can mine an attacking side chain which is about twice as long than it otherwise could, plus one block (because it can start and end on X).

A more thorough analysis would need to take into account the effect of miners switching between chains when they know that their hardware is not efficient for the PoW of the next block. For example if there were another chain with similar hash rate also alternating between X and Y, there could be interesting harmonic effects. This is somewhat hard to model. Alternatively some miners may idle their hardware to save power, which affects the economics of capital cost vs energy cost.

Parallel

In this protocol there are difficulty targets DX and DY, which are adjusted independently based on the history of block times for X and Y respectively. In this case an ideal difficulty adjustment algorithm would ensure that the probability of the next block being found using X is 50%, and similarly for Y.

This incentivizes all miners to mine continuously, which is a security advantage because the worst-case cost of an attack is increased. For instance, if an adversary dominates one algorithm but has no hash power in the other, then they still only have a 50% chance of winning each block. With ideal difficulty adjustment, the adversary's probability of mining each block is AX/2·NX + AY/2·NY. So the maximum advantage per block of an adversary that favours a particular algorithm is reduced relative to the Alternating protocol.

However, the mechanism for balancing the block probability between the two algorithms is potentially subject to attack. An adversary that favours algorithm X, may try to game the difficulty adjustment algorithm to increase the difficulty of Y relative to X. The Zcash difficulty adjustment algorithm is reasonably robust, but it has not been exposed to this kind of attack before (in Zcash as it stands with a single PoW, this attack would gain little for an adversary, because it would still be competing with all other miners at the same difficulty).

Some potential improvements to the difficulty adjustment's resistance to manipulation are described in #3692. It would be better not to have a strong reliance on it, though.

[to be continued]

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

Parallel + half block time + dual confirmation rule

This variant is motivated by attempting to limit the reliance on the difficulty adjustment to balance the selection of blocks between algorithms. It also reduces the chance that the adversary simply gets lucky in having a run of blocks for its favoured algorithm. We use the parallel protocol above, but also modify the confirmation rule to require k confirmations of blocks mined using X, and also k confirmations of blocks mined using Y. In order to compensate for the larger number of confirmations, we halve the effective block time. For example, if each difficulty algorithm targets a time of 150 seconds, then the effective block time will be 75 seconds. Then, the confirmation latency will be roughly double the number of blocks, but about the same length of time. Note that we were considering reducing the block time anyway in #3690.

(We can think of this as being similar to having two chains, running in parallel, that are cross-notarizing each other. Actually doing that would raise other problems such as the lack of a total ordering of transactions; the above approach avoids those problems but achieves similar security against rollback attacks.)

Let's do a little math to work out the effective block time of two algorithms with parallel difficulty adjustment, without assuming that the block times are perfectly balanced. We have two Poisson processes, with different parameters λX = 1/TX and λX = 1/TX, where TX and TY are the expected block times for each algorithm. The two processes are racing to produce a block, so the random variable giving the overall block time is the minimum of the two exponential random variables giving the block times for these processes. This problem is solved here under the (reasonable, for this model) assumption that the two random variables are independent. The answer is that the overall block time is another exponential random variable with parameter λE = λX + λY. That is, the expected block time is TE = 1/(1/TX + 1/TY).

If we set TY = c·TX, we can see how an imbalance in expected block times between the two algorithms affects the overall expected block time: in this case the latter is given by c·TX/(1+c). For example, if c = 1.1 (i.e. the Y difficulty is too high by 10%) then the overall block time increases from 0.5·TX to 0.524·TX, i.e. by a factor of 1.048. Even if c = 2 (i.e. the Y difficulty is too high by 100%), then the overall block time increases from 0.5·TX to 0.667·TX, i.e. by a factor of 1.333. This is not bad at all! We need not be worried that the dual-PoW block time will be less stable than the single-PoW block time; actually it will be more stable.

However, the dual confirmation rule introduces some disadvantages:

  • Existing systems (exchanges, wallets, merchants) aren't set up to have complicated coin-specific confirmation rules. They want a fixed number of confirmations.
  • Strictly speaking, there is no upper bound on the number of blocks needed for confirmation. I don't think this is actually much of a disadvantage in practice, because the probability of a run of blocks being of the same algorithm should tail off exponentially with the run length. However, it would be annoying to have to convince people of this.

Also, in this approach we're reducing the block time without obtaining a reduction in confirmation latency, as might have been expected.

[to be further continued]

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

Parallel + half block time + forcing rule

The protocol in the previous comment also suffers from the problem that if the adversary is successful in "starving" one of the algorithms, then it will take a long time to adjust back to equilibrium, because the difficulty for a given algorithm only changes when a block is found with it. (This is reminiscent of the problem we had recovering from a large miner suddenly disappearing on testnet, just before the release of 2.0.1.)

I propose to fix this by adding a rule that limits the maximum proportion of blocks mined with a given algorithm within a short window. For instance, a possible rule would be:

If 5 out of the last 6 blocks were mined with the same algorithm, then the next block must be mined with the other algorithm.

The effect is that in every run of 7 blocks, at most 5 can be mined with the same algorithm. Therefore, for each integer m > 0, in every run of 7·m blocks, at most 5·m can be mined with the same algorithm.

This forcing rule essentially introduces an element of alternation into the algorithm selection, with similar disadvantages when the next block is to be forced. However, unlike the Alternation protocol, forcing is not expected to happen very often when the difficulty adjustment is working correctly. A back-of-the-envelope simulation demonstrates that if the probabilities of mining a block with each algorithm are balanced, then the forcing should happen by chance only for ~3.22% of blocks. Python code for the simulation is here: dualpowsim.py

Suppose, then, that we set the confirmation rule to 21 blocks. This is only a little more latency than the 10 blocks currently recommended, because the blocks come twice as fast. The forcing rule guarantees that among these 21 blocks, there are a minimum of (21/7)*2 = 6 blocks mined with each algorithm, which should be sufficient to avoid either algorithm being "starved".

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 4, 2018

Note that a forced block will typically take about twice as long. It is tempting to try to modify the difficulty target for forced blocks to compensate for that, but this would increase the profit margin for those blocks (they would have the same reward at lower difficulty), and so it would create a perverse incentive for a mining coalition to try to cause forced blocks.

Instead, I propose halving the block time target for forced blocks, without modifying their per-block difficulty target. This will cause the difficulty adjustment to compensate for the greater block time, maintaining the intended emission schedule (and incidentally also providing a negative feedback so that the algorithm that has had fewer blocks adjusts to a slightly lower difficulty).

@brndnmtthws

This comment has been minimized.

Copy link

commented Dec 5, 2018

Don't change things for the sake of changing things. Unless it's actually broken (it's not), there's no compelling reason to change it.

The idea that having multiple algorithms doesn't sound like it improves security or decentralization. If anything, it serves to devalue the rewards (more competition for the same blocks), so miners will be less compelled to mine ZEC when there are other options out there.

@autotunafish

This comment has been minimized.

Copy link

commented Dec 6, 2018

Assuming the Half Stack at 75 seconds would this require an attacker to possess control of greater than 50% of both algorithms simultaneously since both blocks are being mined at the same time? Also since the hardware with predominantly more hashrate would be incompatible with the other algorithm how feasibly effective is algorithm hopping from gpu (or such) to asic (especially since I [assume] need to maintain conrol of that side)?

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2018

In either of the last two proposals ('Parallel + half block time + dual confirmation rule' or 'Parallel + half block time + forcing rule'), an adversary is trying to satisfy the confirmation rule, which requires at least k blocks of each algorithm, in the same time period in which the rest of the network finds blocks totalling the same amount of adjusted work. In the dual confirmation rule k is specified directly; and in the forcing rule variant I gave as an example, it is 2/7 times the overall number of confirmations.

In a model where finding a block is treated as a Poisson processes and the adversary has specified fractions of the hash rate, and for any of the confirmation rules specified above, the success probability of an attack ending at a given block is well-defined. I have not calculated what it is for any of the dual-PoW confirmation rules, and I am not making any claims about that.

On the other hand, it's certainly false that an adversary needs a majority of the hash rate of both algorithms for non-negligible probability of a successful attack, because the corresponding statement for single PoW is also false.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Dec 10, 2018

@daira I have some additional proposed feature requirements that will almost certainly complicate this analysis. Let me try specifying all of the requirements, starting with the one (aka FR1) which seem consonant with your design analysis first:

Terminology:

  • block selection protocol: the top-level consensus protocol that selects among candidate blocks.
  • block work/verification algorithm: the sub-algorithm which forces miners to compete to nominate blocks, while making it cheap for validating nodes to determine a given solution meets the difficulty requirements.
  • difficulty adjustment algorithms: the block selection protocol uses separate difficulties and difficulty adjustment algorithms for each work/verification algorithm.
  • immediate revenue: this is the expected revenue per time denominated in ZEC as the time window approaches 0 for a given miner.

Requirements:

  • FR1: Award blocks among two categories of miners by a single block selection protocol, such that if the distribution of mining capacity for either algorithm is non-malicious, then the overall result is resistant to attack.
  • FR2: Let one of the work/verification algorithms be identical to current Zcash (as of Sapling), call this alg-A.
  • FR3: Let the other work/verification algorithm be our best effort at being something practically competitively mineable by GPUs at Blossom activation. Call this alg-B.
  • FR4: The immediate revenue for an active miner of Zcash at the block just prior to the activation height for Blossom should be almost identical starting with the activation height. (Subtlety: this includes GPU miners, even though their immediate revenue may be below their costs.)
  • FR5: This immediate revenue for alg-B specialized miners will be 0 at activation height.
  • FR6: Adjust protocol parameters in a linear fashion from the activation height, H to exactly H + 210,000, such that at H + 210,000 the immediate revenue for all mining capacity of alg-A is equal to all mining capacity for alg-B.

Rationale:

  • R1. The rationale for FR4 to FR6 is for there to be no discontinuity for existing Zcash miners in term of revenue per time.
  • R2. Meanwhile, the goal is for the attractiveness of Zcash mining to ramp up for GPU owners.

Concerns:

  • C1. During the early period of this ramp, one algorithm will have a low immediate revenue, so this very likely will impact the security analysis of the block coordination protocol. For example, if the coordination protocol requires K of the last N blocks must be won by alg-B by a forcing rule, but there's 0 revenue to mine alg-B during that period, this seems bad.
  • C2. What if it's not practical to mine alg-B for some time, and during that period new ASICs are deployed?
  • C3. What if early in the ramp, only very large scale GPU mines are profitable due to economies of scale, therefore that portion of the mining network is extremely centralized from the onset?
@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

FR4 is impossible, unless the overall emission rate changes. The purpose of the upgrade is to split the emission between alg-A miners and alg-B miners, which are assumed to have different hardware. Therefore, if the overall emission remains the same, then the aggregate revenue of alg-A miners will necessarily decrease at Blossom activation. Individual miners can obtain alg-B-suitable mining rigs as well to mitigate this, but obviously that has a capital cost. It can be expected that the decrease in revenue will be partly offset by some alg-A miners leaving and a consequent reduction in the alg-A difficulty for the remaining miners, but it's difficult to predict by how much.

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

Oh, I see, you want to ramp in alg-B. In that case FR4 is not impossible, but it's rather complicated. The simplest option is to just linearly increase the proportion of the block reward given to alg-B miners from 0% to 50%. But that is neither secure (there's insufficient incentive to mine alg-B initially), not does it guarantee that the overall emission is the same as it would have been without Harmony.

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

I really don't think FR4-6 are well-motivated. IMHO we should just live with the political fallout due to ASIC miners having a sudden drop in revenue. (This also happens at halvings and it hasn't caused a serious problem for Bitcoin.)

@str4d

This comment has been minimized.

Copy link
Contributor

commented Dec 11, 2018

Referencing an old issue that is somewhat relevant: #1211

@mms710

This comment has been minimized.

Copy link

commented Dec 12, 2018

Update to a comment I made 3 days ago. The original comment just stated that the RICE score for this goal was 5.4.

Sorry, it took me a while to get back to this. Some context on the RICE scoring method: the RICE score is supposed to help provide a guideline for rough prioritization of various ideas (in this case, various possible Blossom goals). While it will be used as a guideline, it is not a hard and fast rule that something with a higher RICE score will always be worked on first or have a higher priority. The most useful way RICE scores can impact the Zcash selection process is by providing an indication of which items are "low-hanging fruit". You'll notice that some of the higher scored items have low effort associated with them.

In addition, it's important to know that this is an initial RICE score. After the goal is fully detailed and specified, we will perform the RICE scoring again because we will have gained more information that will make the RICE scores more accurate.

We calculate our RICE scores using the following formula:
(Reach * Impact * Confidence)/Effort.
Reach: How many users will this change/feature impact, or how many new users will this gain? Alternately, you can think of this as roughly what % of our user base this change will reach. Give this a 1-10 score, 1 being the least amount of reach and 10 being the most. Generally, items with a 9 or 10 score will gain new users.
Impact: How large of an impact will this change/feature have on users? Will it increase their usage of Zcash, or of shielded transactions? Give this a 1-10 score, 1 being the least impact and 10 being the most.
Confidence: How confident are you that this change will reach the amount of users you said and impact users as much as you said? Please express this in a % form between 1-100% (typically in increments of 10), 10% meaning not at all confident and 100% being very confident.
Effort: How many person months will this work take to complete? This should be an estimate and you can use portions of person months in the calculation. For example, 2 weeks = .5 months.

RICE Score for this Item:
Reach: 7 - this will impact a good portion of our users but not necessarily all of them (this will impact miners significantly, and a good portion of the community cares about this issue even if it may not impact them directly)
Impact: 10 - we expect this to have a very high impact on the users this will affect
Confidence: 85% - we're pretty confident about our reach and impact numbers
Effort: 11 - we think this will take 11 person months to complete

Calculation: (7* 10 *.85)/11 = 5.4 RICE Score

@zookozcash

This comment has been minimized.

Copy link

commented Dec 12, 2018

Miners who opt in to mining the new algorithm with receive their mining reward coins time-locked, so that the coins unlock in 52 successive tranches, once per week, for one year. The rationale for this is that it provides additional long-term incentive alignment between coin-holders and miners. This makes the network safer and more reliable for all users. Include the costs of this requirement in the planning for this feature.

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2018

I don't agree that the time lock will make the network safer and more reliable: quite the opposite, because I believe it favours large miners (who have enough capital to afford the delay) at the expense of smaller miners. Actually I believe a large proportion of smaller potential miners would hate this feature and would consider it a severe obstacle to mining ZEC at all. I'm having difficulty expressing how strongly I feel this is a bad idea.

@daira

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2018

Also note that we have no way to time-lock shielded outputs without a circuit change (which is not planned for Blossom, and there's no allowance for it in the schedule), therefore time locking would preclude allowing direct mining to z-addresses (#2488), which would otherwise be feasible for Blossom. That would have a knock-on effect of delaying removal of t-addresses.

[Edit: #2488 has been delayed to NU3. So, it is possible that NU3 could support both shielded time-locking and direct mining to z-addresses. However, this is still a relevant argument because doing both would impose severe constraints on NU3.]

@mms710

This comment has been minimized.

Copy link

commented Dec 13, 2018

We may need to do #2715 as part of this ticket

@tromp

This comment has been minimized.

Copy link

commented Jan 14, 2019

postpone Harmony Mining from NU2-Blossom

That's a missed opportunity. I would suggest to implement Harmony Mining with Alg-B being,
surprise, surprise, Equihash 200,9.

@zawy12

This comment has been minimized.

Copy link

commented Jan 14, 2019

I would suggest to implement Harmony Mining with Alg-B being, surprise, surprise, Equihash 200,9.

Don't forget the foundation of saying "dual POW has higher risk" is that the cost to get > 50% HR in algo B is trivial compared to the cost of getting < 50% HR in algo A. So they should not switch to algo B, especially suddenly. If the axii are backwards, then algo-B is the one with drastically higher cost and of course they should switch immediately. I would have thought the only reason for considering dual algos is the presumption that they have similar costs to get 50% so that the risk is not higher.

@tromp asked me to review what Grin is doing to see if my "equal chain work" concern actually applies. It does not: their chain work is correctly assigned to the blocks. He provided two more links to explain it:
https://www.grin-forum.org/t/what-to-mine-choosing-between-cuckatoo31-and-cuckaroo29/1732
https://www.grin-forum.org/t/on-dual-pow-graph-rates-gps-and-difficulty/2144
https://github.com/jaspervdm/grin_mining_sim/pull/2/files

Grin has to select the initial value and rate of change of "ar_scale" carefully. Hashrate share will be sensitive to smallish changes in ar_scale. This complicating factor was more explicit (and therefore uglier) in the methods I suggested for @solardiz's (and Grin's) "combined" method. The parallel method is more resilient but more complicated. Grin's is the simplest method, provided ar_scale can be chosen and adjusted correctly. By transitioning slowly from A to B, Grin is allowing a market (competition) for B to develop, so if there is a single miner at first who owns most of the equipment for algo B, the threat of a roll back is less. If they were jumping straight to 50/50, and a single miner owned most of algo B HR at the transition, then @daira's results apply.

@zawy12

This comment has been minimized.

Copy link

commented Jan 14, 2019

Long story short: don't consider dual POW unless you have a darn good reason.

@solardiz

This comment has been minimized.

Copy link

commented Jan 15, 2019

@tromp Why would Zcash want to have two instances of the same PoW? Just to debug the dual-PoW support to some extent by the time it's actually used for two different PoWs? I doubt this would achieve much.

@tromp

This comment has been minimized.

Copy link

commented Jan 15, 2019

Yes, if you plan to migrate away from Equihash 200,9 any time in the future, then having dual-pow support in place will ease the transition.

@mms710 mms710 added NU3 wishlist and removed Blossom Goal labels Jan 15, 2019

@mms710

This comment has been minimized.

Copy link

commented Jan 15, 2019

Removed Blossom Goal tag and added NU3 wishlist tag to indicate that this item has been moved to the NU3 wishlist.

@mms710 mms710 moved this from Current Sprint to Sprint Backlog in Arborist Team Jan 15, 2019

@mms710 mms710 moved this from Sprint Backlog to Blocked in Arborist Team Jan 15, 2019

@zookozcash

This comment has been minimized.

Copy link

commented Jan 15, 2019

Yes, if you plan to migrate away from Equihash 200,9 any time in the future, then having dual-pow support in place will ease the transition.

I agree, and I appreciate the good suggestion, but the unresolved issues in the engineering and security of Harmony Mining which are keeping it out of NU2 have to do with the Dual-PoW part, (and with the Time-Locked-Rewards part), not with the new-PoW-alg part.

@zawy12

This comment has been minimized.

Copy link

commented Jan 16, 2019

@zawy12 wrote:

BTG and I had a discussion after their attack and we both concluded that difficulty algorithms have (surprisingly) absolutely no effect on the ability to conduct 51% attacks.

@daira

This is true for single PoW and false for dual PoW. BTG is single PoW.

It's true for 2 POWs if the cost to gain % HR share in both is equal, which is the presumption if you're considering 2 POWs (otherwise you'd just use the POW that has that has higher cost to gain share in order to get greater security). POW really measures "work" so increasing or decreasing the 51% rules is like a violation of the conservation of energy....as long as your energy measurements are in the same units.

@zawy12

This comment has been minimized.

Copy link

commented Jan 16, 2019

Here's a way dual POW has greater risk even if costs are the same: if there is only 1 potential attacker, but you do not know if he is on POW A or B, then there is a 50% you choose the wrong POW. But if you choose both, he's on your network and still has 50% of your total HR because the reward for his POW is 1/2 what it would have been with single, so he has 100% of it.

This makes some really idealistic assumptions about the HR market (that it is perfect). But under that assumption, security seems worse. Maybe precisely 1/2 what it was. But notice the attacker's cost is the same.

So my argument that security is the same is only valid in terms of a cost metric and an ideal marketplace for both POWs. @daira's position is in terms of cost and relies on a non-ideal "POW market" situation. But now I'm saying if you go beyond naive cost, dual POW is less secure even if the POW market is perfect. The probability of a rollback for multi POWs seems to be the sum of their risks as individual POWs, given these idealistic conditions.

This ratio needs to stay below 50%:

(rental HR +colluding miners HR) / (non-colluding staked miners HR)

But this last "higher risk" argument only applies if the market of both POWs is well-developed and not dependent on the coin in question. It does not apply if the attacker is POW A and POW A miners do not have another (large) coin to mine or if the attacker is POW B and there is a slow transition to POW B that gives other miners time to catch up (Grin)

@daira daira changed the title [Blossom NU] Write spec for Harmony Mining Write spec for Harmony Mining Jan 24, 2019

@daira daira unpinned this issue Jan 28, 2019

@MoneroChan

This comment has been minimized.

Copy link

commented Feb 11, 2019

Hi @daira
I'm wondering if "Braiding" the blockchain solves the 2 problems referenced above in the 'Parallel + half block time + dual confirmation rule' method?

I've created a diagram showing how this would work to solve the problems mentioned:
https://i.imgur.com/z0m2UoI.jpg

Quick summary: Transaction Partitioning > 2 Virtual Algorithm workspaces > "Braided" Style Dual-factorization for 'very orderly' recombination to one blockchain to allow 'simple confirmations' at exchanges.

Solves Problem 1: "lack of a total ordering of transactions"

  • As shown in the diagram, Tx Hash partitioning and braided blockchains makes the transactions very orderly and predictable. (See exception handling section Fig 4 about maintaining order)

Solves Problem 2: "- Existing systems (exchanges, wallets, merchants) aren't set up to have complicated coin-specific confirmation rules. They want a fixed number of confirmations"

  • The braid configuration appears to solve this problem by making verification simple at exchanges and giving them a fixed number of confirmations. Exchanges can do verification using just 'one' algorithm that is made up of both algorithms in series, so it's no different to a 'Single long PoW Algorithm' on any other coin. Only difference is, they only have to scan the 3rd last block (so there is always a 2 block confirmation delay), and leave the nodes to to the complicated hard work with the first 2 blocks.

Are there any other problems i missed?
Could this work?
Thanks.

@autotunafish

This comment has been minimized.

Copy link

commented Mar 1, 2019

https://forum.zcashcommunity.com/t/future-of-zcash-mining-circa-2019-and-2020/31737/90?u=autotunafish
Thoughts?

Idea, a proof of research chain like gridcoin (because of the aforementioned reasons) where people earn Zcash (simply) using boinc
No transactions besides the mining payout and sending from researchers address (ZR maybe) to the original chain (ZS) occur, no coins can be sent back from the main chain to the research chain (this prevents pools but no real need for pools anyways with this setup)
Instead of time locking the mining reward it should time lock the ability to send to the original chain giving the researcher the option to stake or do nothing and wait
Outgoing offchain sends and staking would be problematic, if it were possible to create a function to prevent the effective amount of coins Staked to half that exist at that block then no more than 50% could ever be staked (say 1 million coins total, 750,000 Stake, everybody’s effective stake diminishes by 33% of their total Stakes if thats possible or even necessary?)
Since ZR2 ZR transactions are prevented stakes can never be combined (perhaps the blocks intervals are incredibly long and outgoing (ZR2 ZS) transactions and their confirmations would take a long time further incentivising the time locking and staking)
Deciding on which projects could be worked on for reward and how the reward is split from the main protocol is a separate issue of governance

The aforementioned reasons are from here

https://forum.zcashcommunity.com/t/zooko-talking-about-pos-pos-vs-pow-discussion/31437/149?u=autotunafish

GRC isnt suitable for a payment system because of long indeterminate block times (due to the meaningful work executed by all sorts of devices taking indeterminate time) but may be ideal for timelocking, also currently incorporates PoS and Zerocash protocol (for account protection from hijacking)
It is also somewhat time tested having launched oct 2014

I realize that this has no 51% attack benefits for the main chain but seems like it would very inclusive

@autotunafish

This comment has been minimized.

Copy link

commented Mar 12, 2019

Something like this for the main chain allowing for a multitude of Asic miners (sharing it asap) https://t.co/cT7zTLs4A7?amp=1
and the aforementioned idea which would allow for a multitude of general purpose devices

@umma08

This comment has been minimized.

Copy link

commented Jun 8, 2019

is there an update on the status of this issue?

@daira

This comment has been minimized.

Copy link
Contributor

commented Jun 8, 2019

Harmony Mining was not submitted for NU3. The security issues that led to its withdrawal from Blossom have not been solved. My impression is that there isn't anyone willing to take on the necessary work to redesign it and redo the security analysis.

I suspect there now isn't time to submit it for NU4, since there is more work needed on the design than is realistic before the NU4 ZIP submission deadline. Even if there were someone interested in resubmitting a version of it, the soonest that could possibly activate would be NU5 which is scheduled for April 2021.

@nathan-at-least

This comment has been minimized.

Copy link
Contributor Author

commented Jun 11, 2019

I'm closing this ticket to signify that ECC has no current plans for this specific proposal in NU2 or NU3. If ECC or anyone else wants to propose something similar to this, moving forward they should use the ZIP process. (FIXME: link to instructions on how to participate. See zcash/zips#241)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.