Won't get into the technicalities of how merged mining works (just yet); just going to look at something that I found and we can go off there when I have the time one day.
This is a coinbase reward for this transaction here: 7a14dc3f8340c4d81cb29a5c1f49f56536a45030a5bfe659e4f27bce59a2e15e
Using the 'EY Blockchain' tool, we can glean significantly more information about the transactions:
We also have the benefit of seeing the details of each input in the transactions as well (shown below):
Above are all of the details of the op_return inputs that were fed into the transaction (remember this TX is a coinbase reward, so all inputs are generated "out of thin air").
The recipient address (1KFHE7w8BhaENAswwryaoccDb6qcT6DbYY) had the following TX Script attached to it:
Understanding the Op_Return Flags Better
I'm curious about the 'op_return' flags that were added to the transaction as well.
See that below:
Transaction ID (once again if not saved above) = 7a14dc3f8340c4d81cb29a5c1f49f56536a45030a5bfe659e4f27bce59a2e15e
That means that the current documentation is (and has always been) wrong re: transactions on Bitcoin / Litecoin / other chains using op_return within a UTXO framework.
question: is the documentation on op_return actually wrong or have I simply not read it closely enough to discern the difference?
Some Links:
Generalized Bitcointalk Link: https://en.bitcoin.it/wiki/OP_RETURN (this provides a peripheral conversation re: merits of op_return) ; nothing in here explicitly suggests that op_return opcodes being added into the transaction somehow invalidate the entire transaction.
General Documentation RE: 'op_return: Encompassed within the article, 'Script', published on the Bitcoin Wiki [https://en.bitcoin.it/wiki/Script]. Turns out that a TX that contains op_return in it, no longer burns data on the protocol??.. [could've sworn it was like this just a few weeks ago].
Visiting the Bitcoin Core Reference Client Documentation
On the Bitcoin Core website there is a section dedicated to addressing some facet of 'op_return' (based on the 0.12 release, which featured more flexible options to be used in conjunction with op_return).
It states:
"Previously OP_RETURN outputs with a payload were only relayed and mined if they had a single pushdata. This restriction has been lifted to allow any combination of data pushes and numeric constant opcodes (OP_1 to OP_16) after the OP_RETURN. The limit on OP_RETURN output size is now applied to the entire serialized scriptPubKey, 83 bytes by default."
This is even more interesting when considering the fact that there has been a wealth of information to suggest that this is simply not the case though...but okay.
Hmm; in that case, this means that op_return only makes a specific transaction output unspendable (not the entire transaction, which is what we all had figured at one point in time... interesting; if there's anyone that's reading this that has anymore information on this, please reach out and provide some feedback on this).
RSK Merged Mining
What makes 'bitaps' a great tool is the fact that it provides an ASCII translation of some of the information included within the transaction.
See below if you're lost:
The only intelligible portion of the blob circled in the picture above is 'RSKBLOCK'.
Clues to Discern the Meaning of This Block
It appears that we don't need to look far since Sergio Damian Lerner and Jameson Lopp both provided their own dissection of the block (following a pretentious chastisement of the Federal Reserve for doing everything in their power to save the world from a financial apocalypse unlike any other):
https://twitter.com/lopp/status/1259929075902222345?s=20
That tweet bears no importance for us, but the following one by Sergio (longtime Bitcoin Core developer team member) does:
https://twitter.com/SDLerner/status/1259954999305613315?s=20
What is RSK and How is Merged Mining Used With it?
It seems prudent to start with their Twitter account (linked in Sergio's Twitter post), which can be found here: https://twitter.com/RSKsmart
In their bio, they claim to provide, "Smart contracts for ₿ [symbol for Bitcoin]"
One tweet that really got our attention on their page was the following one:
https://twitter.com/RSKsmart/status/1348721442339377156?s=20
More than 50% of the Bitcoin hashing power has been leveraged for merged mining with RSK? That's a considerable amount, especially considering the fact that there are few (if any) individuals that mention RSK when talking about the features / benefits of Bitcoin
What the Hell is "RSK" For Real?
To learn more, we decided to visit the homepage of RSK to see what it is about this platform that's managed to garner >50% of the network's total hash rate.
This DeFi promise is obviously recent (more than likely added in response to the recent DeFi craze in the blockchain space).
What we're looking for more information about can be found below:
For users that can't read the screenshot above (for whatever reason; contact the author if this is the case), it says:
"RSK is the most secure contract platform in the world. RSK's Contract goal is to add value and functionality to the bitcoin Contracts ecosystem by enabling smart contracts, near instant Contracts payments, and higher scalability."
It then states (at the bottom, in bold):
"RSK Blockchain is connected to Bitcoin through Merged Contractsr Mining and the two-way peg also known as the bridge."
Interesting.
Let's press that 'learn more' button to see get some details on how exactly this is supposed to work...
Clicking said button takes us to this link here: https://www.rsk.co/rsk-blockchain/
For All the Visual Learners Out There
Before we even get into an explanation of how RSK Mining works (especially in lieu of its merged mining property), below is a GIF that effectively gives the general gist for how this merged mining works:
A more verbose explanation of how it works:
Still confused? Don't worry - so are we. So let's climb a bit deeper into this rabbit hole.
How the RSK Mining Two-Way Peg Works
More information (documentation) on the ("POW"-peg as they term it), is located here: https://developers.rsk.co/rsk/architecture/powpeg/
According to the documentation:
"RSK’s 2-way peg protocol, called “the **Powpeg”, has matured from its inception in 2018 as a federation to now include many decentralized qualities. The new RSK Powpeg protects private keys stored in special purpose PowHSMs based on tamper-proof secure elements (SE). Each PowHSM runs an RSK node in SPV mode, and so signatures can only be commanded by chain cumulative proof of work. Security is established in the Powpeg through the simplicity of a layered design we refer to as defence-in-depth."
The explanation here is a bit convoluted, admittedly, and seems to be significantly inferior to a directly interopereable solution (such as what Librehash is attempting to do currently!).
General Gist of the 'Two-Way Peg' (as well as the overall protocol)
Essentially, the documentation acknowledges a supposed shortcoming of the Bitcoin protocol by noting that it is Turing "incomplete" (although, this is also what allows Bitcoin transactions and addresses to be generated in a stateless manner; so this appears to be a fair tradeoff).
RSK posits itself as an "extension" to the regular Bitcoin protocol. In order to utilize the supposed extended features that come with RSK, one must send their bitcoins to a "special address" (multi-signature as well) .
This is because, RSK was designed to, "distribute trust among parties: multi-signatures."
According to the documentation:
"With a multi-signature it is possible to give a group of notaries the task to protect locked bitcoins, tolerating a certain amount of malicious, hacked or unavailable parties."
PoW-peg
According to the documentation, this was an evolution in the federated consensus standard that RSK was using previously.
Per the documentation:
"The Powpeg is a unique 2-way peg system that secures the locked bitcoins with the same Bitcoin hashrate that establishes consensus."
[Merged mining, in essence]
The means by which this 'two-way peg' is created is a bit convoluted.
Without wasting too much time, the specification for this facet of the protocol was grabbed from the documentation for time's sake (you can read this all directly if you really want to know more about the specifics of the specification):
This setup honestly feels very convoluted, and what's still confusing here is that there does not seem to be any external / intrinsic reason why someone would want to help keep this network functioning (specifically >50% of the hashrate on Bitcoin).
The motivation that the documentation gives can be found here:
"Since there is no collateral, the RSK Powpeg members are incentivized to participate by receiving a small portion of RSK transaction fees that is automatically channeled to them. As seen in the Ethereum ecosystem, transaction fees can eventually provide a sustained income for miners and sometimes even higher than the blockchain subsidy."
Intermediate Conclusion
People will probably hate me for this conclusion at some point in the future (assuming they ever read that far into this write-up ; if you did, good on you!), but this doesn't feel like something that's worth too much more of our time.
Merged mining is not a new concept (in fact, Satoshi Nakamoto devised the concept on the fly in responise to the proposal of Namecoin as a supplementary project designed to fulfill another duty of Bitcoin that the original protocol is not designed to do)
Considering the fact that the RSK protocol requires 100 confirmations for a "peg-in" transaction to be considered valid (3/4th of a day pretty much), it is unlikely that there will ever be an influx of users looking to submit bitcoins for a 'peg in' to the RSK network (the process feels a bit convoluted as well)
The additional requirement of a PowHSM ownership for interaction with the RSK protocol places a fairly substantive burden upon any prospective end users (and even calls into question who the target audience for this tool actually is)
Top comments (0)