Author

Topic: Using bitcoin for software activation (Read 1319 times)

legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
February 27, 2013, 08:17:11 AM
#11
I'm going to leave off with, I think that if it doesn’t cost any perpetual resources, customers shouldn't have to fork out money in a perpetual manner, however if there is on going costs for the service/product then it should cost. In my opinion it only seems right to give out free open source client stuff (even though it may cost in time/electricity) and to only charge for the services that the client/servers provide. However I will admit not every model could benefit from this, like single player games, photoshop, after effects(Unless of course they allow you to use their (theoretical) services/servers for "cloud rendering" and allow photo shop tools to be open and free... Hmmmmm.... )
legendary
Activity: 1022
Merit: 1033
February 27, 2013, 08:08:10 AM
#10
Software connects to internet again asks for "total" received balance from multiple servers.
Software unlocks software by decryption
Hackers just save the decryption key and replay and distribute at will.

Well, protocol outlined by OP is kinda defective, but it is possible to make a good protocol using smart property:

The seller of the software will send a coin representing smart property ownership to customer's wallet. (Obviously, wallet needs to be smart property-aware.)

Software will then need to communicate with that wallet, requesting proof of ownership of a private key smart property was sent to.

It will check such proof periodically.

Suppose hackers copy private key... If private key isn't secret anymore, anybody can transfer this coin from it, and software licensing module can detect this.

So we have three advantages compared to system we have now:

1. There is no activation server, software will work as long as bitcoin blockchain is alive.
2. One can sell software, simply transfering smart-property coin to buyer's wallet.
3. There is a strong incentive NOT to share your private key with anybody you do not trust. E.g. you can install software on 10 computers within your organization, but if you post key on forum you'll lose your software.

Companies can further discourage piracy by offering trade-in: customer will return an old smartproperty to get discount on new version.

Of course, one might hack by patching a binary...

But, honestly, I don't think that smart property-based software activation is better than monthly membership model like this: http://www.adobe.com/products/creativecloud.html

Company can get a steady stream of revenue, and customer pays only as long as it uses this software.

Bitcoin isn't particularly relevant for monthly membership, it is just a payment system like any other.
legendary
Activity: 2618
Merit: 1007
February 27, 2013, 08:06:57 AM
#9
It might work for a "Kickstarter" style software release though:

Everybody can download the software, encrypted with the same key.
As soon as at least xxx BTC are in address yyy, these are transferred to a vanilla (previously unknown) address which is the key to unlock the software. No activation servers needed.

Might also work for something like "I'll make the program OpenSource for XXX BTC".
legendary
Activity: 980
Merit: 1003
I'm not just any shaman, I'm a Sha256man
February 27, 2013, 07:47:18 AM
#8
In retrospect it sounds like:
Now:
We buy software.
Submit a "unlock" code.
Software decides weather it needs to the internet for activation or not at all or must connect online every X interval,etc

In the future
We download software.
Software connects to internet asks for BTC address from the central server.
User "pays" for requested amount.
Software connects to internet again asks for "total" received balance from multiple servers.
Software unlocks software by decryption
Hackers just save the decryption key and replay and distribute at will.
legendary
Activity: 1022
Merit: 1033
February 27, 2013, 04:00:22 AM
#7
Then you would receive from that bitcoin address of the owner 8 digits - as satoshis - that would be the counter-part key that would enable you to unlock/activate the product.

Check this: https://en.bitcoin.it/wiki/Smart_Property

Quote
Ideally, it could not be known/hacked in advance on the client side.

Well, there is no defense against software patch.
legendary
Activity: 2618
Merit: 1007
February 26, 2013, 09:20:15 AM
#6
All in all, it will be something like "check if transaction X exists, if true: do something". This can be edited to: "check if 1==1, if true: do something"

If you actually distribute software that is uniquely encrypted (every download is different), it takes only 1 paying customer who distributes the unencrypted version and you have the same problem.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
February 26, 2013, 09:10:07 AM
#5
It's highly unlikely that iOS, OS X, Windows, Microsoft Office, Photoshop, and other proprietary software is going to entirely go away anytime soon.

Realistically at the moment I'd have to agree, however, it has also been amazing to watch just how much "open source" has grown in size and scope since it's humble beginnings (and although many on this forum might not like SUSE as a distro I think that SUSE Studio is one of the most innovative platforms that I've seen appear in recent years).

Personally I think it will end up being an unstoppable tide though as more and more projects (like my own humble one) simply could not work if developers (and of course consumers) are forced to pay license fees for effectively every major component that is used to create a large software package (and the closed source model ends up consuming itself as the bigger players swallow up the smaller ones to stop just those sort of licensing problems which then leads to ugly things like anti-trust suits and the smaller players get screwed out of business altogether).

It may take several more years before open source *overtakes* closed source but once that occurs I don't think there will be any *going back*.
member
Activity: 84
Merit: 10
Weighted companion cube
February 26, 2013, 08:42:38 AM
#4
I guess it could work, however, will we actually need *activation* codes once everyone has finally woken up (from the "closed source is better" induced marketing mantra that has kept so many asleep) to that fact that the only *trustworthy* software is *open source* software?

It's highly unlikely that iOS, OS X, Windows, Microsoft Office, Photoshop, and other proprietary software is going to entirely go away anytime soon.

The problem with this idea is that it relies on the value of one bitcoin being a less than the price of the software activation. You can't sell an activation key for the equivalent of $10 for example, and it sounds really unnecessary.
legendary
Activity: 1106
Merit: 1001
February 26, 2013, 08:03:51 AM
#3
I am pretty sure this was discussed in great detail back in 2011... but don't have the time to search for the actual thread right now.
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
February 26, 2013, 05:39:05 AM
#2
I guess it could work, however, will we actually need *activation* codes once everyone has finally woken up (from the "closed source is better" induced marketing mantra that has kept so many asleep) to that fact that the only *trustworthy* software is *open source* software?
legendary
Activity: 1122
Merit: 1017
ASMR El Salvador
February 26, 2013, 05:24:13 AM
#1
The software would provide you with a 8 digits key from a pair. You would have to send that 8 digits - as satoshis - to the owner of the software to receive the couterpart key of the pair, that would be also 8 digits.
The owner of the software would receive the payment in bitcoins and the satoshis would be used to send the key to the software owner bitcoin address. Then you would receive from that bitcoin address of the owner 8 digits - as satoshis - that would be the counter-part key that would enable you to unlock/activate the product. The binding algorithm would involve what time it was and also the specific bitcoin address from which the client/user was sending the request. Ideally, it could not be known/hacked in advance on the client side.

My reasoning seems to be faulty at some point... but here you go.  Cool
Jump to: