From: Andrew Poelstra <apoelstra@wpsoftware•net>
To: Lloyd Fournier <lloyd.fourn@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble
Date: Fri, 20 Sep 2019 12:22:20 +0000 [thread overview]
Message-ID: <20190920122220.GR13224@boulet> (raw)
In-Reply-To: <CAH5Bsr1G6r-g_so96ALo0gpboWDduRaZzFT7Z1rDBFdzDHsXTA@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2019-09-20 12:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 7:52 ZmnSCPxj
2019-09-19 8:39 ` Martin Schwarz
2019-09-19 18:54 ` Lloyd Fournier
2019-09-20 12:22 ` Andrew Poelstra [this message]
[not found] <mailman.1791.1568888841.8631.bitcoin-dev@lists.linuxfoundation.org>
2019-09-19 11:16 ` John Tromp
2019-09-19 15:15 ` ZmnSCPxj
2019-09-19 15:47 ` John Tromp
2019-09-20 5:14 ` ZmnSCPxj
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190920122220.GR13224@boulet \
--to=apoelstra@wpsoftware$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lloyd.fourn@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox