Hi all!
Roasbeef suggested we split up option_simplified_commitment,
since it is fairly ambitious. In particular, he wanted the static
remote_key feature ASAP, and Christian agreed.
I chose to add the fairly trivial symmetric output to this, as it
affects the same output, and resolves th
Hey everyone,
I am glad the suggestion is being picked up. At this time I want to respond
to two of the concerns that have been thrown in. I have some other comments
and ideas but would like to hold them back so that we can have more people
joining the discussion without bias also this mail will a
God afternoon ZmnSCPxj,
Sorry if I was being a bit pedantic,
I just want to be clear that I agree with both yours and Andrea's
arguments
in the initial responses and I see now why the idea doesn't make much sense
at all
in terms of scale and privacy.
> > My initial point was that the fee would b
Hello Rene, ZmnSCPxj, and list
I really like the proposal and I'm sure it's the correct way forward for
reducing payment failures and increasing privacy (through mitigating probing
based network analysis)
However I am concerned that this proposal could introduce a vulnerability to a
spoofe
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 Rene and list,
Let us consider then the rule *when* a rebalancing would be beneficial to the
node.
The node is offered a fee amount (`offered_fee_amount`) for the forwarding.
It knows that, under current channel states, it will definitely have to fail
and earn 0 fees.
If it engage
Good morning John-John,
> > > That would not regard the size of the payments though? A payment leaving
> > > the balance at the far end would pay the same proportional fee as one
> > > close to the middle.
> >
> > "Proportional" means the fee paid is greater if the payment being forwarded
> >
> > That would not regard the size of the payments though? A payment leaving
> the balance at the far end would pay the same proportional fee as one close
> to the middle.
>
> "Proportional" means the fee paid is greater if the payment being
> forwarded is greater.
> That is what "proportional" mea
Good morning John-John,
> That would not regard the size of the payments though? A payment leaving the
> balance at the far end would pay the same proportional fee as one close to
> the middle.
"Proportional" means the fee paid is greater if the payment being forwarded is
greater.
That is what
Good morning Andrea and ZmnSCPxj,
I wrongly assumed the channel balances needed to be known anyway to create
a route. I see
now why that is not the case and why it would scale horribly, in fact it
scales no better than
layer 1 as everyone needs to be notified of every payment. It would also
defeat
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
12 matches
Mail list logo
