ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2017-05-22 📝 Original message:Good morning, >What you ...

📅 Original date posted:2017-05-22
📝 Original message:Good morning,

>What you read is only an introduction of BMM. You may also consult the notes (at the bottom of the BMM post) or the code, although this is time consuming of course.

Looking over the code, I have a question: Is OP_BRIBE supposed to be softforked in, or hardforked? From my understanding, the code as published in your linked github cannot be softforked in, since it is not a softfork-compatible replacement for OP_NOP: it replaces the stack top value with a 0/1 value. Both CLTV and CSV do not touch the stack, only flag an error if they fail.

(What happens if the h* to be put in the coinbase, by chance - even very unlikely chance - is 0? Then <h*> OP_NOP4 is not the same as <h*> OP_BRIBE scripts in result - the former will be rejected by old nodes, the latter will be accepted by new nodes)

Does Drivechain require a hardfork? My understanding is that you want to use some kind of softforked anyone-can-spend transaction to use Drivechain. So I don't quite understand why OP_BRIBE is written the way it is.

Is OP_BRIBE the same as the OP_h_is_in_coinbase operation you described?

How is OP_BRIBE superior to just using a <h*> OP_RETURN script? Cannot a sidechain scan the block for OP_RETURN attesting that the block hash is present in the block? OP_BRIBE encodes <h*> twice (once in the transaction, once in the coinbase), OP_RETURN encodes it once (once in the transaction)

>The literal answer to your question is that mainchain Bitcoin will notice that, for the second withdrawal, the sum of the inputs is less than the sum of the outputs and they the transaction is therefore invalid.

You misunderstand. The first withdrawal was done by double-spending, and exchanging your sidechain funds for mainchain funds using some off-chain method. The second withdrawal is done on-chain.

That said, I confused OP_h_is_in_coinbase as your method of getting out of the sidechain into the mainchain. It seems, OP_h_is_in_coinbase is only for blind mining?

>I feel that my proposal is more secure, as it can operate healthily and quickly while using spv proofs which are much slower and much much easier to audit.

I don't quite understand how Drivechain handles sidechain reorgs, while keeping Bitcoin miners blinded. It seems sidechains need to be known ("seen") by the miner, so I don't see what is being blinded by blinded merge mining.

>>seems to me that your OP_is_h_in_coinbase should scan a series of sidechain block headers backed by mainchain (meaning at the minimum that sidechains should have some common header format prefix), rather than just mainchain depth as your article seems to imply.
>
>How would security be improved as a result? In either case, 51% of hashrate can cause a reorg. The sidechain software itself does scan block headers, of course.

I misunderstand the purpose of your OP_is_h_in_coinbase, sorry.

>>Blind merged mining seems strictly inferior ... a rich attacker can simply reorg the sidechain outright without playing such games.
>
>In the future, when there is no block subsidy, a rich attacker can also do that in mainchain Bitcoin.

I see. However, block subsidies will drop far in the future, do you mean to say, that sidechains will be used only in the far future?

>>How does your proposal handle multiple side block creators on the same sidechain, with the possibility that chain splits occur?
>
>The side block is only "mined" if it is committed to in a mainchain Bitcoin blog, and each mainchain block can only contain one block per sidechain. In this way, drivechain sidechains are different from classical Namecoin merged mining (where one _could_ run the entire system, mining included, without interfacing with Bitcoin at all).

I assume you mean "mainchain Bitcoin block" here.

What mechanism ensures only one mainchain block can contain only one sidechain block? It seems, this isn't implemented by OP_BRIBE yet. Can you elaborate on this mechanism?

>>Regarding your dig about people who dislike data centers, the main issue with miners blindly accepting sidechain commitments is that it violates "Don't trust, verify", not that allows datacenters to be slightly smaller by not including side:nodes.
>
>As I explain early on, in earlier rounds of peer review, the focus was on harms the sidechain technology might do to mainchain Bitcoin, and the "datacenter point" was specifically the chief objection raised. So I am afraid you are entirely incorrect.

I see. It seems, the main problem, is that sidechains can be used to sneak in block size increases. Of course, the advantage of sidechains, is that when it increases block size irresponsibly, only those who participated in the sidechain will suffer.

>In point of fact, the transactions *are* validated...by sidechain full nodes, same as Bitcoin proper.

But from blind merge mining by itself, how would the blinded merge miner know that there exists an actual sidechain full node that actually did validation?

It seems, that the "blinding" in merge mining does not seem to be at all useful without the miner actually seeing the sidechain. If you want miners to upgrade to side:fullnode as well, what would then be the point of blinding? Why not just ordinary merge mining?

Perhaps the datacenter point is simply that your proposal suggests to reduce the size of the datacenter by removing surge suppressors and UPS's, to avoid some definition of "datacenter is a room with >$XXX of equipment".

Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170522/55bb9433/attachment.html>;