Timeline for Security: Creating transactions through downloadable app
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2017 at 20:03 | comment | added | bigpotato | Ideally all user-generated fees are paid on my server so that users aren't deterred from turning their ACs on / off. Given that info, does that mean all my READ / WRITE transactions should be through my server? In terms of security, doesn't that still mean any hacker could just make a billion requests to my AC? i see the security benefits from the user to server side, but from the server to AC it seems just as vulnerable as without blockchain | |
| Nov 24, 2017 at 19:59 | comment | added | natewelch_ | Again, you can leave out the server and have the AC/user create the entry on the blockchain, but then they pay the tx fee | |
| Nov 24, 2017 at 19:57 | comment | added | bigpotato | Hm wouldn't that complicate the architecture? So that means both the server + the AC have to have connection to a node? I guess since the AC is the one making the final operation of turning on / off the device it would make sense... but it seems weird that I have to connect both the server + AC to the node | |
| Nov 24, 2017 at 19:53 | vote | accept | bigpotato | ||
| Nov 24, 2017 at 19:52 | comment | added | natewelch_ | You can run a light client on the AC connected to a reliable node and expect subsecond latency | |
| Nov 24, 2017 at 19:49 | comment | added | bigpotato | Awesome!! However, even with this infrastructure I still have the same concern about how long it would take. So lets say the user has been linked to the AC. If they try to, say, turn on the AC, would that take a long time? When the server performs a READ on the blockchain to see if the user is linked to the AC, is that basically as fast as a SQL operation? | |
| Nov 24, 2017 at 19:46 | comment | added | natewelch_ | Yes, the blockchain is just for authentication in this case. As I said before, you can leave the server just for initial pairing so the user doesn't pay the tx fee. After that you can have the user send messages directly to the AC and the AC can check the blockchain to see if the signer is the owner of the AC | |
| Nov 24, 2017 at 19:43 | comment | added | bigpotato | So in this context, are we just using blockchain for authentication? So after creating the private key / address and linking that to the AC on my server, when the user tries to control the AC through the app, it makes a request to the server, the server checks the blockchain to see if the user is allowed to control that AC, and then either accepts or rejects it. Is that correct? | |
| Nov 24, 2017 at 19:40 | comment | added | natewelch_ | @Edmund Yeah, an actual server. The point of the blockchain isn't to do away with servers, in this context it's to make them no longer hold all the power, e.g. the server can't make your AC do anything unless your private key signs a message telling it to. You could take out the server in this scenario so the AC or user creates the tx linking the user and AC's addresses and the user sends the signed messages directly to the AC, but then the user pays the tx fee for linking. | |
| Nov 24, 2017 at 19:20 | comment | added | bigpotato | Oooo thanks! By "server" do you mean an actual server? Isn't that defeating the point of using blockchain? | |
| Nov 24, 2017 at 18:57 | history | answered | natewelch_ | CC BY-SA 3.0 |