Paul Sztorc [ARCHIVE] on Nostr: 📅 Original date posted:2017-07-02 📝 Original message:Hi, Sorry for the delay, I ...

📅 Original date posted:2017-07-02
📝 Original message:Hi,

Sorry for the delay, I overlooked this email until now. I see that Chris
and CryptAxe both answered but I will also answer, because the message
was addressed to me.

On 6/30/2017 12:00 AM, ZmnSCPxj wrote:
> >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 }} ?

> 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 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).

>
> 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.

Paul