On 7/12/2017 4:50 AM, ZmnSCPxj wrote: > > >>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 do agree with this description. And I am not exactly comfortable with it, but theoretically the random chase would serve no direct benefit to any attacker (and thus be a ~purposeless use of attacker's money), and empirically I do not recall anyone complaining about this happening in Namecoin. And I think it is generally agreed that low-conf transactions are of categorically lower reliability -- and therefore that we are relatively less interested in taking care of users who want the blockchain to provide them with...immediate gratification (for lack of a better term). > >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 > <http://diyhpl.us/%7Ebryan/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? Yes, it is a valid concern. I'm glad you brought this up. My view is that there will be no undercutting attempts in the future, if Bitcoin is popular enough and transactions are constantly arriving. In short, the reason I feel that way is because miners will be both [1] willing and [2] able, to maximize their fee income by imposing a blocksize limit on themselves. They would do this by orphaning non-compliants -- this would be something softfork-esque, but not necessarily enforced by non-mining nodes as it is limited to miner tx-acceptance policy. Here is a link to a presentation of my thoughts on the issue: https://www.youtube.com/watch?v=YErLEuOi3xU&list=PLw8-6ARlyVciNjgS_NFhAu-qt7HPf_dtg&index=4 As I say there, I believe that miners currently have no significant reason to fee-maximize today, which is why we haven't seen this behavior. (Also, someone would need to write the fee-maximization code for this, and that not only would take time, but it would require a person with a very complex intersection of skills.) The paper you mention was written 1.5 months after my presentation was recorded. My conclusion contradicts the first sentence of the last paragraph of "3.1 Model of the system" which reads: "We also assume that miners always have space to include all available transactions." In my model miners do NOT always (or, really, ever) have space to include all available transactions. And miners are happy that they do not, because all of them make more total money as a result (both per block and overall). I think the arguments of the presentation were original, so I would be grateful to you if you offered me your thoughts on it. > 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. I don't understand the word "anyway" in the second sentence. Is that a summary of my proposal, or an assertion of yours. Because as it stands, the bribe part is quite optional -- miners could just mine both chains themselves, and then they would know which h* to include, paying themselves the sidechain's tx fees. (Of course, under what you propose here, miners could also mine it themselves, by placing it in an OP_BRIBEVERIFY). However, if it is limited to a coinbase, then there is at most only 1 hash to process every 10 minutes, which I think is desirable. I like your idea as it is simpler. But a second concern I have is that if a sidechain user wants to use SPV mode, the software will want to know exactly where to find the sidechain headers. If they are always in a known part of the coinbase, then the spv sidechain wallet knows where to look. Re: impose ordering on coinbase outputs, what do you think of a scheme which searches index 1 for an OP RETURN, and if it finds something it interprets that as the root hash of merkle tree of merged mined sidechain h*'s ? If it doesn't find a hash commitment in index 1 it just assumes that no sidechains were mined in this ~10 minute period. > 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. I am actually not in favor of permiessionless creation of sidechains, because the sidechains can interfere with each other to a degree that impacts their usefulness. We do not allow "permissionless creation of transactions", because we do not allow invalid or double-spent transactions. I feel the same logic should apply to the chains themselves. Another youtube presenation about this: https://www.youtube.com/watch?v=xGu0o8HH10U&list=PLw8-6ARlyVciMH79ZyLOpImsMug3LgNc4&index=1 (Much shorter) written post: http://www.truthcoin.info/blog/wise-contracts/ That said, I am fully in favor of forcing the sidechain's permanent deposit address to be equal to some deterministic function of the sha256 hash of its version 0.1 release. Paul _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev