Hocnet: A competitively decentralized internet using Bitcoins

[ben-abuya]

Has anybody seen this description of Hocnet? It's billed as "A competitively decentralized internet." It seems to be a sort of p2p mesh network where nodes that provide services such as routing are rewarded with payment. Although there's been some discussion on how to do payment, Bitcoin figures prominently in the plans. I think the financial incentive to miners in Bitcoin is one of the major drivers of its success so far, so I believe that the same kind of financial incentive to mesh net operators could be a huge driver of mesh net deployment.

https://docs.google.com/document/d/1osU8vnuOW1eV3hdYMxg8hDh7E6kZLvf05uKvgYAE6SU/edit#heading=h.z59dueh145yu
http://www.reddit.com/r/hocnet

[1714031530]

1714031530

[1714031530]

1714031530

[ElectricMucus]

So this is basically the same thing as Darknetplan from last year?

http://www.reddit.com/r/darknetplan

[ben-abuya]

So this is basically the same thing as Darknetplan from last year?

http://www.reddit.com/r/darknetplan

Good question. It's addressed here:

http://www.reddit.com/r/hocnet/comments/v6tk9/this_subreddits_differences_from_rdarknetplan_a/

tl;dr Hocnet is focused on payment for mesh net services and relies on other elements of darknet type stuff for the actual network technology.

[ElectricMucus]

oh well, that's disappointingly close.

But that's not important. The more important thing is: How many of you can actually write code?

[Serith]

It seems that development stuck on how to implement the payment method because Bitcoin by it self can't accommodate it. Was Rapidly-adjusted (micro)payments considered?

Bitcoin transactions are very cheap relative to traditional payment systems, but still have a cost due to the need for it to be mined and stored. There are some cases in which you want to rapidly and cheaply adjust the amount of money sent to a particular recipient without incurring the cost of a broadcast transaction.
For example, consider an untrusted internet access point, like a WiFi hotspot in a cafe you never visited before. You'd like to pay 0.001 BTC per 10 kilobytes of usage, without opening an account with the cafe. A zero-trust solution means it could be fully automatic, so you could just pre-allocate a budget on your phone's mobile wallet at the start of the month, and then your device automatically negotiates and pays for internet access on demand. The cafe also wants to allow anyone to pay them without the fear of being ripped off.

To do this, a protocol similar to one proposed by hashcoin can be used:

• Request a public key from the access point.
• Create, but do not sign, a transaction (T1) that sets up a payment of (for example) 10 BTC to an output requiring both the access point's public key and one of your own to be used. The value to be used is chosen as an efficiency tradeoff.
• Create, but do not sign, another transaction (T2) that has two outputs, one to the access point's key and another that goes back to you. The initial value is 0.001 BTC to the access point and the rest back to you. Use a sequence number of zero on the input and a lock time in the future (e.g., 1 day).
• Send both unsigned transactions to the access point. It sees that T1 and T2 are of the expected form and signs T2. It hands T2 back to you.
• Check that T2 is signed correctly, sign T1 and T2. Send them to the access point, which broadcasts them, thus locking in the agreement. Note that T2 won't get included into a block for at least one day, unless it's replaced by a newer transaction, as determined by the sequence numbers.
• Each time you want 10kb of data quota, sign a new version of T2 with a higher sequence number, the same lock time, and adjust the outputs so more value is allocated to the access point, and send it. The AP sees that the output sizes are correct, signs it, and keeps it (does not broadcast).

This continues until the session ends, or the 1-day period is getting close to expiry. The AP broadcasts the last transaction it saw, replacing the original that was pending. Once the lock time passes, the value transfer is committed. Alternatively, if the session end is negotiated cleanly, the user can sign a transaction that's final (sequence number of UINT_MAX), which signals that no more data quota will be purchased, allowing instant commitment of the transaction.

The lock time and sequence numbers avoid an attack in which the AP provides connectivity, and then the user double-spends the output back to themselves using the first version of TX2, thus preventing the cafe from claiming the bill. If the user does try this, the TX won't be included right away, giving the access point a window of time in which it can observe the TX broadcast, and then broadcast the last version it saw, overriding the user's attempted double-spend.

This seems like a perfect match, but the method relies on Transaction Replacement feature that is not yet implemented. The last I heard about it was  from this thread: Trustless, instant, off-the-chain Bitcoin payments

Looks like the work boils down to:

a) Writing unit tests
b) Doing work prioritization for tx verification

[fellowtraveler]

--- A decentralized mesh network is a "holy grail" of freedom and an important goal to work towards.

--- Such a network is subject to a "tragedy of the commons" and will fail, until digital cash is used to solve issues of resource allocation. (Mojo Nation would have succeeded here, if they had used Bitcoin for the currency instead of Beenz/Flooz. You haven't actually tried a digital cash solution, unless you actually used real digital cash.)

--- Once digital cash is used to solve issues of resource allocation, then wireless mesh routers will start popping up all over the place, like mushrooms, the same as ATMs do today.

--- The solution is for any Node to relay packets for other nodes UP TO A LIMIT, based on a trust value it assigns to each other node.

--- When a node has earned more trust, then other nodes will forward more packets to it, before reaching their limit and demanding payment. (Whereas nodes with less trust, will have to pay more often.)

--- When the limit is reached, payment should be settled using a transaction server such as Open-Transactions.  (http://open-transactions-tv.github.com/) These servers can run anonymously, for a profit.

--- Once voting pools are added to OT (allowing Bitcoin reserves to be stored safely on the blockchain as multisig transactions, so hackers and transaction servers cannot steal them) then Bitcoins can be used to exchange onto/off-of the transaction servers, and to convert into any other asset type (on markets, on those same transaction servers.)

--- Network nodes should be able to demand payment in any currency type they wish, and should be able to pay for whatever resources they need, all at the protocol level.

When this is set up, the network will grow like an organism.

Again: trust units, eventually settled up on transaction servers, eventually settled up in Bitcoin and other currencies. Bitcoin is an essential part of the protocol, since it enables transaction servers to operate anonymously at a profit, but should not be used directly for the microtransactions themselves, since that is infeasible on the blockchain.

[kwukduck]

A mesh nework of trust assigned nodes sounds really backwards.
Imho the way to go is for no node to trust other nodes. As for routing just depend on capacity, relay times etc.

[fellowtraveler]

A mesh nework of trust assigned nodes sounds really backwards.
Imho the way to go is for no node to trust other nodes. As for routing just depend on capacity, relay times etc.

Correct: a node will start out not trusting any other nodes. Therefore it will not be willing to relay packets unless it receives payment for doing so.
And the more it is able to trust any given node to provide that payment, the more packets it will be able to relay before demanding it.
If the protocol is not designed to handle this, then the network will suffer from a "tragedy of the commons" when it could instead be growing like an organism (once digital cash is used to solve issues of resource allocation.)

[unclemantis]

So how do we sign up!?

[ben-abuya]

--- The solution is for any Node to relay packets for other nodes UP TO A LIMIT, based on a trust value it assigns to each other node.

I think this is unavoidable. Unless you know you'll be relaying a lot of packets through a specific node (in which case you could just pre-pay that node), there will have to be trust between nodes.  Doing an online transaction for relaying a single packet, which in itself would require an online transaction, doesn't make sense.

Naturally having a distributed trust and reputation system would be very helpful here.

[teknomunk]

Another option is to treat bitcoin transactions separately from normal traffic.  Something like deep packet inspection or IPv6 link local addresses and having a lightweight bitcoin peer running on each node should allow for payments even when there is no other traffic routed.  Though I agree that for small amounts of traffic, it may be more hassle for both parties.

[byronbb]

I was thinking of a youtube/music/porn site where users install an extension linked to a bitcoin wallet. As long as their wallet is > 0 then they have access to the site. Imagine youtube where you pay a fractional amount to view the video and the content owner gets paid. Plus no infuriating ads.

[Littleshop]

If they make it run on open-mesh hardware like the open-mesh MR3201 I have at least 20 of those laying around.  I would love to put them into use with good software. 

[unclemantis]

Has this service been made yet?

[ben-abuya]

Has this service been made yet?

No, I believe it's still in early planning stages.