From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Paul Sztorc <truthcoin@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP: OP_BRIBVERIFY - the op code needed for Blind Merge Mined drivechains
Date: Fri, 30 Jun 2017 00:00:27 -0400 [thread overview]
Message-ID: <lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com> (raw)
In-Reply-To: <2f2e6b7c-2d47-518a-5a8f-0b5333607aac@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2335 bytes --]
Good Morning Paul,
>It seems that, in your version, the "bribers" would react to the scheme
>in inefficient ways, particularly when the mainchain"s tx-fee-rate (ie
>fee per Kb) is low.
>
>In short, there would be many bribe-attempts (each of which would take
>up space in mainchain blocks), almost all of which would be unsuccessful.
>
>In turn, miners would likely react to this, and try to improve the state
>of affairs by offering users the privilege of occupying transaction slot
>#2 (ie, the one right after the coinbase). Users would need to trust
>miners for this, which introduces a cost friction which is pure
>deadweight loss. And, it might be easier for larger/older miners to be
>trustworthy than smaller/newer ones.
I understand.
>Your way is actually very similar to mine. Mine _forces_ the bribe to be
>in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
>do anything to refund the briber, if the sidechain (but not the
>mainchain) reorganizes (as it can easily do, if an older sidechain
>parent is extended while the mainchain proceeds normally). This creates
>additional risk.
I don't understand this part. In my scheme, a sidechain cannot reorganize unless the mainchain reorganizes, since the consensus loop only cares about matching the current block; it ignores splits and does not consider them valid.
But I suppose you are considering something like the Ethereum mutability feature, which I do not think is something you would want in a sidechain.
>I think mine is also much more space-efficient. Even if ours each had
>exactly one h* per sidechain per block, it seems that I only require one
>hash to be communicated (plus an indicator byte, and a ~2 byte counter
>for the ratchet), whereas you require two. Since its overhead per
>sidechain per block, it actually might really add up.
Do you not provide a single sidechain's h* twice in the block? Once in the coinbase and once in the briber's separate transaction?
In my scheme at least there is no indicator byte -- the "previous block" hash is the indicator of which sidechain it is extending. From your other emails on this list, it seems the ratchet is for withdrawals from sidechain to mainchain? If so, should it not only appear in only some of the sidechains (the ones which are currently doing some withdrawal?)?
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 3030 bytes --]
next prev parent reply other threads:[~2017-06-30 4:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-28 0:37 Chris Stewart
2017-06-28 4:07 ` Gregory Maxwell
2017-06-28 16:35 ` Paul Sztorc
2017-06-28 5:20 ` Luke Dashjr
2017-06-28 5:28 ` Adam Back
2017-06-28 16:43 ` Paul Sztorc
2017-06-28 8:26 ` ZmnSCPxj
2017-06-28 22:20 ` Paul Sztorc
2017-06-28 22:49 ` Russell O'Connor
2017-06-28 23:47 ` Chris Stewart
2017-06-29 1:09 ` Russell O'Connor
2017-06-30 4:00 ` ZmnSCPxj [this message]
2017-06-30 14:12 ` Chris Stewart
2017-06-30 16:51 ` CryptAxe
2017-07-02 21:32 ` Paul Sztorc
2017-07-04 7:21 ` ZmnSCPxj
2017-07-04 15:06 ` Chris Stewart
2017-07-12 8:50 ` ZmnSCPxj
2017-07-12 13:39 ` Russell O'Connor
[not found] ` <CAGL6+mHErvPbvKxrQkJ=DdTuzH-4Fsxh8JnnzVY16m2x6zeJFQ@mail.gmail.com>
2017-07-12 18:02 ` Chris Stewart
2017-07-13 0:00 ` Paul Sztorc
2017-07-13 20:22 ` Chris Stewart
2017-07-13 20:45 ` Paul Sztorc
2017-07-12 23:31 ` Paul Sztorc
[not found] ` <CAF5CFkg+mJQ75ps7f3Xa=j2eBDoNwFEdL-vFrFV5y_FqF3qGRA@mail.gmail.com>
2017-07-12 23:58 ` CryptAxe
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='lYqi6yZAdUknHWs2DvSaM3h1tf3EVLngILZV9gbVBm5JVI96RvBGZaPBEFYNzt0QBkjdJ614BTsWjUkmuuqSd7RPFx-ihUL6SIXocqyW_ss=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=truthcoin@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