<19op>. Ha ellenérvet szeretne benyújtani, kérjük, e-mailt küldjön a Bitcoin Magazine-nak.
BIP119 vagy Check Template Verify (CTV) egy abszurd és nevetséges vita középpontjában állt az elmúlt héten. Ennek a vitának jelenleg két aspektusa van: maga a CTV funkcionalitás és az a felvetett ötlet, hogy rövid távon aktiválják a vitatott Speedy Trial mechanizmust, amely sikeres volt a Taproot aktiválásában. Ez a két kérdés odáig keveredett, hogy a szétválasztásuk és az egyik külön-külön történő megvitatása – finoman szólva – hihetetlenül nagy kihívássá vált.
Mint a Speedy Trial (ST) telepítésével kompatibilis, felhasználó által aktivált soft Fork (UASF) kliens Taproot aktiválás támogatásában részt vevő egyik személy, teljes szívemből kijelenthetem, hogy nagyon ellenzem. az ST aktivációs mechanizmusként való jövőbeni felhasználása. Borzalmas tévedésnek tartom, ami társadalmilag a bányászok kezébe adja a vétómechanizmus és a konszenzusos folyamat túlsúlyos befolyásának felfogását. Úgy gondolom, hogy a konszenzusos változtatások aktiválásának kizárólag a felhasználók kezében kell maradnia, nem a fejlesztők és nem a bányászok kezében. Ennek ellenére a változtatások aktiválásának kérdése csak érintőlegesen kapcsolódik a CTV-javaslathoz, és a viták nagy része kifejezetten magára a határállomásra, illetve a szövetségek általános koncepciójára összpontosul.
Nagyon sok a vita tárgya. zavar, hogy a CTV mit tud és mit nem. A magával a javaslattal szembeni kritikák nagy része, amelyek nem a javasolt aktiválással vagy aktiválási mechanizmussal kapcsolatos problémákban gyökereznek, a helyettesíthetőség romlásán alapulnak, vagyis azon a lehetőségen, hogy valaki érméket küldjön Önnek, és korlátozza, hol költheti el azokat.. Ez két okból nem lehetséges. Először is, a CTV korlátozza az érméket azáltal, hogy PONTOSAN meghatározza, hova kell menniük, és a pontos mennyiséget. Valami olyasmihez, mint az „engedélyezőlisták létrehozása”, hogy korlátozza az érméi elkölthető helyét, minden lehetséges címet előre ki kell számítania, ahol valaki érmét költhet, de ezután ezekre a címekre is ki kell számítania minden lehetséges összeget, amelyet elkölthet. nekik egészen a satoshi szemcsésségéig. Másodszor, a fogadó az, aki címet ad a feladónak, és az, aki eldönti, hogy pontosan milyen Bitcoin-szkriptnek kell megfelelnie ahhoz, hogy elköltse a kapott érméket. Ha a küldő bármilyen módon megváltoztatja ezt a szkriptet, megváltoztatja a „címet”, és a címzett pénztárcája nem is ismeri fel az átvett összeget. Nem más, ha megadunk valakinek egy címet, és pénzt küldünk valaki más pénztárcájába.
Előre aláírt tranzakciók és multisig
Az előre aláírt tranzakciók nagyon fontos összetevői a Bitcoinra épülő dolgoknak. A Lightning előre aláírt tranzakciókra, az állapotláncok előre aláírt tranzakciókra, a diszkrét naplószerződések pedig előre aláírt tranzakciókra épülnek. A multisig szkriptekkel kombinálva garantálható, hogy a multisig által megterhelt meglévő UTXO csak bizonyos előre meghatározott módokon költhető el. Ez a második réteg teljes alapvető magja.
Minden érintett fél létrehoz egy multisig címet, majd válassza ki, hogy mely UTXO-kkal finanszírozza azt. A finanszírozási tranzakció aláírása előtt elkészítik a multisig UTXO-t elköltő tranzakció(ka)t az előre meghatározott módon, majd aláírják és megerősítik a finanszírozási tranzakciót. Anélkül, hogy minden fél beleegyezne abba, hogy hová és milyen feltételek mellett költsék el a forrásokat, semmi sem változtatható. A rendeltetési hely és a feltételek, amelyek mellett a pénzeszközök a célállomásra költöznek, le vannak zárva. Ennek a primitívnek a fő korlátja az, hogy annak garantálása érdekében, hogy ezek a pénzek korlátozottak maradjanak a felhasználási módjukban, mindenki, aki pénzt adományozott, vagy azoktól függ. A kiadási korlátozásoknak részt kell venniük a multisig szerződésben. Ha nem, akkor bízniuk kell a multisig-szerződésben ténylegesen érintett felekben, vagy legalább ezek egy küszöbében (például 3-5 multisig esetén legalább három résztvevőben kell megbízniuk becsületes). Részvétel nélkül meg kell bízniuk abban, hogy a résztvevők csak őszintén írnak alá és/vagy törölhetik a privát kulcsokat anélkül, hogy megőriznék a másolatokat.
Milyen korlátai vannak az előre aláírt tranzakcióknak? A tranzakció minden részletét meg kell határoznia: mit csinál, hová költi el az összeget, bármilyen tranzakció szintű időzárat stb. Soha nem vonhatja vissza a tranzakció aláírását, nem módosíthatja azt, amit már aláírt. Ezért van szüksége a Lightningnek büntetőkulcsokra, és az emberek az ANYPREVOUT és eltoo, mert az előző aláírt tranzakciót nem lehet visszavonni vagy „visszavenni”. Csak annyit tehet, hogy aláír egy újat, és lehetőséget ad neki, hogy frissítse vagy tagadja az előzőt, ha valaki megpróbálja használni. Néha érdemes ezt megtenni, néha megbizonyosodni arról, hogy ez nem lehetséges, de az előző aláírt tranzakció zárolva van, és mindig használható, amíg valaki megőrzi. Soha nem veheti vissza.
CHECKTEMPLATEVERIFY/BIP119
A CHECKTEMPLATEVERIFY (CTV) alapvető funkciója, hogy erősebb garanciákat nyújtson abban a helyzetben, amikor biztosítani szeretné, hogy nem lehetséges cserélje ki az eredetileg aláírt tranzakciót. Ahelyett, hogy a multisig résztvevőire kellene bízni az őszinte viselkedésben, vagy a kulcsgenerátorokban a privát kulcsok törlésében, a CTV garantálja, hogy az érme előre meghatározott módon történő elköltését a konszenzusos szabályok szó szerint kényszerítik. Ez úgy érhető el, hogy belefoglalja annak az előre meghatározott tranzakciónak a kivonatát, amelyet el kíván költeni arra az UTXO-ra, és hozzáadja azt az adott UTXO zárolási szkriptjéhez annak létrehozásakor. Amikor elkölti az érmét, a szkript értelmezője biztosítja, hogy a költési tranzakció hash-je megegyezzen a bemeneti szkriptben szereplővel, és ha a hash nem egyezik, akkor a tranzakció konszenzus alapján érvénytelennek minősül.
ugyanaz a funkcionalitás, mint a multisig és az előre aláírt tranzakciók olyan használati esetekben, amikor azt szeretné garantálni, hogy a kezdeti tranzakciókészlet nem cserélhető ki, kivéve, hogy teljesen eltávolítja azt a követelményt, hogy a multisig kvórum résztvevőiben bízni kell az őszinteségben, vagy valakiben, hogy törölje a privát kulcsokat a tranzakciók aláírása után. Nem nyit új ajtót, nem tesz lehetővé semmi olyat, amit előre megjelölt tranzakciókkal és multisiggel nem lehet megtenni; egyszerűen megszünteti a multisig szkriptben való közvetlen részvétel szükségességét annak érdekében, hogy ne kelljen megbízó harmadik felekre hagyatkoznia a szerződés megfelelő végrehajtásának kikényszerítésében.
A CTV nem tesz többet az „engedélyezőlistára helyezési korlátozások” kényszerített végrehajtásáért, így az érméket csak jóváhagyott címekre lehet elkölteni, mint az előre aláírt tranzakciók esetében. Az összegek, a rendeltetési címek és a konkrét változók különböző kombinációinak száma, amelyek eltérhetnek a költési tranzakciókban, amelyeket előre ki kell számítani és alá kell írni egy ilyesmihez, abszurd módon megterhelő és nem praktikus minden idő előtt visszavonó felhasználó számára. Ez azt a tényt is teljesen figyelmen kívül hagyja, hogy minden egyes előre kiszámított tranzakció minden változási kimenetét hasonlóan meg kell terhelni szinte végtelen számú ilyen kombinációval, valamint a következő tranzakciókészlet változási kimeneteivel, és így tovább, és így tovább, abba, ami gyakorlatilag a végtelen. A CTV egyetlen optimalizálása az, hogy nem kell a CPU-ciklusokat a dolgok aláírásával tölteni, ami semmit sem változtat azon a tényen, hogy ez a gyakorlatban teljesen megoldhatatlan. Miért kell foglalkozni ezzel a sok bonyolultsággal és előre számítással ahelyett, hogy megtagadnák a felhasználók visszavonását, kivéve a 2-ből 2 multisig-et, ahol a tőzsdén van egy kulcs, így megtagadhatják a „rossz tranzakciók” engedélyezését? Vagy csak egyáltalán nem engedik a felhasználókat kivonulni?
A választás
Végső soron az aktiválandó vagy kényszeríteni kívánt választás azon múlik, hogy az egyes felhasználók mit választanak a csomópontjukkal, és ennek az összesített eredménye a teljes hálózaton, amelyet az egyes felhasználók az egyéni választások összeadódnak. Így működik a Bitcoin, és ezen semmi sem változtat – leszámítva a felhasználók független gondolkodásának és döntéshozatalának teljes szétesését. Ennek ellenére véleményem szerint nagyon szégyen lenne, ha egy javasolt fejlesztést megtorpedóznának és lelőnének annak alapján, hogy teljesen félreértik, hogy mit tehet és mit nem, szemben a lehetséges árnyoldalakkal, hatástalanságokkal, ill. kockázatokat jelent a hálózat számára. Véleményem szerint ez nem a felhasználók önszuverenitásának megnyilvánulása vagy a közszereplők által állított tények független ellenőrzése, hanem a nyílt ostobaság és tudatlanság megnyilvánulása.
Remélem, hogy a továbbiakban ez a beszélgetés megfelelően szétválasztható a jelenleg egybemosott két kérdésre – magára a javaslatra és a megvalósításhoz használható aktiválási mechanizmusokra – a jelenlegi helyzet helyett, amikor ez a két dolog vadul összekeverik, és nem ismerik fel a különálló problémák miatt. Végső soron teljesen racionális és ésszerű dolog, ha nem támogatunk egy olyan változtatást, amely magának a soft fork aktiválásnak a kockázatain alapul, vagy jogos hiányosságok vagy kockázatok miatt, amelyeket egy egyedi javaslat jelent a hálózatnak. Mindazonáltal nem gondolom ésszerűnek hangot adni a támogatás hiányának, amelynek gyökere a teljesen nem tényszerű állítások egy javaslatról és arról, hogy valójában mit tehet, miközben e folyamat során magáról a javaslatról félretájékoztatjuk azokat az embereket, akik jelenleg próbálnak megismerni és megértik a javaslatot, hogy saját döntést hozzanak. Ezt a konszenzusos folyamat elleni támadásnak nevezném.
A bitcoinosok ne érezzék szükségét hazugságok és félretájékoztatás terjesztésére annak érdekében, hogy meggyőzzék az embereket arról, hogy ugyanazokat a pozíciókat foglalják el, vagy ugyanúgy cselekedjenek, mint ők.
Ez Shinobi vendégbejegyzése. A kifejtett vélemények teljes mértékben a saját véleményük, és nem feltétlenül tükrözik a BTC Inc. vagy a Bitcoin Magazine véleményét.
