Lets talk about Avalanche

Consensus
#1

Amaury Séchet explaining in detail the mutually beneficial interplay of Nakamoto Proof-of-Work and Avalanche Proof-of-Stake on eCash:

https://x.com/eCashCommunity/status/1837939185925476507

#2

This is Bitcoin Cash Research place. You need to raise the bar and provide some technical research documentation.

Pasting promo videos and talks is basically shilling. It’s unbecoming to this platform.

#3

As was discussed on telegram on this topic, it would indeed be much more productive if there was a technical specification available for what the hybrid ‘PoW + Avalance’ consensus looks like.

The proof-of-stake part (implemented in AVAX) of the protocol is described in this whitepaper: https://ipfs.io/ipfs/QmUy4jh5mGNZvLkjies1RWM4YuvJh5o2FYopNPVYwrRVGV

but the lack of a spec for a hybrid Avalanche solution has been noted years ago already: https://www.reddit.com/r/ecash/comments/tpm85l/avalanche_postconsensus_specification/

and I don’t think that situation has changed since. So a first step would be documenting how XEC uses avalanche so we have a clear design to discuss.

2 Likes
#4

PoW and Avalanche are not complementary. They are both consensus algorithms, it’s ok to have one or the other. It remains a mystery to me as to why have both.

AVAX has Avalanche as consensus mechanism and, as far as consensus goes, it works for them.

1 Like
#5

It’s Avalanche that enforces rules. PoW block producers have to abide by these rules or be orphaned. To stake in Avalanche you must present a proof of your stake that is 2 weeks deep with PoW. It will be very transparent if your staking transaction were to get blocked. The attacker must also have more than 50% of the stake, and since Avalanche is a softfork you can also fall back to PoW very easily. This will send staking profit back to zero.

#6

I asked OpenAI-o1 to write a spec:
“Write a spec on this code: https://github.com/Bitcoin-ABC/bitcoin-abc/tree/master/src/avalanche”

Specification Document for the Avalanche Module in Bitcoin-ABC

Knowledge Cutoff: October 2023

Table of Contents

  1. Introduction
  2. Overview of the Avalanche Protocol
  3. Module Architecture
  1. Data Structures
  1. Interaction with Bitcoin-ABC Core
  2. Network Protocol Messages
  3. Security and Validation
  4. Configuration Parameters
  5. Error Handling and Logging
  6. Extensibility and Future Work
  7. References

1. Introduction

This document specifies the implementation details of the Avalanche module within the Bitcoin-ABC codebase, specifically focusing on the content located at src/avalanche . The Avalanche protocol is integrated into Bitcoin-ABC to enhance transaction and block propagation, enabling faster and more reliable consensus.

2. Overview of the Avalanche Protocol

Avalanche is a consensus protocol that operates on a metastable mechanism, allowing network participants to quickly agree on the validity of transactions and blocks. It improves upon traditional proof-of-work consensus by introducing probabilistic finality and reducing confirmation times.

Key features of Avalanche in Bitcoin-ABC include:

  • Peer Sampling: Randomly selecting peers for queries to maximize the spread of consensus information.
  • Query Mechanism: Initiating queries to peers and collecting responses to determine the acceptance of transactions.
  • Conflict Resolution: Handling conflicting transactions through a voting process to reach consensus.

3. Module Architecture

The Avalanche module comprises several key components responsible for managing peer interactions, handling proofs, maintaining the voting mechanism, and processing messages.

3.1. AvalanchePeerManager

Files:

  • AvalanchePeerManager.h
  • AvalanchePeerManager.cpp

Responsibilities:

  • Manage the set of peers participating in the Avalanche protocol.
  • Keep track of peer availability and responsiveness.
  • Handle registration and deregistration of peer nodes.
  • Maintain peer-related data such as proofs and stakes.

3.2. Proof Management

Files:

  • Proof.h
  • Proof.cpp
  • ProofPool.h
  • ProofPool.cpp
  • ProofId.h

Responsibilities:

  • Manage proofs of stake provided by peers for Sybil resistance.
  • Validate and store proofs in a pool.
  • Provide lookup and retrieval functionalities for proofs.
  • Ensure the uniqueness and integrity of proofs.

3.3. Voting Mechanism

Files:

  • VoteRecord.h
  • VoteRecord.cpp
  • VotingItem.h
  • VotingItem.cpp

Responsibilities:

  • Record and track votes on transactions and blocks.
  • Determine the confidence level of items based on peer responses.
  • Update the acceptance status of items based on voting results.
  • Handle rejections and conflicts through voting outcomes.

3.4. Message Handling

Files:

  • protocol.h
  • protocol.cpp
  • messages.h
  • messages.cpp

Responsibilities:

  • Define the Avalanche-specific network messages (e.g., avapoll , avareply ).
  • Handle serialization and deserialization of protocol messages.
  • Process incoming messages and generate appropriate responses.
  • Integrate with the Bitcoin-ABC networking stack for message propagation.

4. Data Structures

4.1. Proof Data Structure

Represents the proof provided by a peer to participate in the Avalanche network.

Attributes:

  • ProofId: Unique identifier of the proof.
  • Stake UTXOs: List of unspent transaction outputs (UTXOs) that constitute the stake.
  • Signature: Digital signature verifying the ownership of the stake.
  • Expiration Time: Timestamp indicating when the proof expires.

4.2. Avalanche State Objects

Used to track the state of items (transactions, blocks) undergoing the Avalanche consensus process.

Attributes:

  • Confidence Level: Numerical value representing the confidence in the acceptance or rejection of the item.
  • Last Query Time: Timestamp of the last query sent regarding the item.
  • Vote History: Record of recent votes received for the item.
  • Status: Current status (e.g., Pending , Accepted , Rejected ).

5. Interaction with Bitcoin-ABC Core

The Avalanche module interacts with the core components of Bitcoin-ABC in several ways:

  • Transaction Validation: Enhances the standard validation process by providing faster confirmation through consensus.
  • Block Propagation: Assists in the rapid dissemination of new blocks by reaching consensus quickly.
  • Peer Networking: Extends the peer-to-peer networking layer to include Avalanche-specific messages and behaviors.

6. Network Protocol Messages

Key Messages:

  • avapoll : Sent to peers to request their vote on a set of items.
  • avareply : Sent in response to avapoll , containing the peer’s votes.
  • getavaaddr : Request for Avalanche peers’ addresses.
  • avaaddr : Provides a list of Avalanche peers’ addresses.

Message Flow:

  1. Initiation: A node sends an avapoll message to a set of peers, requesting their votes on certain items.
  2. Response: Peers respond with avareply messages containing their votes.
  3. Processing: The initiating node updates its vote records based on the responses.
  4. Consensus Update: Confidence levels are adjusted, and the item status may change to Accepted or Rejected .

7. Security and Validation

  • Proof-of-Stake Verification: Ensures that only nodes with valid proofs can participate in voting.
  • Sybil Resistance: Proofs prevent a single entity from masquerading as multiple peers.
  • Signature Validation: All messages and proofs are cryptographically signed and verified.
  • Expiry Handling: Proofs and votes expire after certain periods to prevent stale data.

8. Configuration Parameters

  • avalanche_proofstake_utxos : Minimum stake required for a valid proof.
  • avalanche_query_timeout : Timeout for expecting replies to queries.
  • avalanche_confidence_threshold : Confidence level required to consider an item accepted.

9. Error Handling and Logging

  • Error Reporting: Errors in processing messages or validating proofs are logged with appropriate severity levels.
  • Fallback Mechanisms: In case of failures, the module falls back to standard consensus mechanisms.
  • Logging: Detailed logs are maintained for debugging and auditing purposes.

10. Extensibility and Future Work

  • Dynamic Peer Management: Enhancements to automatically adjust the peer set based on network conditions.
  • Advanced Conflict Resolution: Implementation of more sophisticated mechanisms for handling conflicts.
  • Scalability Improvements: Optimizations for handling larger volumes of transactions and peers.

11. References

  • Avalanche Consensus Protocol Paper: Details the underlying consensus mechanism.
  • Bitcoin-ABC Documentation: Provides additional context on integration with the core system.
  • Bitcoin Improvement Proposals (BIPs): Relevant BIPs that influence the module design.

Note: This specification reflects the state of the Avalanche module in the Bitcoin-ABC repository as of October 2023. For the most current information, please refer to the official repository.

1 Like
#7

What’s the point of PoW if Avalanche determines TX ordering and PoW only needs to “abide”? Then we have Avalanche as consensus system and PoW just as coin emission distribution system. That’s not Bitcoin anymore.

2 Likes
#8

That’s not Bitcoin anymore.

Yes.

OP, can you state a clear rationale or something?

1 Like
#9

The rationale is economic security. Security is measured in the economic cost to attack, that nobody has bothered yet is not a measurement of anything.The growth of decentralized finance (DeFi) on BCH will introduce more Maximal Extractable Value (MEV) opportunities. In this evolving ecosystem, relying solely on soft security measures will be inadequate. Implementing Avalanche will safeguard the chain against potential attacks and ensure the robust security necessary for DeFi applications to thrive. But yes, I have not heard about any MEV attacks yet. Certainly just a matter of time if DeFi continues to gain traction on Bitcoin Cash.

#10

MEV doesn’t work the same on UTXO as it does on EVM.

Currently, all dapps are maker-taker where taker signs the TXs. This means that miner may nuke the chain of transactions but he CAN’T build an alternative one (by replaying the TXs in different order) because signatures are valid only for the particular order of TXs. Miner’s CAN’T reorder TXs on UTXO chains unless explicitly allowed so by contract design.

Now, you could design both maker and taker contracts to not require signature and have freedom to be rearranged, BUT, why would you do that? Whether something is MEV-able or not is at discretion of app builder.

“if it sucks for the users they’ll just switch to some non-MEVable solution”

and even if it was MEVable, the users would still have their orders filled according to the limit order, so why care if some miner extracted some spread?

#11

This is a typical “citation needed” kind of statement.

The MAIN bug in etherium (where the term originates) is that miners can reorder transactions. Which is impossible on any UTXO based chain like BitcoinCash.

The concern is good. We should not dismiss it out of hand.

Problems will certainly be seen if there is more tokens and defi happening and groth happening in the smart contracts side while the actual simple trade and transfer of bitcoin-cash-based-value would stay static.

I always picture it as a tree. The basic payments, the buying and selling of stuff. That is the stem of the tree. Adding tokens and defi and all that stuff is great, they are the leafs and the small branches that make the whole healthy and complete.

The balance is important. If the tokens and defi become the majority, the balance will be disrupted. It is like a branch becoming bigger than the trunk of a tree. This is not sustainable and the entire thing will topple.
If, on the other hand, the peer to peer payments in mbch continue to grow in number then the increases in defi and tokens are perfectly fine. A strong root can sustain them without issues.

To bring it back out of the analogy. The way to be a healthy coin is to have the most utility in peer to peer payments where people sell stuff for BCH. This brings the value of the coin up, which pays the miners and ensures the long term health of the coin.

#12

Asking AIs that are very likely to hallucinate to write a technical spec for you?

This is truly and deeply intellectually disgusting.

You see, the rule of thumb is, that if you cannot describe something yourself in your own words that are in-depth about the topic, you do not actually understand the topic.

Therefore, you are here pushing for a technology that you do not actually understand.

#13

We agree that miners can nuke the chain of transactions. Imagine a world where you have a liquidity pool between USDC and BCH on the Bitcoin Cash blockchain with 1 billion dollars of value locked up. Sometimes we have several hours between blocks, and price can move a lot in this timeframe. If it moved 10% that would be 100 million up for grabs by nuking zero-conf transaction chains. Considering it only cost $8311 dollars to attack Bitcoin Cash for an hour (https://www.crypto51.app), we will also most likely see deep reorgs to grab all this value. I know it’s a lot more to this calculation, but it’s good enough for the sake of simplicity.

#14

…which can be true, but is all irrelevant, because Proof Of Stake is not, and can never be a replacement.

It’s impossible to share profits honestly and fairly between entities that work on securing the network in PoS.

PoS does not solve Byzantine Generals problem. Therefore it cannot be used to create or maintain fair money.

All your points in this thread are thus irrelevant.

#15

I have refuted this bullshit over and over, but you continue to repeat it. So I’m going to repeat as well: you disagree with me, Wikipedia and OpenAI-o1. Most people would pause and reflect if this was the case, but you prefer to be emerged in your dogma. This forum is for science, so go elsewhere with your dogma.

#16

You cannot refute this “bullshit”, because you have no idea what you are talking about.

In fact, you do not actually understand what “Byzantine Generals” problem mean.

Otherwise you would never claim that Proof Of Stake can ever, ever, EVER solve it.

It’s just impossible.

#17

I’m sure you know better than me, Wikipedia and OpenAI-o1. /s

#18

Unsafe to use for any kind of politically charged topic.

AIs LLMs do not actually understand whatever they are talking about it. They are basically walking libraries with extra bells and whistles.

It’s intellectually insulting to me that you can even use this as an argument.

How about you try harder and explain to me how solving Byzantine Generals problem in PoW Bitcoin works.

And then you explain to me how solving the same problem can be done in PoS. In under 15 sentences, your own words.

I can spot AIs, don’t try trickery with me.

#20

Ad hominem, post reported.

#21

And this is not an ad hominem?