Good morning LL,
> Hi Z,
>
> Thanks again for getting to the bottom of this. I think we are on the same
> page except for one clarification:
>
> On Tue, 8 Jun 2021 at 12:37, ZmnSCPxj wrote:
>
>
> > Thus, in our model, we have the property that Bob can always recover all
> > signatures sent
Good morning LL,
> Hi Z,
>
> I agree with your analysis. This is how I pictured eltoo fast forwards
> working as well.
>
> Another interesting thing about this idea is that it could allow a new type
> of custodial LN provider where the custodian is only in charge of receiving
> payments to the
Hi Z,
I agree with your analysis. This is how I pictured eltoo fast forwards
working as well.
Another interesting thing about this idea is that it could allow a new type
of custodial LN provider where the custodian is only in charge of receiving
payments to the channel but cannot spend them.
Good morning again LL,
So I started thinking as well, about Decker-Russell-Osuntokun and the Fast
Forwards technique, as well as your "desync" idea.
And it seems to me that we can also adapt a variant of this idea with
Decker-Russell-Osuntokun, with the advantage of **not** requiring the
Good morning LL,
> Hi Z,
>
> I just went through the presentation which made your thinking very clear.
> Thanks.
> I will not be able to match this effort so please bear with me as I try and
> explain my own thinking.
> I don't see why fast forwards (FF) need "symmetrically encumbered outputs"?
Hi Z,
I just went through the presentation which made your thinking very clear.
Thanks.
I will not be able to match this effort so please bear with me as I try and
explain my own thinking.
I don't see why fast forwards (FF) need "symmetrically encumbered outputs"?
To me the protocol should be
Good morning list,
> It may be difficult to understand this, so maybe I will make a convenient
> presentation of some sort.
As promised: https://zmnscpxj.github.io/offchain/2021-06-fast-forwards.odp
The presentation is intended to be seen by semi-technical and technical people,
particular
Good morning LL,
> Hey Z,
>
> Thanks for your analysis. I agree with your conclusion. I think the most
> practical approach is the "ask first" 3 round protocol.
>
> Another option is to have `remote_penaltyclaimpubkey` owned by the node
> instead of the hardware device.
> This allows funds to
Hey Z,
Thanks for your analysis. I agree with your conclusion. I think the most
practical approach is the "ask first" 3 round protocol.
Another option is to have `remote_penaltyclaimpubkey` owned by the node
instead of the hardware device.
This allows funds to accrue in the fast forward state
Good morning list,
Note that there is a possible jamming attack here.
More specifically, when "failing" an incoming HTLC, the receiver of the HTLC
sends its signature for a transaction spending the HTLC and spending it back to
the sender revocable contract.
The funds cannot be reused until the
Good morning list,
I have decided to dabble in necromancy, thus, I revive this long-dead thread
from two years ago.
Ph34R mE and my leet thread necromancy skillz.
A short while ago, LL and Steve Lee were discussing about ways to reduce the
privkey onlineness requirement for Lightning.
And LL
11 matches
Mail list logo
