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
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
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
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"
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
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
