Topic: Lightning Network Discussion Thread - page 16. (Read 29772 times)

I have found an interesting article whose aim is to show that capital is not the only factor when it comes to making money from the Lightning Network fees.



Comparison between Andreas Brekken's and Alex Bosworth's nodes. Fees = week_fee_sum. Source

Andreas' node's capacity has been stuck at 43 BTC for a few days now. We should give him a few weeks to collect more accurate data.

What are the latest updates on Andreas Brekken's node? I heard that he was only earning a few cents from it even though he owns half the liquidity in the LN.

Plus where are the attacks on Blockstream and the conspiracy that they developed Lightning to "make money on fees"? Didn't Blockstream say that fees would be unfairly cheap?

Should be able to drop your HTLC to a much lower value, like 3-4 hours instead of 24 hours.

I am playing with Discrete-Event Network Simulator NS3

http://arthurgervais.github.io/Bitcoin-Simulator/index.html

the project is a bit in the limbo and I don't think is up to date ...
while reading the models used I was wondering what parameters should I include to reflect how long a connection must be on ..
https://github.com/arthurgervais/Bitcoin-Simulator/tree/master/src/applications/model

"Problem with nLockTime is that it's hard to broadcast these transactions, so you'd have to leave your Bitcoin node running"..
-Sjors at https://github.com/bitcoin/bitcoin/issues/8431

... my general question is regards to a connection time and new routing path ...

FWIW, changed my lnd.conf to leave feerate at the default of 1, and am instead playing with the "base_fee_msat" (bitcoin.basefee) value.

The explorer at 1ML.com does not properly display feerates below 1 (0.9 turns into 900,000 mil sat), so I think I screwed something up there or maybe they are screwed up ? Whatever. I don't know.

Anyway, adjusted existing channels to;

$lncli updatechanpolicy --base_fee_msat 950 --fee_rate 0.000001 --time_lock_delta 144

Frustrating that fee_rate is treated differently on the command line vs lnd.conf.

The default feerate is 1 in the config, and gets translated to 0.000001 somehow when the channel is opened.

Not sure what's going on there, but so far, I have made 2 satoshis in fees !

    "day_fee_sum": "2",
    "week_fee_sum": "2",
    "month_fee_sum": "2"

The lower the fee rate, the lower routing fees people will have to pay. It might actually encourage wallets to choose your node.

Yesterday, I tried Lightning Spin because one user has a problem with it and I was surprised. I haven't used my Eclair wallet for some time. I had to wait roughly 1 minute and I haven't paid any routing fees!

No because you are biased against the Core developers. It is one thing to question or criticize, but you are imposing your own ideas as "right", and the people against you as "wrong".


Forcing? You can choose to use onchain transactions anytime you want. Plus offchain transactions really help free some space for your onchain transactions.


The Core developers are free to choose which solutions are the best for the long term feasibility of the network.


See you.

Using the official lnd / lncli from Github.

Anyone screw around with fees ?

For example, the defaults are base_fee_msat 1000 and fee_rate of 1

$lncli updatechanpolicy --base_fee_msat 1000 --fee_rate 0.9

I suck at this math thing, but I'm thinking changing the fee rate from 1 to 0.9 makes routing through me cheaper ?

Or more expensive ?

The fee rate used when forwarding payments on our channels. The total fee charged is basefee + (amount * feerate / 1000000), where amount is the forwarded amount. (default: 1)

Got my lnd.conf set up like this at the moment for the Bitcoin config.

I'll certainly report back after a month. So far haven't routed a single satoshi

[Bitcoin]
bitcoin.active=1
bitcoin.basefee=1000
bitcoin.feerate=0.9
bitcoin.minhtlc=1000
bitcoin.timelockdelta=144

First of all, I'm just curious, why should you accuse me of debating just for having a debate? Isn't it kinda personal attack?
A gentleman asked me to express my ideas and i did so, what's wrong here?

Secondly, you have heard about incentives and how people follow them. Right? How don't you understand my argument here?

When you offer scalability off-chain and do nothing about it on-chain, you are forcing people to use the only economic option you have left them with.

I have explicitly specified that it is a right for any developer or company to use bitcoin api for developing second layer protocols or services of any kind, but it is not Core's right to be biased toward them or project the problems like scalability to them.

So, it is not over and we are allowed to have our ideas and suggest our improvements but you think a decade later we will be proved wrong, and sticking with magical 1 MB limit will be proved right.

Ok. See you 2028.  

Shitcoin.com's node capacity seems to be constantly growing. It has already surpassed 40 BTC.


Could you let us know if anything has changed after one month? What implementation are you using?

If anyone is interested in setting up a node on a Raspberry Pi then RaspiBlitz is now available on github. It makes the whole process easier and it also comes with a nice LCD feature.

You are making a debate just to make a debate. You can still use Bitcoin onchain without problems if you want to. But you should not criticize developers if they want to make tools that people might use.


No one is forcing you, and how would it give them misery? Lightning will also make transactions cheaper onchain if they do not want to use Lightning.


It will be over. Let us observe Ethereum and make that our case study. Give it 10 years. Bitcoin Cash will also follow the same path. If it can increase its transactions per block more than Dogecoin. Hahaha.


Make a BIP. The problem in this forum is there are sometimes "very smart" people, but truly they have their own agenda.

I have a link channel established with ACINQ. Have a link established to essentially the top 10-15 nodes by routing connections.

Let Autopilot manage the rest of the connections after connecting to the big ones manually.

That's how I imagined this problem would be dealt with I just didn't see any mention of dealing with it this way in the paper.

Yes, it will take some time before you start earning from routing fees. Note that wallets will prefer the shortest and the cheapest route. At the beginning, this guy earned only $0.01 after one month! In the comments someone pointed out that a lot of people connect to the ACINQ node because it's the default one in Eclair (Android). To how big nodes are you connected to?

I guess it's going to take some time getting established ? Feereport is zeroed after twenty four hours. Have opened over fifty decently funded channels.

This is normal ?

It's not yet available. It is one of the planned features but as you can see it might have a huge impact on the network once it becomes available in the most popular implementations. Take a look at this article. There is some useful information about the future possible upgrades of the Lightning Network.


Nobody can pay a transaction fee for you if you are opening the channel, but you can get a refund later. Lightning faucet is quite useful for new users which want to test if their wallet is working properly. Usually, receiving funds causes more problems.


Wouldn't the rest of participants simply broadcast a penalty transaction in such case?


Thanks for that, I have just ranked up I really appreciate it. I used to read a lot about the Lightning Network a few months ago and I plan setting up my own node on a Raspberry Pi in the future.

Ok, just for you  
LN, as a second layer protocol is suspected to centralization as it has been extensively discussed up-thread and plus a very primitive axiom I believe in: Any second layer protocol on top of bitcoin is vulnerable to centralization, no matter what.

I believe bitcoin is the ultimate and the state of the art decentralized system and as I'm used to emphasis and argue, and have tried to prove regularly, bitcoin's  current situation with pools and ASICs is not inherent and MUST be resolved by means of an evolutionary approach.

Any utility, UI, browser, navigator, analyser, ... that uses bitcoin protocol to lubricate user interaction with the system, remains decentralized as long as it has not wrapped it in a new protocol and abstracted users from the actual system.

Although, Bitcoin is open  and it is definitively any developper's right to invent such protocols/abstraction layers, we should be aware of the implications and threats involved and by no means such a protocol deserves to be advertised as a solution to scaling problem in bitcoin.

For instance, I can trivially design and implement a protocol for traditional banks to keep track of bitcoin deposits of their customers, providing very fast and 'secure' transaction processing utilities for in-bound transaction processing plus a simple clearance system for inter-bank/out-band transactions.
Obviously it would project parts of transaction burden off the blockchain, but do I deserve any  merits? Is it wise to consider my system as an scalability solution for bitcoin?

Right now we have centralized exchanges that transact billions of dollars a day without any overhead for bitcoin network, are they parts of a scalability solution?
They are mostly dangerous wild scammers. Bittrex as one of the biggest ones, few months ago, deliberately seized and scammed millions of dollars worth of user deposits.

My other concern here is the sole protocol stacking approach. A protocol above bitcoin protocol is evil, imo. People are joining bitcoin because of its beauty and its transparency, such abstractions and wrappings, alienates people from the system.

It is just the same as forcing people to do something, making their life a misery and giving them just one option to exit, your favorite one.

Core guys are biased toward LN. Right? It is wrong from the beginning. A 'core' developer should take care of the core protocol instead of commercializing a second layer protocol, shouldn't s/he?
I mean, you just start asking them about sca... and observe that they have already pointed to LN for scalability. So, this is it. It is their ultimate scaling solution that users have no choice other than to adopt.


Wrong! Block size debate is not over, I've showed it in other thread how poor is reasonings behind Core's weird approach to this debate. Mining scene is already centralized by pools and even a 100 times increase in block weight won't change the scene in this regard a bit!
I've suggested a block time decrease earlier as a better version than block size increase, tho.

Reducing block time is a complementary cure for on-chain scalability and should be considered a serious part of any improvement for bitcoin because it has a similar effect on reducing pooling pressure and centralization problems involved.

Outlines of my solution:

• 1- Adopting a Proof of Collaborative Work algorithm, eliminating pools
• 2- Reducing block time to help the above de-pooling agenda
• 3- Revising transaction format to make it more smart and compact
• 4- Making room in blocks/transactions for low level support of sharding strategies

Parts of this solution has already been published in the topic you provided a link for, others are spontaneously discussed in other topics.
Note that eliminating pools is the most critical and urgent step to make sharding as an ultimate scalability solution, feasible.

For now, I'm integrating the most important parts in the second version of my PoCW proposal, due to be published in few days.

Let's leave rank out of this for a moment, because I think it is irrelevant to this discussion. Let's get back to the topic and what you think the LN is. In my view, the LN network solves a part of the scaling problems, by taking some of the micro transactions and placing them off-chain.

People are not forced to do all their transactions off-chain, they are just encouraged to take their micro transactions off-chain, because it is faster and cheaper to do that on a second layer that are focussed on that.

Everyone knows "Block size" increases is one of the most ineffective ways to scale a network, so that is not even considered as a possible solution.

Give us a short explanation of your solution and let's debate this as responsible grownups. This name calling and swearing is so juvenile.  

Edit : I bumped into your thread dedicated to your idea and it looks interesting - https://bitcointalksearch.org/topic/getting-rid-of-pools-proof-of-collaborative-work-4438334

No, I learned it from "him".



It is his one and true "vision". Hahaha.


For a person that says that he "does not" need any authority, you are speaking as if you are an "authority". Why should we listen to you with that attitude?


Then if someone takes the other side of the debate and challenges you, they are hypocrites?

I mean excluding the transaction fee. This gets so abstract so fast but if I am thinking about it correctly, it should be possible for some charitable node to be willing to open a small channel with you in exchange for you paying the nodes transaction fee. That way you could pick up some coins from the faucet for just the price of a transaction fee. I don't think anything like this exists though. Which was my reason for questioning the usefulness of a lightning faucet.

---

  Good lord man. You are so knowledgeable and such an asset to this thread. How are you only a regular member? I'm going to give you a chunk of merit and it's not for this post specifically but because you need it more than others (being only member) while simultaneously deserving it more than many others.


From the paper Scalable Funding of Bitcoin Micropayment Channel Networks


This is amazing! Any idea if this has gone through peer review?


Ok so I finished reading Scalable Funding of Bitcoin Micropayment Channel Networks and yea it's super exciting. I'm not sure but maybe I see a mistaken assumption / attack vector.


It's true that if I uncooperatively leave the channel factory I will lose more money than if I do so cooperatively. But so will everyone else. So in the narrowest sense it is in my self interest to close the channel cooperatively, but what if my motives are more complicated? Couldn't I, in theory, for the cost of X dollar to myself, remove 99*X total dollars from each of my channel factory peers? Maybe causing others to lose 99 times as much wealth as myself is worth sacrificing some of my own wealth.