Bitcoin Forum
June 16, 2024, 02:55:23 AM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Bitcoin / Bitcoin Discussion / Re: POW Rune Protocol on: May 09, 2024, 12:53:12 PM
I was about to suggest you post this elsewhere, but it seems you already do that[1]. Anyway, i skimmed your idea and i have 2 thoughts.
1. How do you handle someone who intend to rent tons of GPU/ASIC at once to instantly mine all token?
2. Limiting to few hash type is probably better for maintainability sake. IMO 2 hash type, where the former can be mined with ASIC and the latter only can be mined with CPU/GPU should be good enough as starter.

[1] https://github.com/ordinals/ord/issues/3739

My idea is that each type of Rune can define a serial list of Hash functions. For example, I can define a PoW Rune , whose HashSequence consists of three different hash algorithms: SHA256, ETHASH, and SCRYPT. The calculation process during Minting would be as follows:
Code:
hash1 := Sha256(blockHash + Nonce)
hash2 := Ethash(hash1)
hash3 := Scrypt(hash2)
Hash3 is the final PoW hash result used to calculate the Mint Amount.
You also can etch a new Rune that includes 10 different HashTypes in it.
Introducing multiple different Hash algorithms can effectively prevent GPU/ASIC.
2  Bitcoin / Bitcoin Discussion / POW Rune Protocol on: May 09, 2024, 04:13:57 AM
Rune protocol is a popular Bitcoin ecological token protocol recently, but Rune's Mint adopts a first-come-first-served method, which cannot reflect fairness. Here I propose a POW-based rune improvement protocol. In this protocol, mint must be based on pow proof, and the number of mint is determined by the hash value of the pow result, so that everyone can mint tokens more fairly.
The changes to the pow rune are as follows:
1. Modification of etching definition
1.1 Remove premine, everyone mints fairly.
1.2 HashSequence
The etching definition contains the hash type, which can be concatenated in multiple ways. The enumeration of hash types is as follows:
Code:
type HashType int

const (
    SHA256 HashType = iota + 1
    SHA3_256
    RIPEMD160
    KECCAK256
    BLAKE2B
    BLAKE2S
    SCRYPT
    ETHASH
    X11
    NEOSCRYPT
    EQUIHASH
    LBRY
    PENTABLAKE
    QUARK
    SKEIN
    WHIRLPOOL
    YESCRYPT
    ZR5
    //......
)
1.3 CommitWindow
CommitWindow defines the height range of submission. For example, if the CommitWindow of a Rune is 100, when performing POW calculation and minting rune, based on the hash of the 1000th block, this mint transaction must be submitted and packaged before the height of 1000+100=1100. Mint beyond the CommitWindow will be considered invalid.
1.4 BaseZero
Defines BaseZero, which requires at least how many zeros to be considered successful
Code:
type Etching struct {
    Divisibility *uint8
    //Premine      *uint128.Uint128 //remove
    Rune         *Rune
    Spacers      *uint32
    Symbol       *rune
    Terms        *Terms
    Turbo        bool

    // new fileds for pow
    HashSequence []HashType
    CommitWindow uint32
    BaseZero uint8
}
2. Submit when minting:
runeId, blockHeight, nonce
How to calculate how many runes are minted?
Code:
hashSequence:=getHashSequence(runeId) //Query the Etching definition of runeid and obtain its hashSequence
blockHash:=getBlockHash(blockHeight) //Get the block hash based on the block height
hash:=CalcHash(hashSequence,blockHash,nonce) //Concatenate blockHash and nonce, and use the hash algorithm corresponding to hashSequence to calculate the final POW hash value.
Count how many zeros are in front of the hash, subtract baseZero, there are n left, then the number is 2^n, the code is as follows:
Code:
func CalcMintAmount(hash []byte, baseZero uint8) uint64 {
    // Calculate how many zeros are at the beginning of the hash in binary
    zeroCount := uint8(0)
    for _, b := range hash {
        if b == 0 {
            zeroCount += 8
        } else {
            for i := 7; i >= 0; i-- {
                if (b>>i)&1 == 0 {
                    zeroCount++
                } else {
                    break
                }
            }
            break
        }
    }
    if zeroCount < baseZero {
        return 0
    }
    // Calculate the final amount
    amount := uint64(1) << (zeroCount - baseZero)
    return amount
}
Other logics such as Transfer and Cenotaph remain unchanged.
In order to distinguish between the existing rune protocol and the pow rune protocol, we can adjust the magic number of the pow rune, such as changing OP_13 to OP_14, so as to achieve mutual non-interference with the existing rune protocol.
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!