1075 sats \ 5 replies \ @niftynei OP 9 Mar 2022 freebie \ parent \ on: @niftynei AMA: lightning, FOSS, bitcoin, leveling up the next 100 btc devs at Base58 bitcoin
you know how telecom companies have no trouble justifying committing capital to building cable networks between extremely busy hubs because there's lots of users (and they can get lots of monthly subscriptions per cable laid)? it's harder to get them to lay miles of cable out to everyone's house in the boonies etc though because the cost to lay the cable will never be repaid by the customer that it serves
the analogous thing in lightning is capital, which is to say who's putting what bitcoin in what channels. if you're a smart capital allocator, you'll only want to commit your funds to channels where it'll get used -- this is because you have real network costs like onchain fees etc that need to be covered (in theory) by the routing fees that you're able to earn from that capital.
who's going to want to put lots of bitcoin into small channels with every end user, who maybe receives a $100 payment every week or two? the onchain costs are high for the amount of turnover that capital gets
I wrote a post to the mailing list about this sometime last year; the general gist of it is that the mempool makes plenty of sense when every other node on the network is participating in looking for the next block (aka mining). in that case, sending every transaction to every node on the network makes a lot of sense
most block construction is fairly centralized now to a handful of mining pools, yet we're still wasting a bunch of bandwidth btw bitcoin nodes ... rather uselessly imo.
Appreciate the thoughtful responses here.
most block construction is fairly centralized now to a handful of mining pools, yet we're still wasting a bunch of bandwidth btw bitcoin nodes ... rather uselessly imo
What solution makes the most sense to you given the fairly centralized nature of mining pools today?
reply
so like, i've been meaning to write a follow up post to ML post about this but whatever, sure staker news it is.
stratumv2. specifically, i think the mempool should be ported out of bitcoin-core to stratumv2.
reply
I'm not familiar with the specifics but i disagree out of hand... here is my 2 sats:
- transaction sending is critical bitcoin's functionality, i broadcast transactions that i am sent by friends from my node on a somewhat regular basis. therefore it should not be removed from core.
- individual node operators who would prefer not to relay transactions may reduce their bandwidth with Blocksonly mode.
Blocksonly reduced the node's bandwidth usage by 88%.
That's significant. But i still think that bitcoin core needs to have the ability to receive & broadcast transactions, therefore it should not be removed from core.
What questions should i be asking to better understand your point of view?
reply
broadcasting a transaction is not the same as relaying a transaction to a miner?? you'd still be able to broadcast a transaction to the relay network from your node, you just wouldn't see other node's transactions until they were included in a block.
if you cared about participating in the bitcoin relay network, you could run stratumv2.
reply
I agreeing that investment makes sense where ample use will pay it back. The telecom example is excellent. A thought: Customers can be found living in many places but shopping in a few. Perhaps a shopping mall (or an investor near one) could create a medium-size node and connect to it (a) the stores in the mall, and (b) the customers coming to the mall? I will be the first to say that MUCH communication will be needed to accomplish this, but I thought I would throw it out there.