New pathfinding variable to give more control over time and cost tradeoff
I always love features like that. Yes, give users more power.
Imagine, you are in a situation where internet is to break up and things gotta be fast. Or there is a DDoS and you don't care if you order something right now or it goes through a little later.
do any other implementations support something similar
Not that I'm aware of. But someone correct me if I'm wrong.
Is it fair to compare this ability to make fee/speed trade-offs to Bitcoin’s mempool where you can pay more to get your transaction approved faster?
Partly yes. But for Onchain the upper speed limit is waiting for a block to be mined. This can take time depending on luck and there is no chance to influence it. Even worse if you want the security of 3 or 6 blocks on top of it.
I always love features like that. Yes, give users more power.
Imagine, you are in a situation where internet is to break up and things gotta be fast. Or there is a DDoS and you don't care if you order something right now or it goes through a little later.
This is underrated.
fascinating idea, do any other implementations support something similar?
Is it fair to compare this ability to make fee/speed trade-offs to Bitcoin’s mempool where you can pay more to get your transaction approved faster?
Not that I'm aware of. But someone correct me if I'm wrong.
Partly yes. But for Onchain the upper speed limit is waiting for a block to be mined. This can take time depending on luck and there is no chance to influence it. Even worse if you want the security of 3 or 6 blocks on top of it.
got it, thanks!
This comment was featured on This Day in Stacker News as the top comment of the day.
Two days in a row!
This comment was featured on This Day in Stacker News as the top comment of the day.
For the devs out there, this is a breakdown of lnd's codebase -- 300k lines of Go 0_0:
=============================================================================== Language Files Lines Code Comments Blanks =============================================================================== Dockerfile 7 293 153 81 59 Go 1254 487919 324756 93382 69781 JSON 20 15424 15422 0 2 Makefile 4 570 392 69 109 Protocol Buffers 16 8300 6063 752 1485 Ruby 1 12 9 1 2 Shell 18 1303 829 246 228 Plain Text 2 325 0 325 0 YAML 18 566 516 25 25 ------------------------------------------------------------------------------- Markdown 52 7761 0 5972 1789 |- BASH 3 24 16 4 4 |- Go 3 183 133 34 16 |- Java 1 72 61 0 11 |- JavaScript 2 204 160 35 9 |- Python 1 76 45 18 13 |- Ruby 1 75 52 8 15 |- Shell 37 1103 1008 42 53 |- XML 2 66 66 0 0 (Total) 9564 1541 6113 1910 =============================================================================== Total 1392 522473 348140 100853 73480 ===============================================================================Headline features: taproot address support (I suppose for spending into funding txs?) and 95% reduction in DB space usage.
One thing i wonder is how a 95% database reduction compares to the current state for those running other implementations?
Said differently, how much larger were LND databases than Core LN or Eclair databases prior to this LND upgrade?
@zerofeerouting
This is great
Kickass :)