kallewoof
commented
4 years ago Only been reading description so far, but
The merge mining commitment in the parent chain is placed in the last 33 bytes of the last output of the last transaction.
Why use this, when there's an extendable witness commitment structure in place already? (Esp. if you incorporate the signet witness commitment extension system I've already written..)
You literally only have to come up with a new 4 byte header that differs from segwit and signet and use it as is..
Note: since Bitcoin does not have consensus-enforced block-final transactions, and since every Bitcoin transaction requires an input, to merge-mine Tradecraft blocks a miner must have at least one input they control.
This would not be an isssue if you used the existing witness commitment, as it is in the coinbase, which all miners have..
I guess it's an issue because you'd have to support two separate segwits in your code?
a miner which submits a share cannot predict whether it will be a valid block or not, and therefore cannot grief a pool through block withholding
...wow? That's a great idea! Is that used elsewhere or is this something you just whipped up? I haven't heard about that before.
Speaking of namecoin btw, is it possible to merge mine both freicoin and namecoin simultaneously?
The right structure for this is probably a prefix-tree, with the genesis block hash as the chain identifier.
This sounds like you can just grind prefixes, but I may be misunderstanding something (alsdo depends on length of prefixes ofc)
maaku
This pull request implements so-called auxiliary proof-of-work (AKA "merge-mining") using SHA256d in a bitcoin-compatible construction, as a soft-fork. Once activated, it allows miners to simultaneously work on both Bitcoin and Freicoin/Tradecraft blocks at the same time, finding proof-of-work solutions that satisfy one or the other, or both chains.
The only previously described soft-fork proof-of-work change is the Forward Blocks proposal. This is a simplification of the ideas presented therein, which achieves the soft-fork proof-of-work change in a way that can be deployed more quickly, but is still compatible with future deployment of Forward Blocks.
The basic idea is that we require each new block to satisfy two proof of work challenges in series: first the auxiliary proof-of-work (merge-mining) challenge, which can be shared across multiple chains including Bitcoin, then the existing (native) header challenge which specific to our chain.
There will be a transition period during which the difficulty of the native header adjusts down and the auxiliary difficulty adjusts up. During this period the overall proof-of-work function will not be progress-free, but the transition period will be short (a few months) and the benefits that come with merged mining well worth it. At the end, the native/compatibility headers will be at or near difficulty 1, which is effectively progress-free, or practically no limit at all once the protocol-cleanup fork activates.
The parent chain contains a commitment to the Tradecraft block at a fixed location. The native chain likewise commits to the auxiliary proof-of-work in a fixed location as well. The block header structure is modified to contain the information needed to validate these commitments.
The merge mining commitment in the parent chain is placed in the last 36 bytes of the last output of the last transaction. This helps to minimize the size of the auxiliary header's Merkle proof. The commitment format is a 32-byte commitment hash, a 4-byte commitment identifier, and the transaction's
nLockTimefield. Note that nolock_heightfield is present, so Bitcoin can act as the parent chain, but the commitment identifier is chosen so that Tradecraft cannot. This allows merge mining with Bitcoin and prevents Tradecraft blocks from containing such a commitment.Note: since Bitcoin does not have consensus-enforced block-final transactions, and since every Bitcoin transaction requires an input, to merge-mine Tradecraft blocks a miner must have at least one input they control.
The commitment structure includes a hash of a pool-selected secret value, which is used for block-withholding protection. The pool can allow auxiliary difficulty to be split across two challenges, one which is calculated in the usual way that is compatible with Bitcoin, and the other using the block-withholding secret. This serves two purposes: (1) a miner which submits a share cannot predict whether it will be a valid block or not, and therefore cannot grief a pool through block withholding, and (2) it decouples the finding of Tradecraft blocks from Bitcoin blocks, since a share that meets the necessary work threshold for both chains isn't necessarily accepted by both.
Once merged mining is activated, every block has two proof-of-work targets: the native difficulty and the auxiliary (merge mined) difficulty. And unlike namecoin, every block MUST have an auxiliary header: merge mining is not optional on a block-by-block basis.
Both the native and auxiliary difficulty adjustment algorithms separately track observed hash rate according to the block timestamps and their expected block arrival predictors, except that the auxiliary difficulty adjustment algorithm targets a longer inter-block interval: 15 minutes / 900 seconds, which results in 4 blocks per hour, or 96 blocks per day.
Once the auxiliary proof is satisfied, a proof then needs to be found for the native header. The miner who finds this proof is allowed to change the coinbase's scriptSig or nSequence field, and/or the header's nNonce and nVersion fields. Note that the native header's nTime field MUST be the same as the auxiliary header's, so nTime-rolling isn't permitted with the native header.
This proposal is now ready for merging.
[x] Switch to Merkle trie structure for commitment. Right now only a commitment to the Tradecraft main net block is allowed. Instead the commitment hash value should be a Merkle tree allowing for the commitment to an arbitrary number of chains or other values. The position within the tree for a given chain would have to be fixed, however, to prevent commitments to multiple competing block templates. The right structure for this is probably a prefix-tree, with the genesis block hash as the chain identifier.
[x] Upgrade difficulty adjustment algorithm. Since the auxiliary proof-of-work has its own difficulty adjustment parameters, this would be a perfect opportunity to replace the difficulty adjustment algorithm with something that serves our needs better. See #3, in which a few candidate adjustment algorithms have been identified.
[x] Add markdown file
auxpow.mdto the documentation directory, explaining the changes.