mirror of
https://github.com/mimblewimble/grin.git
synced 2025-01-20 19:11:08 +03:00
Merge branch 'master' into milestone/2.x.x
This commit is contained in:
antiochp
commit
c6cea4744c
9 changed files with 701 additions and 537 deletions
846
Cargo.lock
generated
846
Cargo.lock
generated
File diff suppressed because it is too large
Load diff
122
SECURITY.md
122
SECURITY.md
|
|
@ -4,12 +4,14 @@ Grin has a [code of conduct](CODE_OF_CONDUCT.md) and the handling of vulnerabili
|
|||
|
||||
## Responsible Disclosure
|
||||
|
||||
For all security related issues, Grin has two main points of contact:
|
||||
For all security related issues, Grin has 4 main points of contact:
|
||||
|
||||
* Daniel Lehnberg, daniel.lehnberg at protonmail.com
|
||||
* Ignotus Peverell, igno.peverell at protonmail.com
|
||||
* hashmap, hashmap.dev at protonmail.com
|
||||
* John Woeltz, joltz at protonmail.com
|
||||
|
||||
Send all communications to both parties and expect a reply within 48h. Public keys can be found at the end of this document.
|
||||
Send all communications to all parties and expect a reply within 48h. Public keys can be found at the end of this document.
|
||||
|
||||
## Vulnerability Handling
|
||||
|
||||
|
|
@ -69,7 +71,7 @@ The Grin Team runs a chain split monitoring tool at (TBD). It is encouraged to m
|
|||
## Public Keys
|
||||
|
||||
### Daniel Lehnberg
|
||||
````
|
||||
```
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
|
||||
mQINBFuWAuMBEACqRebggT91uazP/jzmKOD/UyVwxaXBtEcWt1/hp9fi1azLxGBn
|
||||
|
|
@ -123,7 +125,7 @@ Yt4GsNSSB0khmbq31wIGbll/ZGsSH60h
|
|||
=pLZJ
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
|
||||
````
|
||||
```
|
||||
### Ignotus Peverell
|
||||
```
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
|
|
@ -178,3 +180,115 @@ VaXAUOUL1MeJOiXI96Q=
|
|||
=xdp/
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
```
|
||||
### hashmap
|
||||
```
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
|
||||
xsFNBF0JT20BEADBd71TiSmjdfAOaOiku4b7Qs5vo9wRthTIbufIiUcK/5mg
|
||||
6Dkii31YjZxDXcTvt4Er9luZsJ4ynUBDfyCo8NeUar9o2DGv3CC0bWQ4uSWZ
|
||||
so8ZhaFn3VPHfQBj82s5q7saQmq1wTW6qPCDuT8osm+PN0XJvLWdNrdBwWEj
|
||||
5zDDse1vJ+m2gt+TKrN18LFKMevCEDDahjTqcHyh7Ps5m8pO70u0L/h0STpL
|
||||
dKxurNqoKvgNDBNuUTgd7aWNyaqdZ/QQRM8lojE02RRwd4fqscKj+GGivhlL
|
||||
3rDd3oNacFn0pUIGkrqcELmvEhK592U53zuQW0HJRgx7vOkAao/vwnVTDfOY
|
||||
U2N7vzcpHVk68TCnBreW1o5UHkzlxNcxU8Luv9tXxufVaB1agHVWef6Oju6V
|
||||
TJIcteKMiatTUQi/EfO2vy4E+6PbmNzCxOVeyxLXbcFVFthhZqk2+sW97Owc
|
||||
r1WsuBcNA9fbUHRUs3Fe2vbatB2I/TW5naiZWACOkLwDcip8UZWz2YE98O32
|
||||
HK0335ANRrFlM+8tMXjRhKWyWK5jvmTNxhlEE8eqjskJjk3yK00+UElzkz7D
|
||||
ot8WQWcosbKzBinDiC4ZsxUVFTnqLl+oWZgetci2XDHWH9fWGv8KbX+hAUbP
|
||||
jshNfIIY9bfO2jqdIkRL96R4oo1FVxV9uNjl3wARAQABzTdoYXNobWFwLmRl
|
||||
dkBwcm90b25tYWlsLmNvbSA8aGFzaG1hcC5kZXZAcHJvdG9ubWFpbC5jb20+
|
||||
wsF1BBABCAAfBQJdCU9tBgsJBwgDAgQVCAoCAxYCAQIZAQIbAwIeAQAKCRA3
|
||||
h0ARV3ZFef1sD/0QeymTRUVp/k1HZzmRw+TeRH2DQt81DNrkdB7ylhJgjLzs
|
||||
fftpSAX9E5n6+915MG0tMGtZgDRjUp4OBQTtXue093cJm4R3i4zn6kKCkIpn
|
||||
hpnk9LdlUdFFZogQj9irUpG4vhbBJuxThxKjVHiFfjWIzgfnwrWz1rd5mdkD
|
||||
HDg4Vyhvgu3wif+cMpyCZXCVD/0czNGVh8bQLA8POl/fKHOvrP7pnOE4KDHC
|
||||
HOOUdzhmWqHoh4Yzlgyg07K+Ef7JunA+czGWKpVVOYG+K8ZHp/qA6Rfoy2g5
|
||||
aCunwFvPWFi4qz2nk4HhMwuTHF493LCFZsKCQx96Yiy8fSC4n7nVqi2uhx3r
|
||||
beBJ96/oKHqkILbpjbm+5uSTmQjsb6XBtYoS96ujXAhR1EJOM5PIz1ceajK8
|
||||
MuoR/clqgHH10+DzvnsXEIaXp3cPVpKtnypCT1vipRI6r5XISibYNmHbHYcW
|
||||
qBYWYvXvqMijr+ETFUADO6oUsFm5eWkqIBtnv3oxi9HcD43GtgeAG53B07Wi
|
||||
YA1DnQVhhSE9FOce0AWXLs+eho8X3pITPlUHDxPNHdObc8VAYG7dZkKJo2AU
|
||||
WxsJJnMhNGbHC3uNG6owCdaus8FDrc9vbFFkmadryLKqHyNVNgUOoufxSHie
|
||||
zQ3GkO/bXdwG4ZwrzqriX5qopqwcB8DQyTQU0s7BTQRdCU9tARAArFncxKFn
|
||||
IL7IYQPKWhOkhNpex5FRhbeuB9FWJ2diQJwLOSL/TIxTm0iX9AciU5Xz5o1b
|
||||
q6+Cj7i1+af0ZO1Oyhjn40ha11faonyT6ebB6hpsHpU433ifRLFz4ksQGacM
|
||||
xZSDJJbf+3LoLWLJ0SDDd82arQq1VLNeiNUaOfADOa/3pwAGYFn3q2gvAHJ2
|
||||
XC1N2Om0utTANcQH1RRiUWe2gvpO2ZjzSB9IeZ1chk2TWvekdtwWCImWryxt
|
||||
NK1ISODCbgNSxJEnOgKJp/A+B3rxzDk5naRORdsxQo8V6dewqQrnp84DveTH
|
||||
RpOZvEN5M5P/69wv0WgKortkNYlknMubJ+If7NYd9rEIQqRI3vHtkMisDfDu
|
||||
XP+TUhiIvMPRuH/sC5rzRhfuQ6kl/C/fm+PeOfv3sROfjGyvqvfgfhr4lnBV
|
||||
2haMJTO0wpzTR3uj19gH0FdEe5zTAaSjIkI/Jzk5oFk8yJhaG0brzgAIJ9Nc
|
||||
9Szm3iXWmNZ+ECPURZyZ0M8mnZ0FGTaMDYxNgJzpvSvZNJ3bHvk6riTt924r
|
||||
jMqJt18EBlHlMqijE0KK7UCb0xnAiyWGHqg6AL0NVVv9zb7Fo2gQ2XeALgPV
|
||||
TFX2m6ooUe+2+k+nOQiaWx3P+g3BJ8UsWmyPDlMNV3sVpdbK2SxcpVniBxxX
|
||||
S55gFCiA/cAR09MAEQEAAcLBXwQYAQgACQUCXQlPbQIbDAAKCRA3h0ARV3ZF
|
||||
eRb+D/9HqCmvci0Hb4W+kj0pjPKC9+UrNRTFehk9AjSo2apozsj6jEm/VxQ6
|
||||
TSe791Pog2uHRIxBsdJMJGeQweJPlIppj8P7u3jSFoJzCqjcA4gw74fX/wrj
|
||||
seic093LF6Kj54ZTcbamwDG2QzYoG4nmDo9vGeSnH4Laep+hnTmt0Z4DNAZL
|
||||
597G56kz9z0cEpqUuKX8o4+KjyxMvY8s/Fyl3r3H6wQklBORIjtOFZGxMKrL
|
||||
iG4u7S0kSKeb+EuJnMJ1TwconYoQbyw/6YpB4NDAXjI8omamDgXVq7K1Tq0d
|
||||
B4yfT77/oEsynwYvtAJuOqTUnl9P5qxMxsaz37b0XZAH3LBP3kMAF854b1di
|
||||
EcQ2qEt+WfC8aD1ggq0fV9OcQsB7bdgKEQjFvmu6B3X6zVTavKx+2BT4Yf1I
|
||||
sP653T0MA18j96O4RRxlAEOW+1j3p6XsNRTDuAuWzmpdq/E2KcfdJ11q9EDn
|
||||
JXtRgfeOoXe79uBZftbIKwNZRy9DAyCUTpQR7V9EGppz37b7sYswLXJGOlwE
|
||||
5siUjvePbo0wA9isBEWu0SqQddgFKbUFeLl0YFLFiJU7EHuTSdw/mirToK59
|
||||
mie8azMPT2b90c5pBBBz9FqUkMHPLdJKR0UuaZGbGC/D2TKv928KSrymjlaQ
|
||||
cN4UNoeD4hpgWl16VHn1wtOl5AEGkg==
|
||||
=/+Vo
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
```
|
||||
### John Woeltz
|
||||
```
|
||||
-----BEGIN PGP PUBLIC KEY BLOCK-----
|
||||
|
||||
mQINBF0cFe0BEACkDxjFLQmLI2v8BglkF4sbrSZtqO4jUvSMB2bCW84p+Hl7/XOK
|
||||
4fgiqOoyLMIFqq8o3p7rQD2zqV43CvSZbtXz/GXXybHm8MzRRGBOj4iY5tIfwUEP
|
||||
pVRCyZ7tPh8B0Y/fsY9Cn652tl3QnH+SX7yrNNfszwAmKT2qVRb5tGTknhWNpEeZ
|
||||
gGh/lEUrru01iXt/vA2Vjsx215x1JVotZtpOYFgbe2VfNlrqzxBVQysV1IO9/TfB
|
||||
ziOxQ1oCqvypKKL+M1HLmwj18fUJywwkukZJOxMhsIkHdc7tOZn5lxT8V/PYXK8w
|
||||
Rs/YJ90pGN850bsxsAw2KgVdqkk2G6vSH8UkhL00/KORYxqchh0PoOSMq7P6Vnka
|
||||
+uZA8xulOlbGoupyX/r9PYrqvV96xaXCxPdjztmDCgi4lXwa6d0PzJnWrqKFu4gk
|
||||
IiieHnVsimR6daPePRXkjSWN5VQX8QU9xPiK6/FuoKm6JQhFQEMkM8zDyi9A+L1E
|
||||
FryaoRsUocJdwVdPYTGogFiIBO+4ny3pEhIZJdnSWewoX7GhOldPgrT66zUvX7Uq
|
||||
U+evfuGFQOhAUByN8XWtJ0ws1fwqiENaoD4FYMSwYIcrdxFelTnfQoaHTZINntRp
|
||||
mAy1s/x2i84qv6c+5urjjOc7b/SxnlnMcHtlDI+gt7AcV3Ew6sXQVXO+bwARAQAB
|
||||
tCJKb2huIFdvZWx0eiA8am9sdHpAcHJvdG9ubWFpbC5jb20+iQJUBBMBCgA+FiEE
|
||||
pwlDvRCYWLUDTiOsmWn1cMLvYW8FAl0cFe0CGwMFCQWiy9MFCwkIBwMFFQoJCAsF
|
||||
FgIDAQACHgECF4AACgkQmWn1cMLvYW8F4g/+OkqbxnPXAAwzY24YzBsfhMGlTsWA
|
||||
l08AkKRGStbsUzOyGSkNBQq4TDFd2A8bHdw/9w8g0OVs7Dddj5S5EXoNF2MhsCzK
|
||||
r6IBaU9vMDhochZCsX44TbemttD/XW5LSQ04YHuQgPP7ESDAllkKaKgiopoRCHnv
|
||||
GwBsXVwOlY75uwHkZBlR5tqYmFTLrlvZZppf8YsLxRPf7RmpMa29A+/tZieurN0n
|
||||
5k3DKsAP16QcxLdHDfuZovmKjUW0HEzUZ2qhxY4n0JyUuGrU58q02gy1vm2OZW/3
|
||||
4h/WIZ94UUbQQBRESI8o+8VpsVN8dJRqI7TzJnChWVMnxl8XE0nZAgddrf/91xvS
|
||||
U0NhP/MgW5/VQpWyu/45vsckTCgtHQA6mQ/pn5tBR+8nEhCa8SWRJIEvNKcAuA2o
|
||||
ErNLbxhmUv6vH9PNbRLNtt1njQnihU8IBUIHcBK94t8O3T7jAxluwDrDao2t10fe
|
||||
/ILO7gxWZyFwhlAEvMd7arNu/8bQ027gANEBYpI8o/cn8CkhKQIEG8Uq2vJJk4yw
|
||||
S4rbojQgLksID5zat58MP9PBaf9yTe9zI2p0Xe4m+cR794vvKK0wGuAWqtdKnUO9
|
||||
Fgh6qcg4cxOE5xiY208zE60ILBi4ayJ4Uo/1QHcTLtJy4tNknheQ9GYcSipb3rgu
|
||||
DdyDBSuMwkwdx1a5Ag0EXRwV7QEQAOd20rfa3/yeh8m1BZjJ/2oxUlB9wd4ZOsVz
|
||||
yyPEXir7JsJaw3LQXYcWeR9MNCZrmUERnkbkZmOFZvaHEYnt+GYepk/fY2kHiTJ/
|
||||
/D8TwKCmbO5mddpSDPRvMtWbYHWKfZI+NvnWOx4Pd8FkjlQ9qYDQsZOEKTRRh/48
|
||||
M+0HE2dum3jSFc5mIN0OnvT9BXtk3B+2DcCKe6tM8uvEPdYXxJIosu9kfLxDeXdA
|
||||
Pk9cF1rgDDWvYmgJdDXlV++l4FlS13Me5mvZP/NuIdf9qeCHT3ikQqBCOjl/Zc0c
|
||||
FlH5VZk3yqu5NuDKNKa4vc2qmr2haPUotgeyX7mqMIXQGJLt97bd7u+7IIhkVz2S
|
||||
hbZk4TO02x3hVqxHQtH5BDFxWqoDSoMuVfSm0QVDNNqSFZuEPjjbdjXuv9f3AIwJ
|
||||
Jn1GNXxh+JdKxnOMmlbFp6s0qCvt6oetye3mKtOrk50PBZv9EDaZr8Sj6IoYP2TE
|
||||
GfjVxxzMcKPhmS8DkV8yH3TlVwEzR9pbgt7MwK6uz/QH0FEhjQnYKWcfX4Mcjx75
|
||||
BffBbhVAlv7hIJd7ymXR7E8grfIxx6K8Qk9pW1WWBxkEmfrClla+tu8W7rZpy2Ts
|
||||
bfRzLrpcr2pTSFgpH7qKFZAFY4VTCT0Ecn50ObNWvXExSyr3udoI3olMtPVw1O9v
|
||||
XK3yfUDRABEBAAGJAjwEGAEKACYWIQSnCUO9EJhYtQNOI6yZafVwwu9hbwUCXRwV
|
||||
7QIbDAUJBaLL0wAKCRCZafVwwu9hbxzVD/4jhYx62WIjO6cFKMHC7xpIUgfubJxe
|
||||
2mx502Iyf/nnmqBAv9COGERxqFcMyK7TijtPIVHQqhVJwROYOOYLyA/DnJtyezAt
|
||||
JivvSZmQJ2pi1aMMvqdQEkoDiUy753mnIRnwEBCALqGLLEb6k1JZAXmhiL2vy5ie
|
||||
pJ/nWgFKuf4t+CFov17790uEpMTCqLYuUJ5PdteAwOjnXoX+VVeqX/LiYXQ0XggQ
|
||||
LCMlWTZJaSFfUbaOi+qouuIsLUldeptZAh/Ll3Y0NXkWyeoMx2p85lARrOxuGKBe
|
||||
LTV/uPljaRf2s3zu7fkNA2BWB0jS2jJnPglpywNqcTQbozACLQmhaBKcxJMKkNT3
|
||||
LPX7vlrxIrJ6UGQDdmfCa/AOhbqhp/Cdd6p+W627PQux8v+QP5SvCbWQ8/8/HQoW
|
||||
cL/iWHWv4X4QpWmekrmtsohTOkKR0sJXjYlZFq4IQ25lWLYCOfi2BRJdrmxNmZ+S
|
||||
ELYyPsg/8R9g4QSYeSaNlIOoVVB5zt8fCRUb8P1gYR8lvA57TbwDMre5Ev38JK3a
|
||||
6a0/6+BRHw6gfeHZdywYQdvmz+AdfsBBTr3E3lVEpfUDm0jPvXneD3a2HG3jA/ym
|
||||
Rjpq9ALXjCK/h57vaZExeWItWV75kFSFucWfr/wCKkOS8MLPXUhhrtWuigAdOpXa
|
||||
OXCaSbMWSCzC0g==
|
||||
=BniA
|
||||
-----END PGP PUBLIC KEY BLOCK-----
|
||||
```
|
||||
|
|
|
|||
|
|
@ -183,14 +183,14 @@ pub const DIFFICULTY_DAMP_FACTOR: u64 = 3;
|
|||
pub const AR_SCALE_DAMP_FACTOR: u64 = 13;
|
||||
|
||||
/// Compute weight of a graph as number of siphash bits defining the graph
|
||||
/// Must be made dependent on height to phase out smaller size over the years
|
||||
/// This can wait until end of 2019 at latest
|
||||
/// Must be made dependent on height to phase out C31 in early 2020
|
||||
/// Later phase outs are on hold for now
|
||||
pub fn graph_weight(height: u64, edge_bits: u8) -> u64 {
|
||||
let mut xpr_edge_bits = edge_bits as u64;
|
||||
|
||||
let bits_over_min = edge_bits.saturating_sub(global::min_edge_bits());
|
||||
let expiry_height = (1 << bits_over_min) * YEAR_HEIGHT;
|
||||
if height >= expiry_height {
|
||||
if edge_bits < 32 && height >= expiry_height {
|
||||
xpr_edge_bits = xpr_edge_bits.saturating_sub(1 + (height - expiry_height) / WEEK_HEIGHT);
|
||||
}
|
||||
|
||||
|
|
@ -382,23 +382,29 @@ mod test {
|
|||
|
||||
// 2 years in, 31 still at 0, 32 starts decreasing
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT, 31), 0);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT, 32), 512 * 31);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT, 32), 512 * 32);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT, 33), 1024 * 33);
|
||||
|
||||
// 32 loses one factor per week
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT + WEEK_HEIGHT, 32), 512 * 30);
|
||||
// 32 phaseout on hold
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT + WEEK_HEIGHT, 32), 512 * 32);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT + WEEK_HEIGHT, 31), 0);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT + 30 * WEEK_HEIGHT, 32), 512);
|
||||
assert_eq!(graph_weight(2 * YEAR_HEIGHT + 31 * WEEK_HEIGHT, 32), 0);
|
||||
assert_eq!(
|
||||
graph_weight(2 * YEAR_HEIGHT + 30 * WEEK_HEIGHT, 32),
|
||||
512 * 32
|
||||
);
|
||||
assert_eq!(
|
||||
graph_weight(2 * YEAR_HEIGHT + 31 * WEEK_HEIGHT, 32),
|
||||
512 * 32
|
||||
);
|
||||
|
||||
// 3 years in, nothing changes
|
||||
assert_eq!(graph_weight(3 * YEAR_HEIGHT, 31), 0);
|
||||
assert_eq!(graph_weight(3 * YEAR_HEIGHT, 32), 0);
|
||||
assert_eq!(graph_weight(3 * YEAR_HEIGHT, 32), 512 * 32);
|
||||
assert_eq!(graph_weight(3 * YEAR_HEIGHT, 33), 1024 * 33);
|
||||
|
||||
// 4 years in, 33 starts starts decreasing
|
||||
// 4 years in, still on hold
|
||||
assert_eq!(graph_weight(4 * YEAR_HEIGHT, 31), 0);
|
||||
assert_eq!(graph_weight(4 * YEAR_HEIGHT, 32), 0);
|
||||
assert_eq!(graph_weight(4 * YEAR_HEIGHT, 33), 1024 * 32);
|
||||
assert_eq!(graph_weight(4 * YEAR_HEIGHT, 32), 512 * 32);
|
||||
assert_eq!(graph_weight(4 * YEAR_HEIGHT, 33), 1024 * 33);
|
||||
}
|
||||
}
|
||||
|
|
|
|||
221
doc/intro_SE.md
221
doc/intro_SE.md
|
|
@ -42,17 +42,17 @@ möjligheter att [lära sig mer](http://andrea.corbellini.name/2015/05/17/ellipt
|
|||
|
||||
En elliptisk kurva för kryptografiska är ändamål är enkelt sagt en stor mängd av punkter
|
||||
som vi kallar för _C_. Dessa punkter kan adderas, subtraheras, eller multipliceras med heltal (även kallat skalärer).
|
||||
Given ett heltal _k_ kan vi beräkna `k*H` med skalärmultiplikation, vilket också är en punkt på kurvan _C_. Given ett annat
|
||||
Given en sådan punkt _H_ och ett heltal _k_ kan vi beräkna `k*H` med skalärmultiplikation, vilket också är en punkt på kurvan _C_. Given ett annat
|
||||
heltal _j_ kan vi också beräkna `(k+j)*H`, vilket är lika med `k*H + j*H`. Addition och skalärmultiplikation på elliptiska
|
||||
kurvor behåller sina kommutativa och associativa egenskaper från vanlig addition och multiplikation:
|
||||
|
||||
(k+j)*H = k*H + j*H
|
||||
|
||||
Inom ECC, om vi väljer ett väldigt stort tal _k_ som privat nyckel så anses `k*H` vara dess publika nyckel. Även om
|
||||
Om vi inom ECC väljer ett väldigt stort tal _k_ som privat nyckel så anses `k*H` vara dess publika nyckel. Även om
|
||||
man vet värdet av den publika nyckeln `k*H`, är det nästintill omöjligt att härleda `k` (sagt med andra ord, medan
|
||||
multiplikation är trivialt är "division" med kurvpunkter extremt svårt).
|
||||
multiplikation med kurvpunkter är trivialt är "division" extremt svårt).
|
||||
|
||||
Den föregående formeln `(k+j)*H = k*H + j*H`, med _k_ och _j_ båda privata nycklar demonstrerar att en publik nyckel
|
||||
Den föregående formeln `(k+j)*H = k*H + j*H`, med _k_ och _j_ båda som privata nycklar, demonstrerar att en publik nyckel
|
||||
erhållen av att ha adderat de två privata nycklarna är identisk med de två privata nycklarnas respektive
|
||||
publika nycklar adderade (`k*H + j*H`). I Bitcoin-blockkedjan använder hierarkiska deterministiska plånböcker (HD wallets)
|
||||
sig flitigt av denna princip. MimbleWimble och Grin-implementationer gör det också.
|
||||
|
|
@ -64,55 +64,55 @@ starka garantier av integritet och konfidentialitet.
|
|||
|
||||
Valideringen av MimbleWimble-transaktioner använder sig av två grundläggande egenskaper:
|
||||
|
||||
* **Kontroll av nollsummor.** Summan av utmatningar minus inmatningar är alltid lika med noll, vilket bevisar—utan att
|
||||
* **Kontroll av nollsummor.** Summan av outputs minus inputs är alltid lika med noll, vilket bevisar—utan att
|
||||
avslöja beloppen—att transaktionen inte skapade nya pengar.
|
||||
* **Innehav av privata nycklar.** Som med de flesta andra kryptovalutar garanteras ägandet av transaktionsutmatningar
|
||||
* **Innehav av privata nycklar.** Som med de flesta andra kryptovalutor garanteras ägandet av outputs (UTXOs)
|
||||
med innehavet av privata nycklar. Dock bevisas inte ägandet av dem genom en direkt signering av transaktionen.
|
||||
|
||||
De följande styckena angående saldo, ägande, växel, och bevis klarlägger hur de två grundläggande egenskaperna uppnås.
|
||||
De följande styckena angående saldo, ägande, växel, och range proofs klarlägger hur de två grundläggande egenskaperna uppnås.
|
||||
|
||||
#### Saldo
|
||||
|
||||
Bygger vi på ECC-egenskaperna vi förklarade ovan kan vi beslöja beloppen i en transaktion.
|
||||
|
||||
Om _v_ är beloppet av en inmatning eller utmatning i en transaktion och _H_ en elliptisk kurva, kan vi enkelt bädda in
|
||||
`v*H` i stället för _v_ i en transaktion. Detta fungerar eftersom vi fortfarande kan bekräfta att summan av utmatningarna är
|
||||
lika med summan av inmatningarna i en transaktion med hjälp av ECC-operationer:
|
||||
Om _v_ är beloppet av en input eller output och _H_ en punkt på den elliptiska kurvan _C_, kan vi enkelt bädda in
|
||||
`v*H` i stället för _v_ i en transaktion. Detta fungerar eftersom vi fortfarande kan bekräfta att summan av outputs är
|
||||
lika med summan av inputs i en transaktion med hjälp av ECC-operationer:
|
||||
|
||||
v1 + v2 = v3 => v1*H + v2*H = v3*H
|
||||
|
||||
Bekräftandet av denna egenskap på alla transaktioner låter protokollet bekräfta att en transaktion inte skapar pengar ur
|
||||
tomma intet utan att veta vad beloppen är. Dock finns det ett begränsat antal av användbara belopp och man skulle kunna
|
||||
prova varenda en för att gissa beloppet på din transaktion. Dessutom, om man känner till v1 (till exempel från en föregående
|
||||
transaktion) och det resulterande `v1*H` avslöjar man alla utmatningar med beloppet v1 över hela blockkedjan. Av dessa
|
||||
anledningar introducerar vi en till elliptisk kurva _G_ (i praktiken är _G_ endast en annan generatorpunkt på samma kurvgrupp
|
||||
som _H_) och en privat nyckel _r_ som används som en *bländande faktor*.
|
||||
prova varenda en för att gissa beloppet på transaktionen. Dessutom, om man känner till _v1_ (till exempel från en föregående
|
||||
transaktion) och det resulterande `v1*H` avslöjas alla outputs med beloppet _v1_ över hela blockkedjan. Av dessa
|
||||
anledningar introducerar vi en andra punkt _G_ på samma elliptiska kurva och en privat nyckel _r_ som används som en *förblindningsfaktor*.
|
||||
|
||||
Ett inmatnings- eller utmatningsbelopp i en transaktion kan uttryckas som:
|
||||
En input eller output i en transaktion kan uttryckas som:
|
||||
|
||||
r*G + v*H
|
||||
|
||||
Där:
|
||||
|
||||
* _r_ är en privat nyckel använd som en bländande faktor, _G_ är en elliptisk kurva, och deras
|
||||
produkt `r*G` är den publika nyckeln för _r_ på _G_.
|
||||
* _v_ är ett inmatnings- eller utmatningsbelopp och _H_ är en annan elliptisk kurva.
|
||||
* _r_ är en privat nyckel använd som en förblindningsfaktor, _G_ är en punkt på elliptiska kurvan _C_, och deras
|
||||
produkt `r*G` är den publika nyckeln för _r_ (med _G_ som generatorpunkt).
|
||||
* _v_ är ett input- eller output-belopp och _H_ är en annan punkt på kurvan _C_ som tillsammans producerar en annan
|
||||
public nyckel `v*H` (med _H_ som generatorpunkt).
|
||||
|
||||
Varken _v_ eller _r_ kan härledas på grund av ECC:s grundläggande egenskaper. `r*G + v*H` kallas för
|
||||
ett _Pedersen Commitment_.
|
||||
|
||||
Som ett exempel, låt oss anta att vi vill skapa en transaktion med två inmatningar och en utmatning.
|
||||
Som ett exempel, låt oss anta att vi vill skapa en transaktion med två inputs och en output.
|
||||
Vi har (utan hänsyn till avgifter):
|
||||
|
||||
* vi1 och vi2 som inmatningsbelopp.
|
||||
* vo3 som utmatningsbelopp.
|
||||
* vi1 och vi2 som input-belopp.
|
||||
* vo3 som output-belopp.
|
||||
|
||||
Sådana att:
|
||||
|
||||
vi1 + vi2 = vo3
|
||||
|
||||
Vi genererar en privat nyckel som en bländande faktor för varje inmatningsbelopp och ersätter alla belopp med
|
||||
deras respektive Pedersen Commitment och ekvationen blir därmed:
|
||||
Vi genererar en privat nyckel som en förblidningsfaktor för varje input och ersätter alla belopp med
|
||||
deras respektive Pedersen Commitment och får därmed:
|
||||
|
||||
(ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vi3*H)
|
||||
|
||||
|
|
@ -129,16 +129,15 @@ som i sin tur härstammar från ett förslag av Adam Back för homomorfiska belo
|
|||
|
||||
#### Ägande
|
||||
|
||||
I föregående stycke introducerade vi en privat nyckel som en bländande faktor för att dölja transaktionens belopp.
|
||||
I föregående stycke introducerade vi en privat nyckel som en förblindningsfaktor för att dölja transaktionens belopp.
|
||||
MimbleWimbles andra insikt är att denna privata nyckel kan användas för att bevisa ägande av beloppet.
|
||||
|
||||
Alice skickar 3 mynt till dig och för att dölja beloppet väljer du 28 som din bländande faktor (notera att i praktiken
|
||||
är den bländande faktorn ett extremt stort tal). Någonstans i blockkedjan dyker följande utmatning upp och ska endast
|
||||
vara spenderbar av dig:
|
||||
Alice skickar 3 mynt till dig och för att dölja beloppet väljer du 28 som din förblindningsfaktor (notera att förblindningsfaktorn i praktiken
|
||||
är ett extremt stort tal). Någonstans i blockkedjan dyker följande output upp och ska endast kunna spenderas av dig:
|
||||
|
||||
X = 28*G + 3*H
|
||||
|
||||
_X_ som är resultatet av additionen är synlig för alla. Beloppet 3 är endast känt av dig och Alice, och 28 är endast
|
||||
_X_ som är summan är synlig för alla. Beloppet 3 är endast känt av dig och Alice, och 28 är endast
|
||||
känt av dig.
|
||||
|
||||
För att skicka dessa 3 mynt igen kräver protokollet att 28 ska vara känt. För att demonstrera hur detta fungerar, låt
|
||||
|
|
@ -146,7 +145,7 @@ oss säga att du vill skicka samma 3 mynt till Carol. Du behöver skapa en simpe
|
|||
|
||||
Xi => Y
|
||||
|
||||
Där _Xi_ är en inmatning som spenderar din _X_-utmatning och Y är Carols utmatning. Det finns inget sätt att skapa
|
||||
Där _Xi_ är en input som spenderar din _X_-output och Y är Carols output. Det finns inget sätt att skapa
|
||||
en sådan transaktion utan att känna till din privata nyckel 28. Om Carol ska balansera denna transaktion behöver hon
|
||||
både känna till det skickade beloppet och din privata nyckel så att:
|
||||
|
||||
|
|
@ -154,24 +153,24 @@ både känna till det skickade beloppet och din privata nyckel så att:
|
|||
|
||||
Genom att kontrollera att allt har nollställts kan vi återigen försäkra oss om att inga nya pengar har skapats.
|
||||
|
||||
Vänta! Stopp! Nu känner du till den privata nyckeln i Carols utmatning (vilket i detta fall måste vara samma som ditt
|
||||
för att balansera in- och utmatningarna) så du skulle kunna stjäla tillbaka pengarna från Carol!
|
||||
Vänta! Stopp! Nu känner du till den privata nyckeln i Carols output (vilket i detta fall måste vara samma som ditt
|
||||
för att balansera inputs och outputs) så du skulle kunna stjäla tillbaka pengarna från Carol!
|
||||
|
||||
För att lösa detta problem använder Carol en privat nyckel som hon väljer själv. Låt oss säga att hon väljer 113.
|
||||
Det som hamnar i blockkedjan är:
|
||||
|
||||
Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H
|
||||
|
||||
Nu summeras transaktionen inte längre till noll och vi har ett _överskottsbelopp_ på _G_ (85), vilket är resultatet
|
||||
av summeringen av alla bländande faktorer. Men eftersom `85*G` är en giltig publik nyckel på elliptiska kurvan _C_ vet vi
|
||||
att in- och utmatningarna har subtraheras till noll och transaktionen är därmed giltig.
|
||||
Nu summeras transaktionen inte längre till noll och vi har ett _överskottsbelopp_ (85), vilket är resultatet
|
||||
av summeringen av alla förblindningsfaktorer. Eftersom `85*G` är en giltig publik nyckel för generatorpunkt _G_ vet vi
|
||||
att alla inputs och outputs har balanserats och transaktionen därmed är giltig då `x*G + y*H` är en giltig publik nyckel för generatorpunkt _G_ om och endast om `y = 0`.
|
||||
|
||||
Så allt protokollet behöver göra är att kontrollera att (`Y - Xi`) är en giltig publik nyckel på _G_ och att de två parter
|
||||
som utför transaktionen tillsammans kan producera den privata nyckeln (85 i exemplet ovan). Det enklaste sättet att göra
|
||||
Så allt protokollet behöver göra är att kontrollera att (`Y - Xi`) är en giltig publik nyckel för generatorpunkt _G_ och att de två parter
|
||||
som utför transaktionen tillsammans kan producera dess privata nyckel (85 i exemplet ovan). Det enklaste sättet att göra
|
||||
det är att kräva en signatur med överskottsbeloppet (85), vilket bekräftar att:
|
||||
|
||||
* De parter som utför transaktionen känner till den privata nyckeln, och
|
||||
* Summan av utmatningarna minus inmatningarna i transaktionen är noll (eftersom överskottsbeloppet måste vara en publik nyckel).
|
||||
* De parter som utför transaktionen tillsammans kan beräkna den privata nyckeln (överskottsbeloppet)
|
||||
* Summan av outputs minus inputs i transaktionen är noll (eftersom endast en giltig publik nyckel kan validera signaturen).
|
||||
|
||||
Denna signatur som tillsammans med lite annan information (som exempelvis mining-avgifter) bifogas till transaktionen kallas
|
||||
för _transaktionskärna_ och kontrolleras av alla validerare.
|
||||
|
|
@ -186,10 +185,10 @@ och Grin, så om du har bråttom känn dig fri att hoppa direkt till [Sammanstä
|
|||
|
||||
Låt oss säga att du endast vill skicka 2 mynt till Carol av de 3 mynt du mottog från Alice. För att göra detta behöver du
|
||||
skicka det återstående myntet tillbaka till dig själv som växel. Du genererar en annan privat nyckel (t ex 12) som en
|
||||
bländande faktor för att skydda ditt växel-utmatningsbelopp. Carol använder sin egen privata nyckel som tidigare.
|
||||
förblindningsfaktor för att skydda beloppet på din växel-output. Carol använder sin egen privata nyckel som tidigare.
|
||||
|
||||
Växel-utmatning: 12*G + 1*H
|
||||
Carols utmatning: 113*G + 2*H
|
||||
Växel-output: 12*G + 1*H
|
||||
Carols output: 113*G + 2*H
|
||||
|
||||
Det som hamnar i blockkedjan är något väldigt likt det vi hade tidigare, och signaturen är återigen skapat med
|
||||
överskottsbeloppet, 97 i detta exempel.
|
||||
|
|
@ -201,58 +200,64 @@ Det som hamnar i blockkedjan är något väldigt likt det vi hade tidigare, och
|
|||
I alla beräkningar ovan förlitar vi oss på att alla belopp är positiva. Introduktionen av negativa belopp skulle vara
|
||||
extremt problematiskt då man skulle kunna skapa nya pengar i varje transaktion.
|
||||
|
||||
Till exempel skulle man kunna skapa en transaktion med inmatningen 2 och utmatningar 5 och -3 och fortfarande
|
||||
Till exempel skulle man kunna skapa en transaktion med input-belopp 2 och output-belopp 5 och -3 och fortfarande
|
||||
ha en balanserad transaktion. Detta kan inte upptäcklas enkelt eftersom punkten `x*H` ser ut som vilken annan punkt
|
||||
som helst på kurvan även om _x_ är negativt.
|
||||
|
||||
För att lösa detta problem använder MimbleWimble sig av ett kryptografiskt koncept som kallas "range proofs" (som också härstammar
|
||||
från Confidential Transactions): ett bevis på att ett tal befinner sig inom ett visst intervall utan att avsölja talet.
|
||||
Vi kommer inte att förklara range proofs; du behöver endast veta att för varje `r*G + v*H` kan vi skapa ett bevis som visar
|
||||
Vi kommer inte att förklara range proofs; du behöver endast veta att vi för varje `r*G + v*H` kan skapa ett bevis som visar
|
||||
att _v_ är större än noll och inte orsakar overflow.
|
||||
|
||||
Det är även viktigt att notera att både värdet 113 och värdet 28 måste vara kända för att kunna skapa ett giltigt range proof.
|
||||
Anledningen till detta och en mer utförlig beskrivning av range proofs är förklarat i
|
||||
Det är även viktigt att notera att range proofs krävs för både förblindningsfaktorn och beloppet. Anledningen till detta är att det förhindrar en censureringsattack där en tredje part skulle kunna låsa en UTXO utan att känna till desss privata nyckel genom att skapa följande transaktion:
|
||||
|
||||
Carols UTXO: 133*G + 2*H
|
||||
Attackerarens output: (113 + 99)*G + 2*H
|
||||
|
||||
vilket kan signeras av attackeraren eftersom Carols förblindningsfaktor nollställs i ekvationen `Y - Xi`:
|
||||
|
||||
Y - Xi = ((113 + 99)*G + 2*H) - (113*G + 2*H) = 99*G
|
||||
|
||||
Denna output (`(113 + 99)*G + 2*H`) kräver att både talen 113 och 99 är kända för att kunna spenderas; attackeraren skulle därmed ha lyckats låsa Carols UTXO. Kravet på range proof för förblindingsfaktorn förhindrar detta eftersom attackeraren inte känner till 113 och därmed inte heller (113 + 99). En mer utförlig beskrivning av range proofs är förklarat i
|
||||
[range proof-pappret](https://eprint.iacr.org/2017/1066.pdf).
|
||||
|
||||
#### Sammanställningen av allt
|
||||
|
||||
En MimbleWimble-transaktion inkluderar följande:
|
||||
|
||||
* En mängd inmatningar som refererar till och spenderar en mängd föregående utmatningar.
|
||||
* En mängd nya utmatningar som inkluderar:
|
||||
* Ett belopp och en bländande faktor (vilket bara är en ny privat nyckel) multiplicerade på en kurva och adderade
|
||||
* En mängd inputs som refererar till och spenderar en mängd föregående outputs.
|
||||
* En mängd nya outputs som inkluderar:
|
||||
* Ett belopp och en förblindningsfaktor (vilket bara är en ny privat nyckel) multiplicerade på en kurva och adderade
|
||||
till att bli `r*G + v*H`.
|
||||
* Ett range proof som visar att v är icke-negativt.
|
||||
* En tydlig transaktionsavgift i klartext.
|
||||
* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla utmatningar och
|
||||
avgiften minus inmatningarna).
|
||||
* Ett range proof som bland annat visar att v är icke-negativt.
|
||||
* En transaktionsavgift i klartext.
|
||||
* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla outputs och
|
||||
avgiften minus inputs).
|
||||
|
||||
### Block och kedjetillstånd
|
||||
|
||||
Vi förklarade ovan hur MimbleWimble-transaktioner kan erbjuda starka anonymitetsgarantier samtidigt som de
|
||||
upprätthåller egenskaperna för en giltig blockkedja, d.v.s en transaktion skapar inte pengar och ägandebevis är
|
||||
fastställt med privata nycklar.
|
||||
upprätthåller egenskaperna för en giltig blockkedja, d v s att en transaktion inte skapar pengar och att ägandebevis
|
||||
fastställs med privata nycklar.
|
||||
|
||||
MimbleWimble-blockformatet bygger på detta genom att introducera ett till koncept: _genomskärning_. Med detta
|
||||
MimbleWimble-blockformatet bygger på detta genom att introducera ett till koncept: _cut-through_. Med detta
|
||||
får en MimbleWimble-kedja:
|
||||
|
||||
* Extremt bra skalbarhet då den stora majoriteten av transaktionsinformation kan elimineras på lång sikt utan att
|
||||
kompromissa säkerhet.
|
||||
* Ytterligare anonymitet genom att blanda och ta bort transaktionsinformation.
|
||||
* Förmågan att effektivt synkronisera sig med resten av nätverket för nya noder.
|
||||
|
||||
#### Transaktionsaggregation
|
||||
|
||||
Kom igåg att en transaktion består av följande:
|
||||
|
||||
* En mängd inmatningar som refererar till och spenderar en mängd föregående utmatningar
|
||||
* En mängd nya utmatningar (Pedersen commitments)
|
||||
* En mängd inputs som refererar till och spenderar en mängd föregående outputs
|
||||
* En mängd nya outputs
|
||||
* En transaktionskärna som består av:
|
||||
* överskottsbelopp
|
||||
* transaktionssignatur
|
||||
* kärnöverskottet (överskottsbeloppets publika nyckel)
|
||||
* transaktionssignatur vars publika nyckel är kärnöverskottet
|
||||
|
||||
En transaktion signeras och signaturen inkluderas i en transaktionskärna. Signaturen genereras genom att använda
|
||||
överskottsbeloppet som en publik nyckel för att bevisa att beloppen summeras till 0:
|
||||
En transaktion valideras genom att kärnöverskottet faställs vara en giltig publik nyckel:
|
||||
|
||||
(42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H
|
||||
|
||||
|
|
@ -260,57 +265,54 @@ Den publika nyckeln i detta exempel är `28*G`.
|
|||
|
||||
Vi kan säga att följande är sant för alla giltiga transaktioner (vi ignorerar avgifter för enkelhetens skull):
|
||||
|
||||
summa(utmatningar) - summa(inmatningar) = överskottsbelopp
|
||||
(summan av outputs) - (summan av inputs) = kärnöverskott
|
||||
|
||||
Detsamma gäller för blocken själva när vi inser att ett block helt enkelt är en mängd aggregerade inmatningar, utmatningar, och
|
||||
transaktionskärnor. Vi kan summera transaktionsutmatningarna, subtrahera summan av transaktionsinmatningarna, och jämföra
|
||||
det resulterande Pedersen commitment med summan av överskottsbeloppen:
|
||||
Detsamma gäller för blocken själva när vi inser att ett block helt enkelt är en mängd aggregerade inputs, outputs, och
|
||||
transaktionskärnor. Vi kan summera alla outputs, subtrahera det med summan av alla inputs, och likställa vårt resulterande Pedersen commitment med summan av kärnöverskotten:
|
||||
|
||||
summa(utmatningar) - summa(inmatningar) = summa(överskottsbelopp)
|
||||
(summan av outputs) - (summan av inputs) = (summan av kärnöverskott)
|
||||
|
||||
|
||||
Något förenklat, (återigen ignorerar vi transaktionsavgifter) kan vi säga att MimbleWimble-block kan betraktas precis som
|
||||
Något förenklat (återigen utan hänsyn till transaktionsavgifter) kan vi säga att MimbleWimble-block kan betraktas precis som
|
||||
MimbleWimble-transaktioner.
|
||||
|
||||
##### Kärn-offset
|
||||
|
||||
Det finns ett subtilt problem med MimbleWimble-block och transaktioner som beskrivet ovan. Det är möjligt (och i vissa fall
|
||||
trivialt) att rekonstruera de konstituerande transaktionerna i ett block. Detta är naturligtvis dåligt för integriteten.
|
||||
Detta är "delmängdsproblemet": given en mängd inmatningar, utmatningar, och transaktionskärnor kommer någon delmängd av detta
|
||||
Detta kallas för "delmängdsproblemet": givet en mängd inputs, outputs, och transaktionskärnor kommer någon delmängd av detta
|
||||
kunna kombineras för att rekonstruera en giltig transaktion.
|
||||
|
||||
Till exempel, vi har följande två transaktioner:
|
||||
Betrakta dessa två transaktioner:
|
||||
|
||||
(inmatning1, inmatning2) -> (utmatning1), (kärna1)
|
||||
(inmatning3) -> (utmatning2), (kärna2)
|
||||
(input1, input2) -> (output1), (kärna1)
|
||||
(input3) -> (output2), (kärna2)
|
||||
|
||||
Vi kan aggregera dem till följande block:
|
||||
|
||||
(inmatning1, inmatning2, inmatning3) -> (utmatning1, utmatning2), (kärna1, kärna2)
|
||||
(input1, input2, input3) -> (output1, output2), (kärna1, kärna2)
|
||||
|
||||
Det är trivialt att testa alla möjliga kombinationer och återskapa en av transaktionerna (där summan lyckas bli noll).
|
||||
|
||||
(inmatning1, inmatning2) -> (utmatning1), (kärna1)
|
||||
(input1, input2) -> (output1), (kärna1)
|
||||
|
||||
Vi vet också att allt som kvarstår kan användas för att rekonstruera den andra giltiga transaktionen:
|
||||
|
||||
(inmatning3) -> (utmatning2), (kärna2)
|
||||
(input3) -> (output2), (kärna2)
|
||||
|
||||
För att mildra detta inkluderar vi ett _kärn-offset_ med varje överskottsbelopp. Detta är en bländande faktor som måste
|
||||
tilläggas överskottsbeloppet för att verifiera att det summeras till noll:
|
||||
För att mildra detta inkluderar vi ett _kärn-offset_ med varje transaktionskärna. Detta är en publik nyckel som måste
|
||||
tilläggas kärnöverskottet för att balansera ekvationen:
|
||||
|
||||
summa(utmatningar) - summa(inmatningar) = överskottsbelopp + kärn-offset
|
||||
(summan av outputs) - (summan av inputs) = kärnöverskott + kärn-offset
|
||||
|
||||
Vi "separerar" nyckeln `k` till `k1 + k2` under transaktionsbyggandet. För ett överskottsbelopp `(k1+k2)*G` publicerar vi
|
||||
`k1*G` (överskottet) och `k2` (offset) och signerar transaktionen med `k1*G` som tidigare. Under block-konstruktionen
|
||||
kan vi enkelt summera alla `k2`-offset för att generera ett aggregat-offset för alla transaktioner i blocket. `k2`-offsetet
|
||||
för en individuell transaktion är omöjlig att få fram.
|
||||
Vi "separerar" nyckeln `k` till `k1 + k2` under transaktionsbyggandet. Vi signerar transaktionen med `k1` och publicerar `k2` för att skapa vårt kärn-offset (`k2*G`). Vid block-konstruktionen
|
||||
kan alla kärn-offset summeras för att generera ett aggregat-offset för alla transaktioner i blocket. Kärn-offset för individuella transaktioner blir därmed omöjliga att härleda från ett färdigt block och delmängdsproblemet är löst.
|
||||
|
||||
#### Genomskärning
|
||||
|
||||
Blocks låter miners sätta ihop flera transaktioner till en enstaka mängd som läggs till på kedjan. I följande
|
||||
block-representationer som innerhåller tre transaktioner visar vi endast in- och utmatningarna. Inmatningar refererar till
|
||||
föregående utmatningar som de spenderar. Föregående utmatningar markeras med _x_.
|
||||
Blocks låter miners sätta ihop flera transaktioner till en enstaka struktur som läggs till på kedjan. I följande
|
||||
block-representationer med tre transaktioner visar vi endast inputs och outputs. Inputs refererar till
|
||||
föregående outputs som härmed spenderas. Föregående outputs markeras med _x_.
|
||||
|
||||
I1(x1) --- O1
|
||||
|- O2
|
||||
|
|
@ -323,62 +325,61 @@ föregående utmatningar som de spenderar. Föregående utmatningar markeras med
|
|||
|
||||
Vi lägger märke till följande två egenskaper:
|
||||
|
||||
* Inom detta block är vissa utmatningar spenderade direkt av inkluderade inmatningar (I3 spenderar O2, och I4 spenderar O3).
|
||||
* Inom detta block är vissa outputs spenderade direkt av påföljande inputs (I3 spenderar O2, och I4 spenderar O3).
|
||||
* Transaktionernas struktur spelar faktiskt ingen roll. Eftersom alla transaktioner individuellt summeras till noll
|
||||
måste summan av alla transaktionsinmatningar och utmatningar summera till noll.
|
||||
måste summan av alla inputs och outputs också vara noll.
|
||||
|
||||
Liknande en transaktion, allt som behöver kontrolleras i ett block är att ägandebevis (vilket kommer från transaktionskärnorna)
|
||||
och att blocket i helhet inte skapade pengar ur tomma intet. Således kan matchande inmatningar och utmatningar elimineras, då
|
||||
Liknande en transaktion, är allt som behöver kontrolleras i ett block ägandebevis (vilket kommer från transaktionskärnorna)
|
||||
och att blocket i helhet inte skapade pengar ur tomma intet (förutom det som är tillåtet vid mining). Således kan matchande inputs och outputs elimineras, då
|
||||
deras sammansatta påverkan är noll. Detta leder till följande, mycket mer kompakta block:
|
||||
|
||||
I1(x1) | O1
|
||||
I2(x2) | O4
|
||||
| O5
|
||||
|
||||
Notera att all transaktionsstruktur har eliminerats och att ordningen av in- och utmatningar inte längre spelar någon roll.
|
||||
Summan av alla in- och utmatningar garanteras fortfarande vara noll.
|
||||
Notera att all transaktionsstruktur har eliminerats och att ordningen av inputs och outputs inte längre spelar någon roll.
|
||||
Summan av alla inputs och outputs är garanterat fortfarande noll.
|
||||
|
||||
Ett block består av:
|
||||
|
||||
* En block-header.
|
||||
* En lista av alla inmatningar som kvarstår efter genomskärning.
|
||||
* En lista av alla utmatningar som kvarstår efter genomskärning.
|
||||
* Ett enstaka kärn-offset som skyddar hela blocket.
|
||||
* En block header.
|
||||
* En lista av alla inputs som kvarstår efter genomskärning.
|
||||
* En lista av alla outputs som kvarstår efter genomskärning.
|
||||
* Ett enstaka kärn-offset (aggregatet av alla kärn-offset) som skyddar hela blocket.
|
||||
* Transaktionskärnor för varje transaktion som innehåller:
|
||||
* Publika nyckeln `r*G` erhållen genom summation av alla commitments.
|
||||
* Signaturerna genererade genom överskottsbeloppet.
|
||||
* Publika nyckeln `r*G` erhållen genom summation av alla inputs och outputs.
|
||||
* Signaturen genererad av överskottsbeloppet.
|
||||
* Mining-avgiften
|
||||
|
||||
Med denna struktur erbjuder ett MimbleWimble-block extremt bra integritetsgarantier:
|
||||
|
||||
* Mellanliggande transaktioner är endast representerade av sina transaktionskärnor.
|
||||
* Alla utmatningar ser likadana ut: väldigt stora tal som inte går att skilja åt på något meningsfullt sätt.
|
||||
Om någon vill exkludera en specifik utmatning är de tvungna att exkludera alla.
|
||||
* All transaktionsstruktur har borttagits vilket gör det omöjligt att se vilka in- och utmatningar som passar ihop.
|
||||
* Mellanliggande (genomskurna) transaktioner är endast representerade av sina transaktionskärnor.
|
||||
* Alla outputs ser likadana ut: väldigt stora tal som inte går att skilja åt på något meningsfullt sätt.
|
||||
Om någon skulle vilja exkludera en specifik output skulle de vara tvungna att exkludera alla.
|
||||
* All transaktionsstruktur har tagits bort vilket gör det omöjligt att se vilka inputs och outputs som passar ihop.
|
||||
|
||||
Men ändå kan allting valideras!
|
||||
|
||||
#### Genomskärning hela vägen
|
||||
|
||||
Vi går tillbaka till blocket i föregående exempel. Utmatningarna x1 och x2 som spenderades av I1 och I2 måste ha
|
||||
dykt upp tidigare i blockkedjan. Efter att detta block adderas till blockkedjan kan de utmatningarna tillsammans med
|
||||
Vi går tillbaka till blocket i föregående exempel. Outputs x1 och x2 som spenderades av I1 och I2 måste ha
|
||||
dykt upp tidigare i blockkedjan. Efter att detta block adderas till blockkedjan kan dessa outputs tillsammans med
|
||||
I1 och I2 alla tas bort från blockkedjan eftersom de nu är mellanliggande transaktioner.
|
||||
|
||||
Vi slutleder att kedjetillståndet kan (bortsett från block-headers) vid varje tidspunkt sammanfattas med endast dessa tre ting:
|
||||
Vi slutleder att kedjetillståndet kan (bortsett från block headers) vid varje tidspunkt sammanfattas med endast dessa tre ting:
|
||||
|
||||
1. Den totala mängden mynt skapade genom mining.
|
||||
2. Den kompletta mängden av oförbrukade utmatningar (UTXO).
|
||||
2. Den kompletta mängden av UTXOs.
|
||||
3. Transaktionskärnorna för varje transaktion.
|
||||
|
||||
Det första kan härledas genom att endast observera block-höjden.
|
||||
Det första kan härledas genom att endast observera blockhöjden.
|
||||
|
||||
Både mängden av oförbrukade utmatningar och transaktionskärnorna är extremt kompakta. Detta har två följder:
|
||||
Både mängden av UTXOs och transaktionskärnorna är extremt kompakta. Detta har två följder:
|
||||
|
||||
* En nod i en MimbleWimble-blockkedja får en väldigt liten kedja att behöva ta vara på.
|
||||
* När en ny nod ansluter sig till närverket krävs det väldigt lite information för att den ska bygga kedjan.
|
||||
* När en ny nod ansluter sig till nätverket krävs det väldigt lite information för att den ska bygga kedjan.
|
||||
|
||||
Dessutom kan man inte manipulera mängden av de oförbrukade utmatningarna. Tar man bort ett element ändras summan av
|
||||
de bländande faktorerna och in- och utmatningarna matchar inte längre varandra.
|
||||
Dessutom kan man inte manipulera mängden av UTXOs. Tar man bort ett element ändras summan av transaktionerna och är längre inte lika med noll.
|
||||
|
||||
### Slutsats
|
||||
|
||||
|
|
|
|||
|
|
@ -178,7 +178,7 @@ impl<'a> Response<'a> {
|
|||
}
|
||||
}
|
||||
|
||||
pub const SEND_CHANNEL_CAP: usize = 10;
|
||||
pub const SEND_CHANNEL_CAP: usize = 100;
|
||||
|
||||
pub struct StopHandle {
|
||||
/// Channel to close the connection
|
||||
|
|
|
|||
|
|
@ -74,7 +74,6 @@ pub struct Server {
|
|||
connect_thread: Option<JoinHandle<()>>,
|
||||
sync_thread: JoinHandle<()>,
|
||||
dandelion_thread: JoinHandle<()>,
|
||||
p2p_thread: JoinHandle<()>,
|
||||
}
|
||||
|
||||
impl Server {
|
||||
|
|
@ -257,7 +256,7 @@ impl Server {
|
|||
)?;
|
||||
|
||||
let p2p_inner = p2p_server.clone();
|
||||
let p2p_thread = thread::Builder::new()
|
||||
let _ = thread::Builder::new()
|
||||
.name("p2p-server".to_string())
|
||||
.spawn(move || {
|
||||
if let Err(e) = p2p_inner.listen() {
|
||||
|
|
@ -316,7 +315,6 @@ impl Server {
|
|||
lock_file,
|
||||
connect_thread,
|
||||
sync_thread,
|
||||
p2p_thread,
|
||||
dandelion_thread,
|
||||
})
|
||||
}
|
||||
|
|
@ -531,11 +529,9 @@ impl Server {
|
|||
Ok(_) => info!("dandelion_monitor thread stopped"),
|
||||
}
|
||||
}
|
||||
// this call is blocking and makes sure all peers stop, however
|
||||
// we can't be sure that we stoped a listener blocked on accept, so we don't join the p2p thread
|
||||
self.p2p.stop();
|
||||
match self.p2p_thread.join() {
|
||||
Err(e) => error!("failed to join to p2p thread: {:?}", e),
|
||||
Ok(_) => info!("p2p thread stopped"),
|
||||
}
|
||||
let _ = self.lock_file.unlock();
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -105,7 +105,7 @@ impl BodySync {
|
|||
// 10) max will be 80 if all 8 peers are advertising more work
|
||||
// also if the chain is already saturated with orphans, throttle
|
||||
let block_count = cmp::min(
|
||||
cmp::min(100, peers.len() * p2p::SEND_CHANNEL_CAP),
|
||||
cmp::min(100, peers.len() * 10),
|
||||
chain::MAX_ORPHAN_SIZE.saturating_sub(self.chain.orphans_len()) + 1,
|
||||
);
|
||||
|
||||
|
|
|
|||
|
|
@ -71,7 +71,9 @@ fn main() {
|
|||
|
||||
fn real_main() -> i32 {
|
||||
let yml = load_yaml!("grin.yml");
|
||||
let args = App::from_yaml(yml).get_matches();
|
||||
let args = App::from_yaml(yml)
|
||||
.version(built_info::PKG_VERSION)
|
||||
.get_matches();
|
||||
let node_config;
|
||||
|
||||
// Temporary wallet warning message
|
||||
|
|
|
|||
|
|
@ -1,5 +1,4 @@
|
|||
name: grin
|
||||
version: "2.0.0"
|
||||
about: Lightweight implementation of the MimbleWimble protocol.
|
||||
author: The Grin Team
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue