Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-03-18 📝 Original message: On Thu, Mar 14, 2019 at ...
📅 Original date posted:2019-03-18
📝 Original message:
On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> > so if you used a tagged output, you could do everything normal taproot
> > address could, but also do noinput sigs for them.
> > So you might have:
> > funding tx -> cooperative claim
> > funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
> > funding tx -> update 3 [TAGGED] ->
> > update 4 [TAGGED,NOINPUT] ->
> > settlement 4 [TAGGED,NOINPUT] ->
> > claim [NOINPUT]
> > In the cooperative case, no output tagging needed.
> I might be missing something here, but how do you bind update 3 to the
> funding tx output, when that output is not tagged? Do we keep each
> update in multiple separate states, one bound to the funding tx output
> and another signed with noinput?
I don't know that "separate states" is a great description -- until it
hits the blockchain "update N" is a template that can be filled out in a
variety of ways -- in the above the ways are:
- with a NOINPUT sig and a previous "update" tx as its input
- or with a SINGLE|ANYONECANPAY sig and the funding tx as input
The important thing is that approach means two sigs for each update tx.
The above also has two sigs for each settlement tx (and likewise two sigs
for each HTLC claim if using scriptless scripts) -- one using NOINPUT
in case multiple update tx's make it to the blockchain, and one assuming
everything works as expected that can just use direct key path spending.
I think you can do SINGLE,ANYCANPAY and combine multiple channel closures
if you're directly spending the funding tx, but can't do that if you're
using a NOINPUT sig, because the NOINPUT sig would commit to the tx's
locktime and different channel's states will generally have different
locktimes. You still probably want SINGLE,ANYCANPAY in that case so you
can bump fees though.
> If that's the case we just doubled our
> storage and communication requirements for very little gain.
There's three potential gains:
* it lets us make a safer version of NOINPUT
* it makes the common paths give fewer hints that you're using eltoo
* it puts less data/computation load on the blockchain
With tagged outputs your update tx already indicates you're maybe going
to use NOINPUT, so that probably already gives away that you're using
eltoo, so, at least with output tagging, the second benefit probably
doesn't exist. Using a key path spend (without a script) is probably
going to be cheaper on the blockchain though.
But while I think output tagging is probably better than nothing,
requiring a non-NOINPUT signature seems a better approach to me. With
that one, having a dedicated sig for the normal "publish the latest
state spending the funding tx" case, reduces a unilateral close to only
being special due to the settlement tx having a relative timelock, and
the various tx's using SINGLE|ANYCANPAY, which seems like a win. In that
scenario, just using a single sig is much cheaper than revealing a taproot
point, a pubkey or two, and using two sigs and a CLTV check of course.
It does goes from 1+n signatures per update today to 4+n signatures,
if you're using scriptless scripts. If you don't mind revealing the
HTLCs are HTLCs, and could do them with actual scripts, that reduces to
4 signatures. You could reduce it to 2 signatures by also always posting
"funding tx -> update 0 -> update N -> settlement N", or you could reduce
it to 2+2/k signatures by only doing the non-NOINPUT sigs for every k'th
state (or no more often than every t seconds or similar).
> An
> alternative is to add a trigger transaction that needs to be published
> in a unilateral case, but that'd increase our on-chain footprint.
(The above essentially uses update tx's as optional trigger tx's)
Also, I'd expect the extra latency introduced by the interactive signing
protocol for muSig would be more of a hit (share the nonce hash, share
the nonce, calculate the sig). Particularly if you're doing multiparty
channels with many participants, rather than just two.
Cheers,
aj
📝 Original message:
On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote:
> Anthony Towns <aj at erisian.com.au> writes:
> > I'm thinking of tagged outputs as "taproot plus" (ie, plus noinput),
> > so if you used a tagged output, you could do everything normal taproot
> > address could, but also do noinput sigs for them.
> > So you might have:
> > funding tx -> cooperative claim
> > funding tx -> update 3 [TAGGED] -> settlement 3 -> claim
> > funding tx -> update 3 [TAGGED] ->
> > update 4 [TAGGED,NOINPUT] ->
> > settlement 4 [TAGGED,NOINPUT] ->
> > claim [NOINPUT]
> > In the cooperative case, no output tagging needed.
> I might be missing something here, but how do you bind update 3 to the
> funding tx output, when that output is not tagged? Do we keep each
> update in multiple separate states, one bound to the funding tx output
> and another signed with noinput?
I don't know that "separate states" is a great description -- until it
hits the blockchain "update N" is a template that can be filled out in a
variety of ways -- in the above the ways are:
- with a NOINPUT sig and a previous "update" tx as its input
- or with a SINGLE|ANYONECANPAY sig and the funding tx as input
The important thing is that approach means two sigs for each update tx.
The above also has two sigs for each settlement tx (and likewise two sigs
for each HTLC claim if using scriptless scripts) -- one using NOINPUT
in case multiple update tx's make it to the blockchain, and one assuming
everything works as expected that can just use direct key path spending.
I think you can do SINGLE,ANYCANPAY and combine multiple channel closures
if you're directly spending the funding tx, but can't do that if you're
using a NOINPUT sig, because the NOINPUT sig would commit to the tx's
locktime and different channel's states will generally have different
locktimes. You still probably want SINGLE,ANYCANPAY in that case so you
can bump fees though.
> If that's the case we just doubled our
> storage and communication requirements for very little gain.
There's three potential gains:
* it lets us make a safer version of NOINPUT
* it makes the common paths give fewer hints that you're using eltoo
* it puts less data/computation load on the blockchain
With tagged outputs your update tx already indicates you're maybe going
to use NOINPUT, so that probably already gives away that you're using
eltoo, so, at least with output tagging, the second benefit probably
doesn't exist. Using a key path spend (without a script) is probably
going to be cheaper on the blockchain though.
But while I think output tagging is probably better than nothing,
requiring a non-NOINPUT signature seems a better approach to me. With
that one, having a dedicated sig for the normal "publish the latest
state spending the funding tx" case, reduces a unilateral close to only
being special due to the settlement tx having a relative timelock, and
the various tx's using SINGLE|ANYCANPAY, which seems like a win. In that
scenario, just using a single sig is much cheaper than revealing a taproot
point, a pubkey or two, and using two sigs and a CLTV check of course.
It does goes from 1+n signatures per update today to 4+n signatures,
if you're using scriptless scripts. If you don't mind revealing the
HTLCs are HTLCs, and could do them with actual scripts, that reduces to
4 signatures. You could reduce it to 2 signatures by also always posting
"funding tx -> update 0 -> update N -> settlement N", or you could reduce
it to 2+2/k signatures by only doing the non-NOINPUT sigs for every k'th
state (or no more often than every t seconds or similar).
> An
> alternative is to add a trigger transaction that needs to be published
> in a unilateral case, but that'd increase our on-chain footprint.
(The above essentially uses update tx's as optional trigger tx's)
Also, I'd expect the extra latency introduced by the interactive signing
protocol for muSig would be more of a hit (share the nonce hash, share
the nonce, calculate the sig). Particularly if you're doing multiparty
channels with many participants, rather than just two.
Cheers,
aj