fbpx

Bitcoin သည် လိုက်ဖက်ညီသော UTXO များတွင် လက်မှတ်များကို မည်သို့ပြန်သုံးနိုင်မည်နည်း။


၎င်းသည် Cointelegraph Research မှ Bitcoin ပဋိညာဉ်များအကြောင်း နည်းပညာဆောင်းပါးစီးရီးတွင် အပိုင်း 3 ဖြစ်သည်။ ယခင်ဆောင်းပါးကိုဖတ်ရန် ကလစ်နှိပ်ပါ။ ဒီမှာ.

SIGHASH_ANYPREVOUT အနေဖြင့်၊ အဆိုပြုချက်BIP 118 တွင် ed in the အစောပိုင်း SIGHASH_NOINPUT အယူအဆကို တည်ဆောက်သည် Joseph Poon နှင့် Thaddeus Dryja တို့၏ 2015 Lightning Network စာတမ်းထို့နောက်တွင် Joseph Poon မှ တရားဝင်အဆိုပြုခဲ့သည်။ bitcoin-dev စာပို့ခြင်း။ ဖေဖော်ဝါရီလ 2016 စာရင်း။

SIGHASH_ANYPREVOUT သည် opcode အသစ်မဟုတ်သော်လည်း Bitcoin သို့ soft-fork အဆင့်မြှင့်တင်မှုအဖြစ် အသုံးပြုရန် ဒီဇိုင်းထုတ်ထားသည့် SIGHASH အလံအတွက် အဆိုပြုထားသည့် တန်ဖိုးအသစ်တစ်ခုဖြစ်သည်။ SIGHASH အလံကို လက်မှတ်တစ်ခုတွင် ပေါင်းထည့်ထားပြီး ငွေပေးငွေယူတစ်ခု၏ မည်သည့်အစိတ်အပိုင်းများကို လက်မှတ်ရေးထိုးထားသည်ကို ဆုံးဖြတ်ပြီး CHECKSIG opcode ဖြင့် စစ်ဆေးမည်ဖြစ်သည်။ ရွေးချယ်ထားသော အလံကို လက်မှတ်ရေးထိုးသူမှ ရွေးချယ်သည်၊ ၎င်းမှ ပြဌာန်းထားခြင်းမရှိပေ။ scriptPubKey. softfork တွင် အဆင့်မြှင့်တင်နိုင်မှုနှင့်ပတ်သက်သော နည်းပညာဆိုင်ရာအသေးစိတ်အချက်အလက်များကြောင့် SIGHASH_ANYPREVOUT အဆိုပြုချက်သည် အရင်းခံလိပ်စာများမှ သုံးစွဲငွေများအထိသာ အကျုံးဝင်ပါသည်။

ပုံ 1 တွင်သရုပ်ပြထားသည့်အတိုင်း စံ SIGHASH မုဒ်အမျိုးမျိုးရှိထားပြီးဖြစ်သည်။ အလံကို SIGHASH_ALL ဟုသတ်မှတ်ပါက၊ လက်မှတ်သည် သွင်းအားစုအားလုံး၊ အထွက်များအားလုံးကို နှင့် သုံးစွဲလျက်ရှိသော သီးခြားအမှတ်အသားများကို ဖုံးအုပ်ထားရမည်ဖြစ်ပြီး၊ ထို့ကြောင့် အဆိုပါ UTXO အတိအကျတွင် တရားဝင်ခွင့်ပြုချက်ကို လျှို့ဝှက်သင်္ကေတဖြင့် ချည်နှောင်ထားသည်။ ပွိုင့်တစ်ခုသည် ငွေပေးငွေယူ ID နှင့် အထွက်အညွှန်းကိန်းတစ်ခု၏ ပေါင်းစပ်မှုဖြစ်ပြီး မည်သည့် UTXO အရောင်းအ၀ယ်ပြုလုပ်နေသည်ကို သီးသန့်ခွဲခြားသတ်မှတ်ထားသည်။ SIGHASH_NONE ဖြင့်၊ သွင်းအားစုများသာ လက်မှတ်ရေးထိုးရန် လိုအပ်ပြီး ရလဒ်များကို အတားအဆီးမရှိ ထားခဲ့ပါ။ SIGHASH_SINGLE မူကွဲသည် သွင်းအားစုအားလုံးကို လက္ခဏာပြသည်၊ သို့သော် ထည့်သွင်းမှုတွင် လက်မှတ်ရေးထိုးထားသည့် အညွှန်းအတိုင်း တူညီသောအထွက်ကိုသာ ထုတ်ပေးသည်။ ANYONECANPAY ပြုပြင်မွမ်းမံမှုတွင် ထည့်သွင်းမှုတစ်ခုအား အခြားသူများနှင့် သီးခြားလွတ်လပ်စွာ လက်မှတ်ရေးထိုးခွင့်ပြုခြင်းဖြင့် နောက်ထပ်ပြောင်းလွယ်ပြင်လွယ်မှုကို မိတ်ဆက်ပေးသည်။ အရေးကြီးသည်မှာ၊ ဤရှိပြီးသားမုဒ်များထဲမှ တစ်ခုမှ အမှတ်အသားကို ကတိကဝတ်ကို ချန်လှပ်ထားရန် လက်မှတ်ကို ခွင့်မပြုပါ။ ထိုကန့်သတ်ချက်သည် SIGHASH_ANYPREVOUT ဖယ်ရှားသည့်အရာဖြစ်သည်။

BIP-118 သည် ပုံ 2 တွင် အကျဉ်းချုံးထားသော အနှစ်ချုပ်မှ ဖယ်ထုတ်ထားသော ယခင်ထွက်ရှိမှု မည်မျှနှင့် ကွာခြားသည့် မည်သည့် PREVOUT မျိုးကွဲနှစ်ခုကို သတ်မှတ်သည်။ SIGHASH_ANYPREVOUT အောက်တွင်၊ ရလဒ်ကို ချေဖျက်မှုမှ ဖယ်ထုတ်ထားသော်လည်း လက်မှတ်သည် ယခင်ထွက်ရှိထားသည့် ပမာဏနှင့် scriptPubKey ကဲ့သို့ပင်၊ nSequence. SIGHASH_ANYPREVOUTANYSCRIPT အောက်တွင်၊ ပမာဏနှင့် scriptPubKey ကိုလည်း ဖယ်ထုတ်ထားပါသည်၊ ဆိုလိုသည်မှာ လက်မှတ်သည် အသုံးပြုပြီးသော အထွက်၏ သော့ခတ်ထားသော script နှင့် လုံးဝမသက်ဆိုင်ပါ။ အခြားသော ကတိကဝတ်များ အားလုံးသည် စံ Taproot လက်မှတ် မက်ဆေ့ချ် တည်ဆောက်မှုကို လိုက်နာပြီး SIGHASH_ALL သို့မဟုတ် SIGHASH_SINGLE ကဲ့သို့သော ရွေးချယ်ထားသော အခြေခံအလံပေါ်တွင် မူတည်ပါသည်။

ရလဒ်ကို ချေဖျက်မှုမှ ချန်လှပ်ထားသောကြောင့်၊ တူညီသောလက်မှတ်သည် လက်ကျန်သတ်မှတ်ထားသောနယ်ပယ်များကို ကျေနပ်စေမည့် ကိုက်ညီသည့် UTXO မှန်သမျှကို သုံးစွဲခွင့်ပြုနိုင်သည်။ ဥပမာ၊ ANYPREVOUT | ဖြင့် ကြိုတင်လက်မှတ်ထိုးထားသော ငွေပေးငွေယူတစ်ခု မူရင်းလက်မှတ်ကိုဖန်တီးရန်အသုံးပြုသည့်ပုဂ္ဂလိကသော့သည် 0.5 BTC နောက်ပိုင်းတွင်တူညီသောလိပ်စာမှ 0.5 BTC ကိုရရှိသောအခါတွင် 0.5 BTC အထွက်ကိုထုတ်လုပ်ရန် အားလုံးကို ပြန်လည်အသုံးပြုနိုင်ပါသည်။ UTXO အသစ်တွင် 0.5 BTC ထက်ပိုပါက၊ မူရင်းလက်မှတ်တွင် ပြောင်းလဲမှု output မပါဝင်ပါက ပိုလျှံငွေကို မိုင်းတွင်းလုပ်သားများထံ ဆုံးရှုံးသွားမည်ဖြစ်သည်။ ဤပြန်လည်ပေါင်းစည်းထားသော ပိုင်ဆိုင်မှုသည် မည်သည့်အရာကိုမဆို ကြိုတင်ကာကွယ်မှုဖြစ်စေသည်။ အလွှာ-၂ ပရိုတိုကောများအတွက် အသုံးဝင်သည်။တူညီသောကြိုတင်လက်မှတ်ထိုးထားသောငွေပေးငွေယူသည် တစ်ခုစီအတွက် လက်မှတ်အသစ်များမလိုအပ်ဘဲ ဖြစ်နိုင်သည့် ကွင်းဆက် UTXO အများအပြားတွင် သက်ရောက်ရမည်ဖြစ်သည်။

ပဋိညာဉ်နှင့်တူသော အပလီကေးရှင်းများအတွက်၊ ANYPREVOUT မျိုးကွဲများသည် ယခင်ထွက်ရှိမှု၏ scriptPubKey အား ကတိကဝတ်ကို ထိန်းသိမ်းထားပြီး ပုံမှန်အားဖြင့် အသက်ဆိုင်ဆုံးဖြစ်သည်။ ရံပုံငွေများကို တူညီသောသော့ခတ်ထားသော script တွင် ဆက်လက်တည်ရှိကြောင်း သေချာစေပြီး တွဲဖက်အသုံးပြုနိုင်သော UTXO များတွင် လက်မှတ်များကို ပြန်လည်အသုံးပြုခွင့်ပြုပါသည်။ ANYPREVOUTANYSCRIPT သည် ဤစည်းနှောင်မှုကို လုံးလုံးလျားလျား ဖယ်ရှားပြီး ထို့ကြောင့် ပဋိညာဉ်ပုံစံ အပလီကေးရှင်းများနှင့် မသင့်လျော်ပါ။

OP_CTV နှင့်ဆင်တူသည်၊ SIGHASH_ANYPREVOUT သည် ကြိုတင်လက်မှတ်ထိုးထားသော ငွေပေးငွေယူများဖြင့် ရနိုင်နေပြီဖြစ်သော ယုတ္တိဗေဒအပေါ် တိုးတက်ကောင်းမွန်စေသော်လည်း ၎င်းကိုယ်တိုင်က ထပ်ကာထပ်ကာ ပဋိညာဉ်များ သို့မဟုတ် ငွေပေးငွေယူ စစ်ဆေးခြင်းတို့ကို မလုပ်ဆောင်ပါ။ ယင်းအစား၊ ၎င်းသည် လက်မှတ်တစ်ခုနှင့် သီးခြား UTXO တစ်ခုကြား ဆက်စပ်မှုကို ဖြေလျှော့ပေးကာ လက်မှတ်တစ်ခုအား လိုက်ဖက်ညီသော UTXO အများအပြားတွင် ပြန်လည်အသုံးပြုခွင့်ပေးသည်။

အချို့သော သုတေသနပြုချက်များအရ အဆိုပါ ကတိကဝတ်ကို ဖယ်ရှားခြင်းသည် ပြန်လည်ရယူထားသော သော့တည်ဆောက်မှုကို ဖြစ်နိုင်ချေရှိစေသည် — ဆိုလိုသည်မှာ၊ သက်ဆိုင်ရာ လျှို့ဝှက်သော့ကို မည်သူမှ မသိနိုင်သောကြောင့် သတ်မှတ်ထားသော လက်မှတ်နှင့် မက်ဆေ့ချ်အတွဲမှ ဆင်းသက်လာကာ UTXO ၏ သော့လမ်းကြောင်းကို အသုံးမ၀င်ဘဲ ဇာတ်ညွှန်းလမ်းကြောင်းမှတစ်ဆင့် မည်သူ့ကိုမဆို သုံးစွဲခိုင်းစေပါသည်။ script-path-only enforcement ကိုအားကိုးသည့် ဆောက်လုပ်ရေးလုပ်ငန်းများတွင် သော့လမ်းကြောင်းကို အသုံးမဝင်စေရန်အတွက် ယာယီသော့များလိုအပ်မှုကို ရှောင်ရှားနိုင်မည်ဖြစ်သည်။ ဤရှုထောင့်တွင် ပေါ်လာသည်။ Bitcoin ပဋိညာဉ်များ- အနာဂတ်ကို ထိန်းချုပ်ရန် နည်းလမ်းသုံးသွယ် Jacob Swambo et al မှ (၂၀၂၀)BIP-118 တွင် အဆိုပြုထားသည့် ဒီဇိုင်းထက် သီအိုရီအရ တည်ဆောက်မှုသာ ကျန်ရှိသေးသည်။

SIGHASH_ANYPREVOUT လက်မှတ်များနှင့်ဆက်စပ်သော အဓိကအန္တရာယ်မှာ လက်မှတ်ပြန်ဖွင့်သည်။. ဤလက်မှတ်များသည် တိကျသောအချက်တစ်ခုအတွက် ကျူးလွန်ခြင်းမရှိသောကြောင့်၊ UTXO အသစ်သည် ကျန်ရှိနေသောနယ်ပယ်များကို ကျေနပ်စေသည့်အတွက် တူညီသောလက်မှတ်ကို မူလရည်ရွယ်ထားသည်ထက် မတူညီသော UTXO ကိုသုံးစွဲရန်အသုံးပြုနိုင်ပါသည်။ သတ်မှတ်ထားသောဖွဲ့စည်းပုံများတွင် ဤအန္တရာယ်သည် ပိုမိုသိသာလာပါသည်- မည်သည် ကြိုတင်ပြင်ဆင်ထားသောအခါတွင်မဆို | SINGLE ကို အသုံးပြုပြီး အထွက်ပမာဏများကို ပြန်လည်စီစဉ်နိုင်သည်။ သီးခြား UTXO သည် တူညီသော scriptPubKey နှင့် ပမာဏနှင့်အတူ ရှိနေသောအခါ၊ တူညီသော အများသူငှာသော့သည် တွဲဖက်အသုံးပြုနိုင်သော ဇာတ်ညွှန်းတစ်ခုတွင် ပေါ်လာသောအခါ၊ သို့မဟုတ် သတ္တုတွင်းလုပ်သားတစ်ဦးသည် ဤအခြေအနေများကို အသုံးချရန် ငွေပေးငွေယူအမိန့်ပေးခြင်းနှင့် ပါဝင်ခြင်းတို့ကို လွှမ်းမိုးနိုင်သည့်အခါ။ သို့သော်၊ ဤအခြေအနေများသည် ပရိုတိုကော ဒီဇိုင်းအတွင်း ပြန်လည်ကစားသည့်အခြေအနေများအတွက် အသုံးပြုသူ သို့မဟုတ် ဆော့ဖ်ဝဲအင်ဂျင်နီယာ၏ ချို့ယွင်းချက်တစ်ခုခုကို တမင်တမင်အလွဲသုံးစားလုပ်ရန် လိုအပ်သည်။

ကျွန်ုပ်တို့၏နောက်ဆောင်းပါးတွင် ပံ့ပိုးပေးသည့်ကိရိယာများအဖြစ် အသုံးပြုသည့် Opcodes အကြောင်း ဆွေးနွေးမှုကို စတင်ပါမည်။ ၎င်းတို့သည် Bitcoin script သို့မဟုတ် ဒေတာကိုင်တွယ်ခြင်း၏ ဖော်ပြနိုင်စွမ်းကို တိုးမြင့်စေသော်လည်း အခြားသော opcode များနှင့် ပေါင်းစပ်ထားခြင်းမရှိပါက ပဋိညာဉ်လုပ်ဆောင်ချက်ကို အကောင်အထည်မဖော်ပါ။ ဤနောက်အမျိုးအစားတွင်၊ ကျွန်ုပ်တို့ ဆွေးနွေးပါမည်။ OP_CHECKSIGFROMSTACK နှင့် OP_CAT.



Source

Comments are closed, but trackbacks and pingbacks are open.