Core/grin
0
0
Fork 0
mirror of https://github.com/mimblewimble/grin.git synced 2025-01-20 19:11:08 +03:00
Code Issues Projects Releases Packages Wiki Activity Actions

Organize doc files (#3436)

Browse source 
* create and occupy translations dir

* update translation links

* add mimblewimble whitepaper

* add p2p_protocol from docs

* add validation_logic from docs

Co-authored-by: Paouky <Paouky@users.noreply.github.com>
This commit is contained in:
Paouky 2020-09-10 16:45:14 +03:00 committed by GitHub
parent 3d07adb621
commit dfd0a649c7
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
54 changed files with 936 additions and 349 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
doc/build.md
View file

@ -1,6 +1,6 @@
# Grin - Build, Configuration, and Running
*Read this in other languages: [Español](build_ES.md), [Korean](build_KR.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).*
*Read this in other languages: [Español](translations/build_ES.md), [Korean](translations/build_KR.md), [日本語](translations/build_JP.md), [简体中文](translations/build_ZH-CN.md).*
## Supported Platforms

2
doc/code_structure.md
View file

@ -1,6 +1,6 @@
# Grin code structure
*Read this in other languages: [简体中文](code_structure_ZH-CN.md).*
*Read this in other languages: [简体中文](translations/code_structure_ZH-CN.md).*
Grin is built in [Rust](https://www.rust-lang.org/), a memory safe, compiled language. Performance critical parts like the Cuckoo mining algorithm are built as plugins, making it easy to swap between algorithm implementations for various hardware. Grin comes with CPU and experimental GPU support.

2
doc/coinbase_maturity.md
View file

@ -1,6 +1,6 @@
# The Coinbase Maturity Rule (aka Output Lock Heights)
*Read this in other languages: [Korean](coinbase_maturity_KR.md), [简体中文](coinbase_maturity_ZH-CN).*
*Read this in other languages: [Korean](translations/coinbase_maturity_KR.md), [简体中文](translations/coinbase_maturity_ZH-CN).*
Coinbase outputs (block rewards & fees) are "locked" and require 1,440 confirmations (i.e 24 hours worth of blocks added to the chain) before they mature sufficiently to be spendable. This is to reduce the risk of later txs being reversed if a chain reorganization occurs.

2
doc/contracts.md
View file

@ -1,6 +1,6 @@
# Contracts
*Read this in other languages: [简体中文]( contracts_ZH-CN.md)*
*Read this in other languages: [简体中文](translations/contracts_ZH-CN.md)*
This document describes smart contracts that can be setup using Grin even
though the Grin chain does not support scripting. All these contracts rely

2
doc/fast-sync.md
View file

@ -1,6 +1,6 @@
# Fast Sync
*Read this in other languages: [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md), [简体中文](fast-sync_ZH-CN.md).*
*Read this in other languages: [Español](translations/fast-sync_ES.md), [Korean](translations/fast-sync_KR.md), [简体中文](translations/fast-sync_ZH-CN.md).*
In Grin, we call "sync" the process of synchronizing a new node or a node that
hasn't been keeping up with the chain for a while, and bringing it up to the

2
doc/grin4bitcoiners.md
View file

@ -1,6 +1,6 @@
# Grin/Mimblewimble for Bitcoiners
*Read this in other languages:[Korean](grin4bitcoiners_KR.md)
*Read this in other languages:[Korean](translations/grin4bitcoiners_KR.md)
## Privacy and Fungibility

2
doc/intro.md
View file

@ -1,6 +1,6 @@
# Introduction to Mimblewimble and Grin
*Read this in other languages: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).*
*Read this in other languages: [简体中文](translations/intro_ZH-CN.md), [Español](translations/intro_ES.md), [Nederlands](translations/intro_NL.md), [Русский](translations/intro_RU.md), [日本語](translations/intro_JP.md), [Deutsch](translations/intro_DE.md), [Portuguese](translations/intro_PT-BR.md), [Korean](translations/intro_KR.md).*
Mimblewimble is a blockchain format and protocol that provides
extremely good scalability, privacy and fungibility by relying on strong

2
doc/merkle.md
View file

@ -1,6 +1,6 @@
# Merkle Structures
*Read this in other languages: [Korean](merkle_KR.md), [简体中文](merkle_ZH-CN.md).*
*Read this in other languages: [Korean](translations/merkle_KR.md), [简体中文](translations/merkle_ZH-CN.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

2
doc/mmr.md
View file

@ -1,6 +1,6 @@
# Merkle Mountain Ranges
*Read this in other languages: [Korean](mmr_KR.md), [简体中文](mmr_ZH-CN.md).*
*Read this in other languages: [Korean](translations/mmr_KR.md), [简体中文](translations/mmr_ZH-CN.md).*
## Structure

277
doc/p2p/p2p_protocol.md Normal file
View file

@ -0,0 +1,277 @@
# P2P Protocol
## P2P Messages
#### WARNING: This document is still in progress and has not yet been reviewed by any of the core Grin developers.
* All fields are serialized in Big-Endian byte order unless otherwise specified.
* Variable-length strings (VAR_STR) are encoded in UTF8, and are preceded with a uint64 indicating their lengths.
### Message Types
There are currently 19 different types of P2P Messages:
| Id | Message Type | Description |
|----|------------------|------------------------------------------------------------------------------------------------------------------------------------------|
| 0 | Error | Sent when an issue is found during communication with a peer. Usually followed by closing the connection. |
| 1 | Hand | First part of a handshake, sender advertises its version and characteristics. |
| 2 | Shake | Second part of a handshake, receiver of the first part replies with its own version and characteristics. |
| 3 | Ping | Sent to confirm that the connection is still valid, and used to advertise the node's total_difficulty to confirm whether sync is needed. |
| 4 | Pong | The response to a ping message. |
| 5 | GetPeerAddrs | Used to request addresses of new peers to connect to. |
| 6 | PeerAddrs | Peer addresses sent in response to a GetPeerAddrs message. |
| 7 | GetHeaders | Used to request block headers from a peer. |
| 8 | Header | A single block header received from a peer. |
| 9 | Headers | Multiple block headers received from a peer in response to a GetHeaders message. |
| 10 | GetBlock | Used to request a block from a peer. |
| 11 | Block | A single block received from a peer. |
| 12 | GetCompactBlock | Used to request a compact block from a peer. |
| 13 | CompactBlock | A single compact block received from a peer. |
| 14 | StemTransaction | A stem transaction received from a peer. |
| 15 | Transaction | A transaction received from a peer. |
| 16 | TxHashSetRequest | Used to request the transaction hashset from a peer. |
| 17 | TxHashSetArchive | The transaction hashset in response to the TxHashSetRequest message. |
| 18 | BanReason | Contains the reason your node was banned by a peer. |
### Message structure
All P2P messages follow a generic message structure as follows.
| Size | Name | Data Type | Description/Comments |
|------|---------|-----------------|-----------------------------------------------------------------------------------|
| 2 | Magic | uint8[2] | Magic number used to identify Grin packets. Always hard-coded as {0x1E, 0xC5}. |
| 1 | Type | MessageTypeEnum | Identifier of the packet content. |
| 8 | Length | uint64 | The total length of the message. This will not include the header size (11 bytes).|
| ? | Payload | uint8[] | The actual data. |
TODO: Provide example
### Common structures
##### SocketAddress
| Size | Name | Data Type | Description/Comments |
|------|-----------------|--------------------|-------------------------------------------------------------|
| 1 | IPAddressFamily | uint8 | Identifies the IP address family. 0 = IPv4, 1 = IPv6. |
| 4/16 | IPAddress | uint8[4]/uint16[8] | The IP address. 4 octets for IPv4 or 8 hexadecets for IPv6. |
| 2 | Port | uint16 | The TCP/IP port number. |
##### CapabilitiesMask
| Value | Name | Description |
|-------|-------------------|----------------------------------------------------------------------------|
| 0x00 | Unknown | We don't know (yet) what the peer can do. |
| 0x01 | Full History | Full archival node, has the whole history without any pruning. |
| 0x02 | TxHashSet History | Can provide block headers and the TxHashSet for some recent-enough height. |
| 0x04 | Peer List | Can provide a list of healthy peers. |
| 0x06 | Fast Sync Node | Both "TxHashSet History" and "Peer List" |
| 0x07 | Full Node | "Full History", "TxHashSet History", and "Peer List" |
##### TransactionBody
| Size | Name | Data Type | Description/Comments |
|------|---------|------------|--------------------------------------------------------------------------|
| ? | Inputs | TxInput[] | List of inputs spent by the transaction. |
| ? | Outputs | TxOutput[] | List of outputs the transaction produces. |
| ? | Kernels | TxKernel[] | List of kernels that make up this transaction (usually a single kernel). |
##### CompactBlockBody
| Size | Name | Data Type | Description/Comments |
|------|-------------|------------|-----------------------------------------------------------------------------------------|
| ? | FullOutputs | TxOutput[] | List of full outputs - specifically the coinbase output(s). |
| ? | FullKernels | TxKernel[] | List of full kernels - specifically the coinbase kernel(s). |
| ? | KernelIds | ShortId[] | List of transaction kernels, excluding those in the full list. Each ShortId is 6 bytes. |
##### TxInput
##### TxOutput
##### TxKernel
##### ProofOfWork
| Size | Name | Data Type | Description/Comments |
|------|-------------------|------------|-----------------------------------------------------------------|
| 8 | TotalDifficulty | uint64 | Total accumulated difficulty since genesis block. |
| 4 | ScalingDifficulty | uint32 | Difficulty scaling factor between the different proofs of work. |
| 8 | Nonce | uint64 | Nonce increment used to mine the block. |
| 1 | EdgeBits | uint8 | Power of 2 used for the size of the cuckoo graph. |
| 336 | ProofNonces | uint64[42] | The cuckoo proof nonces. |
### Messages
##### Error
| Size | Name | Data Type | Description/Comments |
|------|---------|-----------|----------------------------------------------|
| 4 | Code | uint32 | Error Code. TODO: Determine possible values. |
| ? | Message | VAR_STR | Slightly more user-friendly message |
##### Hand
| Size | Name | Data Type | Description/Comments |
|------|-----------------|------------------|--------------------------------------------------------------------------------------------|
| 4 | Version | uint32 | Protocol version of the sender. |
| 1 | Capabilities | CapabilitiesMask | Bitmask representing the capabilities of the sender. |
| 8 | Nonce | uint64 | Randomly generated for each handshake to help detect connections to yourself. |
| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. |
| 7/19 | SenderAddress | SocketAddress | Network address of the sender. 7 bytes for IPv4 or 19 bytes for IPv6. |
| 7/19 | ReceiverAddress | SocketAddress | Network address of the receiver. 7 bytes for IPv4 or 19 bytes for IPv6. |
| ? | UserAgent | VAR_STR | Name and version of the software. Example: "MW/Grin 0.1.2" |
| 32 | Hash | uint8[32] | Genesis block of the current chain. Testnet1/2/3 and mainnet all have a different genesis. |
##### Shake
| Size | Name | Data Type | Description/Comments |
|------|-----------------|------------------|--------------------------------------------------------------------------------------------|
| 4 | Version | uint32 | Protocol version of the sender. |
| 1 | Capabilities | CapabilitiesMask | Bitmask representing the capabilities of the sender. |
| 8 | Nonce | uint64 | Randomly generated for each handshake to help detect connections to yourself. |
| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. |
| ? | UserAgent | VAR_STR | Name and version of the software. Example: "MW/Grin 0.1.2" |
| 32 | Hash | uint8[32] | Genesis block of the current chain. Testnet1/2/3 and mainnet all have a different genesis. |
##### Ping
| Size | Name | Data Type | Description/Comments |
|------|-----------------|-----------|-----------------------------------------------------------------------------------------------------|
| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. |
| 8 | Height | uint64 | Total block height accumulated by the sender. See: https://github.com/mimblewimble/grin/issues/1779 |
##### Pong
| Size | Name | Data Type | Description/Comments |
|------|-----------------|-----------|-----------------------------------------------------------------------------------------------------|
| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. |
| 8 | Height | uint64 | Total block height accumulated by the sender. See: https://github.com/mimblewimble/grin/issues/1779 |
##### GetPeerAddrs
| Size | Name | Data Type | Description/Comments |
|------|--------------|------------------|----------------------------------------|
| 1 | Capabilities | CapabilitiesMask | The capabilities the peer should have. |
##### PeerAddrs
| Size | Name | Data Type | Description/Comments |
|------|-------|-----------------|---------------------------------------------------------------------------|
| 4 | Size | uint32_t | The number of peer addresses received. |
| ? | Peers | SocketAddress[] | Peer addresses that match the criteria from the GetPeerAddresses request. |
##### GetHeaders
| Size | Name | Data Type | Description/Comments |
|------|--------|-----------|------------------------------------------------------------------|
| 1 | Size | uint8_t | The number of headers being requested. |
| ? | Hashes | Hash[] | The 32-byte Blake2b hashes of the block headers being requested. |
##### Header
| Size | Name | Data Type | Description/Comments |
|------|-------------------|----------------|--------------------------------------------------------------------------------|
| 2 | Version | uint16 | The version of the block. |
| 8 | Height | uint64 | Height of this block since the genesis block (height 0). |
| 8 | Timestamp | int64 | Timestamp at which the block was built. |
| 32 | Previous | Hash | Blake2b hash of the block previous to this in the chain. |
| 32 | PreviousRoot | Hash | Merklish root of all the commitments in the previous block's TxHashSet. |
| 32 | OutputRoot | Hash | Merklish root of all the commitments in the TxHashSet. |
| 32 | RangeProofRoot | Hash | Merklish root of all range proofs in the TxHashSet. |
| 32 | KernelRoot | Hash | Merklish root of all transaction kernels in the TxHashSet. |
| 32 | TotalKernelOffset | BlindingFactor | Total accumulated sum of kernel offsets since genesis block. |
| 8 | OutputMMRSize | uint64 | Total size of the output Merkle Mountain Range(MMR) after applying this block. |
| 8 | KernelMMRSize | uint64 | Total size of the kernel MMR after applying this block. |
| 178 | ProofOfWork | ProofOfWork | Proof of work and related. |
##### Headers
| Size | Name | Data Type | Description/Comments |
|------|---------|---------------|--------------------------------------------------------------------------|
| 2 | Size | uint16_t | The number of headers received. |
| ? | Headers | BlockHeader[] | The headers matching the hashes provided in the GetBlockHeaders request. |
##### GetBlock
| Size | Name | Data Type | Description/Comments |
|------|-----------|-----------|------------------------------------------------|
| 32 | BlockHash | Hash | The Blake2b hash of the block being requested. |
##### Block
| Size | Name | Data Type | Description/Comments |
|------|--------|-----------------|----------------------------------------------------------------------|
| 405 | Header | BlockHeader | The block header. |
| ? | Body | TransactionBody | The block transaction containing the inputs, outputs, and kernel(s). |
##### GetCompactBlock
| Size | Name | Data Type | Description/Comments |
|------|-----------|-----------|--------------------------------------------------------|
| 32 | BlockHash | Hash | The Blake2b hash of the compact block being requested. |
##### CompactBlock
| Size | Name | Data Type | Description/Comments |
|------|--------|------------------|----------------------------------------------------------------------|
| 405 | Header | BlockHeader | The header with metadata and commitments to the rest of the data. |
| 8 | Nonce | uint64 | Nonce for connection specific short_ids. |
| ? | Body | CompactBlockBody | Container for out_full, kern_full and kern_ids in the compact block. |
##### StemTransaction
| Size | Name | Data Type | Description/Comments |
|------|--------|-----------------|---------------------------------------------------------------------|
| 32 | Offset | BlindingFactor | The kernel "offset" k2. |
| ? | Body | TransactionBody | The transaction body containing the inputs, outputs, and kernel(s). |
##### Transaction
| Size | Name | Data Type | Description/Comments |
|------|--------|-----------------|---------------------------------------------------------------------|
| 32 | Offset | BlindingFactor | The kernel "offset" k2. |
| ? | Body | TransactionBody | The transaction body containing the inputs, outputs, and kernel(s). |
##### TxHashSetRequest
| Size | Name | Data Type | Description/Comments |
|------|-----------|-----------|-----------------------------------------------------------------------|
| 32 | BlockHash | Hash | Blake2b hash of the block for which the TxHashSet should be provided. |
| 8 | Height | uint64 | Height of the corresponding block. |
##### TxHashSetArchive
The response to a TxHashSetRequest. Includes a zip stream of the archive after the message body.
| Size | Name | Data Type | Description/Comments |
|------|-----------|-----------|-----------------------------------------------------------------|
| 32 | BlockHash | Hash | Blake2b hash of the block for which the txhashset are provided. |
| 8 | Height | uint64 | Height of the corresponding block. |
| 8 | Bytes | uint64 | Size in bytes of the archive. |
##### BanReason
| Size | Name | Data Type | Description/Comments |
|------|-----------|------------------|-------------------------|
| 4 | BanReason | ReasonForBanEnum | The reason for the ban. |
## Protocol Versions and Capabilities
### Capabilities
Any feature that users will have the ability to disable should be implemented as a new capability (See CapabilitiesMask above). This includes things like archive mode/full history.
### Protocol Version
Any change to the p2p protocol that is not toggled by the addition of a new capability should result in an increase in protocol version (See Hand & Shake messages above). This includes any addition or removal of a field or entire message, or any backward-incompatible behavior change to an existing field or message. When interacting with peers on an older protocol version, backward compatibility must be maintained, so the newer node should follow the rules of the older protocol version.
##### Phasing out old peers
To reduce the long-term complexity of the code, we can periodically bump the "major" protocol version. Although the protocol version is just a uint32, we can consider every increase by 1000 a new "major" protocol version. We can then gracefully phase out stubborn peers that refuse to upgrade by only supporting 1 major protocol version in the past. Here's what this would look like in practice:
* Peers with a protocol version in the range [0-999] should be able to interact with any peer in the range [0-1999].
* Peers with a protocol version in the range [1000-1999] should be able to interact with any peer in the range [0-2999].
* Peers with a protocol version in the range [2000-2999] should be able to interact with any peer in the range [1000-3999].
Determining when to increase the "major" version is left up to the discretion of the developers. Care must be taken to ensure we are not increasing too quickly however, as any major bump could result in the inability to connect to certain older peers.

2
doc/pruning.md
View file

@ -1,6 +1,6 @@
# Pruning Blockchain Data
*Read this in other languages: [Korean](pruning_KR.md), [简体中文](pruning_ZH-CN.md).*
*Read this in other languages: [Korean](translations/pruning_KR.md), [简体中文](translations/pruning_ZH-CN.md).*
One of the principal attractions of Mimblewimble is its theoretical space
efficiency. Indeed, a trusted or pre-validated full blockchain state only

2
doc/state.md
View file

@ -1,6 +1,6 @@
# State and Storage
*Read this in other languages: [Korean](state_KR.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).*
*Read this in other languages: [Korean](translations/state_KR.md), [日本語](translations/state_JP.md), [简体中文](translations/state_ZH-CN.md).*
## The Grin State

2
doc/stratum.md
View file

@ -1,6 +1,6 @@
# Grin Stratum RPC Protocol
*Read this in other languages: [Korean](stratum_KR.md), [简体中文](stratum_ZH-CN.md).*
*Read this in other languages: [Korean](translations/stratum_KR.md), [简体中文](translations/stratum_ZH-CN.md).*
This document describes the current Stratum RPC protocol implemented in Grin.

2
doc/switch_commitment.md
View file

@ -1,6 +1,6 @@
# Introduction to Switch Commitments
*Read this in other languages: [简体中文](switch_commitment_ZH-CN.md).*
*Read this in other languages: [简体中文](translations/switch_commitment_ZH-CN.md).*
## General introduction

2
doc/table_of_contents.md
View file

@ -1,6 +1,6 @@
# Documentation structure
*Read this in other languages: [Korean](table_of_contents_KR.md), [简体中文](table_of_contents_ZH-CN.md).*
*Read this in other languages: [Korean](translations/table_of_contents_KR.md), [简体中文](translations/table_of_contents_ZH-CN.md).*
## Explaining grin

2
doc/build_ES.md → doc/translations/build_ES.md
View file

@ -1,6 +1,6 @@
# Grin - Compilación, configuración y ejecución
*Lea esto en otros idiomas: [English](build.md), [日本語](build_JP.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).*
*Lea esto en otros idiomas: [English](../build.md), [日本語](build_JP.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).*
## Plataformas soportadas

2
doc/build_JP.md → doc/translations/build_JP.md
View file

@ -1,6 +1,6 @@
# grin - ビルド、設定、動作確認
*この文章を他の言語で読む: [English](build.md), [Español](build_ES.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).*
*この文章を他の言語で読む: [English](../build.md), [Español](build_ES.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).*
## 動作環境

2
doc/build_KR.md → doc/translations/build_KR.md
View file

@ -1,6 +1,6 @@
# Grin - Build, Configuration, and Running
*다른 언어로 되어있는 문서를 읽으려면: [English](build.md), [Español](build_ES.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).*
*다른 언어로 되어있는 문서를 읽으려면: [English](../build.md), [Español](build_ES.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).*
## 지원하는 플랫폼들에 대해서

2
doc/build_ZH-CN.md → doc/translations/build_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Grin - 构建，配置和运行
*阅读其它语言版本: [English](build.md), [Español](build_ES.md), [日本語](build_JP.md), [Korean](build_KR.md).*
*阅读其它语言版本: [English](../build.md), [Español](build_ES.md), [日本語](build_JP.md), [Korean](build_KR.md).*
## 支持的平台

2
doc/code_structure_ZH-CN.md → doc/translations/code_structure_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Grin 代码结构
*阅读其它语言版本: [English](code_structure.md).*
*阅读其它语言版本: [English](../code_structure.md).*
Grin 使用 [Rust]（https://www.rust-lang.org/）编写，这是一个内存安全的编译语言。诸如 Cuckoo 挖掘算法之类的性能关键部分都是作为插件构建的，因此可以轻松地在各种硬件的算法实现之间进行交换。Grin 带有 CPU 和实验性 GPU 支持。

0
doc/coinbase_maturity_KR.md → doc/translations/coinbase_maturity_KR.md
View file

2
doc/coinbase_maturity_ZH-CN.md → doc/translations/coinbase_maturity_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Coinbase 期限规则（亦即"输出锁定高度"）
*阅读其它语言版本: [English](coinbase_maturity.md), [Korean](coinbase_maturity_KR.md).*
*阅读其它语言版本: [English](../coinbase_maturity.md), [Korean](coinbase_maturity_KR.md).*
coinbase 输出（区块奖励和手续费）为“锁定”，需要有 1440 个确认（也就是经过约 24 小时在链上加上区块）才能到期花费。这是为了防止之后如果出现链上回滚的情况下，降低撤销之后交易的风险。

0
doc/contract_ideas_ZH-CN.md → doc/translations/contract_ideas_ZH-CN.md
View file

0
doc/contracts_ZH-CN.md → doc/translations/contracts_ZH-CN.md
View file

2
doc/fast-sync_ES.md → doc/translations/fast-sync_ES.md
View file

@ -1,6 +1,6 @@
# Sincronización rápida
*Lea esto en otros idiomas: [English](fast-sync.md), [简体中文](fast-sync_ZH-CN.md), [Korean](fast-sync_KR.md).*
*Lea esto en otros idiomas: [English](../fast-sync.md), [简体中文](fast-sync_ZH-CN.md), [Korean](fast-sync_KR.md).*
En Grin, llamamos "sync" al proceso de sincronizar un nuevo nodo o un nodo que no ha estado al día con la cadena durante un
tiempo, y llevarlo hasta el último bloque conocido. La Descarga Inicial de Bloques (o IBD) es usada a menudo por otras cadenas

2
doc/fast-sync_KR.md → doc/translations/fast-sync_KR.md
View file

@ -1,6 +1,6 @@
# 빠른 동기화
*다른 언어로 되어있는 문서를 읽으려면: [English](fast-sync.md), [Español](fast-sync_ES.md), [简体中文](fast-sync_ZH-CN.md).*
*다른 언어로 되어있는 문서를 읽으려면: [English](../fast-sync.md), [Español](fast-sync_ES.md), [简体中文](fast-sync_ZH-CN.md).*
Grin에서는 새로 네트워크에 참여하는 노드나 얼마 동안 체인을 따라 잡지 않은 노드(의 상태)를 알려진 최신 블록으로( 원문에서는 most-worked block 이라고 표현- 역자 주 ) 가져 오는 프로세스를 "동기화"라고 부릅니다. Initial Block Download (또는 IBD)는 다른 블록 체인에서 자주 사용되지만 빠른 동기화를 사용하는 Grin에서는 일반적으로 전체 블록을 다운로드하지 않으므로 문제가 됩니다.

2
doc/fast-sync_ZH-CN.md → doc/translations/fast-sync_ZH-CN.md
View file

@ -1,6 +1,6 @@
# 快速同步
*阅读其它语言版本: [English](fast-sync.md), [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md).*
*阅读其它语言版本: [English](../fast-sync.md), [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md).*
在 Grin 中，我们把同步一个新节点或一段时间未跟上链的节点，并将其升级到最新的已知工作量最大的块的过程称为“同步”（"sync"）。 初始块下载（或 IBD）通常在其他区块链中被采用，但这对 Grin 来说这是有问题的，因为它通常不会下载完整的块。

0
doc/grin4bitcoiners_KR.md → doc/translations/grin4bitcoiners_KR.md
View file

2
doc/grin4bitcoiners_ZH-CN.md → doc/translations/grin4bitcoiners_ZH-CN.md
View file

@ -1,7 +1,7 @@
# Grin/Mimblewimble 致比特币持有者
* 阅读其他语言版本：[Korean](grin4bitcoiners_KR.md)、 [English](grin4bitcoiners.md)
*阅读其他语言版本： [English](../grin4bitcoiners.md), [Korean](grin4bitcoiners_KR.md).*
## 隐私和可互换性

2
doc/intro_DE.md → doc/translations/intro_DE.md
View file

@ -1,6 +1,6 @@
# Einführung in Mimblewimble und Grin
*In anderen Sprachen lesen: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md)*
*In anderen Sprachen lesen: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md)*
Mimblewimble ist ein Blockchain-Format und Protokoll, welches auf starke kryptographische Primitiven setzt und dadurch äußerst gute Skalierbarkeit, Privatsphäre und Fungibilität bietet. Es befasst sich mit Lücken, die in fast allen gegenwärtigen Blockchainimplementierungen existieren.

2
doc/intro_ES.md → doc/translations/intro_ES.md
View file

@ -1,6 +1,6 @@
# Introducción a Mimblewimble y Grin
*Lea esto en otros idiomas: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*Lea esto en otros idiomas: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
Mimblewimble es un formato y un protocolo de cadena de bloques que proporciona una escalabilidad, privacidad y funcionalidad
extremadamente buenas al basarse en fuertes algoritmos criptográficos. Aborda los vacíos existentes en casi todas las

2
doc/intro_JP.md → doc/translations/intro_JP.md
View file

@ -1,6 +1,6 @@
# Mimblewimble と Grin 概論
*この文章を他の言語で読む： [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*この文章を他の言語で読む： [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
Mimblewimble は、極めてよいスケーラビリティ、プライバシー、そして代替可能性（fungibility）の解決法を提供
するブロックチェーンのフォーマット・プロトコルである。Mimblewimble は、ほとんどすべてのブロックチェーンの

2
doc/intro_KR.md → doc/translations/intro_KR.md
View file

@ -1,6 +1,6 @@
# Mimblewimble 과 Grin 에 대한 소개
*다른 언어로 되어있는 문서를 읽으려면: [English](intro.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md), [简体中文](intro.zh-cn.md).*
*다른 언어로 되어있는 문서를 읽으려면: [English](../intro.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md), [简体中文](intro.zh-cn.md).*
MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다.
Mimblewimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다.

2
doc/intro_NL.md → doc/translations/intro_NL.md
View file

@ -1,6 +1,6 @@
# Inleiding tot Mimblewimble en Grin
*Lees dit in andere talen: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*Lees dit in andere talen: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
Mimblewimble is een blockchain formaat en protocol die extreem goede schaalbaarheid, privacy en fungibiliteit biedt door zich te berusten op sterke cryptografische primiteven. Het adresseert de lacunes die in bijna alle huidige blockchain-implementaties bestaan.

3
doc/intro_PT-BR.md → doc/translations/intro_PT-BR.md
View file

@ -1,6 +1,6 @@
# Introdução ao Mimblewimble e ao Grin
*Leia isto em outros idiomas: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*Leia isto em outros idiomas: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
O Mimblewimble é um formato e protocolo blockchain que fornece ótima escalabilidade, privacidade e fungibilidade, para isso contando com primitivas criptográficas fortes. Ele aborda as lacunas existentes em quase todos as implementações blockchain atuais.
@ -288,4 +288,3 @@ Além disso, o conjunto completo de saídas não gastas não pode ser adulterado
### Conclusão
Neste documento, cobrimos os princípios básicos subjacentes a um blockchain Mimblewimble. Usando as propriedades de adição da Criptografia de Curva Elíptica, construímos transações completamente opacas, mas que ainda assim podem ser corretamente validadas. E ao generalizar essas propriedades em blocos, podemos eliminar uma grande quantidade de dados do blockchain, permitindo uma grande escalabilidade bem como a rápida sincronização de novos pares.

2
doc/intro_RU.md → doc/translations/intro_RU.md
View file

@ -1,6 +1,6 @@
# Введение в МимблВимбл и Grin
*На других языках: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*На других языках: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
МимблВимбл это формат и протокол блокчейна, предоставляющий
исключительную масштабируемость, приватность и обезличенность криптовалюты,

2
doc/intro_SE.md → doc/translations/intro_SE.md
View file

@ -1,6 +1,6 @@
# Introduktion till Mimblewimble och Grin
*Läs detta på andra språk: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
*Läs detta på andra språk: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).*
Mimblewimble är ett blockkedjeformat och protokoll som erbjuder extremt bra
skalbarhet, integritet, och fungibilitet genom starka kryptografiska primitiver.

2
doc/intro_ZH-CN.md → doc/translations/intro_ZH-CN.md
View file

@ -1,7 +1,7 @@
Mimblewimble 和 Grin 简介
=====================================
*阅读其它语言版本: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).*
*阅读其它语言版本: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).*
Mimblewimble是一个区块链格式和协议，依托于健壮的加密原语，提供非常好的可扩展性、隐私和可替代性。它解决了当前几乎所有实现的区块链（与现实需求之间）差距。Mimblewimble 的白皮书在[本项目的WiKi](https://github.com/mimblewimble/docs/wiki/A-Brief-History-of-MinbleWimble-White-Paper)中可以找到，WiKi是开放的。

0
doc/merkle_KR.md → doc/translations/merkle_KR.md
View file

2
doc/merkle_ZH-CN.md → doc/translations/merkle_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Merkle Structures
*阅读其它语言版本: [English](merkle.md), [Korean](merkle_KR.md).*
*阅读其它语言版本: [English](../merkle.md), [Korean](merkle_KR.md).*
Mimblewimble 是设计给用户在仅给出修剪后的数据的情况下也能验证系统状态。
为了实现此目标，所有交易数据都通过 Merkle trees 提交给了区块链，该 Merkle trees 即使在被修剪后也需要在更新和序列化操作上有良好的效率。

263
doc/translations/mimblewimble.md Normal file
View file

@ -0,0 +1,263 @@
https://scalingbitcoin.org/papers/mimblewimble.txt
MIMBLEWIMBLE
Tom Elvis Jedusor
19 July, 2016
\****/
Introduction
/****\
Bitcoin is the first widely used financial system for which all the necessary
data to validate the system status can be cryptographically verified by anyone.
However, it accomplishes this feat by storing all transactions in a public
database called "the blockchain" and someone who genuinely wishes to check
this state must download the whole thing and basically replay each transaction,
check each one as they go. Meanwhile, most of these transactions have not
affected the actual final state (they create outputs that are destroyed
a transaction later).
At the time of this writing, there were nearly 150 million transactions
committed in the blockchain, which must be replayed to produce a set of
only 4 million unspent outputs.
It would be better if an auditor needed only to check data on the outputs
themselves, but this is impossible because they are valid if and only if the
output is at the end of a chain of previous outputs, each signs the next. In
other words, the whole blockchain must be validated to confirm the final
state.
Add to this that these transactions are cryptographically atomic, it is clear
what outputs go into every transaction and what emerges. The "transaction graph"
resulting reveals a lot of information and is subjected to analysis by many
companies whose business model is to monitor and control the lower classes.
This makes it very non-private and even dangerous for people to use.
Some solutions to this have been proposed. Greg Maxwell discovered to encrypt
the amounts, so that the graph of the transaction is faceless but still allow
validation that the sums are correct [1]. Dr Maxwell also produced CoinJoin,
a system for Bitcoin users to combine interactively transactions, confusing
the transaction graph. Nicolas van Saberhagen has developed a system to blind
the transaction entries, goes much further to cloud the transaction graph (as
well as not needed the user interaction) [3]. Later, Shen Noether combined
the two approaches to obtain "confidential transactions" of Maxwell AND the
darkening of van Saberhagen [4].
These solutions are very good and would make Bitcoin very safe to use. But
the problem of too much data is made even worse. Confidential transactions
require multi-kilobyte proofs on every output, and van Saberhagen signatures
require every output to be stored for ever, since it is not possible to tell
when they are truly spent.
Dr. Maxwell's CoinJoin has the problem of needing interactivity. Dr. Yuan Horas
Mouton fixed this by making transactions freely mergeable [5], but he needed to
use pairing-based cryptography, which is potentially slower and more difficult
to trust. He called this "one-way aggregate signatures" (OWAS).
OWAS had the good idea to combine the transactions in blocks. Imagine that we
can combine across blocks (perhaps with some glue data) so that when the outputs
are created and destroyed, it is the same as if they never existed. Then, to
validate the entire chain, users only need to know when money is entered into
the system (new money in each block as in Bitcoin or Monero or peg-ins for
sidechains [6]) and final unspent outputs, the rest can be removed and forgotten.
Then we can have Confidential Transactions to hide the amounts and OWAS to blur
the transaction graph, and use LESS space than Bitcoin to allow users to fully
verify the blockchain. And also imagine that we must not pairing-based cryptography
or new hypotheses, just regular discrete logarithms signatures like Bitcoin.
Here is what I propose.
I call my creation Mimblewimble because it is used to prevent the blockchain from
talking about all user's information [7].
\****/
Confidential Transactions and OWAS
/****\
The first thing we need to do is remove Bitcoin Script. This is sad, but it is too
powerful so it is impossible to merge transactions using general scripts. We will
demonstrate that confidential transactions of Dr. Maxwell are enough (after some
small modification) to authorize spending of outputs and also allows to make
combined transactions without interaction. This is in fact identical to OWAS,
and allows relaying nodes take some transaction fee or the recipient to change
the transaction fees. These additional things Bitcoin can not do, we get for free.
We start by reminding the reader how confidential transactions work. First, the
amounts are coded by the following equation:
C = r*G + v*H
where C is a Pedersen commitment, G and H are fixed nothing-up-my-sleeve elliptic
curve group generators, v is the amount, and r is a secret random blinding key.
Attached to this output is a rangeproof which proves that v is in [0, 2^64], so
that user cannot exploit the blinding to produce overflow attacks, etc.
To validate a transaction, the verifer will add commitments for all outputs, plus
f*H (f here is the transaction fee which is given explicitly) and subtracts all
input commitments. The result must be 0, which proves that no amount was created
or destroyed overall.
We note that to create such a transaction, the user must know the sum of all the
values of r for commitments entries. Therefore, the r-values (and their sums) act
as secret keys. If we can make the r output values known only to the recipient,
then we have an authentication system! Unfortunately, if we keep the rule that
commits all add to 0, this is impossible, because the sender knows the sum of
all _his_ r values, and therefore knows the receipient's r values sum to the
negative of that. So instead, we allow the transaction to sum to a nonzero value
k*G, and require a signature of an empty string with this as key, to prove its
amount component is zero.
We let transactions have as many k*G values as they want, each with a signature,
and sum them during verification.
To create transactions sender and recipient do following ritual:
1. Sender and recipient agree on amount to be sent. Call this b.
2. Sender creates transaction with all inputs and change output(s), and gives
recipient the total blinding factor (r-value of change minus r-values of
inputs) along with this transaction. So the commitments sum to r*G - b*H.
3. Recipient chooses random r-values for his outputs, and values that sum
to b minus fee, and adds these to transaction (including range proof).
Now the commitments sum to k*G - fee*H for some k that only recipient
knows.
4. Recipient attaches signature with k to the transaction, and the explicit
fee. It has done.
Now, creating transactions in this manner supports OWAS already. To show this,
suppose we have two transactions that have a surplus k1*G and k2*G, and the
attached signatures with these. Then you can combine the lists of inputs and
outputs of the two transactions, with both k1*G and k2*G to the mix, and
voilá! is again a valid transaction. From the combination, it is impossible to
say which outputs or inputs are from which original transaction.
Because of this, we change our block format from Bitcoin to this information:
1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with
whatever else data this needs. For a sidechain peg-in maybe it references
a Bitcoin transaction that commits to a specific excess k*G value?
2. Inputs of all transactions
3. Outputs of all transactions
4. Excess k*G values for all transactions
Each of these are grouped together because it do not matter what the transaction
boundaries are originally. In addition, Lists 2 3 and 4 should be required to be
coded in alphabetical order, since it is quick to check and prevents the block
creator of leaking any information about the original transactions.
Note that the outputs are now identified by their hash, and not by their position
in a transaction that could easily change. Therefore, it should be banned to have
two unspent outputs are equal at the same time, to avoid confusion.
\****/
Merging Transactions Across Blocks
/****\
Now, we have used Dr. Maxwell's Confidential Transactions to create a noninteractive
version of Dr. Maxwell's CoinJoin, but we have not seen the last of marvelous Dr. Maxwell!
We need another idea, transaction cut-through, he described in [8]. Again, we create a
noninteractive version of this, and to show how it is used with several blocks.
We can imagine now each block as one large transaction. To validate it, we add all the
output commitments together, then subtracts all input commitments, k*G values, and all
explicit input amounts times H. We find that we could combine transactions from two
blocks, as we combined transactions to form a single block, and the result is again
a valid transaction. Except now, some output commitments have an input commitment exactly
equal to it, where the first block's output was spent in the second block. We could
remove both commitments and still have a valid transaction. In fact, there is not even
need to check the rangeproof of the deleted output.
The extension of this idea all the way from the genesis block to the latest block, we
see that EVERY nonexplicit input is deleted along with its referenced output. What
remains are only the unspent outputs, explicit input amounts and every k*G value.
And this whole mess can be validated as if it were one transaction: add all unspent
commitments output, subtract the values k*G, validate explicit input amounts (if there
is anything to validate) then subtract them times H. If the sum is 0, the entire
chain is good.
What is this mean? When a user starts up and downloads the chain he needs the following
data from each block:
1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with
whatever else data this needs.
2. Unspent outputs of all transactions, along with a merkle proof that each
output appeared in the original block.
3. Excess k*G values for all transactions.
Bitcoin today there are about 423000 blocks, totaling 80GB or so of data on the hard
drive to validate everything. These data are about 150 million transactions and 5 million
unspent nonconfidential outputs. Estimate how much space the number of transactions
take on a Mimblewimble chain. Each unspent output is around 3Kb for rangeproof and
Merkle proof. Each transaction also adds about 100 bytes: a k*G value and a signature.
The block headers and explicit amounts are negligible. Add this together and get
30Gb -- with a confidential transaction and obscured transaction graph!
\****/
Questions and Intuition
/****\
Here are some questions that since these weeks, dreams asked me and I woke up sweating.
But in fact it is OK.
Q. If you delete the transaction outputs, user cannot verify the rangeproof and maybe
a negative amount is created.
A. This is OK. For the entire transaction to validate all negative amounts must have
been destroyed. User have SPV security only that no illegal inflation happened in
the past, but the user knows that _at this time_ no inflation occurred.
Q. If you delete the inputs, double spending can happen.
A. In fact, this means: maybe someone claims that some unspent output was spent
in the old days. But this is impossible, otherwise the sum of the combined transaction
could not be zero.
An exception is that if the outputs are amount zero, it is possible to make two that
are negatives of each other, and the pair can be revived without anything breaks. So to
prevent consensus problems, outputs 0-amount should be banned. Just add H at each output,
now they all amount to at least 1.
\****/
Future Research
/****\
Here are some questions I can not answer at the time of this writing.
1. What script support is possible? We would need to translate script operations into
some sort of discrete logarithm information.
2. We require user to check all k*G values, when in fact all that is needed is that their
sum is of the form k*G. Instead of using signatures is there another proof of discrete
logarithm that could be combined?
3. There is a denial-of-service option when a user downloads the chain, the peer can give
gigabytes of data and list the wrong unspent outputs. The user will see that the result
do not add up to 0, but cannot tell where the problem is.
For now maybe the user should just download the blockchain from a Torrent or something
where the data is shared between many users and is reasonably likely to be correct.
[1] https://people.xiph.org/~greg/confidential_values.txt
[2] https://bitcointalk.org/index.php?topic=279249.0
[3] https://cryptonote.org/whitepaper.pdf
[4] https://eprint.iacr.org/2015/1098.pdf
[5] https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf
[6] http://blockstream.com/sidechains.pdf
[7] http://fr.harrypotter.wikia.com/wiki/Sortilège_de_Langue_de_Plomb
[8] https://bitcointalk.org/index.php?topic=281848.0

2
doc/mmr_KR.md → doc/translations/mmr_KR.md
View file

@ -1,6 +1,6 @@
# Merkle Mountain Ranges
*다른 언어로 되어있는 문서를 읽으려면: [English](mmr.md), [简体中文](mmr_ZH-CN.md).*
*다른 언어로 되어있는 문서를 읽으려면: [English](../mmr.md), [简体中文](mmr_ZH-CN.md).*
## MMR의 구조

2
doc/mmr_ZH-CN.md → doc/translations/mmr_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Merkle Mountain Ranges
*阅读其它语言版本: [English](mmr.md), [Korean](mmr_KR.md).*
*阅读其它语言版本: [English](../mmr.md), [Korean](mmr_KR.md).*
## 结构

0
doc/pruning_KR.md → doc/translations/pruning_KR.md
View file

2
doc/pruning_ZH-CN.md → doc/translations/pruning_ZH-CN.md
View file

@ -1,6 +1,6 @@
# 修剪区块链数据
*阅读其它语言版本: [English](pruning.md), [Korean](pruning_KR.md).*
*阅读其它语言版本: [English](../pruning.md), [Korean](pruning_KR.md).*
Mimblewimble 的主要吸引力之一是其理论空间效率。确实，一个受信任或预先验证的完整区块链状态仅需要未花费的交易输出，它可以非常小。

2
doc/state_JP.md → doc/translations/state_JP.md
View file

@ -1,6 +1,6 @@
# 状態とストレージ
*別の言語で読む: [English](state.md), [Korean](state_KR.md), [简体中文](state_ZH-CN.md).*
*別の言語で読む: [English](../state.md), [Korean](state_KR.md), [简体中文](state_ZH-CN.md).*
## Grinの状態

2
doc/state_KR.md → doc/translations/state_KR.md
View file

@ -1,6 +1,6 @@
# 상태와 스토리지
*다른 언어로 되어있는 문서를 읽으려면: [English](state.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).*
*다른 언어로 되어있는 문서를 읽으려면: [English](../state.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).*
## Grin의 상태

2
doc/state_ZH-CN.md → doc/translations/state_ZH-CN.md
View file

@ -1,6 +1,6 @@
# 状态和存储
*阅读其它语言版本: [English](state.md), [Korean](state_KR.md), [日本語](state_JP.md).*
*阅读其它语言版本: [English](../state.md), [Korean](state_KR.md), [日本語](state_JP.md).*
## Grin 的状态

0
doc/stratum_KR.md → doc/translations/stratum_KR.md
View file

2
doc/stratum_ZH-CN.md → doc/translations/stratum_ZH-CN.md
View file

@ -1,6 +1,6 @@
# Grin Stratum RPC 协议
*阅读其它语言版本: [Korean](stratum_KR.md)，[English](stratum.md).*
*阅读其它语言版本: [Korean](../stratum_KR.md)，[English](stratum.md).*
本文说明在 Grin 部署目前的 Stratum RPC 协议。

2
doc/switch_commitment_ZH-CN.md → doc/translations/switch_commitment_ZH-CN.md
View file

@ -1,6 +1,6 @@
# 秘诺切换简介
*阅读其它语言版本： [English](switch_commitment.md)*
*阅读其它语言版本： [English](../switch_commitment.md)*
## 概述

0
doc/table_of_contents_KR.md → doc/translations/table_of_contents_KR.md
View file

2
doc/table_of_contents_ZH-CN.md → doc/translations/table_of_contents_ZH-CN.md
View file

@ -1,6 +1,6 @@
# 文档结构
*阅读其它语言版本： [English](table_of_contents.md)，[Korean](table_of_contents_KR.md)*
*阅读其它语言版本： [English](../table_of_contents.md)，[Korean](table_of_contents_KR.md)*
## Grin 详解

48
doc/validation/validation_logic.md Normal file
View file

@ -0,0 +1,48 @@
# Standalone Validations Logic
## Transaction
* Validate the "transaction body"
* Validate the total weight, including reward is lower than the consensus max weight
* Validate the sorting of inputs, outputs and kernels by their hashes
* Validate the outputs have all been fully cut-through (no inputs matching an included output)
* Batch verify all output range proofs (but only those that aren't in the validation cache yet)
* Verify all kernel signatures against the excess and the message (fee+lock_time?)
* Verify no output or kernel include invalid features (coinbase)
* Verify the big "sum": all inputs plus reward+fee, all output commitments, all kernels plus the kernel excess
## Block
* Validate the "transaction body" as with transactions
* Verify no kernels have a future lock height
* Check that the reward plus fees "sums" correctly with the coinbase outputs commitments and kernels excess
* Verify the big "sum": all inputs plus reward+fee, all output commitments, all kernels plus the kernel excess from the header
# Chain validations
Headers and blocks have a quick rejection check first when they've already gone through validation and have either been accepted or definitely rejected (non orphans, no local error).
## Header
In all header difficulty calculations, the difficulty proven by the proof-of-work is subject to adjustments due to either Cuckatoo sizes or Cuckaroo scaling factor.
* Check the version against what we're expecting at the moment given a hard fork schedule.
* Check the header timestamp isn't too far off in the future (12 * block time)
* Check we either have a primary or secondary proof of work solution
* Check the solution is a valid Cuck(ar|at)oo cycle of the required length (42)
* Check the previous block header exists
* Check the heights are coherent (previous + 1)
* Check the header timestamp is strictly greater than the previous
* Check the header PoW total difficulty is greater than the previous one
* Check the header PoW satisfies the network difficulty claimed in the header
* Check the calculated network difficulty equals the header claimed network difficulty
* Check the header secondary scaling factor matches the network calculated one
* Validate the previous header MMR root is correct against the local MMR.
## Block
* Run full header validation
* Check we have the previous full block (orphan otherwise)
* Run standalone block validation
* Validate the MMRs roots and sizes against our header
* Block header goes through full header validation