Good morning Paul, Chris, and CryptAxe,
@Paul
>> >Your way is actually very similar to mine. Mine _forces_ the bribe to be
>> >in the earliest txn (the coinbase) and to only occur once. Yours doesn"t
>> >do anything to refund the briber, if the sidechain (but not the
>> >mainchain) reorganizes (as it can easily do, if an older sidechain
>> >parent is extended while the mainchain proceeds normally). This creates
>> >additional risk.
>>
>> I don"t understand this part. In my scheme, a sidechain cannot
>> reorganize unless the mainchain reorganizes, since the consensus loop
>> only cares about matching the current block; it ignores splits and
>> does not consider them valid.
>
>If I"ve understood you correctly, you have said that each OP Return
>links the (ex)-latest block to a brand new block, and that whichever
>message of this kind comes first (in the mainchain) wins and the rest
>are discarded.
>
>So what if I had a sidechain represented by a jumble of capital letters,
>discarded entries as lowercase letters.
>
>Mainchain Block #200001: [0 --> Q], [0 -->v], [0 -->s], [0 -->b],
>Mainchain Block #200002: [Q --> H], [Q --> z],
>Mainchain Block #200003: [H --> F]
>Mainchain Block #200004: [F --> J], [F -->w]
>Mainchain Block #200005: [H --> P], [J -->x]
>Mainchain Block #200006: [P --> D]
>
>Isn"t the chain {{ Q --> H --> F --> J }} now starting to reorg, with a
>competing chain {{ Q --> H --> P --> D }} ?
No, because at block #20005, the topmost sidechain block is J, not H, and the 
H->P will not be considered as valid -- only the J->x is valid, even though 
H->P comes first.
Please see the pseudocode I sent before in detail and consider how it will work 
with your given mainchain blocks example.
>> But I suppose you are considering something like the Ethereum
>> mutability feature, which I do not think is something you would want
>> in a sidechain.
>
>What I do want to do, is retain the existing model to some extent.
>Specifically, to the degree where sidechains could salvage some bad
>situations (eg value overflow incident, or March 2013 incident).
I suppose some kinds of mutability are desirable. In my model, a sidechain 
reorg can be forced if the sidechain code is forked to specifically force some 
previously-valid block to become invalid, by developer fiat. In the example you 
gave, basically, if you want to reorg from Q->H->F->J to Q->H->P->D then you 
would fork the sidechain consensus code to declare that block F is invalid.
I am hesitant to make mutability something that is easy to force, however.
>> >I think mine is also much more space-efficient. Even if ours each had
>> >exactly one h* per sidechain per block, it seems that I only require one
>> >hash to be communicated (plus an indicator byte, and a ~2 byte counter
>> >for the ratchet), whereas you require two. Since its overhead per
>> >sidechain per block, it actually might really add up.
>>
>> Do you not provide a single sidechain"s h* twice in the block? Once
>> in the coinbase and once in the briber"s separate transaction?
>
>That is a good point. Technically, we do include it twice, but the
>second instance (briber-transaction) can be "shuffled" out if the
>counterparties are part of the same Lightning Network (which I expect to
>the be the case, in equilibrium).
Payments on LN are finalized when the payee provides a preimage for a hashlock, 
whether by chain or by LN. Although I suppose you can use a bribelocked 
timelocked contract instead of a hashlocked timelocked contract. I suppose it 
would be almost the same, except the bribelock is provided off-chain as a proof 
of existence in a mainblock coinbase.
In addition, it may be possible to create a payment channel specifically 
between a sidechain operator and a mainchain miner.
>> In my scheme at least there is no indicator byte -- the "previous
>> block" hash is the indicator of which sidechain it is extending. From
>> your other emails on this list, it seems the ratchet is for
>> withdrawals from sidechain to mainchain? If so, should it not only
>> appear in only some of the sidechains (the ones which are currently
>> doing some withdrawal?)?
>
>No, sorry. There are many tangled issues (Drivechain (total system);
>side-to-main withdrawals (OP CountACKs); individual Drivechains
>themselves; Blind Merged Mining (OP BribeVerify)). The ratchet is not
>about withdrawals, it is exclusively about Blind Merged Mining, and
>making a better OP BribeVerify that offers better guarantees to both sides.
Can you describe the ratchet better? I am sorry but when I first heard of 
"blind" merge mining, the first thing that came to mind was the use of 
OP_RETURN. This is truly blind as the mainchain miner is given what is 
effectively a blob of data, and the mainchain miner cannot expect any kind of 
format from OP_RETURN. This has the tremendous advantage of not even requiring 
a softfork.
@Chris
>What if a attacker pays a large fee to have his *invalid* block hash included 
>in the bitcoin mainchain? Would this block *have* to be included in the 
>sidechain's blockchain forever since *it was* included in bitcoin blockchain?
In my scheme, if you read carefully through the pseudocode, a block list node 
is valid only if its block is valid.
Basically, in my scheme, the OP_RETURN data *is* the sidechain block headers 
stored on the mainchain. To save space, the sidechain block headers are reduced 
to only the previous-block-header commitment and the current-block-data 
commitment. All of the other data you would want to put in the block header 
(e.g. UTXO set commitment, signalling bits, time-of-day...) would be part of 
the current-block-data instead of the block header. Thus if the 
current-block-data is invalid the sidechain block header is invalid and another 
sidechain block header based on the previous block header will be searched for.
My understanding is that your attack scenario is not helped by OP_BRIBEVERIFY 
alone, as a rich sidechain attacker can provide a bigger bribe to an invalid h* 
especially since the mainchain miner will not even check the h*, just insert it 
into the coinbase.
>Maybe I am missing something here, but why we do *explicitly* commit to the 
>previous block hash? Isn't it implicitly committed to via SHA256(SHA256())?
In order to eliminate having to specify a sidechain index, and to remove 
sidechain indexes altogether. Instead the sidechain is identified by its 
topmost block header hash.
@CryptAxe
>The ratchet system is actually what links the h* data from bribes to sidechain 
>blocks. h*'s (which are sidechain block hashes) are added to the ratchet 
>system if they move the sidechain forward or start a split like I mentioned 
>before. Then a sidechain can request of their local mainchain node to verify 
>the headers they have downloaded from sidechain peers and form the side chain.
I see. However, then, I propose that my OP_RETURN scheme is superior as the 
sidechain block headers are indeed visible directly on the mainchain, and the 
mainchain node does not even need to be "local", but can be sourced anywhere, 
without requiring a ratchet structure (whose purpose I still have not managed 
to grok).
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to