From: Anthony Towns <aj@erisian•com.au>
To: bitcoin-dev@lists•linuxfoundation.org,
lightning-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness
Date: Fri, 26 Feb 2016 13:20:56 +1000 [thread overview]
Message-ID: <20160226032056.GA10450@sapphire.erisian.com.au> (raw)
In-Reply-To: <CAAS2fgTphe5T8EBtz0xKRpRuLaO0P=3WeW2d1WD6b4Ark79rMQ@mail.gmail.com>
On Fri, Feb 26, 2016 at 01:32:34AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > I'm interested in input and in the level of receptiveness to this. If
> > there is interest, I'll write up a draft BIP in the next couple days.
> .. I think this should probably be constructed as a new segwit script type,
> and not a base feature.
+1 to both
> The exact construction you're thinking of there isn't clear to me...
I think the idea is that you have three transactions:
anchor:
input: whatever
output:
- single output, spendable by 2-of-2 multisig
- [possibly others as well, whatever]
commitment:
input: anchor
outputs:
1. payment to A
2. payment to B
3. HTLC to A on R1, timeout T1
4. HTLC to A on R2, timeout T2
5. HTLC to B on R3, timeout T3
...
penalty:
inputs:
all the outputs from the commitment tx
outputs:
1. 99% as payment to me
2. 1% as outsourcing fee
As long as the key I use for spending each of commitment transactions
outputs is "single use" -- ie, I don't use it for other channels or
anywhere else on the blockchain, then as long as the signature commits
to the outputs it's safe afaics.
(You still have to send a lot of data to the place you're outsourcing
chain-monitoring to; all the R1,R2,R3 and T1,T2,T3 values are needed in
order to reconstruct the redeem scripts)
> one thing that comes to mind is that I think it is imperative that we
> do not deploy a without-inputs SIGHASH flag without also deploying at
> least a fee-committing sighash-all.
If the fee for commitment transactions changes regularly (eg, a new
commitment transaction is generated every few seconds/minutes, and the fee
is chosen based on whatever estimatefee returns), I think this would cause
problems -- you couldn't use a single signature to cover every revoked
commitment, you'd need one for each different fee level that you'd used
for the lifetime of the channel. Actually, the size of the commitment
transaction will differ anyway depending on how many HTLCs are open,
so even if estimatefee didn't change, the fee would still differ. So I
think commiting to a fee isn't workable for the lightning use case...
> When you do write a BIP for this its imperative that the vulnerability
> to replay is called out in bold blinking flaming text, along with the
> necessary description of how to use it safely. The fact that without
> input commitments transactions are replayable is highly surprising to
> many developers... Personally, I'd even go so far as to name the flag
> SIGHASH_REPLAY_VULNERABLE. :)
+1, though I'm not sure it's so much "vulnerable" to replay as it is
"explicitly designed" to be replayable...
Cheers,
aj
next prev parent reply other threads:[~2016-02-26 3:21 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 1:07 Joseph Poon
2016-02-26 1:32 ` Gregory Maxwell
2016-02-26 1:48 ` Joseph Poon
2016-02-26 3:20 ` Anthony Towns [this message]
2016-02-26 1:34 ` Bryan Bishop
2016-02-26 2:02 ` Joseph Poon
2016-02-26 2:35 ` Luke Dashjr
2016-02-29 0:25 ` Rusty Russell
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=20160226032056.GA10450@sapphire.erisian.com.au \
--to=aj@erisian$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=lightning-dev@lists$(echo .)linuxfoundation.org \
/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