From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Chris Stewart <chris@suredbits•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: Wed, 12 Jul 2017 04:50:52 -0400 [thread overview]
Message-ID: <hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com> (raw)
In-Reply-To: <CAGL6+mEeuhQp3TiLFOOAWO_wcRZXsfASKNT4364SSNzER6_xgw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4091 bytes --]
>>In my scheme, if you read carefully through the pseudocode, a block list node is valid only if its block is valid.
>
>It seems this is a contradiction against the "blind" part of blind merge mining. How can a bitcoin blockchain node enforce this without tracking the sidechain?
From: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-June/014668.html
>>>>2. When a sidechain-node wants to know the consensus, it downloads mainchain-blocks and looks for OP_RETURN's.
>>>>2.1. Starting with its genesis cons-pair hash (equivalent to the empty list) as the current cons-pair, it scans each OP_RETURN transaction.
>>>>2.1.1. If an OP_RETURN is 64-byte and has the parent cons-pair equal to the current cons-pair, look for the side block indicated and confirm its correctness. If correct, update the current cons-pair for the hash of the OP_RETURN data.
>>>>2.2. When reaching the latest mainchain block, the current cons-pair is now the sidecoin/altcoin latest block.
>>>>2.3. Note that if multiple OP_RETURN in a block match the current cons-pair, the first one is considered the correct chain. This property means that the sidechain/altchain can only have a chainsplit if the mainchain has a chainsplit.
It's the sidechain node which needs to learn about the sidechain blockchain anyway. So it's the one that does the checking of this.
For that matter, a mainchain miner can be bribed to commit to a random number rather than a valid h* block, and it will still lead all the sidechain nodes on a random chase to look for the indicated block.
>I'll follow your discussion with Paul about sidechain reorgs, but I think his proposal is more desirable -- it follows what actually happens in the bitcoin mining process where we *can* have chain splits when
>miners simultaneously find a block. Other miners will pick one of the two blocks to mine on top of and eventually one chain will become longer than the other. Therefore that chain will have it's block's
>orphaned and the miners/nodes following the dead chain will reorg on top of the longest chain.
In this paper: http://diyhpl.us/~bryan/papers2/bitcoin/On%20the%20instability%20of%20Bitcoin%20without%20the%20block%20reward%20-%202016.pdf
As far as I understood that paper, it means that if the block reward no longer exists, miners can profitably attempt to undercut any full blocks.
Sidechains do not have block rewards (unless the sidechain issues its own asset type that is separate from and not convertible to mainchain bitcoins).
Thus, to protect against undercutting attacks in the sidechain, we would need to ensure that the sidechain cannot be reorged without the mainchain (which currently still has a block reward) being reorged.
At least, this is my consideration. Perhaps the paper is wrong?
---
In any case, let me propose actual improvements to the OP_BRIBEVERIFY proposal:
1. Remove the necessity of coinbase commitments. The miner commits to the sidechain_id and h* in the transaction that pays the OP_BRIBEVERIFY anyway. That way the h* commitment occurs only once in the block, in the transaction that does the OP_BRIBEVERIFY. In addition, there is no need to impose particular ordering on the coinbase outputs, which would be problematic as pointed out by others, for example if the miner is interested only in merge mining for sidechain id #35 and nobody else.
2. When verifying a block, keep a set of sidechain ID's. When processing a transaction in that block with OP_BRIBEVERIFY, check if the sidechain ID is in that set. If not in that set, add it to that set and continue script processing. If already in the set, fail the script processing. This ensures that at most one OP_BRIBEVERIFY exists for each sidechain_id in a mainchain block.
3. Don't number sidechain_id from 0, 1, 2, 3..., because people will fight over the small numbers. Instead identify sidechains by, for example, the hash of their names or the hash of their genesis block or whatever. This allows true permissionless creation of sidechains, without some authority existing that centrally allocates sidechain ID's.
Regards,
ZmnSCPxj
[-- Attachment #2: Type: text/html, Size: 5131 bytes --]
next prev parent reply other threads:[~2017-07-12 8:51 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
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 [this message]
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='hvQJ5M9JSIbEjJuabefPJi_DBqDTTXYnJ1xEg7_rBozOBrI8WDzL6zwn9Zt7au5QHc3P3DPNYDBrsQCTkSB6lOFWPJ8UuY_W4GyIzQ-Qvfs=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=chris@suredbits$(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