Good morning aj,
I understand.
Looks like that makes sense.
It seems possible to use this, then, together with watchtowers.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐ Original Message ‐‐‐
On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote:
> On Fri, Mar 22, 2019 at
On Fri, Mar 22, 2019 at 01:59:14AM +, ZmnSCPxj wrote:
> > If codeseparator is too scary, you could probably also just always
> > require the locktime (ie for settlmenet txs as well as update txs), ie:
> > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > OP_CHECKDLSVERIFY OP_CHECKDLS
> > and have update txs
Good morning aj,
>
> If you are committing to the script code, though, then each settlement
> sig is already only usable with the corresponding update tx, so you
> don't need to roll the keys. But you do need to make it so that the
> update sig requires the CLTV; one way to do that is using codesep
On Thu, Mar 21, 2019 at 10:05:09AM +, ZmnSCPxj wrote:
> > IF OP_CODESEPARATOR OP_CHECKLOCKTIMEVERIFY OP_DROP ENDIF
> > OP_CHECKDLSVERIFY OP_CHECKDLS
> > Signing with NOINPUT,NOSCRIPT and codeseparatorpos=1 enforces CLTV
> > and allows binding to any prior update tx -- so works for an update
Good morning aj,
> > Then each update transaction pays out to:
> > OP_IF
> > OP_CSV OP_DROP
> > OP_CHECKSIGVERIFY OP_CHECKSIG
> > OP_ELSE
> > OP_CHECKLOCKTIMEVERIFY OP_DROP
> > OP_CHECKSIGVERIFY OP_CHECKSIG
> > OP_ENDIF
>
> Yeah.
>
> I think we could potentially make that shorter still:
>
>
On Wed, Mar 20, 2019 at 08:07:00AM +, ZmnSCPxj via Lightning-dev wrote:
> Re-reading again, I think perhaps I was massively confused by this:
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > CHECKSIGVERIFY CHECKSIG
> > or CHECKSIGVERIFY CHEC
Hi aj,
Re-reading again, I think perhaps I was massively confused by this:
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
> CHECKSIGVERIFY CHECKSIG
> or CHECKSIGVERIFY CHEC
Hi all,
> Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse
> scenario (as well as the second), I'd be content with that proposal.
How would this work with watchtowers?
As I understand it, the current plan for eltoo watchtowers would be to store
both `SIGHASH_NOINPUT` signa
Sorry AJ, my prior email was not constructive :(
I consider the "my software reused my keys" the most reasonable attack
scenario, though still small compared to other lightning attack surfaces.
But I understand the general wariness of third-parties reusing
SIGHASH_NOINPUT signatures.
Since "must
Anthony Towns writes:
> If you publish to the blockchain:
...
> 4 can be dropped, state 5 and finish can be altered). Since the CSV delay
> is chosen by the participants, the above is still a possible scenario
> in eltoo, though, and it means there's some risk for someone accepting
> bitcoins that
On Thu, Mar 14, 2019 at 01:00:56PM +0100, Christian Decker wrote:
> Anthony Towns 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
Anthony Towns 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
Good morning aj,
>
> Trying to maximise privacy there has the disadvantage that you have to
> do a new signature for every in-flight HTLC every time you update the
> state, which could be a lot of signatures for very active channels.
If I remember accurately this is already true for current Poon-
On Thu, Mar 14, 2019 at 05:22:59AM +, ZmnSCPxj via Lightning-dev wrote:
> When reading through your original post I saw you mentioned something about
> output tagging somehow conflicting with Taproot, so I assumed Taproot is not
> useable in this case.
I'm thinking of tagged outputs as "tapr
Good morning aj,
When reading through your original post I saw you mentioned something about
output tagging somehow conflicting with Taproot, so I assumed Taproot is not
useable in this case.
However, it is probably more likely that I simply misunderstood what you said,
so if you can definitive
On Wed, Mar 13, 2019 at 06:41:47AM +, ZmnSCPxj via Lightning-dev wrote:
> > - alternatively, we could require every script to have a valid signature
> > that commits to the input. In that case, you could do eltoo with a
> > script like either:
> > CHECKSIGVERIFY CHECKSIG
> >
Good morning aj,
First off, I have little to no idea of the issues at the lower-level Bitcoin.
In any case ---
> - alternatively, we could require every script to have a valid signature
> that commits to the input. In that case, you could do eltoo with a
> script like either:
>
>
Hi all,
The following has some more thoughts on trying to make a NOINPUT
implementation as safe as possible for the Bitcoin ecosystem.
One interesting property of NOINPUT usage like in eltoo is that it
actually reintroduces the possibility of third-party malleability to
transactions -- ie, you pu
18 matches
Mail list logo
