[DOC] Translation some files in doc dir.

doc/grin4bitcoiners.md

@@ -1,5 +1,7 @@
 # Grin/MimbleWimble for Bitcoiners
 
+*Read this in other languages:[Korean](grin4bitcoiners_KR.md)
+
 ## Privacy and Fungibility
 
 There are 3 main properties of Grin transactions that make them private:
@@ -39,7 +41,7 @@ Bitcoin's 10 minute block time has its initial 50 btc reward cut in half every 4
 
 Nope, no address. All outputs in Grin are unique and have no common data with any previous output. Instead of relying on a known address to send money, transactions have to be built interactively, with two (or more) wallets exchanging data with one another. This interaction **does not require both parties to be online at the same time**. Practically speaking, there are many ways for two programs to interact privately and securely. This interaction could even take place over email or Signal (or carrier pigeons).
 
-### If transaction information gets removed, can't I just cheat and create money?
+### If transaction information gets removed, can I just cheat and create money?
 
 No, and this is where MimbleWimble and Grin shine. Confidential transactions are a form of [homomorphic encryption](https://en.wikipedia.org/wiki/Homomorphic_encryption). Without revealing any amount, Grin can verify that the sum of all transaction inputs equal the sum of transaction outputs, plus the fee. Going even further, comparing the sum of all money created by mining with the total sum of money that's being held, Grin nodes can check the correctness of the total money supply.
 

doc/grin4bitcoiners_KR.md

@@ -0,0 +1,58 @@
+# Bitcoiner를 위한 Grin/MimbleWimble
+
+## 프라이버시와 대체가능성(Fungibility)
+
+Grin 트랜잭션에는 트랜잭션을 프라이빗하게 만드는 3 가지 주요 속성이 있습니다.
+
+1. 주소가 없습니다.
+2. 금액은 없습니다.
+3. 하나는 다른 트랜잭션을 사용하는 2 개의 트랜잭션을 하나의 블록으로 병합하여 모든 중간 정보를 제거 할 수 있습니다.
+
+처음두 가지 속성은 모든 트랜잭션을 서로 구별 할 수 없음을 의미합니다. 거래에 직접 참여하지 않는 한 모든 입력과 출력은 임의의 데이터 조각처럼 보입니다 (말하자면 출력값과 입력값 모두 랜덤한 곡선 위의 점입니다).
+
+또한 블록에 트랜잭션이 없습니다. Grin 블록은 마치 하나의 거대한 트랜잭션처럼 보이고 입력과 출력 사이의 모든 연관성이 사라집니다.
+
+## 확장성(Scalability)
+
+이전 섹션에서 설명한 것처럼 MimbleWimble 트랜잭션과 블록 포맷 때문에 출력이 다른 트랜잭션의 입력에 의해 직접 소비(spent) 될 때 트랜잭션을 합칠 수 있습니다. (예를 들어 - 문맥의 부드러움을 위해 첨가함, 역자 주 )앨리스가 밥에게 돈을 주고 밥이 캐럴에게 돈을 주면 밥은 결코 연관되지 않은것처럼 보이고 실제로 밥의 트랜잭션은 블록체인에서 보이지 않습니다.
+
+더 많은 트랜잭션들을 블록에 밀어 넣으면 대부분의 출력이 다른 입력에 의해 조만간 소비됩니다. 따라서 *모든 소비 출력값을(spent outputs) 안전하게 제거 할 수 있습니다*. 그리고 (bitcoin과 유사한 트랜잭션의 수를 가정 한다면)몇 GB 이하로 전체 블록 체인을 저장하고, 다운로드하고, 완벽하게 검증 할 수 있습니다.
+
+즉, Grin 블록 체인은 트랜잭션 수가 아닌 사용자 수 (사용되지 않은 출력)에 따라 확장됩니다. 그러나 현재 하나 주의하자면 (kernel 이라고 불리는 약 100 바이트의 데이터) 작은 데이터 조각은 각 트랜잭션마다 기다릴 필요가 있습니다. 그러나 이를 최적화하기 위해 노력하고 있습니다.
+
+## 스크립팅(Scripting)
+
+아마도 MimbleWimble은 스크립트(Script)를 지원하지 않는다는 말을 들었을 겁니다. 어떤면에서 이 말은 사실입니다. 그러나 암호화 기법 덕분에 Bitcoin에서 스크립트를 필요로 하는 많은 계약은 Elliptic Curve Cryptography의 속성을 사용하여 Grin으로 작성 할 수 있습니다. 지금까지 아래와 같은 구현을 어떻게 하는지 하는지 알고 있습니다. :
+
+* Multi-signature transactions.
+* 아토믹 스왑 (Atomic swap).
+* Time-locked transactions and outputs.
+* 라이트닝 네트워크 (Lightning Network)
+
+## 블록 생성주기와 블록 보상비율
+
+비트코인(Bitcoin)은 처음에 10분마다 50개의 btc를 제공했고 2100만 비트코인이 유통 될 때까지 4 년마다 블록 보상이 반으로 줄어듭니다. Grin의 블록 보상율은 선형적이며(Linear) 블록 보샹율은 떨어지지 않습니다.( 계속 60GRN/block의 비율을 유지한다는 의미 - 역자 주) Grin의 블록 보상은 현재 60 초마다 블록을 생성하고 블록당 60개의 Grin을 받도록 세팅되어 있습니다. 이는 ​다음과 같은 두가지 이유로 인해 효과가 있습니다. 1) (코인의) 가치저하가 0에 가까우며 2) 매년 무시할 수 없는 양의 동전이 매년 분실되거나 파괴되기 때문입니다 (코인을 계속 사용한다면 코인의 가치저하는 없으며 비트코인처럼 많은 양의 코인이 분실되거나 없어지기 때문에 상기 2가지 이유를 말한것 같음 - 역자 주).
+
+## FAQ
+
+### 잠시만요 뭐라구요? 주소가 없다구요?
+
+네, 주소가 없습니다. Grin의 모든 출력은 유니크 하고 이전 출력과 공통된 데이터가 없습니다. 알려진 주소를 사용하여 돈을 송금하는 대신 두 개 이상의 지갑(주소)이 서로 데이터를 교환하면서 대화식으로 트랜잭션을 만들어야만 합니다. **이 인터렉션에서는 서로 동시에 온라인 상태일 필요는 없습니다**. 실제로 두 프로그램이 프라이빗 하고 안전하게 인터렉션 할 수 있는 방법은 다양합니다. 이 인터렉션은 이메일이나 시그널 (또는 전보 전달 비둘기)을 통해 일어날 수도 있습니다.
+
+### 트랜잭션 정보가 제거된다면 사기는 치거나 코인을 만들어 낼수 있지 않나요?
+
+아니요, MimbleWimble과 Grin의 장점이 돋보이는것이 바로 이런 점 입니다. Confidential transaction은 [동형(homomorphic)암호](https://en.wikipedia.org/wiki/Homomophic_encryption)의 한 형태입니다. 금액을 드러내지 않고 Grin은 모든 거래의 입력값의 합계가 거래의 출력값의 합계 + 수수료를 합한 것과 일치하는지 확인이 가능합니다. 더해서 마이닝으로 만들어진 모든 코인의 합계와 보유하고 있는 총 금액과 비교하여, Grin노드는 코인의 모두 얼마나 공급  되었는지 그 정확성을 확인할 수 있습니다.
+
+### 만약 트랜잭션 릴레이를 받는다면 컷 쓰루 전에는(cut-through) 누구에게 트랜잭션이 속하는지 알 수 없지 않나요?
+
+어떤 거래에 의해서 어떤 출력값을 소비하고 있는지 알 수 있지만 여기서 데이터의 흔적이 멈춥니다. 모든 입력과 출력은 임의의 데이터 조각처럼 보이므로 돈이 전송되었는지, 여전히 같은 사람에게 속해 있는지, 어떤 출력값이 실제로 전송했는지,  어떤것이 변경되었는지 등은 알 수 없습니다. Grin 트랜잭션들은 *식별 할 수있는 정보가 없습니다*.
+
+또한, Grin은 [Dandelion relay](dandelion/dandelion_KR.md)를 활용하여 트랜잭션이 발생한 IP 또는 클라이언트에 대한 추가적인 익명성을 제공하고 트랜잭션을 합칠 수 있습니다.
+
+### 퀀텀 컴퓨타게돈(compute + armageddon) 에 대해서 궁금해요.
+
+모든 Grin 출력값에는 해싱된 퀀텀 세이프 데이터가 포함되어 있습니다. 양자 컴퓨팅이 현실화되더라도, 기존 동전을 해킹하지 못하게 하는 추가 검증을 안전하게 도입 할 수 있습니다.
+
+### 어떻게 이 모든일이 가능한거죠?
+
+이와 관련해서는 [technical introduction](intro_KR.md)문서를 참조하세요.

doc/merkle.md

@@ -1,5 +1,7 @@
 # Merkle Structures
 
+*Read this in other languages:[Korean](merkle_KR.md)
+
 MimbleWimble is designed for users to verify the state of the system given
 only pruned data. To achieve this goal, all transaction data is committed
 to the blockchain by means of Merkle trees which should support efficient

doc/merkle_KR.md

@@ -0,0 +1,113 @@
+# 머클의 구조
+
+MimbleWimble은 Pruning 데이터만 있는 시스템의 상태를 사용자가 증명하도록 설계되었습니다. 이러한 목표를 달성하기 위해 모든 트랜잭션 데이터는 pruning 된 경우라도 효율적인 업데이트와 serialization을 지원하는 Merkle 트리를 사용하여 블록 체인에 커밋됩니다.
+
+또한 거의 모든 거래 데이터 (입력, 출력, Excess 및 Excess proof)는 어떤 방식으로 합산 될 수 있으므로 Merkle sum 트리를 기본 옵션으로 처리하고 여기에서 합계를 처리하는 것이 좋습니다.
+
+Grin의 디자인 목표는 모든 구조를 구현하기 쉽고 가능한 한 간단하게 만드는 것입니다.
+MimbleWimble은 많은 새로운 암호화 방식을 내 놓았고 이러한 방식을 가능한 한 쉽게 이해할 수 있도록 만들어야합니다.
+새로운 암호화 방식의 입증 규칙은 스크립트가 없이도 구체화 하기 쉽고 Grin은 매우 명확한 의미론을 가진 프로그래밍 언어로 작성되기 때문에 단순함은 잘 알려진 컨센서스 룰을 달성하는 것에도 좋습니다.
+
+## Merkle Trees
+
+각 블록마다 4가지의 머클 트리가 커밋됩니다.
+
+### Total Output Set
+
+각 오브젝트는 uspent output 을 나타내는 commitment 또는 spent를 나타내는 NULL 마커 두 가지 중 하나입니다. Unspent 출력에 대한 sum-tree 입니다 (Spent 된 것은 합계에 아무런 영향을 미치지 않습니다). output 세트는 현재 블록이 적용된 *후에* 체인 의 상태를 반영해야합니다.
+
+Root 합계는 제네시스 블록 이후 모든 Excess의 합계와 같아야합니다.
+
+설계 요구 사항은 아래와 같습니다.
+
+1. 효율적으로 추가 되어야 하고 및 unspent 에서 spent 로 업데이트가 되어야 합니다.
+2. 특정 출력값이 Spent 임을 효율적으로 증명해야 합니다.
+3. UTXO root간에 diffs를 효율적으로 저장합니다.
+4. 수백만 개의 항목이 있거나 누락된 데이터가 있는 경우에도 트리에 효율적으로 저장되어야 합니다.
+5. 노드가 NULL로 커밋되는 경우에는 unspent 하위 항목이 없고 그 데이터를 결과적으로 영구히 삭제할 수 있게 합니다.
+6. 부분 아카이브 노드에서 Pruning된 트리의 serializtion 및 효율적인 병합을 지원합니다.
+
+### Output의 증거
+
+이 트리는 전체 출력 set을 반영하지만 commitment 대신 range proof를 가집니다. 이 트리는 절대 업데이트 되지 않고, 단지 추가되고, 어떤 것이든 더이상 더하지 않습니다. 출력을 소비 할 때 Tree를 삭제하는 것보다는 tree 에서 rangeproof를 삭제하는 것으로 충분합니다.
+
+설계 요구 사항은 아래와 같습니다.
+
+1. 부분 아카이브 노드에서 Pruning 된 트리의 serializtion 과 효율적인 병합을 지원해야 합니다.
+
+### 입력과 출력
+
+각 객체는 입력 (이전 트랜잭션 출력에 대한 명확한 레퍼런스) 또는 출력 (commitment, rangeproof) 중 하나입니다. 이 sum-tree는 출력에 대한 commitment이고 입력의 commitment에 대한 원본입니다.
+
+입력 레퍼런스는 이전 commitment의 해시입니다. 모든 unspent 출력은 유니크 해야한다는 것이 컨센서스의 규착입니다.
+
+Root 합계는 이 블록의 Excess 합계와 같아야 합니다. 이에 대해 다음 섹션을 참고하세요.
+
+일반적으로 밸리데이터는 이 Merkle 트리의 100 % 또는 0 %를 확인 할 수 있으므로 모든 디자인과 호환됩니다.
+설계 요구 사항은 다음과 같습니다 :
+
+1. Proof of publication을 위해서 증명을 효율적으로 포함해야 합니다.
+
+### Excesses
+
+각 객체는 (초과, 서명) 형식입니다. 이러한 객체는 Excess를 합친 sum-tree 입니다.
+
+일반적으로 밸리데이터는 항상 이 트리의 100 %를 확인 할 것이므로 Merkle 구조일 필요가 전혀 없습니다. 그러나 나중에 부분 아카이브 노드를 지원하기 위해 효율적인 Pruning을 지원하기를 원합니다.
+
+설계 요구 사항 은 아래와 같습니다. :
+
+1. 부분 아카이브 노드에서 pruning 된 tree의 serialzatoin 과 효율적인 병합을 지원해야 합니다.
+
+## 제안된 Merkle 구조
+
+**모든 tree에 대해 다음과 같은 설계가 제안됩니다. Sum-MMR은 모든 노드가 합계에 포함될 데이터 와 자식수의 합계입니다.
+결과적으로 모든 노드가 모든 하위 노드의 수로 커밋됩니다.**
+
+[MMRs, or Merkle Mountain Ranges](https://github.com/opentimestamps/opentimestamps-server/blob/master/doc/merkle-mountain-range.md)
+
+출력값 세트를 위해서 6개의 디자인 원칙은 다음과 같습니다.
+
+### 효율적인 insert/updates
+
+즉시적이여야 합니다. (지금은 proof-of-inclusion입니다.). 이 원칙은 균형 잡힌 Merkle tree 디자인에 합당합니다.
+
+### 효율적인 proof-of-spentness
+
+Grin은 proof of spentness가 필요하지 않지만 SPV client 을 위해 앞으로 지원하는 것이 좋습니다.
+
+자식의 수는 tree의 각 개체에 대한 인덱스를 의미합니다. 삽입은 트리의 맨 오른쪽에서만 발생하므로 변경되지 않습니다.
+
+이렇게하면 동일한 출력이 나중에 트리에 추가 되더라도 영구적으로 proof-of-spentness를 허용하고 동일한 출력에 대해서도 오류 잘못된 증명에 대해서도 방지 할 수 있습니다. 이러한 속성은 삽입 순서가 지정되지 않은 tree에서는 하기 어렵습니다.
+
+### 효율적인 diffs의 저장
+
+모든 블록을 저장하면 충분합니다. 업데이트는 실행 취소만큼 수월하고, 블록은 항상 순서대로 처리되기 때문에 트리의 오른쪽에서 인접한 출력 세트를 제거하는 것과 만큼 reorg를 하는 동안 블록을 되감는 것이 간단합니다. 삭제를 지원하도록 설계된 트리의 반복 삭제보다 훨씬 빠릅니다.
+
+### 데이터가 손실되는 상황에서도 효율적인 tree의 저장
+
+랜덤한 결과가 소비되었을 때 root 해시를 업데이트하려면 전체 tree를 저장하거나 계산할 필요가 없습니다. 대신 depth 20에 해시 만 저장할 수 있습니다. 쉽세 말하자면 최대 100 만개가 저장됩니다. 그런 다음 각 업데이트는 이 depth보다 위의 해시를 다시 계산하면됩니다 (Bitcoin의 히스토리에는 2 ^ 29 미만의 출력이 있으므로 각 업데이트에 대해 크기가 2 ^ 9 = 512 인 트리를 계산해야 함). 모든 업데이트가 완료되면 root 해시를 다시 계산할 수 있습니다.
+
+이 깊이는 설정 할 수 있고 출력 set가 증가하거나 사용 가능한 디스크 공간에 따라 변경 될 수 있습니다.
+
+이런 과정은 어느 Merkle 트리에서 가능하지만 깊이를 어떻게 계산하느냐에 따라 PATRICIA tree 나 다른 prefix tree로 인해 복잡 할 수 있습니다.
+
+### 사용된 코인 지우기
+
+코인은 spent 에서 unspent로 이동하지 않으므로 spent 된 코인에 대한 데이터는 더 이상 업데이트나 검색를 위해 필요하지 않습니다.
+
+### Pruning 된 tree 의 효율적인 Serialization
+
+모든 노드는 자식 수를 가지므로 밸리데이터는 모든 해시가 없이도 tree 구조를 결정할 수 있으며 형제 노드를 결정할 수 있습니다.
+
+출력 세트에서 각 노드는 unspent한 자식의 합계도 커밋하므로 밸리데이터는 pruning 된 노드에서 합계가 0인지 여부를 반드시 확인을 하기에 unspent 된 코인의 데이터가 누락되더라도 알게 됩니다.
+
+## Algorithms
+
+구현체로서 함께 표시됩니다.
+( 소스코드를 참고하라는 의미 - 역자 주 )
+
+## Storage
+
+합계 tree 데이터 구조를 사용하면 출력 set과 출력 증거를 효율적으로 저장하면서 root 해시 또는 root 합계 (해당되는 경우)를 즉시 검색 할 수 있습니다. 그러나 tree는 시스템에 모든 출력 commitment 와 증거 해시를 포함해야합니다. 이 데이터는 너무 커서 pruning을 고려하더라도 메모리에 영구적으로 저장 될 수 없으며 재시작 할 때마다 처음부터 다시 작성하기에는 비용이 큽니다. (이런 경우에 Bitcoin이 UTXO당 2개의 해시를 가진다고 가정하면 적어도 3.2GB의 용량을 필요로 하는 50M UTXO가 있습니다.). 따라서 이 데이터 구조를 디스크에 저장하는 효율적인 방법이 필요합니다.
+
+해시 트리의 또 다른 한계는 키 (즉, 출력 commitment)가 주어지면, 그 키와 연관된 tree에서 리프노드를 발견하는 것이 불가능합니다. 그래서 root에서 tree로 찾아 내려 갈 수 없습니다. 따라서 전체 키에 대한 추가 인덱스가 필요합니다. MMR은 append 전용 바이너리 tree이므로 삽입 위치를 기준으로 tree에서 키를 찾을 수 있습니다. 따라서 tree에 삽입 된 키의 전체 인덱스 (즉, 출력 commitment)의 삽입 포지션 또한 필요합니다.

doc/mmr.md

@@ -1,5 +1,7 @@
 # Merkle Mountain Ranges
 
+*Read this in other languages:[Korean](mmr_KR.md)
+
 ## Structure
 
 Merkle Mountain Ranges [1] are an alternative to Merkle trees [2]. While the