John Tromp [ARCHIVE] on Nostr: 📅 Original date posted:2019-09-19 📝 Original message:dear ZmnSCPxj, > Which I ...
📅 Original date posted:2019-09-19
📝 Original message:dear ZmnSCPxj,
> Which I suppose is my point: you lose some of the "magic shrinking blockchain" property in implementing relative locktimes, as you now increase the data you have to store forever (i.e. the kernels).
The "magic shrinking" of MW never applied to kernels. To validate the
current UTXO set, you need to validate *all* the kernels, each of
which is a Pedersen commitment to zero together with a Schnorr
signature using said commitment as public key. Then you need to check
that the sum of UTXO commitments (outputs) minus the summed block
rewards times G (inputs) equals the sum of kernel commitments.
Basically, the same check that is applied to individual transactions.
> It seems to me that Poon-Dryja and Decker-Wattenhofer can be "directly" ported over to any MimbleWimble blockchain with relative locktimes.
> Reference [5] seems to be Poon-Dryja ported over to using relative locktimes for MimbleWimble.
Yes, Beam's design is a straightforward port of Poon-Dryja.
> Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPUT` requirement.
> I have tried to derive an equivalent to this `SIGHASH_NOINPUT` somehow by considering that the "reference to previous kernel" as being akin to the Bitcoin transaction input referring to a previous output, however it seems to be not easy to create a retargatable "reference to previous kernel" in this way.
The Grin "Elder channel" design of [3] is similar in spirit to eltoo
though, as the revocation transaction can be combined with the final
close transaction to counter any closing attempt to an obsolete state.
The design also offers some bandwidth savings compared to the
Poon-Dryja design.
> In any case, it seems to me that the loss of SCRIPT does not prevent a MimbleWimble blockchain from using an offchain updateable cryptocurrency system.
Correct; lack of scripts is not as much of a handicap for MW as it
appears. Multi-sig, atomic swaps, and payment channels are all
possible.
regards,
-John
📝 Original message:dear ZmnSCPxj,
> Which I suppose is my point: you lose some of the "magic shrinking blockchain" property in implementing relative locktimes, as you now increase the data you have to store forever (i.e. the kernels).
The "magic shrinking" of MW never applied to kernels. To validate the
current UTXO set, you need to validate *all* the kernels, each of
which is a Pedersen commitment to zero together with a Schnorr
signature using said commitment as public key. Then you need to check
that the sum of UTXO commitments (outputs) minus the summed block
rewards times G (inputs) equals the sum of kernel commitments.
Basically, the same check that is applied to individual transactions.
> It seems to me that Poon-Dryja and Decker-Wattenhofer can be "directly" ported over to any MimbleWimble blockchain with relative locktimes.
> Reference [5] seems to be Poon-Dryja ported over to using relative locktimes for MimbleWimble.
Yes, Beam's design is a straightforward port of Poon-Dryja.
> Decker-Russell-Osuntokun ("eltoo") is harder due to the `SIGHASH_NOINPUT` requirement.
> I have tried to derive an equivalent to this `SIGHASH_NOINPUT` somehow by considering that the "reference to previous kernel" as being akin to the Bitcoin transaction input referring to a previous output, however it seems to be not easy to create a retargatable "reference to previous kernel" in this way.
The Grin "Elder channel" design of [3] is similar in spirit to eltoo
though, as the revocation transaction can be combined with the final
close transaction to counter any closing attempt to an obsolete state.
The design also offers some bandwidth savings compared to the
Poon-Dryja design.
> In any case, it seems to me that the loss of SCRIPT does not prevent a MimbleWimble blockchain from using an offchain updateable cryptocurrency system.
Correct; lack of scripts is not as much of a handicap for MW as it
appears. Multi-sig, atomic swaps, and payment channels are all
possible.
regards,
-John