public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ruben Somsen <rsomsen@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>,
	"christopher.gilliard@gmail.com" <christopher.gilliard@gmail.com>
Subject: Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF
Date: Tue, 4 May 2021 14:51:14 +0200	[thread overview]
Message-ID: <CAPv7TjYpMRRH563BmhWu64g5LuLH=Q1NXdFS-8_ivKeFwqTCuA@mail.gmail.com> (raw)
In-Reply-To: <1m_DMz6Z562s0k_NXlvCLxOeXwOUdF4-teyh_XgnEyB6jirU8wJVWkXxMWJi9GfNfc5H89X0ac0keYSzV60CETvH0UB-7YI2ZXhLLP3UOy4=@protonmail.com>

[-- Attachment #1: Type: text/plain, Size: 5274 bytes --]

Good evening ZmnSCPxj,

Thanks for thinking it through. I appreciate the time and effort.

>sidechain functionaries will not earn anything once there are at least 2
functionaries [...] they are doing all this work of validating the
sidechain blocks, but gain nothing [...] the entire sidechain depends on
this one sidechain functionary

I think your description is accurate, and while it may intuitively sound
problematic, it turns out it does not actually cause any issues.

Even in a scenario where one entity is consistently creating all the
spacechain blocks, they can only do so as long as they consistently leave 0
profit on the table for others. This is actually perfectly acceptable,
because that means this entity is not censoring anyone. As soon as they try
to abuse their position with censorship, it's trivial for anyone to step in
and outbid them.

How trivial, you may wonder? Well, there is very little difference between
being a spacechain miner and a spacechain user. Both are expected to run
full nodes, the only difference is that the miner has some BTC available
and is willing to use it to "mine" the block reward in the spacechain. This
means that the barrier for users to act as miners is low to the point where
it may happen altruistically, and, interestingly, it also doubles as an
appealing way for users to purchase spacecoins in a decentralized fashion.

Btw, I personally prefer not to call a "BMM chain" a sidechain, because in
my eyes it's not a sidechain if the chain has its own altcoin. The
spacechain design (which avoids the use of an altcoin) comes closer to
being a sidechain in that regard, but even there the use of the term
"sidechain" is debatable.

I hope this clarifies things.

Cheers,
Ruben





On Mon, May 3, 2021 at 7:17 AM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:

> 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
>

[-- Attachment #2: Type: text/html, Size: 6013 bytes --]

  reply	other threads:[~2021-05-04 12:51 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-16  7:45 [bitcoin-dev] BIP - limiting OP_RETURN / HF 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
2021-05-04 12:51           ` Ruben Somsen [this message]
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='CAPv7TjYpMRRH563BmhWu64g5LuLH=Q1NXdFS-8_ivKeFwqTCuA@mail.gmail.com' \
    --to=rsomsen@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=christopher.gilliard@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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