Re: [Lightning-dev] Rebalancing argument
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 the heuristics can target solely the fee rate. The earliest suggestion of this I can recall was from Tadge way back in like 2015 or so. The goal here is for a node to ideally maintain relatively balanced channels, but then charge a payment an amount that scales super linearly when flows consume most of their available balance. The current fee schedule is essentially: base_fee + amt*rate clighting and lnd (borrowed from c-lightning) currently use a "risk factor" to factor in the impact of the time lock on the "weight" of an edge when path finding. With this, the fee schedule looks like: (base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,) In the future, we may want to allow nodes to also signal how they wish the fee to scale with the absolute CLTV of the HTLC extend to this. This would allow them to more naturally factor in their conception of the time value of their BTC. Finally, if we factor in an "balance disruption" factor, the fee schedule may look something like this: (base_fee + amt*rate) + (cltv_delta * risk_factor / 1,000,) + gamma*f(capacity, amt) Here f is a function whose output is proportional to the distance the payment flow (assuming full capacity at that instance) puts the channel away from being fully balanced, and gamma is a coefficient that allows nodes to express the degree of penalty for unbalancing a channel. f itself is either agreed upon by the network completely, or resembles a certain polynomial, allowing nodes to select coefficients as they wish. We may want to consider moving to something like this for BOLT 1.x+ as it allows nodes to quantify their apprehension to time locks and also channel balance equilibrium affinity. Alternatively, if we move to something like HORNET, then during the set up phase, nodes can ask for an initial "quote" for a set of payment ranges, then just use that quote for all payments sent. This allows nodes to keep their fee schedules private (for w/e reason) and also change them at a whim if they wish. -- Laolu On Sun, Jul 1, 2018 at 8:39 AM Dmytro Piatkivskyi < dmytro.piatkivs...@ntnu.no> wrote: > Hi Rene, > > Thanks for your answer! > > 1. The Lightning network operates under different assumptions, that is > true. However, the difference is minor in terms of the issue posed. The > premise for the quoted statement is that taking fees changes the nodes’ > balances, therefore selected paths affect the liquidity. In the Lightning > network fees are very small, so the change in liquidity may be negligible. > Moreover, intermediate nodes gain in fees, which only increases the > liquidity. > > 2.A. It is too early to speculate where the privacy requirements will > settle down. Flare suggests a mechanism of sharing the infrastructure view > between nodes, possibly sharing weights. As the network grows routing will > become more difficult, however we don’t know yet to which extent. It may > organise itself in ‘domains’, so when we send a payment we know to which > domain we are sending to, knowing the path to it beforehand. The point is > we don’t know yet, so we can’t speculate. > > 2.B. That is surely an interesting aspect. HTLC locks > temporarily downgrade the network liquidity. Now the question is how it > changes the order of transactions and how that order change affects the > transaction feasibility. Does it render some transactions infeasible or > just defers them? It definitely needs a closer look. > > Yet the question remains — are there obvious advantages of cycle > transactions over a smart fee/routing system? In any sense. Path lengths, > for example. To answer that I am going to run a simulation, but also would > appreciate your opinions. > > Best, > Dmytro > > From: René Pickhardt > Date: Sunday, 1 July 2018 at 13:59 > To: Dmytro Piatkivskyi > Cc: lightning-dev > Subject: Re: [Lightning-dev] Rebalancing argument > > Hey Dmytro, > > thank your for your solid input to the discussion. I think we need to > consider that the setting in the lightning network is not exactly > comparable to the one described in the 2010 paper. > > 1st: the paper states in section 5.2: "It appears that a mathematical > analysis of a transaction routing model where intermediate nodes charged a > routing fee would require an entirely new approach since it would > invalidate the cycle-reachability relation that forms the basis of our > results." > Since we have routing fees in the lightning network to my understanding > the theorem and lemma you quoted in your medium post won't hold. > > 2nd: Even if we neglect the routing fees and assume the theorem still > holds true we have two conditions that make the problem way more dynamic: > A) In the
Re: [Lightning-dev] Including a Protocol for splicing to BOLT
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 value). > So, instead, maybe a new `channel_announce_reopen` which informs > everyone that an old scid will eventually become a new scid, and that > the nodes involved will still consider routes via the old scid to be > valid regardless. I thought of it more as a new alias for the old channel, so that the update in the network view is just switching names after the announce depth is reached. > Then an ordinary `channel_announce` once the announce depth of the new > scid is reached. > > From point of view of old nodes, the channel is closed for some > blocks, but a new channel between the two nodes is then announced. > > From point of view of new nodes, the channel is referred to using the > previous scid, until an ordinary `channel_announce` is received, and > then the channel is referred to using the new scid. The message announcing the reopen or the alias should probably preceed the actual close, otherwise nodes may prune the channel from their view upon seeing the close. The message then simply has the effect of saying "ignore the close, let it linger for 6 more blocks before really removing from your network view". > For myself, I think splice is less priority than AMP. But I prefer an > AMP which retains proper ZKCP (i.e. receipt of preimage at payer > implies receipt of payment at payee, to facilitate trustless > on-to-offchain and off-to-onchain bridges). Agreed, multipath routing is a priority, but I think splicing is just as much a key piece to a better UX, since it allows to ignore differences between on-chain and off-chain funds, showing just a single balance for all use-cases. > With AMP, size of channels is less important, and many small channels > will work almost as well as a few large channels. Well, capacities are still very much important, and if there is a smaller min-cut separating source and destination than the total amount of the payment, then the payment will still fail. We now simply no longer require a single channel with sufficient capacity to exist. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput
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 > insecure for traditional applications where a third party might pay to > an address a second time, and should only be used in special protocols > which make that kind of mistake unlikely. I don't agree. Address reuse is undefined behaviour. Nobody should assume it is safe or works. I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in a wallet I am writing, which explicitly does not support address reuse. Luke ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput
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 applications where a third party might pay to > an address a second time, and should only be used in special protocols > which make that kind of mistake unlikely. Otherwise, I'm worried > that wallets might start using this sighash because it simplifies > handling malleability without realizing that when a third party reuses > a script pubkey, completely outside of control of the wallet that uses > the flag, funds will be lost as soon as a troublemaker shows up (but > not, sadly, in testing). This sort of risk is magnified because the > third party address reuser has no way to know that this sighash flag > has (or will) be used with a particular scriptpubkey. Absolutely agree that we should be signaling the danger of using noinput as clearly as possible to developers, and I'm more than happy to adopt the _unsafe suffix suggested by jb55. I think using non-sighash_all sighashes is always a huge danger, as you have correctly pointed out, so maybe we should be marking all of them as being unsafe, or make sure to communicate that danger on a higher level (docs). ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput
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 Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Second Level Protocols - Lightning - Patents
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 and sale of the invention. The intent, is that the
> inventor is compensated for the toil in creating the invention, while the
> revealed design may help future inventors to consider, an improved
> designed, after the granted monopoly has ended.
>
> Thus, the patent system, has the concept, "prior art".
>
> If the item being patented, is in the past ("prior") already known among
> practitioners ("art"), then there is no need for the state to "pay for"
> revealing the design by granting a monopoly. Already, the design is
> revealed and known, so why should the state pay the inventor with a
> state-enforced monopoly?
>
> Importantly, any evidence, that the design of the invention is known, is
> prior art. This includes publications made by the inventor himself or
> herself. It is prior art since the fact of publication indicates that
> other practitioners now know of the art of the new design.
>
> Another consideration, is the "grace period".
>
> An inventor may publish, the design of the invention, at some past point,
> and then file for a patent afterward. However, the fact of the
> publication, even initiated by the inventor, is itself prior art, and is
> evidence that the invention is known (and that the state must, logically,
> not pay for it by enforcing a patent-backed monopoly).
>
> Of course, an inventor may publish an invention with intent to patent it
> later. Thus, the state allows, a grace period, after the inventor publishes
> the design, to patent the design. Importantly, this grace period is not of
> unlimited duration. The de facto global state government, the USA,
> provides a grace period of 1 year only.
>
> For reference, the Poon-Dryja whitepaper for Lightning was published in
> 2016, and the current year is now known to be 2018.
>
> As the current Lightning design is designed publicly and continuously
> published in the lightning-rfc (thus a continuous evidence that the design
> of Lightning is already known), and is in any case based on the prior-art
> Poon-Dryja paper, and neither Poon nor Dryja have applied for patents of
> the Lightning design within a year of publication of the Poon-Dryja paper,
> then the state will not bother to grant a patent to the inventors of
> Lightning.
>
> (the above describes the ideal operation of patent systems. it should be
> noted, that agents operating patent systems are known to run on cognitive
> substrates that are highly amenable to external corrupting influences, and
> thus non-ideal operation may occur in practice.)
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On June 22, 2018 11:21 PM, Praveen Baratam
> wrote:
>
> Hello everybody,
>
> I just heard from a friend that Second Level Protocols such as Lightening
> Network can be patented if the author/inventor chooses to!
>
> Is it possible? Am I missing something?
>
> Best,
>
> Praveen Baratam
>
> about.me
> ᐧ
>
>
>
--
Dr. Praveen Baratam
about.me
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
