You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a user, I would like to push my verification hashes directly to the Bitcoin network, so that I know no intermediary has messed with my hashes.
Implement logic that allows a local Bitcoind or Geth node to be queried and written-to directly. It is not clear at this stage if this would be for "one-off" notarisation events from within the admin area or programmatically, or for bulk hash submission to the blockchain network. If the latter case, an intermediary step of Merkle Tree creation and root-hash submission would need to feature - lest the user need to pay exhorbitant TX fees for anchoring hashed data to the blockchain.
The text was updated successfully, but these errors were encountered:
I'm working on a page type that will embed a SHA3 hash in the OP_RETURN field of a Bitcoin transaction. However, every approach I've come across to issue those transactions is "server-pays" - the server has to host a hot wallet and spend small amounts of currency to get them on the network. Aside from being a security risk, the CMS user (or a customer) wishing to pay for verification is unable to do so with their own funds. Proof of Existence (poex.io) does manage to create a user-pays approach to fund themselves, so it's definitely possible. Once I have something to show I'll see if I can integrate it into verifiable.
One quick-and-dirty way of doing bulk transaction without a full Merkle tree is to hash all of the files into a single result: sha3(sha3(file1)+sha3(file2)+sha3(file3)). Say a customer generates an order containing three documents, all of which they've paid to have verified on a single transaction. The receipt would show all three individual hashes of their file, the resulting SHA3 hash that was embedded in the blockchain, and a link to the transaction where they can inspect it.
Interesting. For the latter point viz quick-and-dirty: The module's API is already there for developers to use and certainly what is there already could easily support the multi-document hash approach via a custom verify() method. In short: I'm unconvinced any core changes are required, besides perhaps unbundling verification logic from write() logic (See #35)
You raise an interesting side-issue / idea in the use of verifying bulk-publication, perhaps using SilverStripe's Campaign functionality.
As a user, I would like to push my verification hashes directly to the Bitcoin network, so that I know no intermediary has messed with my hashes.
Implement logic that allows a local Bitcoind or Geth node to be queried and written-to directly. It is not clear at this stage if this would be for "one-off" notarisation events from within the admin area or programmatically, or for bulk hash submission to the blockchain network. If the latter case, an intermediary step of Merkle Tree creation and root-hash submission would need to feature - lest the user need to pay exhorbitant TX fees for anchoring hashed data to the blockchain.
The text was updated successfully, but these errors were encountered: