Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-29 Thread Rusty Russell via bitcoin-dev
Joseph Poon via bitcoin-dev  writes:
> Ideally, a 3rd-party can be handed a transaction which can encompass all
> prior states in a compact way. For currently-designed Segregated Witness
> transactions, this requires storing all previous signatures, which can
> become very costly if individuals to thousands of channel state updates
> per day.

AFAICT we need more than this.  Or are you using something other than
the deployable lightning commit tx style?

If each HTLC output is a p2sh[1], you need the timeout and rhash for
each one to build the script to redeem it.  In practice, there's not
much difference between sending a watcher a tx for every commit tx and
sending it information for every new HTLC (roughly a factor of 2).

So we also need to put more in the scriptPubKey for this to work; either
the entire redeemscript, or possibly some kind of multiple-choice P2SH
where any one of the hashes will redeem the payment.

Cheers,
Rusty.
[1] eg. from 
https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
OP_HASH160 OP_DUP # Replace top element with two copies of its hash
 OP_EQUAL # Test if they supplied the HTLC R value
OP_SWAP  OP_EQUAL OP_ADD
  # Or the commitment revocation hash
OP_IF # If any hash matched.
 # Pay to B.
OP_ELSE # Must be A, after HTLC has timed out.
 OP_CHECKLOCKTIMEVERIFY Ensure (absolute) time 
has passed.
 OP_CHECKSEQUENCEVERIFY # Delay gives B enough time to 
use revocation if it has it.
OP_2DROP # Drop the delay and htlc-timeout from the stack.
 # Pay to A.
OP_ENDIF
OP_CHECKSIG # Verify A or B's signature is correct.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-25 Thread Anthony Towns via bitcoin-dev
On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell via bitcoin-dev wrote:
> On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
>  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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-25 Thread Joseph Poon via bitcoin-dev
Hi Bryan,

On Thu, Feb 25, 2016 at 07:34:24PM -0600, Bryan Bishop wrote:
> Well if you are bothering to draft up a BIP about that SIGHASH flag,
> then perhaps also consider some other SIGHASH flag types as well while
> you are at it?

I'll take a look at those proposals when drafting the BIP. I think for
LN, there is a single clean way to achieve outsourcability, but may be
compatible with other arrangements. I'm somewhat averse to proposing too
much flexibility before there's clear use-cases, though. However, if
others do have uses/examples for other sighash flags, I'd be very
interested while drafting this BIP!

> FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
> http://gnusha.org/bitcoin-wizards/2015-04-07.log

Yeah, I think the nice thing about SegWit is that you resolve
malleability without worrying about replay attacks in the event of key
reuse. That's why I think it's only safe to do this new sighash type
inside segwit itself -- if you only wanted protection against
malleability you'd use segwit, and not touch this new sighash type
(you'd only use the new sighash flag if you actually need its features).

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-25 Thread Joseph Poon via bitcoin-dev
Hi Greg,

On Fri, Feb 26, 2016 at 01:32:34AM +, Gregory Maxwell wrote:
> I think to be successful we must be absolutely ruthless about changes
> that go in there beyond the absolute minimum needed for the safe
> deployment of segwit... so I think this should probably be constructed
> as a new segwit script type, and not a base feature.

Absolutely, I'd certainly be interested in this being the first
proof/example for the script upgrade mechanisms if it's not ideal for
this to be implemented as part of Segregated Witness itself.

> The reason for this is that if hardware wallets are forced to continue
> transferring input transactions to check fees or to use
> without-inputs, they may choose the latter and leave the users
> needlessly exposed to replay attacks.

Yes, I think it's necessary to include the fees as part of the
signature, which will also allow for wallets to not require downloading
the input transactions. However, it's necessary to not include the input
amount itself, as they may differ. SegWit itself is very nice in that it
prevents improperly designed wallets and services using the bitcoin RPC
from making mistakes, you can resolve malleability without compromises
-- I also think any proposed SIGHASH should ensure some measure of
safety from design error/shortcuts.

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

That's a good point, choosing a scary name is probably very helpful.

Thanks, I'll clarify with a specific BIP soon.

-- 
Joseph Poon
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-25 Thread Bryan Bishop via bitcoin-dev
On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote:
> This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
> does not include as part of the signature, the outpoint being spent
> (txid and index), nor the amount. It however, would include the spent
> outpoint's script as part of the signature. Note that this is just a

Well if you are bothering to draft up a BIP about that SIGHASH flag,
then perhaps also consider some other SIGHASH flag types as well while
you are at it?

Various proposed sighash types:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html

"Build your own nHashType" proposal draft:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

jl2012's reply:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010779.html

petertodd's reply about OP_CODESEPARATOR linked back to this thread
regarding "Build your own nHashType":
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007771.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007802.html
http://gnusha.org/bitcoin-wizards/2014-12-09.log

((That particular thread had other replies which can be viewed here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/thread.html
))

Also, there was a draft implementation of SIGHASH_NOINPUT:
https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4

FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
http://gnusha.org/bitcoin-wizards/2015-04-07.log

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

2016-02-25 Thread Gregory Maxwell via bitcoin-dev
On Fri, Feb 26, 2016 at 1:07 AM, Joseph Poon via bitcoin-dev
 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.

The design of segwit was carefully constructed to make it maximally
easy and safe to soft-fork in future script enhancements after its
deployment with the specific goal of avoiding indefinite delays in its
deployment from inevitable scope creep from additional things that are
"easy" to deploy as part of segwit.  I think to be successful we must
be absolutely ruthless about changes that go in there beyond the
absolute minimum needed for the safe deployment of segwit... so I
think this should probably be constructed as a new segwit script type,
and not a base feature.

The exact construction you're thinking of there isn't clear to me...
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. The reason for this is that if
hardware wallets are forced to continue transferring input
transactions to check fees or to use without-inputs, they may choose
the latter and leave the users needlessly exposed to replay attacks.

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. :)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev