Re: Chainpoint Community Group Announcement

Adan,

You have no reason to apologize.  You built a technology and you want it
widely adopted.  No one faults you for that.

I appreciate the support for Chainpoint. We've been thinking about how to
make it possible for Stampery style proofs to be generated and validated
using Chainpoint syntax.  The example you sent via email is a good start.
The major technical hurdle is that you've chosen a non-standard way of
constructing Merkle trees; your MerkleMixer
<https://github.com/stampery/elixir-merkle>.  As far as I can tell, the
primary reason is that you can remove the left/right designation in the
proof path, thus allowing you to create a slightly more compact proof.  We
chose to go with standard merkle trees because there are dozens of
libraries on Github for developers to use in a wide variety of languages.
That said, it's entirely possible to create a proof type that accommodates
Stampery's way of building trees.

By the end of the week, we'll post some ideas to Chainpoint Community
Group.  Peter Todd rightly pointed out that several of the things you can
do with Chainpoint aren't as well documented as they could be.

We too want there to be a widely accepted standard.  That's why we started
this process.  I look forward to seeing your proposals.  I see no reason
why we can't incorporate many of your suggestions into a next version of
Chainpoint.

Wayne
----------

[image: Tierion] <http://tierion.com/>

Wayne Vaughan / CEOwayne@tierion.com / 860.836.8633

Tierionhttp://tierion.com

[image: Twitter] <https://twitter.com/waynevaughan> [image: Linkedin]
<https://linkedin.com/in/wayne> [image: skype]
<https://htmlsig.com/skype?username=w.vaughan>

On Wed, Sep 21, 2016 at 12:31 PM, Adán Sánchez de Pedro Crespo <
adan@stampery.co> wrote:

> Hi,
>
> I speak for everyone at Stampery when I say I am very happy to see
> Chainpoint gain traction and media attention.
>
> Wayne, I apologize if any of my prior messages made you to think that I
> somehow disdain all the hard work behind Chainpoint. On the contrary, I
> am strongly betting for Chainpoint as a base for a future standard
> because I am fully aware that it is the result of collecting tons of
> feedback from Tierion's customers and many members of the community.
>
> We at Stampery understand it perfectly because we have gone down the
> exactly same path. We have spent nearly two years building and improving
> our scalable blockchain data anchoring platform (BTA). This has been
> possible thanks to all the valuable feedback we have gathered over this
> lengthy process from our customers and partners (among them,
> multibillion companies like Telefónica [1] and Prosegur [2]).
>
> Counting solely our consumer-oriented solutions (stamp.io, Trailbot and
> our former Gmail plugin), we have anchored more than 100K files, emails
> and datasets during the last year. Moreover, for the last 6 months, we
> have been performing dual blockchain anchoring (Bitcoin + Ethereum), so
> the total number of proofs/receipts delivered to our customers is close
> to 150K. In addition to this amount, there are also many thousands of
> "stamps" made by our customers' production products and services
> directly using Stampery's API through any of our wrappers for NodeJS,
> Ruby, Python, Elixir, Java, and PHP.
>
> I can imagine that Tierion, Blockstack and other relevant players have
> created a similar number of records and also delivered a huge amount of
> proofs/receipts.
>
> In my opinion, it is unacceptable that proofs/receipts generated by all
> these platforms are incompatible, not uniform and impossible to verify
> by using a single test suite.
>
> So, the reason behind all my suggestions is not accommodating Chainpoint
> to Stampery's own technology but tackling some improvements that, based
> on our experience, we believe would worth being discussed for future
> Chainpoint updates. All of them just aim to ensure maximum coverage of
> all the currently existing data anchoring scenarios [3].
>
> I am really happy to hear that Tierion is open to consider the
> aforementioned and other suggestions. Otherwise, what would be the point
> of creating a Chainpoint Community Group? In a standardization process
> like this, I believe there needs to be a continued discussion and
> negotiation between all interested parties. Furthermore, all this should
> be set in a context of mutual acknowledgement without anyone having an
> implicit superiority.
>
> It is important to be as inclusive as possible, to consider all valid
> proposals regardless of who is the proponent and also to try to embrace
> novel approaches (e.g. Peter Todd's recent and outstanding OpenTimestamps).
>
> I think we have a unique opportunity to establish an industry-wide
> standard for proofs/receipts. This is an extraordinary chance to prove
> the maturity of our blockchain technologies in contrast to the
> prevailing noise and nonsense.
>
> Let's bring all the affected parties into the conversation, make them
> join the Chainpoint CG and manifest their commitment to cooperation.
> This is key to the success and adoption of the eventual standard. The
> more parties will get involved, the better proposal we will come up with.
>
> Let's do our utmost to make this standard happen. I am sure it will
> worth it :)
>
> That said, I am starting a thread in the Chainpoint CG with some
> proposals regarding the group mission, methodology, governance and areas
> of work.
> As further proof/receipt format discussion will take place there, I will
> also send another email explaining my suggestions for the standard with
> more detail.
>
> Links:
> [1]  https://en.wikipedia.org/wiki/Telef%C3%B3nica
> [2]  https://en.wikipedia.org/wiki/Prosegur
> [3]  See the "Scenarios to cover" section:
> https://docs.google.com/document/d/1wBnKYxLVE8P7ve-
> 0RIWCWSV3E5LaPcZ4gGLihszpzV4/edit?usp=sharing
>
> Best regards,
>
> --
> Adán Sánchez de Pedro Crespo
> CTO, Stampery Inc.
> San Francisco - Madrid
> T: +34 663 163 375
>
>