Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Directly submit hashes to Bitcoin #14

Open
phptek opened this issue Jun 29, 2018 · 2 comments
Open

Directly submit hashes to Bitcoin #14

phptek opened this issue Jun 29, 2018 · 2 comments
Assignees
Labels
enhancement New feature or request help wanted Extra attention is needed
Milestone

Comments

@phptek
Copy link
Owner

phptek commented Jun 29, 2018

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.

@phptek phptek added enhancement New feature or request help wanted Extra attention is needed labels Jun 29, 2018
@phptek phptek added this to the 1.1 milestone Jun 29, 2018
@phptek phptek modified the milestones: 1.1, 2.0 Jul 17, 2018
@elliot-sawyer
Copy link
Collaborator

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.

@phptek
Copy link
Owner Author

phptek commented Oct 11, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants