LearnBitcoin

Bitcoin Dev Archive 2015

Virtual Notary.

5 messages, 20 to 25 May 2015. Started by Emin Gün Sirer.

Emin Gün Sirer, Jeff Garzik, Jonas Schnelli, Ben Vulpes, Mike Hearn

Permalink Original thread on gnusha.org

Emin Gün Sirer permalink original

Hi everyone,

Given the recent discussions on projects that use the Bitcoin blockchain to record factoids, people on this list might be interested in the Virtual Notary project. Virtual Notary is essentially an online witness (aka attestor) to online factoids. It can provide:

  * proof of Bitcoin funds (without revealing public addresses or fund
location on the blockchain)
  * proof of Bitcoin address ownership
  * proof of Tweet
  * proof of real estate value
  * proof of DNS ownership
  * proof of existence
  * proof of web page contents
  * proof of weather conditions

The factoids can be recorded on the blockchain (if you pay for the transaction with Bitcoin or PayPal), or they can be part of a free attestation chain that we maintain. The website provides a permanent URL to the factoids it generates; it also provides an X.509 certificate that you can download and keep safe in perpetuity, independent of the website.

The link to the website is here:
  http://virtual-notary.org
The link to the writeup describing the various factoids and their use cases
is here:
  http://hackingdistributed.com/2013/06/20/virtual-notary-intro/

We are actively looking for people who are interested in developing the service further. Specifically, if you have suggestions for how to extend the service, for new proof/factoid types, or for how to build a business case around the core idea, please let us know.

Best, - egs

Jeff Garzik in reply to Emin Gün Sirer permalink original

On Wed, May 20, 2015 at 3:25 AM, Emin Gün Sirer <el33th4x0r@gmail•com> wrote:

Quoted text (14 lines)
> Hi everyone,
>
> Given the recent discussions on projects that use the Bitcoin blockchain
> to record factoids, people on this list might be interested in the Virtual
> Notary project. Virtual Notary is essentially an online witness (aka
> attestor) to online factoids. It can provide:
>
>   * proof of Bitcoin funds (without revealing public addresses or fund
> location on the blockchain)
>
>   * proof of Bitcoin address ownership
>
>   * proof of Tweet
>

For what it's worth, a subsidiary of Dunvegan Space Systems is pursuing exactly this as a business.

EMail JGarzik@DSS•co if you want to know more.

Jonas Schnelli in reply to Emin Gün Sirer permalink original
Quoted text (23 lines)
> * proof of Bitcoin funds (without revealing public addresses or
> fund location on the blockchain)
>
> * proof of Bitcoin address ownership
>
> * proof of Tweet
>
> * proof of real estate value
>
> * proof of DNS ownership
>
> * proof of existence
>
> * proof of web page contents
>
> * proof of weather conditions
>
> The factoids can be recorded on the blockchain (if you pay for the
> transaction with Bitcoin or PayPal), or they can be part of a free
> attestation chain that we maintain. The website provides a
> permanent URL to the factoids it generates; it also provides an
> X.509 certificate that you can download and keep safe in
> perpetuity, independent of the website.

Hi Emin

This is going into the right direction. Well done! The certificates (X.509/p12) are far more enduser-friendly than just a normal PoE hash.

Your site needs some UX love and i just tried to OR_RETURN a Email-Address-Verification. But after creating a 0.0001 tx and waiting for two confirmations it still said that the payment has not yet been received. There is probably something broken regarding the bitcoin payment verification.

The weather and real estate notarization definitively needs a „US only“ badge somewhere.

Two ideas: - - Maybe adding a way of decentralize your notary service log via a opensource p2p daemon (obviously sensitive data should be somehow encrypted)? - - Adding a opensource UI app to examine certs (maybe offline capable with p2p daemon chain as mentioned above). This could prove independence from your website/service.

</jonas>

Ben Vulpes in reply to Jonas Schnelli permalink original

I cannot let http://www.deedbot.org go unmentioned on this thread.

On Friday, May 22, 2015, Jonas Schnelli <dev@jonasschnelli•ch> wrote:

Quoted text (82 lines)
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > * proof of Bitcoin funds (without revealing public addresses or
> > fund location on the blockchain)
> >
> > * proof of Bitcoin address ownership
> >
> > * proof of Tweet
> >
> > * proof of real estate value
> >
> > * proof of DNS ownership
> >
> > * proof of existence
> >
> > * proof of web page contents
> >
> > * proof of weather conditions
> >
> > The factoids can be recorded on the blockchain (if you pay for the
> > transaction with Bitcoin or PayPal), or they can be part of a free
> > attestation chain that we maintain. The website provides a
> > permanent URL to the factoids it generates; it also provides an
> > X.509 certificate that you can download and keep safe in
> > perpetuity, independent of the website.
>
>
> Hi Emin
>
> This is going into the right direction. Well done!
> The certificates (X.509/p12) are far more enduser-friendly than just a
> normal PoE hash.
>
> Your site needs some UX love and i just tried to OR_RETURN a
> Email-Address-Verification. But after creating a 0.0001 tx and waiting
> for two confirmations it still said that the payment has not yet been
> received. There is probably something broken regarding the bitcoin
> payment verification.
>
> The weather and real estate notarization definitively needs a „US
> only“ badge somewhere.
>
> Two ideas:
> - - Maybe adding a way of decentralize your notary service log via a
> opensource p2p daemon (obviously sensitive data should be somehow
> encrypted)?
> - - Adding a opensource UI app to examine certs (maybe offline capable
> with p2p daemon chain as mentioned above). This could prove
> independence from your website/service.
>
> </jonas>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQIcBAEBAgAGBQJVXvAoAAoJECnUvLZBb1PsJpsQAKRYDUTUYA59765w0jbBlK+S
> ArxpaxwPmG7ZLhDYoTHJ/welvXsMSzREZrJNKYl7LBHQBPldeTRQHfHwH05qiwBL
> H5rC+BTyaglud3x7Bxo0fNrXJB4tkfX2ykPJs+2bqPi9OE0uVlXi2Vh/6cV1U/Uq
> RWRfpa19GnSE7IRft5G19FVsG8hrrpuLhzVraAQeZTLyGBKd+hlpjI/qr6TOl8ra
> 5K3bFb2J1+UoaFXLlKCSsSx+9PsydlcJFwnr2H/Z7r1M39j5XYag3Ba6W58ats4z
> 6DCTL1xRVOCTNDbVgkYzZUDCtv5oDspQ2S0nauJLDVz5ADUaZ+bsmBFwseo+XuZV
> TLUxsYfPsqEzUKF2a7ZfMjQG0EUx8oh5DU+o1F5wcBSXDOM+ucdOGYbMrBMV1i9W
> GoPUN1QPkqfUTTRiYYnzP2ySyPUoJqZrcwEB7E7nV8O2xE4Q00zCDlOSqU8aVl7j
> 9lIs/sTpcK5S0kFfc68n6NVlWYU+CBdGlnmvMdbEkydV2P3ft1+THqQ8LNiYRhWX
> 7kHzgG58yUQjvgsOEEb4xTXgA5u4euxBVY+SwKN6cTXA7dWg1s39UEJroaKuXYN5
> iZTj2XkBtD+pwtUPIMs79Kb2/PZRGy7SJui2RbExFX1/8oBbHRV5Ii6+MNw11RNz
> RTV0kHof6+6u1BFYHTFX
> =UmgJ
> -----END PGP SIGNATURE-----
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge•net <javascript:;>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
Mike Hearn in reply to Emin Gün Sirer permalink original

Very nice Emin! This could be very useful as a building block for oracle based services. If only there were opcodes for working with X.509 ;)

I'd suggest at least documenting in the FAQ how to extract the data from the certificate:

openssl pkcs12 -in virtual-notary-cert-stocks-16070.p12 -nodes -passin
pass:"" | openssl x509 -text|less

That's good enough to get started, but I note two issues:

   1. X.509 is kind of annoying to work with: example code in popular
   languages/frameworks to extract the statement would be useful.
   2. The stock price plugin, at least, embeds the data as text inside the
   X.509 certificate. That's also not terribly developer friendly and risks
   parsing errors undermining security schemes built on it.
   The way I'd solve this is to embed either a protocol buffer or DER
   encoded structure inside the extension, so developers can extract the
   notarised data directly, without needing to do any additional parsing.