<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 28 September 2015 at 09:49, Damon Hart-Davis <span dir="ltr"><<a href="mailto:damon@opentrv.uk" target="_blank">damon@opentrv.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
><br>
> In a chat with Viv today (helping us with out business plan, but also a blockchain whiz) the possibility of using a blockchain mechanism to provide at least these two features in the long-term data store came up.<br>
><br>
> I've been trying to understand blockchain to see if we could use it for our own purposes and I can't see how it would be used for that particular use case. If I understand things correctly, blockchain is a distributed ledger where every transaction is signed and all nodes have a full copy of the ledger. I think there are also variations to allow some nodes to only have a partial copy of the ledger.<br>
<br>
</span>The data would be authenticated from node to concentrator and then signed there.<br></blockquote><div><br></div><div>OK, that makes sense. That said, is there a risk of MitM attack between the node and concentrator that could circumvent that or should that be dealt with by the authentication mechanism?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> I'm not sure where this ledger would go: it can't be stored on the sensors nodes as they don't have the capacity for it and even concentrators would be hard pressed to deal with it. That leaves a data platform but doesn't that go against the OpenTRV principle of having something that can work without that data platform?<br>
<br>
</span>The long-term data store would be blockchain.  One copy with the factory/canteen/etc, one with auditors and one with (say) the H&SE.<br>
<br>
This has various neat features about soft real-time alerts, multiple copies off-site and un-tamperable.<br>
<br>
There are some issues of the speed of blockchain operations but there are possible solutions to that such as some simple batching.<br></blockquote><div><br></div><div>OK so that raises other issues about data privacy and differentiated data access. Considering use cases like this:</div><div>1. Customer has buildings in multiple jurisdictions with multiple H&S enforcement agencies,</div><div>2. Customer changes auditors at some point in time,</div><div>3. Some of the data gathered should not be shared with external parties,</div><div>4. Customer leaves one location and moves to another one (they need to have access to historical data at the old location until the date they left for some time after that date, and access to historical and live data at the new location the date they move in).</div><div><br></div><div>This means that you need to make it possible to share different parts of the blockchain with different entities. How would that work?</div><div><br></div><div>Bruno</div><div><br></div></div></div></div>