Re: Chainpoint Community Group Announcement

Mountie,

Here's a quick but incomplete answer:

Each private blockchain will likely have it's own method.  We plan on
adding a URI anchor type to a future version of Chainpoint.  This would
allow you to publish the anchor to IPFS, Twitter, AWS S3 or anywhere else
you want.  When combined with anchoring data in to a POW chain (Bitcoin),
you can get strong assurance that the integrity of your data can be
verified.  The key is to anchor into multiple sources so you don't have a
single point of failure.

I agree with you that you want to be able to anchor data and impose the
minimal externality onto the chain.  In the case of Bitcoin, one of the
historical points of contention has been the UTXO pool. Bottom-line: miners
will start to filter transactions or demand high transaction fees if
everyone increases the load on the blockchain. There is no free lunch!

It's possible to construct an anchor into Bitcoin that can be verified
against the block header. Peter Todd has done this with OpenTimeStamps.
We're testing additional anchor types with 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 1:12 PM, Mountie Lee <mountie@paygate.net> wrote:

> Hi.
>
> thanks for your mail.
>
> could you switch document mode you attached
> to allowing comments?
>
> here some questions
>
> how to cover or handle private chains?
> many groups are trying to handle blockchain privately with reduced
> difficulties.
> even some private chains has very low trust than the public chains.
> actually can not define it is blockchain.
> who and how define chainID?
>
> some groups are not trying to load data on OP_RETURN script to reduce or
> postpone the tx fee to consumer side(meaning putting data on input script).
> who and how define anchor type?
>
> regards
> mountie.
>
> 2016년 9월 21일 (수) 오후 5:32, Adán Sánchez de Pedro Crespo <adan@stampery.co>님이
> 작성:
>
>> 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
>>
>>
>>