aaron-lebo / dissent

Implementation of a decentralized, transferable, and open software license system using the Bitcoin protocol
MIT License
10 stars 0 forks source link

blockchain bloat #2

Open oillio opened 10 years ago

oillio commented 10 years ago

A distributed licensing server is a cool idea, and software security would be a good place to start with implementing smart property. Your solution to proving ownership is interesting. The constant movement of the colored coin would make any attempt at duplication challenging. The obvious issue this causes though is blockchain bloat. You will have a constant stream of transactions for every instance of every game currently running. There are proposals to pare down the blockchain by discarding old transactions, but with the bitcoin blockchain, you need all transactions related to the colored coin to prove chain of custody and ownership.

I don't think namecoin can solve this issue. You could probably solve it in a separate coin and blockchain, but you would need to find a way to incentivize people to mine it. You might be able to solve this by baking the DRMcoin (not a good name) node into the application being licensed and using some sort of proof of stake setup to reduce the processing requirements. This might be interesting as the act of running the application will generate the coins required to pay the transaction fees required to authenticate the application.

Even if you found a solution, the nature of the problem would still require data to propagate across the entire network for every currently running instance of every game using the system. Each running game would be constantly consuming bandwidth and processing power from each node in the network. My hunch is that the cost of running such a network will make it impractical when you scale the bandwidth needs to the level of the Steam install base.

At the end of the day, you still have the problem that the software cannot be authenticated if the computer does not have access to the network. No playing XBox on submarines.

oillio commented 10 years ago

One more point. You will need to protect against fake blockchains. With the way it is currently setup, it would be trivial to replace the namecoin client with a simulation that fakes the network. Your application would need to verify the DRMcoin network it was connected to was sufficiently large enough as to not be faked. This could probably be handled with a verification of a proof of work in the blockchain.

There are a lot of non-trivial problems, and moving parts that would need to fit together just right to make something like this practical.

aaron-lebo commented 10 years ago

Yes, yes, yes. I was looking for exactly this kind of input when I threw this together, and I really appreciate the thought that you put into this.

I agree that there are currently too many problems with a working implementation in any existing cryptocurrency. I did run across colored coins and get how they are designed to meet this need, but like you pointed out, avoiding "duplication" and the resulting issues is the really painful point.

Not only that, but I've learned out ideological people can get about this. Either people don't feel like there should be any copy protection at all or are happy with what exists.

But again, thanks a lot for taking the time to give some input.

On Mon, Jan 6, 2014 at 8:25 PM, Dan Jasek notifications@github.com wrote:

One more point. You will need to protect against fake blockchains. With the way it is currently setup, it would be trivial to replace the namecoin client with a simulation that fakes the network. Your application would need to verify the DRMcoin network it was connected to was sufficiently large enough as to not be faked. This could probably be handled with a verification of a proof of work in the blockchain.

There are a lot of non-trivial problems, and moving parts that would need to fit together just right to make something like this practical.

— Reply to this email directly or view it on GitHubhttps://github.com/aaron-lebo/dissent/issues/2#issuecomment-31708284 .