[bitcoin-dev] Timelocks and Lightning on MimbleWimble

[bitcoin-dev] Timelocks and Lightning on MimbleWimble

[ZmnSCPxj]

Good morning list,

I was reading transcript of recent talk: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/

And in section "Taproot: main idea":

> Q: Can you do timelocks iwth adaptor signatures?
>
> ...
>
> A: This is one way it's being proposed by mimblewimble; but this requires the ability to aggregate signatures across transactions.
>
> Q: No, there's two transactions already existing. Before locktime, you can spend wit hthe adaptor signature one like atomic swaps. After locktime, the other one becomes valid and you can spend with that. They just double spend each other.
>
> A: You'd have to diagram that out for me. There's a few ways to do this, some that I know, but yours isn't one of them.

I believe what is being referred to here is to simply have an `nLockTime` transaction that is signed by all participants first, and serves as the "timelock" path.
Then, another transaction is created, for which adaptor signatures are given, before completing the ritual to create a "hashlock" path.

I find it surprising that this is not well-known.
I describe it here tangentially, for instance: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016888.html
The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction" and "pre-swap backout transaction", which are `nLockTime`d transactions.
Later transactions then use a Scriptless Script-like construction to transfer information about a secret scalar x.

My understanding of MimbleWimble is that:

* There must exist a proof-of-knowledge of the sum of blinding factors used.
  This can be trivially had by using a signature of this sum, signing an empty message or "kernel".
* I believe I have seen at least one proposal (I cannot find it again now) where the "kernel" is replaced with an `nLockTime`-equivalent.
  Basically, the `nLockTime` would have to be explicitly published, and it would be rejected for a block if the `nLockTime` was less than the block height.
  * There may or may not exist some kind of proof where the message being signed is an integer that is known to be no greater than a particular value, and multiple signatures that signed a lower value can somehow be aggregated to a higher value, which serves this purpose as well, but is compressible.

My understanding is thus that the above `nLockTime` technique is what is indeed intended for MimbleWimble cross-system atomic swaps.

--------

However, I believe that Lightning and similar offchain protocols are **not possible** on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.

All practical channel constructions with indefinite lifetime require the use of *relative* locktime.
Of note is that `nLockTime` represents an *absolute* lifetime.

The only practical channel constructions I know of that do not require *relative* locktime (mostly various variants of Spilman channels) have a fixed lifetime, i.e. the channel will have to be closed before the lifetime arrives.
This is impractical for a scaling network.

It seems to me that some kind of "timeout" is always necessary, similar to the timeout used in SPV-proof sidechains, in order to allow an existing claimed-latest-state to be proven as not-actually-latest.

* In Poon-Dryja, knowledge of the revocation key by the other side proves the published claimed-latest-state is not-actually-latest and awards the entire amount to the other party.
  * This key can only be presented during the timeout, a security parameter.
* In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff starts this timeout, and only the smallest-timeout state gets onchain, due to it having a time advantage over all other versions.
* In indefinite-lifetime Spilman channels (also described in the Decker-Wattenhofer paper), the absolute-timelock initial backoff transaction is replaced with a kickoff + relative-locktime transaction.
* In Decker-Russell-Osuntokun, each update transaction has an imposed `nSequence` that forces a state transaction to be delayed compared to the update transaction it is paired with.

It seems that all practical offchain updateable cryptocurrency systems, some kind of "timeout" is needed during which participants have an opportunity to claim an alternative version of some previous claim of correct state.

This timeout could be implemented as either relative or absolute lock time, but obviously an absolute locktime would create a limit on the lifetime of the channel.
Thus, if we were to target an indefinite-lifetime channel, we must use relative lock times, with the timeout starting only when the unilateral close is initiated by one participant.

Now, let us turn back to the MimbleWimble.
As it happens, we do *not* actually need SCRIPT to implement these offchain updateable cryptocurrency systems.
2-of-2 is often enough (and with Schnorr and other homomorphic signatures, this is possible without explicit script, only pubkeys and signatures, which MimbleWimble supports).

* Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed this was the original formulation).
  * Since we have shown that, by use of two transaction alternatives, one timelocked and the other hashlocked, we can implement an HTLC-like construct on MimbleWimble, that is enough.
* Relative locktimes in Decker-Wattenhofer are imposed by simple `nSequence`, not by `OP_CSV`.
  HTLCs hosted inside such constructions can again use the two-transactions construct in MimbleWimble.
* Ditto with indefinite-lifetime Spilman.
* Ditto with Decker-Russell-Osuntokun.
  * The paper shows the use of `OP_CSV`, but aj notes it is redundant, and I agree: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html

Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from being deployed on MimbleWimble.

Instead, it is the "nonexistence of **relative** locktime" that prevents Lightning over MimbleWimble.

Why would **relative** locktimes not possibly exist?
In order to **validate** a relative locktime, we need to know the blockheight that the output we are spending was confirmed in.

But the entire point of the "magical shrinking blockchain" is that already-spent outputs can be removed completely and all that needs to be validated by a new node is:

* The coin-creation events.
* The current UTXO set (plus attached rangeproofs).
* The blinding keys.
* Signatures of the blinding keys, and the kernels they sign (if we use the "kernels encode `nLockTime`" technique in some way, they should not exceed the current supposed blockheight).

The problem is that an output that exists in the UTXO set might be invalid, if it appears "too near" to an `nSequence` minimum spend of a previous output that was spent in its creation.
That is, the above does not allow validation of **relative** locktimes, only **absolute locktimes**.
(At least as far as I understand: there may be special cryptographic constructs that allow signatures to reliably commit to some relative locktime).

This means that relative locktimes need to be implemented by showing the transactions that spend previous UTXOS and create the current UTXOs, and so no backwards to coin-creation events.
This forces us back to the old "validate all transactions" model of starting a new node (and seriously damaging the entire point of using MimbleWimble anyway).

I do not believe it is the lack of SCRIPT that prevents Lightning-over-MimbleWimble, but rather the lack of relative locktime, which seems difficult to validate without knowing the individual transactions and when they were confirmed.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[Martin Schwarz]

[-- Attachment #1: Type: text/plain, Size: 8438 bytes --]

Isn't there some way to "rebase" a relative lock-time to some anchor even
further in the past while cancelling out the intermediate transactions?

best regards,
Martin

On Thu, Sep 19, 2019 at 9:52 AM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> I was reading transcript of recent talk:
> https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
>
> And in section "Taproot: main idea":
>
> > Q: Can you do timelocks iwth adaptor signatures?
> >
> > ...
> >
> > A: This is one way it's being proposed by mimblewimble; but this
> requires the ability to aggregate signatures across transactions.
> >
> > Q: No, there's two transactions already existing. Before locktime, you
> can spend wit hthe adaptor signature one like atomic swaps. After locktime,
> the other one becomes valid and you can spend with that. They just double
> spend each other.
> >
> > A: You'd have to diagram that out for me. There's a few ways to do this,
> some that I know, but yours isn't one of them.
>
> I believe what is being referred to here is to simply have an `nLockTime`
> transaction that is signed by all participants first, and serves as the
> "timelock" path.
> Then, another transaction is created, for which adaptor signatures are
> given, before completing the ritual to create a "hashlock" path.
>
> I find it surprising that this is not well-known.
> I describe it here tangentially, for instance:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016888.html
> The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction"
> and "pre-swap backout transaction", which are `nLockTime`d transactions.
> Later transactions then use a Scriptless Script-like construction to
> transfer information about a secret scalar x.
>
> My understanding of MimbleWimble is that:
>
> * There must exist a proof-of-knowledge of the sum of blinding factors
> used.
>   This can be trivially had by using a signature of this sum, signing an
> empty message or "kernel".
> * I believe I have seen at least one proposal (I cannot find it again now)
> where the "kernel" is replaced with an `nLockTime`-equivalent.
>   Basically, the `nLockTime` would have to be explicitly published, and it
> would be rejected for a block if the `nLockTime` was less than the block
> height.
>   * There may or may not exist some kind of proof where the message being
> signed is an integer that is known to be no greater than a particular
> value, and multiple signatures that signed a lower value can somehow be
> aggregated to a higher value, which serves this purpose as well, but is
> compressible.
>
> My understanding is thus that the above `nLockTime` technique is what is
> indeed intended for MimbleWimble cross-system atomic swaps.
>
> --------
>
> However, I believe that Lightning and similar offchain protocols are **not
> possible** on MimbleWimble, at least if we want to retain its "magical
> shrinking blockchain" property.
>
> All practical channel constructions with indefinite lifetime require the
> use of *relative* locktime.
> Of note is that `nLockTime` represents an *absolute* lifetime.
>
> The only practical channel constructions I know of that do not require
> *relative* locktime (mostly various variants of Spilman channels) have a
> fixed lifetime, i.e. the channel will have to be closed before the lifetime
> arrives.
> This is impractical for a scaling network.
>
> It seems to me that some kind of "timeout" is always necessary, similar to
> the timeout used in SPV-proof sidechains, in order to allow an existing
> claimed-latest-state to be proven as not-actually-latest.
>
> * In Poon-Dryja, knowledge of the revocation key by the other side proves
> the published claimed-latest-state is not-actually-latest and awards the
> entire amount to the other party.
>   * This key can only be presented during the timeout, a security
> parameter.
> * In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff
> starts this timeout, and only the smallest-timeout state gets onchain, due
> to it having a time advantage over all other versions.
> * In indefinite-lifetime Spilman channels (also described in the
> Decker-Wattenhofer paper), the absolute-timelock initial backoff
> transaction is replaced with a kickoff + relative-locktime transaction.
> * In Decker-Russell-Osuntokun, each update transaction has an imposed
> `nSequence` that forces a state transaction to be delayed compared to the
> update transaction it is paired with.
>
> It seems that all practical offchain updateable cryptocurrency systems,
> some kind of "timeout" is needed during which participants have an
> opportunity to claim an alternative version of some previous claim of
> correct state.
>
> This timeout could be implemented as either relative or absolute lock
> time, but obviously an absolute locktime would create a limit on the
> lifetime of the channel.
> Thus, if we were to target an indefinite-lifetime channel, we must use
> relative lock times, with the timeout starting only when the unilateral
> close is initiated by one participant.
>
> Now, let us turn back to the MimbleWimble.
> As it happens, we do *not* actually need SCRIPT to implement these
> offchain updateable cryptocurrency systems.
> 2-of-2 is often enough (and with Schnorr and other homomorphic signatures,
> this is possible without explicit script, only pubkeys and signatures,
> which MimbleWimble supports).
>
> * Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed
> this was the original formulation).
>   * Since we have shown that, by use of two transaction alternatives, one
> timelocked and the other hashlocked, we can implement an HTLC-like
> construct on MimbleWimble, that is enough.
> * Relative locktimes in Decker-Wattenhofer are imposed by simple
> `nSequence`, not by `OP_CSV`.
>   HTLCs hosted inside such constructions can again use the
> two-transactions construct in MimbleWimble.
> * Ditto with indefinite-lifetime Spilman.
> * Ditto with Decker-Russell-Osuntokun.
>   * The paper shows the use of `OP_CSV`, but aj notes it is redundant, and
> I agree:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html
>
> Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from
> being deployed on MimbleWimble.
>
> Instead, it is the "nonexistence of **relative** locktime" that prevents
> Lightning over MimbleWimble.
>
> Why would **relative** locktimes not possibly exist?
> In order to **validate** a relative locktime, we need to know the
> blockheight that the output we are spending was confirmed in.
>
> But the entire point of the "magical shrinking blockchain" is that
> already-spent outputs can be removed completely and all that needs to be
> validated by a new node is:
>
> * The coin-creation events.
> * The current UTXO set (plus attached rangeproofs).
> * The blinding keys.
> * Signatures of the blinding keys, and the kernels they sign (if we use
> the "kernels encode `nLockTime`" technique in some way, they should not
> exceed the current supposed blockheight).
>
> The problem is that an output that exists in the UTXO set might be
> invalid, if it appears "too near" to an `nSequence` minimum spend of a
> previous output that was spent in its creation.
> That is, the above does not allow validation of **relative** locktimes,
> only **absolute locktimes**.
> (At least as far as I understand: there may be special cryptographic
> constructs that allow signatures to reliably commit to some relative
> locktime).
>
> This means that relative locktimes need to be implemented by showing the
> transactions that spend previous UTXOS and create the current UTXOs, and so
> no backwards to coin-creation events.
> This forces us back to the old "validate all transactions" model of
> starting a new node (and seriously damaging the entire point of using
> MimbleWimble anyway).
>
> I do not believe it is the lack of SCRIPT that prevents
> Lightning-over-MimbleWimble, but rather the lack of relative locktime,
> which seems difficult to validate without knowing the individual
> transactions and when they were confirmed.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 9773 bytes --]

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[Lloyd Fournier]

[-- Attachment #1: Type: text/plain, Size: 9460 bytes --]

Hi ZmnSCPxj,

I can give some context on the exchange during the talk. I was the "Q" and
Andrew Polestra was the "A".

I followed up with Andrew after and he indeed knew about the pre-signed
nlocktime transaction double spend technique (actually, I thought he was
the one who originally came up with that idea for scriptless atomic swaps).
He clarified saying that you can do that with locktime (absolute time
locks) but not with sequence numbers (relative time locks). i.e. to enforce
sequence numbers you need to use OP_CHECKSEQUENCEVERIFY. He said that it
would make sense to change that so it's enforced regardless of script.

However, I talked to Antoine Riard later who was adamant that sequence
numbers already worked as expected. He pointed to the fact that BIP68
already describes it as an independent constraint [1]

So if things do work as described in BIP68 then we should be able to do
lightning on Bitcoin without any script once we have Schnorr. I'm keen to
actually figure out all the details of how to do this. It works in my head
but I think I should write it down somewhere to make sure it works.

 [1] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

LL


On Thu, Sep 19, 2019 at 5:52 PM ZmnSCPxj via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Good morning list,
>
> I was reading transcript of recent talk:
> https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
>
> And in section "Taproot: main idea":
>
> > Q: Can you do timelocks iwth adaptor signatures?
> >
> > ...
> >
> > A: This is one way it's being proposed by mimblewimble; but this
> requires the ability to aggregate signatures across transactions.
> >
> > Q: No, there's two transactions already existing. Before locktime, you
> can spend wit hthe adaptor signature one like atomic swaps. After locktime,
> the other one becomes valid and you can spend with that. They just double
> spend each other.
> >
> > A: You'd have to diagram that out for me. There's a few ways to do this,
> some that I know, but yours isn't one of them.
>
> I believe what is being referred to here is to simply have an `nLockTime`
> transaction that is signed by all participants first, and serves as the
> "timelock" path.
> Then, another transaction is created, for which adaptor signatures are
> given, before completing the ritual to create a "hashlock" path.
>
> I find it surprising that this is not well-known.
> I describe it here tangentially, for instance:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-April/016888.html
> The section "Payjoin2swap Swap Protocol" refers to "pre-swap transaction"
> and "pre-swap backout transaction", which are `nLockTime`d transactions.
> Later transactions then use a Scriptless Script-like construction to
> transfer information about a secret scalar x.
>
> My understanding of MimbleWimble is that:
>
> * There must exist a proof-of-knowledge of the sum of blinding factors
> used.
>   This can be trivially had by using a signature of this sum, signing an
> empty message or "kernel".
> * I believe I have seen at least one proposal (I cannot find it again now)
> where the "kernel" is replaced with an `nLockTime`-equivalent.
>   Basically, the `nLockTime` would have to be explicitly published, and it
> would be rejected for a block if the `nLockTime` was less than the block
> height.
>   * There may or may not exist some kind of proof where the message being
> signed is an integer that is known to be no greater than a particular
> value, and multiple signatures that signed a lower value can somehow be
> aggregated to a higher value, which serves this purpose as well, but is
> compressible.
>
> My understanding is thus that the above `nLockTime` technique is what is
> indeed intended for MimbleWimble cross-system atomic swaps.
>
> --------
>
> However, I believe that Lightning and similar offchain protocols are **not
> possible** on MimbleWimble, at least if we want to retain its "magical
> shrinking blockchain" property.
>
> All practical channel constructions with indefinite lifetime require the
> use of *relative* locktime.
> Of note is that `nLockTime` represents an *absolute* lifetime.
>
> The only practical channel constructions I know of that do not require
> *relative* locktime (mostly various variants of Spilman channels) have a
> fixed lifetime, i.e. the channel will have to be closed before the lifetime
> arrives.
> This is impractical for a scaling network.
>
> It seems to me that some kind of "timeout" is always necessary, similar to
> the timeout used in SPV-proof sidechains, in order to allow an existing
> claimed-latest-state to be proven as not-actually-latest.
>
> * In Poon-Dryja, knowledge of the revocation key by the other side proves
> the published claimed-latest-state is not-actually-latest and awards the
> entire amount to the other party.
>   * This key can only be presented during the timeout, a security
> parameter.
> * In Decker-Wattenhofer decrementing-`nSequence` channels, a kickoff
> starts this timeout, and only the smallest-timeout state gets onchain, due
> to it having a time advantage over all other versions.
> * In indefinite-lifetime Spilman channels (also described in the
> Decker-Wattenhofer paper), the absolute-timelock initial backoff
> transaction is replaced with a kickoff + relative-locktime transaction.
> * In Decker-Russell-Osuntokun, each update transaction has an imposed
> `nSequence` that forces a state transaction to be delayed compared to the
> update transaction it is paired with.
>
> It seems that all practical offchain updateable cryptocurrency systems,
> some kind of "timeout" is needed during which participants have an
> opportunity to claim an alternative version of some previous claim of
> correct state.
>
> This timeout could be implemented as either relative or absolute lock
> time, but obviously an absolute locktime would create a limit on the
> lifetime of the channel.
> Thus, if we were to target an indefinite-lifetime channel, we must use
> relative lock times, with the timeout starting only when the unilateral
> close is initiated by one participant.
>
> Now, let us turn back to the MimbleWimble.
> As it happens, we do *not* actually need SCRIPT to implement these
> offchain updateable cryptocurrency systems.
> 2-of-2 is often enough (and with Schnorr and other homomorphic signatures,
> this is possible without explicit script, only pubkeys and signatures,
> which MimbleWimble supports).
>
> * Poon-Dryja revocation can be rewritten as an HTLC-like construct (indeed
> this was the original formulation).
>   * Since we have shown that, by use of two transaction alternatives, one
> timelocked and the other hashlocked, we can implement an HTLC-like
> construct on MimbleWimble, that is enough.
> * Relative locktimes in Decker-Wattenhofer are imposed by simple
> `nSequence`, not by `OP_CSV`.
>   HTLCs hosted inside such constructions can again use the
> two-transactions construct in MimbleWimble.
> * Ditto with indefinite-lifetime Spilman.
> * Ditto with Decker-Russell-Osuntokun.
>   * The paper shows the use of `OP_CSV`, but aj notes it is redundant, and
> I agree:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-March/001933.html
>
> Thus, it is not the "nonexistence of SCRIPT" that prevents Lightning from
> being deployed on MimbleWimble.
>
> Instead, it is the "nonexistence of **relative** locktime" that prevents
> Lightning over MimbleWimble.
>
> Why would **relative** locktimes not possibly exist?
> In order to **validate** a relative locktime, we need to know the
> blockheight that the output we are spending was confirmed in.
>
> But the entire point of the "magical shrinking blockchain" is that
> already-spent outputs can be removed completely and all that needs to be
> validated by a new node is:
>
> * The coin-creation events.
> * The current UTXO set (plus attached rangeproofs).
> * The blinding keys.
> * Signatures of the blinding keys, and the kernels they sign (if we use
> the "kernels encode `nLockTime`" technique in some way, they should not
> exceed the current supposed blockheight).
>
> The problem is that an output that exists in the UTXO set might be
> invalid, if it appears "too near" to an `nSequence` minimum spend of a
> previous output that was spent in its creation.
> That is, the above does not allow validation of **relative** locktimes,
> only **absolute locktimes**.
> (At least as far as I understand: there may be special cryptographic
> constructs that allow signatures to reliably commit to some relative
> locktime).
>
> This means that relative locktimes need to be implemented by showing the
> transactions that spend previous UTXOS and create the current UTXOs, and so
> no backwards to coin-creation events.
> This forces us back to the old "validate all transactions" model of
> starting a new node (and seriously damaging the entire point of using
> MimbleWimble anyway).
>
> I do not believe it is the lack of SCRIPT that prevents
> Lightning-over-MimbleWimble, but rather the lack of relative locktime,
> which seems difficult to validate without knowing the individual
> transactions and when they were confirmed.
>
> Regards,
> ZmnSCPxj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 11016 bytes --]

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[Andrew Poelstra]

[-- Attachment #1: Type: text/plain, Size: 2386 bytes --]

On Fri, Sep 20, 2019 at 04:54:34AM +1000, Lloyd Fournier via bitcoin-dev wrote:
> Hi ZmnSCPxj,
> 
> I can give some context on the exchange during the talk. I was the "Q" and
> Andrew Polestra was the "A".
> 
> I followed up with Andrew after and he indeed knew about the pre-signed
> nlocktime transaction double spend technique (actually, I thought he was
> the one who originally came up with that idea for scriptless atomic swaps).
> He clarified saying that you can do that with locktime (absolute time
> locks) but not with sequence numbers (relative time locks). i.e. to enforce
> sequence numbers you need to use OP_CHECKSEQUENCEVERIFY. He said that it
> would make sense to change that so it's enforced regardless of script.
> 
> However, I talked to Antoine Riard later who was adamant that sequence
> numbers already worked as expected. He pointed to the fact that BIP68
> already describes it as an independent constraint [1]
> 
> So if things do work as described in BIP68 then we should be able to do
> lightning on Bitcoin without any script once we have Schnorr. I'm keen to
> actually figure out all the details of how to do this. It works in my head
> but I think I should write it down somewhere to make sure it works.
> 
>  [1] https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
> 
> LL
>

Yep, during the recorded exchange I was confused about the content of
the BIP. Later I described the exchange to Dan Robinson, who showed me
the actual text :).

Sorry for the confusion - Lloyd was totally right and you can do
relative locktimes this way in Taproot without needing to expose a
script.


Having said this, there is the important caveat that your "emergency
backout" keys are online to produce a pre-signed transaction, and
that a suitable destination is known beforehand. This makes sense for
Lightning or most atomic swap protocols where the money simply returns
to the original owner, but not e.g. for Liquid, where the emergency
keys have never been brought online (and anyway the contents of any
transaction they might sign depends on facts and circumstances that
aren't known ahead of time).


-- 
Andrew Poelstra
Director of Research, Blockstream
Email: apoelstra at wpsoftware.net
Web:   https://www.wpsoftware.net/andrew

The sun is always shining in space
    -Justin Lewis-Webster


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[John Tromp]

> However, I believe that Lightning and similar offchain protocols are **not possible** on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.

MimbleWimble can easily incorporate relative lock heights, in addition
to absolute lock heights. Grin and Beam have included the latter since
launch.

Grin's proposal for relative lock heights is at [1] with discussion at [2].
Based on these, Grin also has a rough design for payment channels at [3].

Beam included relative lock heights in its recent HardFork [4] and has
a payment channel design at [5].

regards,
-John

[1] https://github.com/antiochp/grin-rfcs/blob/relative_lock_heights/text/0000-relative-kernels.md
[2] https://github.com/mimblewimble/grin-rfcs/pull/19
[3] https://gist.github.com/antiochp/e54fece52dc408d738bf434a14680988
[4] https://github.com/BeamMW/beam/releases/tag/beam-3.0.5654
[5] https://docs.beam.mw/laser_beam.pdf

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[ZmnSCPxj]

Good morning John,


> > However, I believe that Lightning and similar offchain protocols are not possible on MimbleWimble, at least if we want to retain its "magical shrinking blockchain" property.
>
> MimbleWimble can easily incorporate relative lock heights, in addition
> to absolute lock heights. Grin and Beam have included the latter since
> launch.
>
> Grin's proposal for relative lock heights is at [1] with discussion at [2].
> Based on these, Grin also has a rough design for payment channels at [3].
>
> Beam included relative lock heights in its recent HardFork [4] and has
> a payment channel design at [5].
>

Thank you for this information.
I am aware that absolute locktimes were possible in MimbleWimble.

However, it does seem to imply that kernels are not compressible (unlike the original MimbleWimble where the kernel is just an empty string and thus never stored).
So at least for kernels of relative locktimes, are not pruneable and will contribute to blockchain size.
(I believe I saw some proposal for absolute locktimes that allow some amount of aggregation/pruning of absolute-locktime kernels from the mimblewimble.pdf by andytoshi.)

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).
It is not a *total* loss of the "magic shrinking blockchain", I see now, however.

Still, it does see worth the cost of accepting having to store kernels forever in exchange for being able to layer on top of a MimbleWimble blockchain.

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.


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.


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.

Regards,
ZmnSCPxj

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[John Tromp]

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

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

[ZmnSCPxj]

Good morning John,

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

However, my understanding is that, at least with the original mimblewimble.txt from Jedusor, the signatures and the Pedersen-commitment-to-0 could all be aggregated into a single signature and Pedersen-commitment-to-0, if we were to use Schnorr-like signatures.
(it is possible I misunderstand this; I am not in fact a cryptographer.
Indeed, the original mimblewimble.txt mentions having to store every `k*G` and every signature attesting to it, although does not mention Schnorr and might not have considered the possibility of signature aggregation when using Schnorr-like signatures.
There could be security issues I am unaware of, for example.)

In addition, the mimblewimble.pdf from andytoshi includes a "Sinking Signatures" section, which to my understanding, combines absolute-locktime kernels with partial O(log n) aggregation of the signatures that attest it.
Again, it is possible I misunderstand this.

It seems to me that neither technique is possible with relative locktime kernels.
Again, this may be merely my ignorance of such.

In any case, this is mostly moot and I ask only out of curiosity in order to know more about kernels in non-relative-locktime MimbleWimble chains.


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

This seems interesting.
I shall look into this further.

Regards,
ZmnSCPxj