This might be informative: https://github.com/ipfs/go-ipfs/blob/master/docs/file-transfer.md
Topic: Data routing for money, rather than payment routing for money. (Read 219 times)
Every user of Bitcoin, who is online, is connected to every other user.
I can send a message (txn) and he can get it. Push.
This is very powerful. Instead of an IP though, you have a BTC address.
A P2P network that allows you to push messages to other users (bouncing through various nodes) in in effect - the same as the internet itself.
The current design of the internet does not distinguish between different routes across the web.
Is there not a more sustainable design - where the most used, the routes that transfer the most data, pay more for their usage? Those routes would require the largest routers to handle the traffic, BUT would make the most money if users had to pay fractional amounts to transfer data.
Say you try to access BTC://NETFLIX over the current Bitcoin P2P network. Not as a flood fill obviously (which is what BTC normally does) but just for routing purposes. The messages would only be bounced through the required nodes to get to you, no matter how far behind a NAT or firewall you may be. (We're all connected after all)
You or NETFLIX depending on the business model would need to pay for the use of that bandwith. The incentive structure would be there to offer those data routing services.
The LN network - is a P2P network of already P2P connected Bitcoin Nodes.
There is an overlap there, that you could make generic, and let people connect to other nodes for any reason they like, as long as they pay for the bandwidth used on the data hops.
Sorry - I'm rambling. There just seems to be a powerful property of a large scale P2P network like Bitcoins that is being under utilised.
I can send a message (txn) and he can get it. Push.
This is very powerful. Instead of an IP though, you have a BTC address.
A P2P network that allows you to push messages to other users (bouncing through various nodes) in in effect - the same as the internet itself.
The current design of the internet does not distinguish between different routes across the web.
Is there not a more sustainable design - where the most used, the routes that transfer the most data, pay more for their usage? Those routes would require the largest routers to handle the traffic, BUT would make the most money if users had to pay fractional amounts to transfer data.
Say you try to access BTC://NETFLIX over the current Bitcoin P2P network. Not as a flood fill obviously (which is what BTC normally does) but just for routing purposes. The messages would only be bounced through the required nodes to get to you, no matter how far behind a NAT or firewall you may be. (We're all connected after all)
You or NETFLIX depending on the business model would need to pay for the use of that bandwith. The incentive structure would be there to offer those data routing services.
The LN network - is a P2P network of already P2P connected Bitcoin Nodes.
There is an overlap there, that you could make generic, and let people connect to other nodes for any reason they like, as long as they pay for the bandwidth used on the data hops.
Sorry - I'm rambling. There just seems to be a powerful property of a large scale P2P network like Bitcoins that is being under utilised.
I don't see how it's possible, you must make the file available publicly (obviously encrypted) or make direct connection between Bob and Alice.
OP mentioned a problem regarding the direct connection:
But all the current methods, for the 99.99% of cases where neither party has access to an external IP or a NAT routeable address.. etc, use a centralised intermediary.
And in this case, a central server is one of the best solutions IMO.
Especially if the server (obviously with an own publicly routable IPv4 address) is hosted by alice or bob itself.
Without a publicly routable address, no direct connections can be established. You also can't get incoming connections on your bitcoin node without a publicly routable address.
But.. even if customer of major ISP's are sitting behind a NAT (mostly because all of them are short on IPv4 addresses), most of them do assign you a /64 network of IPv6 addresses.
And with IPv6 (given that both, alice and bob, are sitting behind a NAT and have an IPv6 address) a direct connection is possible again.
In this case a middle-man (doesn't matter whether centralized server or just a 3rd person used for routing) is not necessary.
Is there a way of delivering the data over a simple p2p network - in a decentralised way - much like LN (where you are guaranteed payment for your work - hence more likely to offer your services) ?
The problem is when you are adding the payment option in this design. First you have to decide whether this is a simple file sharing between peers (like Torrent) or is it a file selling between a content creator and his customers.
In either case I don't see any reason why you need a middle man (router) like LN since the file is only held and stored by the owner and nowhere else and he is already uploading it every time someone wants it.
If it is file sharing them it is just a matter of knowing the IP address of the one with the file and connecting to it. Basically P2P Torrent network instead of being a semi-P2P Torrent network (eliminating trackers).
If it is file selling it is the same as before but you only need a way to ensure payment, a multi signature scheme might work here.
There are several decentralized file storage projects: IPFS, FileCoin, Sia, Storj
Yes - but I don't want it stored. And the Miners of those file-coins don't get paid just to forward it.I only want to transfer the file, with proof that the recipient received it, and a mechanism to ensure some payment to the router.
It's not clear why you don't want it stored. The file must be stored somewhere for some length of time, even if temporarily. You can encrypt the file if privacy is the issue.
Proof of receipt is difficult no matter how the file is transferred, but it easy to prove that the file is accessible by the recipient.
The nodes that store the file are effectively the routers and they get paid accordingly.
There are several decentralized file storage projects: IPFS, FileCoin, Sia, Storj
Yes - but I don't want it stored. And the Miners of those file-coins don't get paid just to forward it.
I only want to transfer the file, with proof that the recipient received it, and a mechanism to ensure some payment to the router.
There are several decentralized file storage projects: IPFS, FileCoin, Sia, Storj
Sharing the file is no problem.. under normal circumstances.. I agree.
But all the current methods, for the 99.99% of cases where neither party has access to an external IP or a NAT routeable address.. etc, use a centralised intermediary.
Is there a way of delivering the data over a simple p2p network - in a decentralised way - much like LN (where you are guaranteed payment for your work - hence more likely to offer your services) ?
Thought experiment as much as anything currently usable..
But all the current methods, for the 99.99% of cases where neither party has access to an external IP or a NAT routeable address.. etc, use a centralised intermediary.
Is there a way of delivering the data over a simple p2p network - in a decentralised way - much like LN (where you are guaranteed payment for your work - hence more likely to offer your services) ?
Thought experiment as much as anything currently usable..
May i ask what the use case would be ?
File sharing is nothing extra ordinary which has to be protected in several ways.
One could simply encrypt the file (e.g. asymmetrically or symmetrically with the decryption key being encrypted asymmetrically) and use any form of communication to transfer the file (email, fileserver, p2p network, centralized file hoster, direct TCP connection, etc.. ).
Am i missing something here ?
File sharing is nothing extra ordinary which has to be protected in several ways.
One could simply encrypt the file (e.g. asymmetrically or symmetrically with the decryption key being encrypted asymmetrically) and use any form of communication to transfer the file (email, fileserver, p2p network, centralized file hoster, direct TCP connection, etc.. ).
Am i missing something here ?
Bob wants to send Alice a 1k file.
He is not connected to Alice and must go through Carol.
Carol says she will forward it for some BTC.
Similar to LN but for Data.
--------------------
1)simplest insecure way :
Bob gives the file to Carol. Carol gives it to Alice. Alice signs a message saying she has received it, gives it to Carol. Carol gives the signed message to Bob. Bob pays Carol.
No way for Carol to pretend she has given the file to Alice. No way for Carol to ensure Bob pays her at the end or Alice signs message. Not good.
2) Ramp it up..
Bob gives the file to Carol. Carol gives the hash of the file to Alice. Alice creates a transaction that pays out to Carol, if she provides an input that hashes to the hash of the file. Carol collects the BTC by publishing the 1k file and spending the txn.
Again - not great. Alice pays, though Bob could pre-pay her, and Alice does not know if the file is the original file Bob actually tried to send her.. AND the whole (could be encrypted) file is published on chain. What if the file was 1 MB? (do it 1000 times for 1K.. only works off-chain)
3) Bob signs the hash of the file. Give the file + signature to Carol. Then same as 2..
4).. Some kind of data HTLC ?
All these methods are unsatisfactory..
It must be off-chain compatible (for a success - with drop down to on-chain on cheat ? May not be worth the fee..).
It must be compatible with multiple hops.
How to lock up data, share it, and guarantee payment on successful delivery.. I see it as very similar to LN.. but a little different..
Anyone have any ideas ?
He is not connected to Alice and must go through Carol.
Carol says she will forward it for some BTC.
Similar to LN but for Data.
--------------------
1)simplest insecure way :
Bob gives the file to Carol. Carol gives it to Alice. Alice signs a message saying she has received it, gives it to Carol. Carol gives the signed message to Bob. Bob pays Carol.
No way for Carol to pretend she has given the file to Alice. No way for Carol to ensure Bob pays her at the end or Alice signs message. Not good.
2) Ramp it up..
Bob gives the file to Carol. Carol gives the hash of the file to Alice. Alice creates a transaction that pays out to Carol, if she provides an input that hashes to the hash of the file. Carol collects the BTC by publishing the 1k file and spending the txn.
Again - not great. Alice pays, though Bob could pre-pay her, and Alice does not know if the file is the original file Bob actually tried to send her.. AND the whole (could be encrypted) file is published on chain. What if the file was 1 MB? (do it 1000 times for 1K.. only works off-chain)
3) Bob signs the hash of the file. Give the file + signature to Carol. Then same as 2..
4).. Some kind of data HTLC ?
All these methods are unsatisfactory..
It must be off-chain compatible (for a success - with drop down to on-chain on cheat ? May not be worth the fee..).
It must be compatible with multiple hops.
How to lock up data, share it, and guarantee payment on successful delivery.. I see it as very similar to LN.. but a little different..
Anyone have any ideas ?
Jump to: