Why hasn't anyone built a P2P protocol with LN rewards built-in? \ stacker news ~bitcoin

Why hasn't anyone built a P2P protocol with LN rewards built-in?

1755 sats \ 17 comments \ @kenovios 19 Jan 2023 bitcoin

We've seen many p2p protocols rise and fall in the past years. One of the main reasons they kept falling was the lack of incentive for peer participation, i.e "Why would I ever dedicate hardware to help the network when I can enjoy a free ride?".

With LN you can integrate micro-payments every time a peer offers or requests a micro-service, in the p2p network terms.

If you modify an existing protocol like BitTorrent or IPFS to require a tiny LN payment prior to receiving blocks wouldn't that help with network growth & peer participation? This way dedicating resources for the network seems like a wise move by individuals.

Other than that anything related to "how long will something be stored" is about supply & demand. If people keep paying to download specific files then hosts will want to keep them alive longer since they're making them sats.

Thoughts?

view all related items

13 sats \ 2 replies \ @lightcoin 19 Jan 2023

it's a hard problem, "proof of retrievability" types of protocols have only recently been implemented in filecoin for example (siacoin uses a similar protocol but relies on some trust assumptions iirc).

you might be interested in this attempt to build the same with bitcoin: https://github.com/cgilliard/bips/blob/storage/bip-XXXX.mediawiki

15 sats \ 1 reply \ @kenovios OP 19 Jan 2023

it's a hard problem, "proof of retrievability" types of protocols have only recently been implemented in filecoin for example (siacoin uses a similar protocol but relies on some trust assumptions iirc).

Do you need that proof though? Worst case you lose 1sat and you temporarily blacklist that peer

0 sats \ 0 replies \ @lightcoin 20 Jan 2023

depends on implementation details and use-case but either way if 1 sat is all that's on the line, maybe not!

230 sats \ 0 replies \ @kevkevin 19 Jan 2023

Take a look at LSATs it's what lightning labs uses for loop

201 sats \ 3 replies \ @l0k18 19 Jan 2023

We are busy doing this now :D

It's a distributed VPN protocol based off HORNET. We may have something to demonstrate by the end of next month, fingers crossed.

17 sats \ 2 replies \ @calle 19 Jan 2023

cool, who are "you"?

17 sats \ 0 replies \ @ek 20 Jan 2023

Click on his profile, he means indranet

10 sats \ 0 replies \ @l0k18 20 Jan 2023

There is two of us. I'm working on the protocol, the guy who is sponsoring the project is also doing a lot of devops and server implementation.

For my part (l0k18) cryptography, session/bandwidth accounting, onion message processing are pretty much done, I will be working on path diagnostics next, for when nodes become unreachable or go offline, and then moving towards the session management system and peer recommendation algorithm.

10 sats \ 0 replies \ @nerd2ninja 19 Jan 2023

I mean I haven't built anything like that because I don't really care about something like that, but feel free to open up a repo and write something up.

0 sats \ 7 replies \ @kristapsk 20 Jan 2023

It's hard to do proof of bandwidth, besides bandwidth nowadays is cheap in a lot of civilized countries. I can seed torrents from my laptop and feel no difference at all.

0 sats \ 6 replies \ @l0k18 20 Jan 2023

It is, unless your traffic passes through multiple nodes on a p2p network, and then each one can keep an account. I've just completed the basic bandwidth accounting for Indranet this morning. The proof part is that you pay in advance and then demand delivery. Poor delivery doesn't get repeat business, and the unit cost is very small (like 6.25 sats/Mb). By default, indra nodes lightning channels (via lnd) don't charge fees, because the relay operators should be factoring running costs into their bandwidth fee rates.

34 sats \ 5 replies \ @kristapsk 20 Jan 2023

the unit cost is very small (like 6.25 sats/Mb)

Is it small? 6400 sats (more than 1$) per GiB. Downloading films that way seems more expensive than paying for streaming services.

Also problem is sybil attacks. One can spin up a lots of nodes, which is basically free, take small fee upfront and then not deliver content. Maybe JoinMarket style fidelity bonds with timelocked BTC could help here.

17 sats \ 3 replies \ @kenovios OP 20 Jan 2023

Also problem is sybil attacks. One can spin up a lots of nodes, which is basically free, take small fee upfront and then not deliver content. Maybe JoinMarket style fidelity bonds with timelocked BTC could help here.

Spinning up LN nodes isn't free, it requires BTC

0 sats \ 1 reply \ @0260378aef 21 Jan 2023

Yes, this also sacrificing time value, so it's the same general concept, but it's much less than a direct timelocked utxo, locked for say 6 months. Because if I open a channel with myself I can immediately close that with one txfee, at any time, in order to spend it. Realistically you couldn't assume sacrifice of more than one coop-close txfee.

0 sats \ 0 replies \ @l0k18 22 Jan 2023

The idea I have is that users will be from a wide variety of economic situations, and mandating a minimum excludes those with less resources, who still have need of the system and the option to run relays.

https://bitcoinfees.earn.com/

At the top of this page you can see that there are transactions all the way down to 1 satoshi. So using such a fee, and the fact it doesn't have to clear before a few days, one can cycle two amounts to keep one constantly in the air and satisfy the requirement.

So an amount that is reasonable for a poor person, kept continuously locked up, serves as a proof of age of the relay, while their routing fees will likely earn them more than enough to increase this amount in order to improve the number of new clients they get.

Of course, one has to open channels to run an Indranet relay, which is a mandatory up front cost. A sybil attacker will not want to open up long living channels, so the amount of time a HTLC is locked in the channel also can be a data point to select a relay for first time use. Keep in mind also that the cost/time delay for closing them can be quite high so this also raises the bar for a profitable scam.

But HTLCs can be closed at any time, where a timelocked transaction cannot be spent until the specified block height is passed.

The other thing that the time locked transaction used in association with a relay's identity is objective proof of the time the node has been running, which will constitute the largest factor in the amount of new clients a node can attract. Sybil attackers window of opportunity is quite small, really, especially if their relay doesn't get a lot of use in the beginning. So, proof of the time of setup and the age of the node is definitely the most effective defense against attempts to capture fees without delivering service.

A final point - the amount of service purchased at a time can be very very small. The client just needs a few megabytes ahead of current usage and new payments can be streamed fee-free. This could be in the range of 5-50 sat renewed every few minutes.

I think with these measures in place there would be very little risk of sybil attacks since there just won't be the economic incentive

0 sats \ 0 replies \ @l0k18 20 Jan 2023

Yes, this also helps, but Indra channels don't need to be big.

0 sats \ 0 replies \ @l0k18 20 Jan 2023

The prices are set by the user. $1/gb is probably on the expensive side in Europe but nearly normal in USA and Asia. The price setting will have a helper tool to deal with various kinds of metering and billing schemes.

Yes, I just recently came up with a scheme that also, probably not coincidentally, uses timelocked BTC. It specifically requires a continuously active chain of time locked transactions that refer to the address of an initial TXID that is part of a node's pseudonymous identity.

Both age and size contribute factors in the random selection for peers to recommend relays (it has to be done carefully so as to not deanonymise recent connections). Age matters more, second is number of recommendations and third, and least, is the average amount of BTC locked on the TXID over its lifespan.

I'm glad to hear that my idea isn't entirely unique. It should ensure that it isn't profitable to spawn a node and then take it down, since one has to make a BTC tx as well as the amount, to prove arrival as well as to encourage a competition to have the highest lifetime average locked up. Nodes also contribute to this consensus ranking of peers in that they can raise the profile of reliable new nodes, but the primacy of the influence of age enforces maintaining a running, delivering node for a substantial amount of time before it even gets to get many clients connecting.

Ah yes, the last piece is that the benefit of locking up more is a progressively longer cycle for renewal. So, a sybil attacker is in a dilemma where they can lock up more, to get ahead of the new nodes, but then be stuck unable to spend that coin until a lot later, or use a smaller one and be at the bottom of the priority list for clients to select for first time usage.