Matt Corallo writes:
> Ultimately, defining a "near the top of the mempool" criteria is fraught
> with issues. While it's probably OK for the original problem (large
> batched transactions where you don't want a single counterparty to
> prevent confirmation), lightning's requirements are very
ZmnSCPxj via Lightning-dev writes:
> HTLCs as American Call Option, or, How Lightning Currently Cannot Work Across
> Assets, or, An Argument For Single-Asset Lightning Network
Interesting. FWIW, I believe that multi-asset LN will fail for a
related, but different reason: to prevent long-lived
Fabrice Drouin writes:
> Follow-up: here's more detailed info on the data I collected and
> potential savings we could achieve:
>
> I made hourly routing table backups for 12 days, and collected routing
> information for 17 000 channel ids.
>
> There are 130 000 different channel updates :on
Hi Chris,
What we've learned building a lite bitcoin/LN wallet is that there are
different things it must implement:
- a bitcoin wallet. We started with bitcoinj, but there are known
issues with Bloom Filters, which is one of the reasons why we ended up
building our own wallet that connect to
Sorry for the late reply.
Hmm, I included the old RBF-pinning proposal as a comparison.
Personally, I find it both less clean and less convincingly secure.
Ultimately, defining a "near the top of the mempool" criteria is fraught
with issues. While it's probably OK for the original problem
Happy new year lightning-dev!
This topic is my main area of research at moment so I'm really happy to see
a thread about it. In general I agree with ZmnSCPxj's analysis and
conclusions. I'd like to add a couple of ideas to this discussion and would
greatly appreciate some early peer review on
Hello Lightning Network devs,
I am a crypto youtuber seeking knowledge of btc, lightning network especially
the latest developments. But I want to give truth to my audience not Hopium so
I need facts. My problem is am not a techie so can you tell me where I can find
details on the latest
Good morning all,
> 6. In addition, F adds to the OM onion hop packet the below information:
> 1. `payment_point`
> 2. `exchange_rate_point`
> 3. The point sum of `(om_to_s_scalar + s_to_om_scalar) * G`
> 4. A signature using the point `(om_to_s_scalar + s_to_om_scalar) * G`
Good morning David and CJP,
Although we have determined that the David solution and all classes of that
solution are insufficient, it also triggered me to mentally compare the CJP
solution to the David solution.
David solution effectively makes the exchange node (OM in CJP terminology) also
