NEW HIP

[jojoin]

New Hacash Improvement Proposals (HIPs) can be posted here to allow the community to consistently assign HIP number and included to the list.

[jojoin]

HIP-17: https://hacashtalk.com/t/proposal-for-the-issuance-of-external-assets-on-the-hacash-mainnet-draft/338

Proposal for the Issuance of External Assets on the Hacash Mainnet (Draft)

Background: The launch of HACD inscription function has achieved good results, and the value of artistic or other types of assets can now be easily stacked on HACD, which is essentially a new way of issuing assets.

In order to support a more diverse ecosystem, a proposal is made to introduce a mechanism for issuing assets (referred to as tokens) directly on the Hacash mainnet, with the following objectives in mind:

By limiting the number of tokens that can be issued per unit of time through a gas competition mechanism, the core operation of the Hacash sound money system can be ensured to be free from the influence of short-term speculation.

Increase the gas fee for token transfers to some extent, ensuring that the costs of HAC, HACD, and BTC transfers, as well as the opening and closing of layer 2 channel, remain low.

The token remains at the same level of status and technical support as HAC, HACD, and BTC on the layer 1, rather than being treated as secondary assets like contract assets on the EVM.

Strictly design the occupancy of the state data space to ensure that the decentralization of the Hacash mainnet is not negatively affected by unnecessary factors.

[Iv-84]

HIP-## Elimination and Redesign of HACD Bidding System

(Hacash Talk Post Under Review - Link Coming Soon)

Abstract

The proposed changes aim to enhance decentralization and improve network security while maintaining node synchronization speed as well as the integrity and value proposition of HACD within the Hacash ecosystem. This proposal suggests the elimination of the HACD (Hacash Diamond) bidding system from Hacash’s Layer 1 (L1) blockchain and provides a roadmap for its potential redevelopment on a Layer 2 (L2) solution.

Background

Hacash operates with two Proof-of-Work (PoW) assets:

• HAC: The primary asset forming the main blockchain.
• HACD: A secondary PoW asset recorded as a transaction on the HAC chain, with one HACD transaction permitted every 5 HAC blocks.

Currently, during these 5 blocks, miners compete to discover HACD and subsequently engage in a bidding process. The miner of the 5th HAC block selects the highest bid, embedding the transaction into the blockchain. While this system encourages competitive bidding, it suffers from several decentralization and security issues:

• Miner-Centric Decision Making: The decision to accept the highest bid is solely at the discretion of the HAC block miner. This creates vulnerabilities where malicious miners could modify node code to accept their own bids and disregard higher bids from other participants.
• Bid Pool Centralization: The pool used to decide the best bid exists exclusively on the miner’s node. Nodes with unstable connectivity or nodes that have been functioning for only a short period (e.g., minutes or seconds) may lack access to the highest bid data, further centralizing the bidding process and undermining network fairness.

These issues compromise the fundamental decentralization of Hacash, as outlined in its whitepaper.

Additionally, the whitepaper emphasizes that the core value of blockchain lies in its trustlessness, not merely decentralization: “The core value of blockchain does not lie in decentralization, permanent data storage, or evading regulation. Instead, it rests in the concept of trustlessness, which means mitigating structural trust risks within a system” (Hacash Whitepaper, p. 10). Therefore, ensuring that HACD mining operates in a trustless manner is critical.

Proposal

To address these challenges and align with Hacash’s principles, we propose the following:

1. Elimination of HACD Bidding on L1:

   • Remove the bidding process entirely from the L1 blockchain.
   • Prevent reliance on miner-centric decision-making and exclusive node data.

2. Adjust HACD Generation Mechanics:

   • Remove the limit of one HACD per 5 blocks.
   • Introduce a dynamic difficulty mechanism for HACD mining, similar to HAC, to regulate HACD generation to approximately 50-60 diamonds daily.

3. Fixed Value for HACD:

   • Assign a fixed fee value for each HACD mined to maintain deflation. For example, 20 HAC (calculated as 50% of the 40 HAC created in the current 5-block cycle).

4. Future Development of HACD Bidding on L2:

   • Delegate the bidding mechanism to a dedicated L2 solution, leveraging off-chain scalability for decentralized auctions without overburdening L1.

Rationale

• Decentralization: Eliminating L1 bidding ensures that no single miner or node holds undue power over the HACD creation process.
• Trustlessness: Ensuring that HACD mining is trustless mitigates risks associated with centralized control or manipulation, aligning with the core value of blockchain.
• Network Synchronization: Not storing the bidding data in L1 (as proposed by HIP 17) minimizes storage and computational overhead, supporting efficient synchronization of nodes, as highlighted by the system's emphasis on practical scalability and network performance in the whitepaper.
• Scalability: By transitioning bidding to L2, Hacash can achieve high-performance auctions without compromising L1 efficiency.

Conclusion

This proposal outlines a clear path to reinforce Hacash’s decentralization and improve network fairness. By removing the flawed bidding system from L1 and reimagining it on L2, Hacash can maintain HACD’s value and utility while staying true to its foundational principles.

References

• Hacash Whitepaper:
  • Definition of HACD as a “block diamond” without explicit mention of a bidding system (p. 47).
  • “The core value of blockchain does not lie in decentralization, permanent data storage, or evading regulation. Instead, it rests in the concept of trustlessness, which means mitigating structural trust risks within a system” (p. 10).
  • Emphasis on “Signature Stripping and Data Compression” to optimize storage and improve synchronization efficiency (p. 76-77).

[hacashdiamond]

@jojoin hi, I want to create a system where I can bid on diamonds using an API. I used the API below, but it's not working. I don't know if it's the right API. Which API should I use to bid on diamonds?

[http://nodeapi.hacash.org/operate/fee/raise?fee_prikey=8D969EEF6ECAD3C29A3A629280E686CF0C3F5D5A86AFF3CA12020C923ADC6C92&fee=32:248&tx_hash=ad26a35116664176426f3c08adad147577b9a85999cb89d465becf6a27002c04]