Hur gör man en Coin split på ett säkert sätt?

Det kommer ett antal forkningar av Bitcoin och andra kryptovalutor där det saknas replay protection/RP.

Problemet vid en fork är att det plötsligt finns två blockchain där den privata nyckeln passar i båda blockkedjorna.
För att få kontroll över båda blockkedjorna får coinsen inte dela samma adress.

Om man flyttar coins finns det en risk att någon illvillig hackare kopierar transaktionen och återupprepar den på den andra blockkedjan. Resultatet är att coins flyttas runt utan kontroll och risken är att man förlorar kontrollen över sina egna coins.

En Coin split behöver bara utföras en gång och då separeras coin innehavet på två olika privata nycklar i de båda blockkedjorna och alla framtida försök till RP misslyckas. Efter en lyckad coin split kan innehavet på de olika blockkedjorna säljas eller flyttas utan risk.

Vilka lösningar finns det för att göra Coin split på ett säkert sätt?

Jag har själv ett förslag på en coin split.

Efter att forken är klar så kan man göra en coin split.

Man köper ett ytterst litet belopp från en exchange eller annan handlare till ens egen wallet.
Man kan också köpa ett litet belopp från en miner som efter forken fått miners reward.

Detta lilla belopp läggs till den egna walleten, denna summa är nu högre än vad som finns på den andra blockkedjan och om man skickar hela beloppet till en ny wallet då kommer alla försök till RP att misslyckas på den andra blockkedjan.

Funderar också lite på det här, det är inte helt säkert. Om du har 1BTC och köper upp 0.01 BTC till din wallet, så att du har 1.01 BTC som du sedan skickar vidare, så går det inte att kopiera transaktionen på den andra blockkedjan eftersom att summan som skickas är högre än den som finns i walleten. Meen, om då, någon annan, vem som helst, skickar 0.01 BTC till dig på den andra blockkedjan, så att du har rätt summa, kan dom då senare kopiera transaktionen så att 1.01 BTC skickas på båda kedjorna iallafall?

Du har rätt men detta exempel är långsökt om inte attacken är riktat mot en speciell wallet/person.

Om avsikten är att förstöra en viss blockkedja då kan man konstruera program som övervakar blockkedjan och hittar dessa försök att skydda sig mot RP, för att därefter överföra belopp så att replay attacken lyckas, detta är långsökt.

Jimmy Song(Bitcoin utvecklare) har nämnt i ett youtube klipp att, Bitcoin från en miner som fått utdelning efter forken inte kommer att kunna användas i en replay attack. Han refererar till beloppet som "tainted" och får replay transaktionen att bli avvisad/rejected av Bitcoin nätverket. Det ska räcka med en satoshi för att uppnå detta.

Vi vet inte riktigt vad som kommer hända, säkrast är att undvika transaktioner den första dagen tills man vet vad som väntar och därefter agera på bästa sätt för att skydda sig.

Jag antar att info om eventuella problem kommer att diskuteras på Twitter, Reddit och flashback mm..

Gruppen kring Segwit2X/BT2 verkar opålitlig.

Bra fråga det där! Helt klart ett intressant fall.

Det kommer dock inte funka därför att den nya UTXO:n (dvs, de 0,01 från vem som helst ovan) som skall användas i den speglade transaktionen inte matchar de inputs som användes i ursprungstransaktionen.

Hmm, det där förklaringen lät rätt krånglig. Återkommer med en bättre förklaring senare när jag har mer tid.

Bitcoins UTXO-modell gör detta omöjligt, som sagt. En transaktion är en helhet av vissa specifika inputs, deras hashes och deras signaturer. Så fort man inför en ny UTXO, som detta kräver, så är den omöjlig att göra identisk med den tidigare input man vill matcha.

Detta fick mig att fundera lite generellt på UTXO-modellen, som jag redan insett hade bra egenskaper. Här är ytterligare en. Speciellt intressant är att Ethereum inte fungerar så här och att Vitalik argumenterat (jag är inte påläst i detalj här dock) för styrkor med att välja en annan lösning (med bl a transaction nonces).

Nu tänker jag högt och snabbt här, men nog 17 är det så att man får se upp mycket mer med potentiella replay attacker hos Ethereum än hos Bitcoin pga av detta. UTXO-modellen borde ge avsevärt bättre resistens.

Japp, men detta är bara ett specialfall och en följd av att inputs måste vara identiska vid replays, vilket blir än mer omöjligt för inputs som har ursprung i coinbase-tx som inte ens existerar på andra sidan.

Skriver helt under på det. Det är en sak att sitta och teoretisera runt detta. Man bör vara maximalt försiktig med verkliga innehav ändå.

lite morgontrött men det borde fungera om du vet att den lilla transaktionen inte går att göra replay attack på men hur vet du det? som jag ser det kräver det att någon annan tar bort risken för replay attacks redan innan du skickar dina bitcoins - du har inte gjort något mer än att ta emot nya bitcoins som inte finns på andra kedjan.

chansen att få nya coins när man tar ut bitcoins från en exchange är nog ytterst liten.



Jajjemän

Coinbase förlorade väl någa hundratusen ETC när ETH skulle hardforka bort the DAO fiaskot

Korrekt, men nu är du tillbaka på ett fall där transaktionen som helhet kommer accepteras på båda sidor som den är, dvs helt utan att någon försöker tillföra en ny UTXO för att möjliggöra attacken. Så, visst, vi måste ha en divergens i historiken någonstans för att kunna stoppa replays. Men när vi väl har det, så går det inte att skapa attacker med hjälp av nya transaktioner.

Man bör ju iofs lätt kunna skapa divergensen själv med att först skicka till egna adresser på olika sätt på respektive sida, tills dess man ser att replays blir omöjliga (respektive kedja har låst skillnaden djupt nog). Skulle det bli replays här så har man ju inte förlorat något innehav (bara tx fees). Sen är det safe att skicka till andra.

Se där. Kände inte till just deras klanteri vid den forken. Det verkar finnas gott om dem.

Man kan utnyttja att kedjorna antagligen har olika avgifter för att komma med i ett block. Så om man sätter avgiften så att transaktionen bara går igenom på ena kedjan. Därefter sätter man en högre avgift på den andra kedjan för att stänga ute replay-attacken.

Man kan utnyttja att en replay-attack skapar en viss tidsfördröjning. Om jag skickar en transaktion på varje kedja där det enda som skiljer är adresserna och sänder dessa transaktioner exakt samtidigt. Då hinner inte transaktionen replayas innan min transaktion. Replay-attacken kommer då att ses som en double spend. Eftersom det är en double spend som inte ökar avgiften så kommer den avvisas av miners. Kräver dock speciell mjukvara denna metod.

Tror du är meveten om detta, men för de som kanske undrar:

Även om replay-risker är extremt låga här så kan latency och temporära forks ställa till det om man har extrem otur. I ett tidigt skede efter chain split så kan dessutom noderna omedvetet hjälpa till att skapa replays, innan man fått en allt mer permanent network split också. Så vill man vara helt säker, så bör man göra detta mellan egna adresser, innan man skickar dem vidare senare till någon annan part. Replayskydda först, spendera sen.

Sen lite onödiga funderingar:

Det roliga med det här är att man inte ens behöver använda olika adresser när man skall skapa unika UTXOs. Exempelvis kan man skapa 2 outputs, där man delar upp det man vill skicka lite olika, för respektive transaktion på de olika kedjorna. Då blir txid olika för dessa UTXOs på respektive kedja när man vill spendera dem.

Sen kan man ju också utnyttja lite transaction malleability på ett nytt sätt och helt enkelt köra identiskt transaktionsinnehåll men använda olika secure random i ECDSA-signaturerna. Då blir txid olika så länge det inte är segwit-tx. Tror inte det funkar för segwit-tx dock, men osäker. Man får ju unika wtxid och witness root hash som blir beroende av respektives sidas signatur, men inte unika txid, för de UTXOer man ville särskilja, om jag tänker rätt. Nåja, bara teori, inget relevant att använda sig av.

Bra påpekande, man ska alltid splitta till adresser som man själv har full kontroll över. De metoder jag nämnde är inte 100%-iga. Vet man inte exakt vad det är man håller på med så ska man alltid invänta riktlinjer eller verktyg från ens wallet provider om hur man ska genomföra splitten.

Ytterligare problematik kan vara reorganisering(reorg) av blockkedjan.

Efter att man splittat till adresser som man själv har full kontroll över, då kan det vara bra att vänta på minst sex verifikationer innan man är helt säker på att splitten lyckats.