Miközben az anti-Bitcoin propaganda maximális utánégetővel próbálja terjeszteni az igét, mely szerint a Bitcoin immáron csak egy store of value product, amit valójában senki nem is használ és amúgy sincs semmi jövője, addig a háttérben csak gőzerővel készülnek a fontosabbnál fontosabb fejlesztések. A 2017 szeptemberében beaktivált SegWit protokoll önmagában is komoly scaling reliefként kellett volna, hogy hasson, de a lassú adaptálás és a szándékosnak tűnő gáncsolások miatt ez eddig korántsem hozta el a várt hatást. A helyzet azonban az, hogy a SegWit protokoll messze többet célzott meg eleve, mint amit sokan beleláttak. A Segregated Witnessnek köszönhetően immáron elindult az első hivatalos mainnet Lightning Network Service, amin keresztül a TorGuard anonim VPN szolgáltatásra lehet előfizetni off-chain tranzakciókkal mindösszesen 1 sat tranzakciós díj mellett. Persze úgy korrekt, ha egy rövid gondolat erejéig kitérünk a Bitcoin láncról levált alternatív scaling megoldásra (Bitcoin Cash) is, hiszen ott is vannak most olyan történések, amik bőven beárazódhatnak az elkövetkező néhány napban. Gondolok itt az address format upgrade-re és hardforkra a hétvégén, valamint a jövő hét elején időszerűvé váló Coinbase EUR-BCH pár újraengedélyezése.
Ennyit a BCH-ról, kanyarodjunk is vissza a Bitcoinra: végre ma hivatalos is bekerült a Bitcoin Core kliensbe a SegWit addressek GUI támogatása. Ez egy régóta függőben lévő tartozása volt a fejlesztőcsapatnak, de immáron ez az akadály/kifogás is elhárult az elől, hogy bárki elkezdje támogatni a SegWit protokollt.
Az aktuális dolgok mellett azonban történik bőven fejlesztés a háttérben is, ezek olyan protokollfejlesztések, amelyek megjelenése jelentősen fogja átrajzolni a Bitcoin skálázhatóságát. Ezen törekvések közül talán a legérdekesebb kezdeményezés a MAST (Merkelized Abstract Syntax Tree), mely jelenleg tesztelési fázisban van és az élesítéséhez egyébként egy soft-forkra lesz majd szükség, tehát semmiképp sem érdemes ezt rövidtávon várni. A MAST eredendően Peter Todd, Russel O’Connor és Dr. Pieter Wuille kezdeményezése alapján jött létre és formálódott BIP-pé (Bitcoin Improvement Proposal)
Ahhoz, hogy mindenki számára emészthető formában írjak a MASTról előbb egy picit ki kell bontani az alapokat. Mint arról itt a blogon már nagyon sokszor elmélkedtem a Bitcoin protokolláris szinten egy smart-contract engine, ami valójában minden utalásnál egy-egy apró pici scriptet futtat le, ami ellenőrzi a küldő fél jogosultságát a tranzakcióban felhasználni kívánt bitcoinokhoz. Ez az a scriptréteg, ami lényegében a Bitcoin egyik legfontosabb hozzáadott értékét teremti meg: a protokollszintű “termékfejlesztés” lehetőségét, hiszen a scriptnyelv adta keretek között nagyon komplex alkalmazáslogikákat lehet a blokkláncra ültetni (lásd HTLC, Lightning Network Payment Channelek, stb.).
Ezen scriptnyelv egy magasabb szintű interpretációja a P2SH tranzakciós protokoll, amit lényegében akkor láthattok, amikor egy tranzakció forrásánál vagy céljánál “3” számmal kezdődő címet láttok. Alapesetben egy-egy tranzakció forrásának feloldásához egy privát kulcs kell, pontosabban a privát kulccsal előállított aláírás és annak ellenőrzéséhez szükséges publikus kulcs. A P2SH (Pay To Script Hash) scriptekkel esetében azonban nem egy privát kulcs kell az input feloldásához, hanem egy scriptnek a lefuttatása, pontosabban annak a végeredménye.
Hogy mi mindennek a lényegé? A P2SH lehetővé teszi azt, hogy egy-egy adott mennyiségű Bitcoin valójában ne egy konkrét személy (address) tulajdonában álljon, hanem egy script birtokolja azt, melyek lefutási eredménye alapján dől el, hogy ki költheti el ezen script addressére elhelyezett vagyont. Így lehetővé válik pl egy multi-sign wallet létrehozása, mely tranzakció ideje alatt dönti el, hogy valójában az adott mennyiségű bitcoin tényleg elkölthető-e. (pl. multi-sign esetén rendelkezünk a megfelelő mennyiségű aláírással).
A P2SH addressekre küldött bitcoin tranzakciójában nem látszódnak a konkrét scriptek, csak azoknak a hash-e. Ugyanezen optimalizáció azonban már nem igaz arra az esetre, amikor elküldeni készülünk egy P2SH address tartalmát, hiszen ilyenkor bizonyítékot kell arról szolgáltatni, hogy miként futott le a script és arról is, hogy pontosan mi is futott le. Éppen ezért a scripteket ilyenkor (tehát elköltéskor) tárolni kell a blokkláncban. Ez azonban egy nagyon költséges művelet. Ugyanannyi input és output esetén a P2SH tranzakciók mérete átlagosan 2x akkora mint egy normál 1-es kezdetű címről küldött tranzakció mérete. Ennek megfelelően a tranzakció költségei is duplázódnak, de ennél is fontosabb, hogy egy egyszerű P2SH tranzakció is két normál tranzakció helyét foglalja el a blokkláncban, ami a mai igencsak telített blokkok esetén kifejezetten komoly pazarlásnak tekinthető.
És akkor itt jön a MAST…
A MAST nevéhez méltán azt célozza meg, hogy a scripteket merkel treebe rendezi és ennek megfelelően a tárolja a scriptek hashét a blokkokban. Egy korábban már a Bitcoin scriptingnyelvéről készült cikkben már bemutattam ezt az egyszerű “végrendelet” típusú Bitcoin P2SH scriptet:
Emlékeztetőül a script annyit csinál, hogy annak tartalmát Alice boldogan költheti bármikor, de ha három hónapig nem használ egy outputot, akkor ahhoz már Charlie és a Bob is hozzáférhet AMENNYIBEN mindketten aláírják együtt a tranzakciót.
Látható, hogy ezen script feltehetően az esetek 99%-ában úgy fog lefutni, hogy Alice használja azt. Ennek ellenére minden egyes futtatás esetén tárolni kell az egész scriptet, hiszen maga az eredeti P2SH script hash-e csak az egész script ismerete esetén ellenőrizhető.
Ezen scriptnek ráadásul a legnagyobb része a fenti példában nem is látszik, ez ugye a bizonyos publikus kulcsok, amik csak érzékeltetésként így nézhetnek ki:
var pubkeys = [
new PublicKey(‘022df8750480ad5b26950b25c7ba79d3e37d75f640f8e5d9bcd5b150a0f85014da’),
new PublicKey(’03e3818b65bcc73a7d64064106a859cc1a5a728c4345ff0b641209fba0d90de6e9′),
new PublicKey(‘021f2f6e1e50cb6a953935c3601284925decd3fd21bc445712576873fb8c6ebc18’),
];
Ha pl a fenti scriptben nem egy OP_2 lenne, hanem mondjuk egy OP_3 öt különböző publikus kulccsal (ez ugye a tipikus 3of5 multi-sig), akkor a teljes script mérete közel megduplázódna csak az extra publikus kulcsok miatt.
Az alábbi ábra jól mutatja, hogy milyen szinten jelentek meg robbanásszerűen a multi-sig addressek 2014-et követően:
Jól látható, hogy a legtöbb address a tipikus 3 of 5 és a 2 of 3 multi-sig típusba esik. 2017 elején már közel 2 millió BTC csücsült ilyen típusú scriptek walletekben.
Talán ennyi alap bőven elég ahhoz, hogy a alátámasszam az anti-bitcoin propaganda azon állításának valótlanságát, mely szerint a MAST semmit sem fog segíteni a skálázási problémán. Lássuk mit is kezd a MAST a fentebbi scripttel. Mindenek előtt a végrehajtási útja alapján egy merkle fába rendezi a scriptet:
A MAST az összes scriptet egy ehhez hasonló fába rendezi és minden doboznak kiszámolja a saját script hashét, majd a blockokban lévő tranzakciós hash merkel fa módszerét követve kiszámolja a merkel root hasht, ami logikailag leképzi a teljes script hashét is.
Ezen a ponton jön be az MAST legfőbb lényege: Ha merkel tree elven számolódik ki a script hash-e, akkor nem kell a teljes scriptet tárolni a blockláncban, elégséges tárolni csak azon ágakat, amik ténylegesen ki is értékelődtek az adott tranzakció vizsgálata során. Tehát a fenti példánál maradva, ha Alice költ a vagyonából, akkor teljesen felesleges és szükségtelen a komplett scriptet tárolni minden spendingnél, hiszen Bob és Charlie azokban az esetekben nem került képbe. Ellenben ha úgy alakulna, hogy letelt a 3 hónap és Bob+Charlie lenyúlja Alice pénzét, akkor pedig Alice publikus kulcsa válna irrelevánssá a tranzakció szempontjából.
Mekkora lehet a valós hatása a blockskálázás szempontjából? 2017 év eleji állapot szerint így nézett ki az UTXO-k eloszlása a multi-sig walletek arányában:
Tehát közel 5 millió address mögött állt 2 of 3 multi-sig script (ezeket átlagosan 30%-ot tud faragni a MAST) és további kb negyedmillió address mögött volt 3 of 5 multi-sig script, ahol a MAST megtakarítása akár 40% is lehet.
A MAST önmagában (függetlenül a segwittől, LN-től, sidechaintől, transaction batchingtől) hoz ennyit egy átlagos P2SH multi-sig tranzakción. A fenti végrendelet típusú beágyazott multi-sig tx-en pedig 60%-ot is meghaladó megtakarítást hoz. A Lightning Networkhöz szükséges HTLC P2WSH esetén pedig ez a megtakarítás akár 70%+ is lehet, ha a csatornát közös megegyezéssel zárja le a két fél.
Egy nagyon fontos adalékról azonban még nem beszéltem: a privacy. Egy tipikus 2of3 vagy 3of5 multi-sig script egészen pontosan 1 vagy 2 személyenek az aláírásával tartalmaz több “titkot” mint amennyi valóban alá is írta az adott tranzakciót.
Vegyük azt a példát, hogy Alice és Bob létrehoz egy multi-sig walletet az üzleti vállalkozásához, de azzal a gyanúval élve, hogy bármelyiküket elütheti egyszer csak a villamot, ezért bevonják a wallet kontrolljába Charlie-t is. Charlie egy olyan személy akiben vagy mindketten megbíznak, vagy valójában egyikük sem ismeri Charlie-t, de annyit tudnak, hogy Charlie egy független mediátor (pl crypto oracle) aki vállalja, hogy bámilyen vitás helyzetben közvetít és a döntése alapján aláírásával oldja fel a vitás helyzeteket. Charlie azonban nem akarja, hogy publikus kulcsa minden egyes tranzakcióban ott legyen mivel így személye később akár összeköthető Alice és Bob esetleges ügyeivel. Charlie szeretne egészen addig rejtve maradni amíg nem kell VALÓBAN mediálnia a felek között. Nos ezt a “védelmet” számára a MAST biztosítja, hiszen egészen addig nem kerül be a publikus azonosítója a blokkláncba, amíg nem kell neki is aláírnia egy tranzakciót. Így Charlie egészen addig rejtve marad. Ellenben később Charlie bármikor szavatolni tudja, hogy végig rendelkezésére állt Alicenak és Bobnak, hiszen a MAST által kiszámolt script hash valójában csak akkor érvényes, ha az eredeti kontraktus scriptben benne szerepelt az ő publikus kulcsa is.
Ez utolsó privacy szempont bizonyítja, hogy a MAST nem csak a skálázás és a “tech geek faktor” miatt fontos, hanem valódi hozzáadott értéke is van…
Ennyire egyszerű és nagyszerű a MAST és egyben ennyire komoly kihatása is lesz a jövő Bitcoin hálózatára.
Koszi
Ismét egy velős írás, azonban (talán csak mert nem figyeltem jól), egy dolog nem tiszta nekem: addig, amíg nem kerül be a blokkláncba a szükségtelen info (pl. Charlie public key-e), addig az hol csücsül. És mi garantálja a később érvénybe lépő script nodeban, hogy tényleg Charlié a jog, vagyis honnan kerül be épp az ő publikus kulcsa? (mert ugye azt írod, hogy a blokkláncba sem kerül addig be, amíg nincs rá szükség, de akkor mi szavatolja a script módosítatlanságát?)
Sry, ha valahol ez triviálisan benne van, így 3-kor annyira nem fog jól az agyam. 🙂
Charlie publikus kulcsa a P2SH scriptben “csücsül” és erre jönne rá a MAST réteg, ahol a script módosít-6-atlanságát a merkel root hash szavatolná, már amennyiben ugye a Bip114 status:draft-ból final-ra változna a dev. consensus jóvoltából, ami 2016.04.02-a óta nem történt meg sajnos.
Hm, a script hol csücsül? Eddig azt gondoltam, hogy a blockchainben, de ugye ha Charlie kulcs nincs benne, akkor gyakorlatilag a script egésze nincs a chainben, de akkor hol van? Mi figyeli, hogy triggerelődik-e a Charlie kulcsát használó ág? Csaba azt írja, hogy amikor lefut a script, egyfajta bizonyítékként a blokkláncba kerül, ami lefutott, de helyileg hol fut az a script? A bányászgépeken? És hogy kerül oda? És mi hitelesíti, hogy az a script valid? Elnézést kérek, de nekem itt egy hatalmas köddel kell megbirkóznom. 😀 Ahogy korábban is írtam, én nem félek felvállani a laikust (vagy ostobát), ha az kell ahhoz, hogy megértsem. Szóval köszi a türelmet és kíváncsiam várom, ha valaki hajlandó szájbarágni.
Nézzük a folyamatot:
– script megírásra kerül. A script tartalma lesz lockolva, tehát abból keletkezik egy hash. Ezen hash kerül befoglalásra a tranzakció sciptjébe, ez általában így néz ki: OP_HASH160 20 0x1234567…. OP_EQUAL
– Ebből létrejön a P2SH address, amire te szabadon tudsz küldeni bitcoint. Ellenben ebben a fázisban a blokkláncon sehol nem látszik a tényleges script, csak annak a hash-e és az abból képzett P2SH address.
Amikor viszont költeni akarsz róla, akkor bizony a tranzakcióval együtt be kell küldened a scriptet is. Amit előbb ellenőriz az adott miner (lefuttatja a OP_EQUAL checket), hogy valóban ez a script tartozik-e a P2SH addresshez. Majd ha igen, akkor ténylegesen végrehajtja magát a scriptet és annak kimenetele alapján dönti el, hogy az adott tranzakció végrehajtható avagy sem. Sikeres végrehajtás esetén a blockba bekerül a script is a tranzakcióval együtt, hiszen később csak a teljes script ismeretében lehet ellenőrizni, hogy valóban jogos volt-e a tranzakció.
Ó… így már sokkal világosabb. Köszi szépen.
“Ahogy korábban is írtam, én nem félek felvállani a laikust (vagy ostobát), ha az kell ahhoz, hogy megértsem. Szóval köszi a türelmet és kíváncsiam várom, ha valaki hajlandó szájbarágni.”
Köszönjük, hogy ezt sokunk helyett, felvállalod. 😀
Köszönöm a infót és hitem megerősítését a Bitcoin-ba!
Ez egy kellemes költségcsökkentés a multisign walletes felhasználás esetén. Az a baj, hogy az ilyenek az össz forgalmat tekintve kevesen vannak, magyarán ez a throughputot gyakorlatilag nem fogja növelni.
Amíg meg a mezei tranzakcióknak olyan horror a költsége, amilyen, addig ez kb. mint a halottnak a csók. Üzleti felhasználásra (mert multisign walletet jelenleg csak ílyenre használnak kb.) nem nyolcszoros horror ktg., hanem csak háromszoros, na bumm. Ráadásul majd egyszer, valamikor, talán, gondolom újabb forkolós cirkusszal megfűszerezve. Ráadásul ethereum láncon még mindig mérföldekkel egyszerűbb, olcsóbb a smart contractolás.
Ha ilyen fejlesztések vannak még a talomban, akkor én nem várnék csodákat.
Szerintem ezeket a dolgokat nem igazán érdemes összekeverni. Az Ethereum smart contractja egy generikus smart contract engine, amin lényegében bármilyen programot lehet futtatni, ami éppen jól esik. Ezzel szemben a Bitcoin smart contract enginének egyetlen célja az, hogy a tranzaktálásnál lehessen bonyolult kiértékelési/döntési logikákat implementálni. Megjegyzem az Ethereum perpillanat igen komoly gondokkal küzd (továbbra is), az árfolyamával együtt a tranzakciós költségek is ATH-ra kerültek. Most az 1300 dolláros árfolyamával már 3-4 USD körül van egy átlagos tranzakció díja. Ezt extrapolálva a Bitcoin jelenlegi árfolyamára (14k) azt lehet levonni, hogy a sokkal fejlettebb és minden szempontból világot látott Ethereum ugyanakkora egy coinra eső árfolyam esetén ugyanakkora txfeekkel működne. Talán nem véletlen, hogy a blokkláncok sorra jelentik be, hogy onchain helyett layer2 felé skálázódnak (LTC, Ethereum mellett ugye a Monero csapat is a SegWit és a Lightning Network-ön dolgozik)
Amennyiben egy blokklánc amellett teszi le a voksát, hogy Layer2-ben akar skálázódni, akkor onnantól a fejlesztőknek egyetlen célja lehet: A layer1 minél jobb optimalizálása. Ezen optimalizálásban segít a SegWit mellett a batched tx mode, a MAST és pl a Drivechain BIP. Ezek a fejlesztések most a legfontosabbak. Én a helyedben nem nézném annyira le ezeket a fejlesztéseket. A Bitcoin most egy szunnyadó óriás…
Tisztában vagyok a bitcoin és az ethereum protokolljai, képességai közötti eltéréssel. Pont ez a baj, hogy a bitcoin esetében a primitív scriptelési lehetőségek miatt a cikkben szereplő példádban mutatott multisign walletnál bonyolultabb vagy nem megvalósítható, vagy csak nagyon bonyolultan, több tranzakcióval, illetve nagy lekötött összegekkel, értelemszerűen ennek megfelelően baromi költségesen.
Az utolsó devconon volt erről egy jó előadás, ha gondolod megkeresem.
Szóval hiába lenne egy teoretikus, jelenleg baromira nem valós szituációban (eth-btc azonos árfolyam) az egyszerű “kriptapízt küldök Mariskának” tranzakció költsége hasonló, ha bonyolultabb contractok esetében (amiről itt szó van) ég és föld a különbség. Ettől függetlenül értelmes célra használhatatlan mindkét hálózat a spekuláción kívül kb. jelenleg. 🙂
A layer1 optimalizálására az említettek közül kb. a Drivechain egyedül, ami nem a fingreszelés kategória – már ha azt egyáltalán hívhatjuk layer1 megoldásnak, én inkább nem hívnám annak, hiszen az is egy alternatív réteget húz be a főlánc mellé. Sajnos ki tudja mikor és ki tudja milyen következményekkel lesz belőle bármi is. Nem lennék meglepődve, ha előbb látnánk erre használható megoldást ethereum vonalon, ahol szintén gyúrják már a sidechaineket.
A layer1 skálázást nagyon egyszerű lett volna javítani akár rövidtávon is, csomó politikai ármánykodás méregfogát azonnal kihúzva: emelni kellett volna azon a kurva blokkméreten.
“layer1 THROUGHPUT optimalizálására”
csak hogy ne elbeszéljünk egymás mellett, bocsi!
A záró konklúziód hibátlan, teljesen jogos, hogy az elmúlt két év bármelyik percében bekövetkező blokkméret növelés kihúzta volna ennek az egész storynak a méregfogát. És persze politika így meg politika úgy, de az szögezzük le, hogy mi tényleg csak azt látjuk, ami a színpadon zajlik és esetleg lehetnek halvány tippjeink arról, hogy mi történhet a színfalak mögött. Bár ezen tippek nagy része is inkább csak a vágyaink manifesztációja.
Nem gondolom, hogy a Bitcoin jó úton jár, de mindettől független számomra a Bitcoin az egyetlen olyan játékos, aki nem úgy akarja megoldani lovaskocsi sebesség problémáját, hogy befog még egy-két lovat a fogat elé. Amiket most lefektet a Bitcoin technológiákat (Conf Trans, MAST, SegWit, layer2, sidechain, two-way pegged drivechains, stb.) azok lesznek a következő évek blockchain implementációinak az esszenciális alapjai. Persze lehet, hogy eme pionír szerepbe akár bele is halhat maga az egész blokklánc. Tény, hogy a Bitcoin mögött álló fejlesztők elvi alapon akarják a legjobbat és nem foglalkoznak a realizásokkal. Pl a fenti példánál maradva akkor sem hajlandók befogni plusz 1 lovat a szekér elé, ha azon az életük múlna, ők lázasan küzdenek azon, hogy az ő szekerüket ne lovak húzzák, hanem mondjuk egy robbanómotor hajtsa. Persze a többi szénné pimpelt fogathajtó csak nevet rajtuk és befognak még egy-két lovat áramvonalasabbá teszik az egész szekeret és még talán azon is agyalnak, hogy vajon két tengely helyett három tengellyel nem-e jobb lenne az úttartás…
>számomra a Bitcoin az egyetlen olyan játékos, aki nem úgy akarja megoldani lovaskocsi sebesség problémáját, hogy befog még egy-két lovat a fogat elé
Mások sem. Ez a blokkméreten drámázás csak BTC-fork vonalon ment, többi hasonló technológiára épülő nevesebb hálózaton jó ideje szintén a layer2 és sidechain irányba tapogatóznak, de ezt te is írtad fentebb, úgyhogy nem tudom ez most így honnan.
Azt meg, hogy a többi említett fejlesztés csak fingreszelés, throughputra komolyabb hatása nem igazán lesz, szépen átsiklottad és szajkózod őket tovább. A következő évek blockchain implementációinak alapjai? Max a BTC node implementációk alapjai, mert amúgy ez elég roflmao kijelentés lenne.
Abban persze maximálisan egyetértünk, hogy a blokkméret-növelgetés hosszú távon nem megoldás, de ezt megbeszéltük már itt, felesleges a terjengős hasonlat. A jelen problémáira igenis megoldás lett volna, ha valami, akkor könnyen lehet ez a döntést a hálózat veszte, mint ahogy majdnem az is lett tavaly novemberben.
Mondj nekem egy olyan blokkláncot, ami nem a Bitcoint követve foglalkozik a layer2-vel… A többi layer2, sidechain implementáció mint a Bitcoin/Blockstream által megalapozott utat követi. Persze ha Te ismersz teljesen független blocklánc alapú layer2 implementációt, akkor mea culpa én nem tudok egy ilyenről sem (include Ethereum plasma sem uniq, hiszen azt is Jospeh Poon rakta össze, aki ugye magát az LN-t is dizájnolta).
Azt mondod, hogy a SegWit, MAST és a többi improvement csak fingreszelgetés, mitöbb azt állítod, hogy szándékosan elsiklok ezek áteresztőképességre gyakorolt alacsony hatása felett. Nos szó sincs erről, egyszerűen csak nem értékelek egy olyan dolgot, aminek egyelőre nem lehet valóban mérni a hatását. Állításodat arra alapozod, hogy jelenleg a P2SH multisig tx-ek aránya elenyésző a nomál P2PKH tx-ekhez képest. Az ugye megvan, hogy az összes payment channel multi-sig wallet és a channel close scriptek több mint a fele a forced closeokról szól, amiknek a kódja a channel zárások 99%-ában hasztalan lesz és a MAST úgy ahogy van ki fogja optimalizálni azt a blokkokból. Ha abból indulunk ki, hogy a generikus forgalomnak (pl. exchangek közötti arbitrázs, hot-cold wallet mozgások, stb.) egy nagy része átkerül a layer2-be és így a blokkok nagy része már csak payment channel management txekkel lesz tele, akkor vajon továbbra is valid lesz a “fingreszelés” hasonlatod?
Az egész cikk egy jövőbeli funkcióról és annak vélt hozzáadott értékéről szól egy jelenleg még nem létező környezetben. Te pedig azért húzod le mindezt, mert MA éppen ez nem old meg semmit…
Fantasztikus hasonlatok.
Az mondjuk fel sem merül, hogy anyagi érdekek fűződnek a probléma megoldásának elodázásához.
Esetleg néha felnézhetnének a fejlesztők, hogy lássák mi a helyzet a konkurenciához képest.
Amúgy meglátásom szerint még jó is volna ha az Ethereum lenyomná végre a Bitcoint, mert az a pávatánc ami az utóbbi kb fél éve a Bitcoin körül zajlik csak árt a piacnak.
Elnézve a dolgok alakulását ez amúgy már talán nincs is olyan messze.
Hasonloan latom.
A blokkmeret _noveles_ nem old meg semmi: 1 megas blokkmeret mellett X tx-el le lehet floodolni a mempoolt, akkor 10 megas blokkmeret mellett 10*X tx is le lehet. Csak penz kerdese. a kis sarganal meg van abbol eleg.
A meregfogat akkor huzta volna ki, ha vegtelen blokkmeret lenne, akkor nem erne meg spamelni a halot. csak akkor meg a txfee veszti ertelmet.
kraken ujra elerheto, es 0%-os koltseggel lehet kereskedni…
Végre vmi jó hír a téli depresszióban fetrengő cryptovilágnak:)
mit gondoltok, mikor lesz kész a bitcoin csapata a legfontosabb fejlesztésekkel?
Nem kereskedesi vagy befektetesi tanacs, de nekem nagyon ugy tunik, hogy szukosebb honapok ele nezunk, talan nem is az a kerdes, hogy essunk tovabb hanem hogy meddig I’ll. Hol lesz, lehet az alja ennek a kornek….(2500-5000) esetleg 5000-9000$ korul, na talan ez a helyes keredes?!
Szamomra a joker kephez kapcsolhato asszociaciok a legerdekesebbek. Irnal egy par szot errol? Koszonom.
Sziasztok! bocsánat az OFF-ért,de hátha van itt valaki aki tudna segíteni. Tudnátok esetleg ajánlani egy jó könyvelőt ?
Ez engem is érdekelne.