5 ms·

Subspace: A messaging layer for Bitcoin

27 points by moks 12y ago

davidgerard 12y ago
This is an excellent example of the difference between "interesting" and "useful". This should be every bit as successful in its niche as ssh over DNS (which is a thing you can actually do as well). Seriously, this is a ridiculous stretch to find some use case - any use case! - for Bitcoin. At least there won't be a spam problem, as you need to pay to get your transactions processed at all: https://blockchain.info/unconfirmed-transactions https://blockchain.info/unconfirmed-transactions I wonder if one message would actually cost more than an SMS yet. SMS tends not to wait serious fractions of an hour, though.
- mappu 12y ago
  The system described in the article doesn't use proof-of-work. There's no artificial transmission latency at all. It seems unrelated? to bitcoin aside from being inspired by it and borrowing some terminology. It's a very cool protocol design, clearly a lot of thought has gone into the various tradeoffs, and i hope it sees some uptake.
kubindurion 12y ago
You should take a look at Whisper (independent protocol being developed by Ethereum developers, can be used with Bitcoin). https://github.com/ethereum/wiki/wiki/Whisper-Overview https://github.com/ethereum/wiki/wiki/Whisper-Overview https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol https://github.com/ethereum/wiki/wiki/Whisper https://github.com/ethereum/wiki/wiki/Whisper
chrisdew 12y ago
There may be a problem with the "prefix length" parameter. What the user will want to specify is not the proportion off all messages they want to download, but the number or bandwidth. i.e. If subspace has 1,024 users, I might specify a prefix which lets me download ~128 users messages to find my own. When subspace becomes more popular and has 2^20 users, I don't want to download a thousand times more messages. The prefix needs to be adjustable, or auto-adjusted with regard to the total number of users.

27 points by moks 12y ago

This is an excellent example of the difference between "interesting" and "useful". This should be every bit as successful in its niche as ssh over DNS (which is a thing you can actually do as well). Seriously, this is a ridiculous stretch to find some use case - any use case! - for Bitcoin. At least there won't be a spam problem, as you need to pay to get your transactions processed at all: https://blockchain.info/unconfirmed-transactions https://blockchain.info/unconfirmed-transactions I wonder if one message would actually cost more than an SMS yet. SMS tends not to wait serious fractions of an hour, though.

mappu 12y ago
The system described in the article doesn't use proof-of-work. There's no artificial transmission latency at all. It seems unrelated? to bitcoin aside from being inspired by it and borrowing some terminology. It's a very cool protocol design, clearly a lot of thought has gone into the various tradeoffs, and i hope it sees some uptake.

kubindurion 12y ago

You should take a look at Whisper (independent protocol being developed by Ethereum developers, can be used with Bitcoin). https://github.com/ethereum/wiki/wiki/Whisper-Overview https://github.com/ethereum/wiki/wiki/Whisper-Overview https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol https://github.com/ethereum/wiki/wiki/Whisper-Wire-Protocol https://github.com/ethereum/wiki/wiki/Whisper https://github.com/ethereum/wiki/wiki/Whisper

chrisdew 12y ago

There may be a problem with the "prefix length" parameter. What the user will want to specify is not the proportion off all messages they want to download, but the number or bandwidth. i.e. If subspace has 1,024 users, I might specify a prefix which lets me download ~128 users messages to find my own. When subspace becomes more popular and has 2^20 users, I don't want to download a thousand times more messages. The prefix needs to be adjustable, or auto-adjusted with regard to the total number of users.