Kraken

Proof of Reserves

Audit

Alamin ang tungkol sa proseso ng Kraken sa pag-audit

Proseso ng Proof-of-Reserves Audit ng Kraken  

Introduction

This document provides background and guidance regarding Kraken’s audit process.

Kraken holds full reserves, and we employ an independent, cryptographically-verified audit in order to prove to third parties, including our customers, that customer funds are properly held. Transparency and independently verified audits are critical to ensure that companies hold full reserves of customer funds. A public proof-of-reserve scheme is technically possible to implement. However, there are important externalities, user privacy among them, that must be carefully considered in the specific implementation of a public proof-of-reserve scheme. We believe that exchanges and wallets must build trust through accountability and that we bear a responsibility to address the community's desire for transparency.

Over the past several weeks, Kraken has successfully developed and completed an industry-leading, independent, cryptographically-verified audit. We are proud to submit this overview of our process to the global digital currency community. We believe that the Bitcoin industry is capable of providing a level of assurance and accountability that surpasses the traditional financial services industry, and we aim to lead the charge toward optimal transparency.

Current Landscape

Ang nagtulak sa inisyatibong ito ay ang proposal ni Greg Maxwell na patunayan ng mga exchange/wallet ang kanilang Bitcoin reserves. [1]

Hanggang sa kasalukuyan, ang mga audit na ginawa ng Bitcoin industry ay malabo, mababaw, hindi isinasapubliko at walang independently verifiable na cryptographic verification. Layunin ng Kraken na magbigay ng proof of concept at magtakda ng industry standards para sa mas higit na transparency at pananagutan mula sa digital currency ecosystem na maaaring sundan at mapagbuti ng iba.

Kalidad ng Proseso

Maxwell’s proposal would have required bitcoin companies to reveal all of their balance-containing addresses. This method would result in the public knowledge of exchanges’ or wallet providers’ bitcoin wallets and total holdings, information that is commercially sensitive and presents potential security risks to companies and users. Worse, it would result in an impermissible breach of user privacy, in which the history and trajectory of the individual holdings and financial activity could be tracked by third parties without cause or due process.

Our process does not require us to disclose our total balance, addresses, or keys to the public. By combining and leveraging the strengths of both a trusted auditor and publicly-verifiable cryptography, the Kraken audit represents the ideal balance between privacy and transparency.

Since Bitcoin is the dominant cryptocurrency, our initial audit will cover only Bitcoin reserves. However, audits for other assets will be considered for future development.

Process Overview

  • Phase 1 - Sinusuri ng auditor ang mga pondo ng buong wallet ng Kraken

    Ibinibigay ni Kraken sa auditor lahat ng ating mga public address na may kasamang signature. Ang block hash sa oras na pirmahan ito ay parte ng signed message at maaaring gamiting timestamp kung kailan ginawa ang signature. Ive-verify ng auditor ang mga signature ng mga public address na ito at pagkatapos, gagamitin ng auditor ang bitcoin blockchain upang kunin ang kabuuang halagang maaaring gamitin sa mga addresses na iyon sa isang tiyak na oras.

    Ang code na kinakailangan para sa phase na ito ay isinulat ni Michael Gronager, COO ng Payward, at maaaring maging open source ang kabuuan nito sa hinaharap. Gayunpaman, ang karamihan sa code ay open source na dahil ang code ay libcoin-based. [2]

  • Phase 2 - Sinisiguro ng auditor na ang balanse ng mga Kraken user ay tumutugma sa pondong nasa Kraken wallet

    Ibinibigay ni Kraken sa auditor ang BTC balance ng bawat user at mag-ge-generate ng Merkle tree. Ipa-publish ng auditor ang root node hash para makita ng lahat, at para kumpirmahin, kung totoo, na ang kabuuang hawak na kinakatawan ng root hash ay malapit na tantiya sa halagang nakikita niya sa ating wallet mula sa blockchain. Sinisiguro ng flow na ito na walang anumang itinatago si Kraken sa mga node na humahantong sa root node.

    Para sa phase na ito ng audit, magkakaroon ang auditor ng access sa source code para sa tree-generating program at sa data file na naglalaman ng mga indibidwal na account balance. Inilabas ni Kraken ang C++ code para sa phase na ito sa ilalim ng MIT License: https://github.com/payward/krakendb

  • Phase 3 - Malayang pinapatunayan ng mga user na ang kanilang mga balanse sa account ay kasama sa data na ginamit ng auditor

    Ibinibigay ni Kraken sa mga user ang halaga na naireport sa auditor, kasama na ang mga node (at mga adjacent node) mula sa kanilang account papunta sa root (na tumutugma sa inilabas ng auditor). Isinisiwalat din natin ang hashing method na ginamit upang ma-generate ang hash para sa kanilang node, upang mapatunayan din nila na ang node ay kumakatawan sa halagang sinasabi nating laman nito.

    Ginagawa nitong posible para sa mga user na malayang patunayan na ang kanilang account ay kasama sa data na ginamit at na-verify ng auditor.

Mga Pagkukulang

Sa bahaging ito, inilalarawan namin ang ilan sa kakulangan ng pagsusuri na ito. Tandaan na ito ay hindi isang kumpletong listahan ng mga kahinaan. Gayunpaman, dahil pinahahalagahan namin ang transparency sa aming mga user, kami ay nagbibigay ng impormal na background sa mga tiyak na kahinaan na aming natuklasan sa proseso ng pagsusuri.

Hindi tulad ng mga pisikal na asset, ang impormasyon ay hindi kailangang tanggalin mula sa pag-aari ng isa upang mailipat sa iba. Kaya, ang Kraken o ibang kumpanya na gumagamit ng pamamaraang ito ng pagsusuri ay hindi maaaring patunayan na ang mga private key ay hindi nakopya ng isang attacker. Hindi rin natin mapapatunayan na mayroon kaming eksklusibong pag-aari ng mga nasuring pondo. Mapapatunayan lamang natin na sa oras ng pagsusuri, kami ay isa sa mga nagmamay-ari ng mga private key.

Ang full audit ay maaring hindi maisagawa on-demand nang walang paunang abiso. Dahil sa kinakailangang impormasyon, istraktura ng pag-audit, at security practices ng industry standard ng cold storage, ang isang biglaang pagsusuri sa parehong araw ay hindi maaring maisagawa. Aming naisip ang isang potensyal na 'light' audit building bago isagawa ang full audit, na nagmumula sa mga dati nang na-generate na mga signature, na maaaring mas madalas maisagawa.

Ang auditor ay dapat na mapagkakatiwalaan at may kakayahan. Ang komunidad ay marapat na pinaniniwalaan na pinahahalagahan ng auditor ang kanyang reputasyon at may kakayahang panteknikal. Maraming mga pagkakataon sa proseso ng pagsusuri na maaaring linlangin ng auditee ang isang hindi gaanong teknikal o mas paranoid na auditor. Mayroon ding mga pagkakataon para sa auditor na sadyain o hindi sinasadyang makompromiso ang confidential na impormasyon ng kumpanya at ng customer. Ang auditor at auditee ay dapat isaalang-alang kung sino ang nagbibigay ng computer, ang audit space, blockchain, koneksyon sa Internet, ang router, DNS, atbp. Kung ang layunin ay itago ang isang bilyong dolyar na fraud, tiyak na mahihirapang ma-kompromiso ang audit.

Ang audit ay hindi tuloy-tuloy na nire-renew ng real time. Maaring ang mga key ay nawala o ang pondo ay nanakaw mula sa huling oras ng audit. Ang full audit ay nire-renew ang patunay na ang mga key ay hindi nawawala, ngunit ito ay maaring magdulot ng mas malaking banta sa pagkakalantad dahil kinakailangang magamit ang ang mga cold storage key upang magsagawa ng audit.

Ang auditee ay maaaring humiram ng pansamantalang pondo o ipahiram ang mga key sa tunay na may-ari ng pondo upang makapasa sa audit.

Ang auditor ay maaaring makaipagsabwatan o bumigay sa mga pagbanbanta mula sa auditee.

Patuloy na Batayan

Nilalayon naming patuloy na magsagawa ng regular na pag-audit. Dahil walang universally trusted na auditor, maaari kaming gumamit ng ibang auditor, o maraming mga auditor sa bawat pagkakataon. Sa paraang ito, masisiyahan ang mga taong may pagdududa sa kredensyal ng isang partikular na indibidwal na auditor.

Mga Pagbabago at Pagpapabuti sa Hinaharap

Umaasa kaming makatanggap ng puna mula sa komunidad na makakatulong sa amin at sa iba pa na mapabuti ang prosesong ito para sa mga susunod na pag-audit. Bilang miyembro ng komunidad na ito, umaasa rin kaming makakatrabaho ang mga industry organizations tulad ng DATA (www.datauthority.org) upang makatulong sa pagbuo ng mga basic standard, scalable tools, at isang komprehensibong manual para makagawa ng parehong audit ang iba pang nasa industriya.

References

[1] Buod gawa ni Zak Wilcox: https://iwilcox.me.uk/2014/proving-bitcoin-reserves. Nais naming pasalamatan si Greg Maxwell sa kaniyang mga ideya.

[2] libcoin is the transformation of bitcoin into modular, reusable libraries: https://github.com/libcoin/libcoin

Paano ma-verify ang balanse ng iyong personal na Kraken account sa Kraken audit

Tingnan din ang: Kraken Proof-of-Reserves Audit Process.

Ipinapaliwanag ng mga instruksyong ito kung paano ma-verify cryptographically ang balanse sa iyong Kraken account at kung kasali ba ito sa audit.

Makikita sa verification na ito ang lamang Bitcoin (XBT) ng iyong account sa oras na isinagawa ang pag-audit.

 

  • Step 1

    Kung hindi ka pa naka-log in sa iyong Kraken account, mangyaring mag-log in na.

    Pumunta sa https://www.kraken.com/ at tiyaking ang ipinapakita sa address bar ng iyong browser ay "https://www.kraken.com/"

  • Step 2

    Pindutin ang "Funding" tab -> "Audit" subtab -> "Bitcoin (XBT)" sa kaliwa.

    Figure 1. Kraken Bitcoin Audit page

  • Step 3

    Tingnan ang impormasyon tungkol sa iyong account na pinatunayan ng auditor

    • Ang Oras ng pag-audit, ang siyang timestamp na ginamit ng auditor.

    • Ang Submission code, na isang 64 bit salt.

    • Ang Dami ng Bitcoins na nasa iyong account noong isinagawa ang audit. Ito ang balance value ng iyong account na ibinigay namin sa auditor.

    • Kasama sa Mga Tala ang mga impormasyong mula sa auditor na nagpapatunay sa root hash na ginamit sa pag-audit. Kasama din dito ang isang link sa pirmado at detalyadong ulat.

    • Ang mga Hash mula sa iyong node hash papuntang root hash, pati na mga adjacent hash. Ang mga hash values sa iyong landas ay ipinapakita na may asterisk (*) upang maipakita ang pagkakaiba sa mga adjacent node hash. Gamit ang mga hash na ito, maaari mong makumpirma na ang iyong node ay kasama sa root:

    • Ang pinakaunang linya ay dapat na kapareho ng root hash value na ibinigay ng auditor.

      Kung gusto mong ma-verify ang iyong sariling node hash (ang pinakahuling hash na may * sa listahan), gawin ito:

      sha256(sha256(<submission code> || ":" || <dami ng tinanggalan ng decimal point at nangungunang mga 0's>))

      Ang halagang iyan ay kailangang pareho sa pinakuling halagang na given sa mga hash.

      Halimbawa ng code

      Submission code: 379377cd8190f9bf

      Amount: 0.01500000

      Python

      import hashlib; print(hashlib.sha256(hashlib.sha256(b'379377cd8190f9bf:1500000').digest()).hexdigest());
      

      PHP

      echo hash('sha256', hash('sha256', '379377cd8190f9bf:1500000', true));
      

      Result

      66b51ba0f4a5cf8278acac6782ffdfb9a64b9f7c895bc308266b0757c7025b27
      

      Maaari mong ganap na ma-verify ang iyong Merkle branches sa pamamagitan ng paggawa ng isang hash sa bawat pares ng hash (o “tuple”). Ang format ay:

      sha256(left-hash || right-hash)
      

      Ang resulta ay kailangang pareho sa naunang tuple hash (o sa root hash) na may *. Gagawin ito sa lahat ng tuples.

      Maliban sa root hash, lahat ng hash ay ibinibigay bilang mga tuples, na kumakatawan sa left-hash at right-hash sa ganyang pagkakasunod-sunod. Ang * ay inilalapat sa mga hash na kumakatawan sa iyong direct nodes.

      Halimbawa ng code:

      Hashes:

      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3* c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b* 5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c
      

      Python

      import hashlib; print(hashlib.sha256(b'c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'.decode('hex'))).hexdigest();
      

      PHP

      echo hash('sha256', hex2bin('c3fb1f931c681f4a7b779fb19e107bba156cae78c3a928707c42b395b056541b5e01ee0fee85641dd5cd4e3005792f973a2a1362180783041eb1719163b1d21c'));
      

      Result

      306daae528dc137c9053554c45e90a631ef859490a3ede651d488135602500a3