rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.aeđź“… Original date posted:2019-12-18
đź“ť Original message:
Hi Bastien,
The use case you're describing strikes me as similar to a slashing protocol
for a LN node and a watchtower, i.e punishing
a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
unlock some funds for B".
Here a rough slashing protocol I've sketched out to someone else off-list,
it may work for you use case if you replace the penalty tx
by the funding transaction as a way for the trusted channel funder to clear
his liability. Though you will need onchain interactivity
before the fact but you may be able to reuse slashing outpoint for multiple
channel funding.
Slashing Protocol
----------------------
Alice and Bob lock fund in channel outpoint X. They issue commitment tx N.
Will the accountable watchtower locks fund
in a 2-of-2 slashing outpoint Y with Bob the client.
When Alice and Bob update channels to N', Bob and Will use some output from
commitment N (like upcoming anchor output)
to create an accountable tx M. M is paying to Bob after timelock+Bob sig or
is paying to transaction success_penalty P
with Will sig + Bob sig. Success_penalty P will have 2 inputs, one from M
and from J the justice tx than Bob has given
to Will. J is spending Alice's revoked commitment N.
So this slashing protocol should avoid Bob making false claim, because you
need a revoked broadcast to enable the claim
and at same time we use a justice tx output as a proof than Will have done
its monitoring+punishment job. Will shouldn't
learn commitment balance if there is no channel breach and Alice and Bob
wouldn't be able to collude against Will, if
watchtower have a penalty tx on Alice non-revoked commitment tx, that's her
concern.
So topology would be:
to_Bob
/
X <---------- N <--------- J
^ ^
\ \
Y <--------------- M <---------- P - to_Will
\
to_Bob
Main idea of the protocol is to use transactions topology of a first
contract as proofs for a subsidiary contract.
I'm quite sure it's insecure, just quick ideas, any thoughts ?
(but would be really cool to have one accountable protocol to both
watchtower and pay-to-open use cases to save
engineering costs)
Cheers,
Antoine
Le mar. 17 déc. 2019 à 16:08, Ethan Heilman <eth3rs at gmail.com> a écrit :
> From where I'm sitting the fact that OP_CAT allows people to build
> more powerful constructions in Bitcoin without introducing additional
> complexity at the consensus layer is a positive not a negative. Using
> OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
> protocol tool for enforcing fairness in layer two protocols.
>
> On Tue, Dec 17, 2019 at 11:27 AM ZmnSCPxj via Lightning-dev
> <lightning-dev at lists.linuxfoundation.org> wrote:
> >
> > Good morning t-bast,
> >
> > Further, we can enforce that RBF is signalled for every spend of the
> output by:
> >
> > <0> OP_CHECKSEQUENCEVERIFY OP_DROP <R> OP_SWAP OP_CAT <ACINQ>
> OP_CHECKSIG
> >
> > Requiring that RBF is signalled gives a little more assurance.
> > Suppose ACINQ becomes evil and double-spends the output.
> > The transaction that is posted in the mempool must be marked by RBF due
> to the `OP_CHECKSEQUENCEVERIFY` opcode, since `nSequence` also doubles as
> RBF opt-in.
> > Then anyone who notices the double-spend can RBF the double-spending
> transaction to themselves rather than ACINQ.
> > This also further publishes ACINQ private key, until the winning
> transaction has an `OP_RETURN` output that pays the entire value as fees
> and nobody can RBF it further.
> >
> > This is a minor increase in the assurability of the construction, by
> making any output that is double-spent directly revocable in favor of the
> miners.
> > Again, it requires `OP_CAT`, which is a very dangerous opcode, allowing
> such powerful constructions.
> >
> > Regards,
> > ZmnSCPxj
> >
> >
> > > Thanks a lot David for the suggestion and pointers, that's a really
> interesting solution.
> > > I will dive into that in-depth, it could be very useful for many
> layer-2 constructions.
> > >
> > > Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`
> construction,
> > > a lot of cool tricks coming up once (if?) we have such tools in the
> future ;)
> > >
> > > Le mar. 17 déc. 2019 à 16:14, ZmnSCPxj <ZmnSCPxj at protonmail.com> a
> Ă©crit :
> > >
> > > > Good morning David, t-bast, and all,
> > > >
> > > > > I'm not aware of any way to currently force single-show signatures
> in
> > > > > Bitcoin, so this is pretty theoretical. Also, single-show
> signatures
> > > > > add a lot of fragility to any setup and make useful features like
> RBF
> > > > > fee bumping unavailable.
> > > >
> > > > With `OP_CAT`, we can enforce that a particular `R` is used, which
> allows to implement single-show signatures.
> > > >
> > > > # Assuming signatures are the concatenation of (R,s)
> > > > <R> OP_SWAP OP_CAT <ACINQ> OP_CHECKSIG
> > > >
> > > > The above would then feed `s` only on the witness stack.
> > > >
> > > > Regards,
> > > > ZmnSCPxj
> >
> >
> > _______________________________________________
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191217/52ad7f11/attachment.html>