Update Swedish intro.md (#2968)

* Update Swedish intro.md

Significant improvements, including a less excessive translation of the English terminology.

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
+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 utmatningarna är
+`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 inmatningarna i en transaktion med hjälp av ECC-operationer:
+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
+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öjar man alla utmatningar med beloppet v1 över hela blockkedjan. Av dessa
+transaktion) och det resulterande `v1*H` avslöjas alla outputs 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
+anledningar introducerar vi en andra punkt _G_ på samma elliptiska kurva och en privat nyckel _r_ som används som en *förblindningsfaktor*.
-som _H_) och en privat nyckel _r_ som används som en *bländande faktor*.
 
-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
+* _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_ på _G_.
+produkt `r*G` är den publika nyckeln för _r_ (med _G_ som generatorpunkt).
-* _v_ är ett inmatnings- eller utmatningsbelopp och _H_ är en annan elliptisk kurva.
+* _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.
+* vi1 och vi2 som input-belopp.
-* vo3 som utmatningsbelopp.
+* 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
+Vi genererar en privat nyckel som en förblidningsfaktor för varje input och ersätter alla belopp med
-deras respektive Pedersen Commitment och ekvationen blir därmed:
+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
+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 den bländande faktorn ett extremt stort tal). Någonstans i blockkedjan dyker följande utmatning upp och ska endast 
+är ett extremt stort tal). Någonstans i blockkedjan dyker följande output upp och ska endast kunna spenderas av dig:
-vara spenderbar 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
+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 in- och utmatningarna) så du skulle kunna stjäla tillbaka pengarna från Carol!
+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
+Nu summeras transaktionen inte längre till noll och vi har ett _överskottsbelopp_ (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
+av summeringen av alla förblindningsfaktorer. Eftersom `85*G` är en giltig publik nyckel för generatorpunkt _G_ vet vi
-att in- och utmatningarna har subtraheras till noll och transaktionen är därmed giltig.
+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
+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 den privata nyckeln (85 i exemplet ovan). Det enklaste sättet att göra
+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
+* De parter som utför transaktionen tillsammans kan beräkna den privata nyckeln (överskottsbeloppet)
-* Summan av utmatningarna minus inmatningarna i transaktionen är noll (eftersom överskottsbeloppet måste vara en publik nyckel).
+* 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
+    Växel-output:   12*G + 1*H
-    Carols utmatning:  113*G + 2*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.
+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:
-Anledningen till detta och en mer utförlig beskrivning av range proofs är förklarat i 
+
+    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 inputs som refererar till och spenderar en mängd föregående outputs.
-* En mängd nya utmatningar som inkluderar:
+* En mängd nya outputs som inkluderar:
-  * Ett belopp och en bländande faktor (vilket bara är en ny privat nyckel) multiplicerade på en kurva och adderade
+  * 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.
+  * Ett range proof som bland annat visar att v är icke-negativt.
-* En tydlig transaktionsavgift i klartext.
+* En transaktionsavgift i klartext.
-* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla utmatningar och 
+* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla outputs och 
-avgiften minus inmatningarna).
+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
+upprätthåller egenskaperna för en giltig blockkedja, d v s att en transaktion inte skapar pengar och att ägandebevis
-fastställt med privata nycklar.
+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 inputs som refererar till och spenderar en mängd föregående outputs
-* En mängd nya utmatningar (Pedersen commitments)
+* En mängd nya outputs
 * En transaktionskärna som består av:
-  * överskottsbelopp 
+  * kärnöverskottet (överskottsbeloppets publika nyckel) 
-  * transaktionssignatur
+  * transaktionssignatur vars publika nyckel är kärnöverskottet
   
-En transaktion signeras och signaturen inkluderas i en transaktionskärna. Signaturen genereras genom att använda 
+En transaktion valideras genom att kärnöverskottet faställs vara en giltig publik nyckel:
-överskottsbeloppet som en publik nyckel för att bevisa att beloppen summeras till 0:
 
     (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
+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 transaktionsutmatningarna, subtrahera summan av transaktionsinmatningarna, och jämföra
+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:
-det resulterande Pedersen commitment med summan av överskottsbeloppen:
 
-    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)
+    (input1, input2) -> (output1), (kärna1)
-    (inmatning3) -> (utmatning2), (kärna2)
+    (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
+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 överskottsbeloppet för att verifiera att det summeras till noll:
+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
+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
-`k1*G` (överskottet) och `k2` (offset) och signerar transaktionen med `k1*G` som tidigare. Under 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.
-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.
 
 #### 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
+Blocks låter miners sätta ihop flera transaktioner till en enstaka struktur 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
+block-representationer med tre transaktioner visar vi endast inputs och outputs. Inputs refererar till
-föregående utmatningar som de spenderar. Föregående utmatningar markeras med _x_.
+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)
+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. Således kan matchande inmatningar och utmatningar elimineras, då
+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.
+Notera att all transaktionsstruktur har eliminerats och att ordningen av inputs och outputs inte längre spelar någon roll.
-Summan av alla in- och utmatningar garanteras fortfarande vara noll.
+Summan av alla inputs och outputs är garanterat fortfarande noll.
 
 Ett block består av:
 
-* En block-header.
+* En block header.
-* En lista av alla inmatningar som kvarstår efter genomskärning.
+* En lista av alla inputs som kvarstår efter genomskärning.
-* En lista av alla utmatningar som kvarstår efter genomskärning.
+* En lista av alla outputs som kvarstår efter genomskärning.
-* Ett enstaka kärn-offset som skyddar hela blocket.
+* 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.
+  * Publika nyckeln `r*G` erhållen genom summation av alla inputs och outputs.
-  * Signaturerna genererade genom överskottsbeloppet.
+  * 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.
+* Mellanliggande (genomskurna) 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.
+* 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 vill exkludera en specifik utmatning är de tvungna att exkludera alla.
+Om någon skulle vilja exkludera en specifik output skulle de vara tvungna att exkludera alla.
-* All transaktionsstruktur har borttagits vilket gör det omöjligt att se vilka in- och utmatningar som passar ihop.
+* 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
+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 de utmatningarna tillsammans med
+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
+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.
-de bländande faktorerna och in- och utmatningarna matchar inte längre varandra.
 
 ### Slutsats