On Mon, Jul 31, 2023 at 02:42:29PM -0400, Clara Shikhelman wrote:
> > A different way of thinking about the monetary approach is in terms of
> > scaling rather than deterrance: that is, try to make the cost that the
> > attacker pays sufficient to scale up your node/the network so that you
> >
Hi AJ,
A different way of thinking about the monetary approach is in terms of
> scaling rather than deterrance: that is, try to make the cost that the
> attacker pays sufficient to scale up your node/the network so that you
> continue to have excess capacity to serve regular users.
>
> In that
On Wed, Jul 19, 2023 at 09:56:11AM -0400, Carla Kirk-Cohen wrote:
> Thanks to everyone who traveled far, Wolf for hosting us in style in
> NYC and to Michael Levin for helping out with notes <3
Thanks for the notes!
Couple of comments:
> - What is the “top of mempool” assumption?
FWIW, I think
Hi Zeeman,
> A proposal I made in the Signal group after the summit would be to not
use MuSig2 signing for commitment transactions (== unilateral closes).
> Instead, we add a tapscript branch that is just ` OP_CHECKSIGVERIFY
OP_CHECKSIG` and use that for unilateral closes.
> We only sign with
> > - For taproot/musig2 we need nonces:
> > - Today we store the commitment signature from the remote party. We don’t
> > need to store our own signature - we can sign at time of broadcast.
> > - To be able to sign you need the verification nonce - you could remember
> > it, or you could use
Hi List,
At the end of June we got together in NYC for the annual specification
meeting. This time around we made an attempt at taking transcript-style
notes which are available here:
https://docs.google.com/document/d/1MZhAH82YLEXWz4bTnSQcdTQ03FpH4JpukK9Pm7V02bk/edit?usp=sharing
.
To decrease
