Thank you for the detailed explanation! ☺
ᐧ
On Fri, Jun 29, 2018 at 8:25 AM ZmnSCPxj wrote:
> Good morning Praveen,
>
> The patent system, has intent, that the inventor will completely reveal
> the design of the invention, in exchange for a (time-bound) state monopoly
> on the construction
A convention in Haskell libraries is to use an "unsafe" prefix to any function
that may have side effects (here be dragons, etc)
I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal
this.
___
Lightning-dev mailing list
On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
Gregory Maxwell writes:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional
ZmnSCPxj via Lightning-dev
writes:
> For myself, I think, for old nodes, it should just appear as a
> "normal" close followed by a "normal" open.
That's exactly what they should look like, since the channel is being
closed with the existing protocol and opened (possibly with a slightly
different
Dmytro wrote:
> Yet the question remains — are there obvious advantages of cycle
> transactions over a smart fee/routing system?
That's a good question, it may be the case that by modifying the fee
structure to punish flows that unbalance channels further, then this can
simplify the problem as
