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_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
