Good morning Paul,
Thank you for your consideration.
>> 1. Unifies merge mining (h* commitment) and WT^ validity voting.
>> Merge-mined headers increase the vote on a WT^, by increasing the depth
>> of the WT^.
>
>1. I think it is a mistake for SHOM ("Sidechain Headers on Mainchain")
>to "unify merged-mining and the WT^ validity voting". This causes the
>SHOM to regress to mere extension blocks, and they therefore take on
>many of the negative properties of extension blocks.
>
>See: http://www.drivechain.info/faq/index.html#usefulness
I don't see how this regress occurs. Perhaps I need more information on
extension blocks.
>> 2. Through OP_BRIBEVERIFY, the power to decide the validity of a
>> sidechain lies in the economic majority rather than in the miners.
>
>I don"t think that this is true. 51% miner-group can pay bribes to
>themselves, and orphan any block or txn that disagrees with them.
Any miner that rejects a bribe from outside the miner-group in order to put
their desired hash on the sidechain, values their desired hash more than the
bribe to put a different hash. This rejection is a loss of potential proift,
and other miners who accept the bribe gain the profit from it.
>I also don"t think that there is any meaningful difference between "what
>the economic majority wants" and "what the miners do". To me it is a
>blindingly obvious fact: miners are paid more, only if they increase the
>value of { exchange_rate * ([x>=0] + txn_fees) }. This only increases if
>Bitcoin is expected to be more objectively useful, and if its users
>treasure its use sufficiently to warrant the payment of high tx fees.
>
>When miners disagree with, for example, the bitcoin-dev mailing list,
>this is because miners are attempting to guess what the economic
>majority wants, and, in making this earnest attempt, miners believe that
>the bitcoin-dev interest is different from the economic majority interest.
>
>Obviously, I don"t expect to change any minds on this list. After all,
>(since no one dares oppose the economic majority), it is a smart
>strategy to pretend that the economic majority always agrees with you.
>And it is extra smart to avoid examining that belief too carefully.
Your last paragraph does not make sense to me. I suspect I have hit upon a
nerve and will make no further comment on this sub-topic.
>>2.2.1. This seems to imply that sidechains where unified merge-mining
>> and WT^ voting are paid for by economic majority, effectively work as
>> proof-of-stake. The difference here is that the proof does not have to
>> cover itself (i.e. the stake being used to prove is outside the system
>> which the proof is proving) and it is really more of a
>> proof-of-sacrifice-of-stake, since the economic majority needs to pay
>> (and thus lose) the stake for continued operation of the sidechain. One
>> can argue that proof-of-work is just an instance of
>> proof-of-sacrifice-of-stake anyway.
>
>I agree with most of this, but I think in proof of work and proof of
>stake the security guarantee is more reasonable.. In SHOM, there is no
>reason to believe that the the quantity "total amount of money available
>for withdrawal in a given time" will always be smaller than "sum of 288
>bribes".
This is indeed the problem. SHOM, as it unifies merge mining and WT^ voting,
also allows theft attempts, and once the money available for withdrawal exceeds
the sum of 288 bribes, we enter a dollar auction game between the thief and the
sidechain users: https://en.wikipedia.org/wiki/Dollar_auction
As thieves are expected to follow the simple greedy algorithm, sidechain death
can be triggered by a single theft attempt.
Assuming potential thieves understand the dollar-auction irrationality, they
may be disincentivized, as presumably there are more sidechain protectors than
thieves, and the sidechain protectors can (we hope) all outbid the thief. But
the problem is that this require rational behavior from thieves. Mere greedy
algorithm, or disruption for the sake of disruption, would still collapse SHOM
sidechains.
But given the many parallels between SHOM and drivechains: what happens if 26%
of miners disrupt all sidechains by always downvoting WT^? In that case,
sidechains still collapse as a whole, with practically the same effect as the
SHOM thief.
We could limit the money available for withdrawal, but that weakens the
side-to-main peg, reducing the value of the sidecoin relative to the maincoin.
The problem, to my mind, is that blind merge mining is pointless if it does not
also allow voting on WT^. In the end, no matter how novel a sidechain may be,
what is valued is the maincoin backing the sidecoin; that is the whole point of
the two-way peg. A sidechain user may OP_BRIBEVERIFY valid sideblocks onto the
mainchain, but if that user cannot vote on WT^ anyway, no matter how valid
sideblocks committed on the mainchain, it would be pointless if the sidechain
is attacked by mainchain miners. You may as well remove blind merge mining, as
miners who must vote on WT^ will need to understand the sidechain validity
rules anyway.
>> 2.2.2. Miner behavior on Bcash and Bitcoin suggests to me that a good
>> portion of the miners are interested more in short-term profits than
>> long-term.
>
>As long as some critical mass of investors exist, there is no difference
>between short and long term profits. It is impossible for an investor to
>act in a way that affects the long term, but does not immediately also
>affect the short term.
I do not quite follow. Can you expand more on this?
>> I have not seen a good explanation of how drivechain WT^ validity voting
>> works in detail; my understanding is that a WT^ is presented on the
>> mainchain, then a voting period is established during which miners
>> somehow vote for whether the WT^ is valid or not, then the voting ends
>> and a UTXO is somehow created. If it is in some Sztorc video, I
>> apologize, I am unable to usefully view them.
>Some documentation is here:
>https://github.com/drivechain-project/docs/blob/master/bip1-hashrate-escrow.md
Thank you.
>> I think lockboxes should have fixed value. The value should be big
>> enough that the cost of OP_WITHDRAWPROOFVERIFY is low. Particularly for
>> privacy-oriented sidechains, all lockboxes having the same value will
>> help tremendously in continuing obscurity after side-to-main transfers.
>> However, I am uncertain whether sidechain or mainchain should enforce
>> this fixed value. This parameter is something to be endlessly debated.
>> Perhaps it should be sidechain that enforces this, but then mistakes
>> could occur on the mainchain where some lockbox on the mainchain is
>> deemed invalid on the sidechain, and cannot be unlocked validly except
>> by destroying the sidechain.
>I don"t think this makes any sense, because it implies that the value of
>288 block"s worth of mainchain BTC transaction fees should always be
>worth more than the entire market capitalization of Bitcoin.
>
>Specifically, in this case, the error it introduces is that someone
>could get around the fixed value by just using multiple sidechains. Then
>the miners would just attack all the sidechains simultaneously. (And
>these smaller sidechains would themselves have much smaller fees.)
In order to attack multiple sidechains, bribing thieves must pay bribes for
each sidechain being attacked. Even if a miner attacks, bribes for valid
sidechains must be rejected by the miner, effectively reducing the miner's
profits, and the bribes to be rejected must be for all the sidechains to be
attacked.
If withdrawals have a fixed or maximum value, then the bribe a thief must be
prepared to pay (or turn down, in the case of thieving miners) must be no more
than the maximum value / 288.
Unfortunately, capping withdrawals weakens the side-to-main peg, which weakens
the reason for even using SHOM. This is the true weakness of SHOM: it provides
only a very weak side-to-main peg.
>>
>> Sidechains may first be deployed as federated peg, then at some
>> sidechain height the federation may announce a move to
>> drivechain/sidechain-headers-on-mainchain. The move from federated to
>> economic-majority-controlled would involve the federation moving its
>> controlled lockboxes to OP_WITHDRAWPROOFVERIFY lockboxes.
>Sergio likes this idea, but I think that this attitude represents a lack
>of faith in the design. Either the design works or it does not. Either
>the federation works or it does not.
I agree.
>>
>> Sidechain hardforks would be very contentious, with only one clear
>> winner that can unlock lockboxes. I think, part of sidechain design
>> must be the understanding that sidechains must never be hardforked, and
>> only softforked. Indeed, I am very much convinced that it is impossible
>> to safely hardfork mainchain at all, and any block size increase must by
>> necessity be softforked in.
>This is already the case in what we have done...the only way to
>guarantee that all clients report the same WT^ is if they are all
>running softforks of the first version.
Yes.
>> The mechanism that supports sidechains supports any financial system,
>> including centralized, non blockchain ones. The h* commitments can be
>> made into commitments to the financial system"s state. Basically, it is
>> an implementation of CoinWitness, without using zk-SNARKs and instead
>> using some mainchain-voted proof, where validity is judged by how much
>> maincoin was sacrified to advance that proof. The supported financial
>> system might even allow arbitrary execution of Turing-complete code for
>> more vulnerabilities.
>This is why I do not want ultra-easy, completely-permissionless creation
>of sidechains. Miners (and therefore, users) may NOT desire the EXPECTED
>behavior of the sidechain.
I am fine with some economic bond or proof-of-burn to start a sidechain. But I
am opposed to any permissioned method of starting sidechains. To my mind,
asking miners to install your software is already permissioned.
>> Is there some spec for WT^ layout?
>Yes, see above.
Thank you.
Regards,
ZmnSCPxj_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
