Good afternoon ZmnSCPxj,
Thank you for your thoughtful reply! I agree with many of your points.
One thing I wanted to say regarding the forces that act on banks:
> It is helpful to remember that banks have, historically, been federations:
> they are typically implemented as corporations, which
Bastien TEINTURIER writes:
> Hi Rusty,
>
> On the eclair side, we instead send `funding_locked` as soon as we
> see the funding tx in the mempool.
>
> But I think your proposal would work as well.
This would be backward compatible, I think. Eclair would send
`funding_locked`, which is perfectly
Hi Lisa,
First of all great work on dual-funding and I appreciate this write up too. A
couple thoughts I had.
> Assuming that all the UTXOs in your wallet will, at some point, end up in a
> lightning channel, all of your UTXOs will be *publicly* associated with your
> node at some point
>
Good morning elsirion,
> Hi ZmnSCPxj,
>
> let me chime in here, I've been working on federated mint for quite some time
> now but only recently began talking about it more publicly.
>
> > WabiSabi "simply" replaces blinded signatures with blinded credentials.
> > Blinded signatures are fairly
Hi,
> * WabiSabi uses KVACs which afaik do not allow client side validation. While
> I can't say if it will be a big problem it makes detecting certain failure
> scenarios harder imo.
> * The KVAC scheme referred to in WabiSabi [1] is not a threshold scheme
> afaik, undermining the central
Good morning lisa,
> A dedicated attacker could probably figure out your UTXO set, but that's not
> much different from the current system; the only difference is the span of
> time
> it takes them to figure it out.
>
> ## Things We've Done to Counter This:
> I had the pleasure of finally
Hi ZmnSCPxj,
let me chime in here, I've been working on federated mint for quite some time
now but only recently began talking about it more publicly.
> WabiSabi "simply" replaces blinded signatures with blinded credentials.
> Blinded signatures are fairly low-bandwidth either you have a
A summary of the first workshop is here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019079.html
The focus for this second workshop was fee bumping and package relay.
For more details on package relay see:
Thanks for instigating this, Rusty! 0conf/turbo channels have been hackable
for a long time, and we would love to unlock new user experiences for our
platforms with it, formally if possible.
0conf is desired by every wallet, every LN exchange, and truly shows off
something only LN can uniquely
Hi Rusty,
On the eclair side, we instead send `funding_locked` as soon as we
see the funding tx in the mempool.
But I think your proposal would work as well.
We may want to defer sending `announcement_signatures` until
after the funding tx has been confirmed? What `min_depth` should
we use
10 matches
Mail list logo
