From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Ruben Somsen <rsomsen@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: "christopher.gilliard@gmail•com" <christopher.gilliard@gmail•com>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Date: Mon, 03 May 2021 05:17:46 +0000 [thread overview]
Message-ID: <1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com> (raw)
In-Reply-To: <CAPv7TjaLF-LeEvyfHXs6-4E2cqwDK6qvEQHzwyRy9SUpFA5G=g@mail.gmail.com>
Good morning Ruben,
> Hi Yanmaani,
>
> >Merged mining at present only needs one hash for a merkle root, and that's stored in the coinbase.
>
> Yes, but that method is not "blind", meaning BTC miners have to validate the merged-mined chain, which is a significant downside.
>
> >It would be even simpler to add the following rules
>
> That would require a specific soft fork, whereas the method described in my post avoids doing that.
>
> >do I need to put in a transaction that burns bitcoins for the tx fee
>
> The blind merged-mined chain (which I call a "spacechain") needs its own native token in order to pay for fees. The mechanism I proposed for that is the perpetual one-way peg, which allows fair "spacecoin" creation by burning BTC, and circumvents creating bad speculative altcoin incentives. Anyone can create a spacechain block and take the fees, and then try to get BTC miners to include it by paying a higher fee than others (via RBF).
What bothers me about BMM is the B.
Mainchain miners assume that sidechain functionaries check the sidechain rules.
Their rule is that if the sidechain functionary is willing to pay an amount, then obviously the sidechain functionary must benefit by at *least* that amount (if not, the sidechain functionary is losing funds over time and will go out of business at some point).
Thus the BMM is an economic incentive for sidechain functionaries to be honest, because dishonesty means that sidechain nodes will reject their blocks and they will have earned nothing in the sidechain that is of equal or greater value than what they spend on the mainchain.
But the BMM on mainchain is done by bidding.
Suppose a sidechain functionary creates a block where it gets S fees, and it pays (times any exchange rates that arise due to differing security profiles of mainchain vs sidechain) M in fess to mainchain miners to get its commitment on the mainchain.
Then any other competing sidechain functionary can create the same block except the S fees go to itself, and paying M+1 in fees to mainchain miners to get *that* commitment mainchain.
This triggers a bidding war.
Logically, further sidechain functionaries will now bid M+2 etc. until M=S (times exchange rates) and the highest bidder earns nothing.
That means that sidechain functionaries will not earn anything once there are at least 2 functionaries, because if there are two sidechain functionaries then they will start the above bidding war and all earnings go to mainchain miners, who are not actually validating anything in the sidechain.
So they are doing all this work of validating the sidechain blocks, but gain nothing thereby, and are thus not much better than fullnodes.
Even if you argue that the sidechain functionaries might gain economic benefit from the existence of the sidechain, that economic benefit can be quantified as some economic value, that can be exchanged at some exchange rate with some number of mainchain tokens, so M just rises above S by that economic benefit and sidechain functionaries will still end up earning 0 money.
If there is only one sidechain functionary the above bidding war does not occur, but then the entire sidechain depends on this one sidechain functionary.
So it does not seem to me that blinded merge mining would work at scale.
Maybe.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2021-05-03 5:18 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-04-16 7:45 Christopher Gilliard
2021-04-16 13:56 ` Russell O'Connor
2021-04-16 15:34 ` Christopher Gilliard
2021-04-16 15:55 ` Andrew Poelstra
2021-04-16 23:52 ` ZmnSCPxj
2021-04-17 3:57 ` Christopher Gilliard
2021-04-17 15:50 ` Peter Todd
2021-04-17 16:57 ` Christopher Gilliard
2021-04-16 13:59 ` Clark Moody
2021-04-16 15:33 ` Christopher Gilliard
2021-04-16 16:32 ` Jeremy
2021-04-16 17:05 ` Christopher Gilliard
2021-04-16 18:00 ` Jeremy
2021-04-16 19:15 ` Kostas Karasavvas
2021-04-16 20:12 ` Christopher Gilliard
2021-04-17 7:41 ` Kostas Karasavvas
2021-04-16 20:30 ` Ruben Somsen
2021-04-16 21:09 ` Christopher Gilliard
2021-04-20 1:23 ` yanmaani
2021-04-20 8:45 ` Zach Greenwood
2021-04-20 17:12 ` Christopher Gilliard
2021-04-20 19:07 ` Ruben Somsen
2021-05-03 5:17 ` ZmnSCPxj [this message]
2021-05-04 12:51 ` Ruben Somsen
2021-04-20 1:22 ` yanmaani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=christopher.gilliard@gmail$(echo .)com \
--cc=rsomsen@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox