Nagbibigay ang newsletter ng Bitcoin Optech ng mga nangungunang sa mga mambabasa-Lvel buod ng pinakamahalagang mga teknikal na balita na nangyayari sa Bitcoin, kasama ang mga mapagkukunan na makakatulong sa kanila na matuto nang higit pa. Upang matulungan ang aming mga mambabasa na manatiling napapanahon sa Bitcoin, muling inilalathala namin ang pinakabagong isyu ng newsletter na ito sa ibaba. Alalahanin na mag-subscribe upang matanggap ang nilalamang ito diretso sa iyong inbox. mga proyekto.
Balita
Walang makabuluhang balita sa linggong ito.
“https://bitcoinops.org/en/preparing-for-taproot/”target=”_ blank”> series tungkol sa kung paano maaaring maghanda ang mga developer at service provider para sa paparating na pag-aktibo ng taproot sa taas ng block na 709,632.
Sa 1,000 bloke na natanggap bago ang pagsusulat na ito, 11% ng lahat ng mga input ng transaksyon ay naglalaman ng isang multisig opcode. Ang dalawa sa pinakamalaki at pinaka-agarang mga benepisyo ng taproot ay mahahayag kung marami sa mga gumagamit at serbisyo na lumilikha ng mga transaksyong iyon ay lilipat mula sa mga multisig opcode patungo sa scriptless multisignature .
Ang unang pangunahing benepisyo ay ang pagbawas sa laki ng transaksyon. Ang mga multisig na nakabatay sa script ay tumataas sa laki dahil maraming mga key at lagda ang kinakailangan, ngunit ang mga multisignature ay pare-pareho ng maliit na sukat. Ang pinakamaliit na mabisang patakaran sa multisig (1-of-2) ay nangangailangan ng mas maraming espasyo kaysa sa isang patakaran sa multisignature na maaaring kasangkot sa libu-libong mga lumagda. Ang pagbawas sa laki ay humahantong sa direktang pagbawas ng mga bayarin para sa mga multisignature na gumagamit at isang hindi direktang pagbawas sa mga bayarin para sa lahat ng mga gumagamit dahil ang parehong halaga ng pangangailangan para sa mga nakumpirmang transaksyon ay maaaring matupad gamit ang isang mas maliit na halaga ng block space.
Ang pangalawang pangunahing benepisyo ay pinabuting privacy. Ang bawat paggamit ng multisigs ay natatanging naitala sa chain ng block kung saan maaaring gamitin ng mga surveillant ito upang makagawa ng matalinong hulaan tungkol sa kasaysayan ng pitaka at kasalukuyang balanse ng mga indibidwal na gumagamit. Halimbawa, pagtingin sa block 692,039, maaari nating makilala hindi lamang ang paggasta ng multisig mula sa paggastos ng solong-sig ngunit makilala rin ang pagitan ng iba’t ibang mga itinakdang laki at mga threshold para sa mga multisigs. sa data ng block chain ay hindi masasabi na ang isang gumastos ay gumamit ng isang multisignature. Kapag ang isang multisignature ay ginagamit para sa isang paggastos sa keypath, hindi ito makikilala mula sa paggasta ng solong-sig. Kung ang lahat ng solong-sig at multisigs sa bloke sa itaas ay inilipat sa paggastos ng keypath na P2TR, iilan lamang sa mga kakaibang paggasta ang makikilala ng kanilang mga script (at kahit na ang mga maaaring gumamit ng mga paggastos ng keypath sa pinakamagandang kaso).
Gumagamit ng mga multisignature
May kamalayan kami sa tatlong mga skim na multisignature na batay sa schnorr na partikular na idinisenyo para sa Bitcoin, lahat ng miyembro ng MuSig pamilya:
MuSig (tinatawag ding MuSig1), na dapat ay simpleng ipatupad ngunit nangangailangan ng tatlong pag-ikot ng komunikasyon sa panahon ng proseso ng pag-sign.MuSig2, simpleng ipatupad din. Tinatanggal nito ang isang pag-ikot ng komunikasyon at pinapayagan ang isa pang pag-ikot na isama sa pangunahing palitan. Pinapayagan ang paggamit ng isang medyo katulad na proseso ng pag-sign sa ginagamit namin ngayon gamit ang multisig na nakabatay sa script. Nangangailangan ito ng pag-iimbak ng labis na data at pagtiyak na ang iyong software sa pag-sign o hardware ay hindi maaaring linlangin sa hindi namamalayang paulit-ulit na bahagi ng session ng pag-sign.MuSig-DN (Deterministic Nonce), na mas kumplikadong ipatupad. Ang komunikasyon nito sa pagitan ng mga kalahok ay hindi maaaring pagsamahin sa pangunahing palitan, ngunit may kalamangan na hindi ito mahina laban sa paulit-ulit na pag-atake sa session. maraming pagpapatupad ang pipiliing gumamit ng parehong protocol. Ang mga may-akda ng mga panukala ng MuSig na iminumungkahi na magiging MuSig2 dahil sa kamag-anak nitong pagiging simple at mataas na gamit.
Mayroong isang bukas at aktibong binuo na PR sa proyekto ng libsecp256k1-zkp upang magdagdag ng suporta sa MuSig2. Inaasahan namin na ang pangunahing multisignature na daloy ng trabaho ay magmumukhang katulad ng sumusunod:
Ang wallet para sa bawat kalahok ay bubuo ng isang BIP32 xpub na ibinabahagi sa lahat ng iba pang mga kalahok sa pamamagitan ng isang tagapaglaraw ng script ng output o ibang pamamaraan (katulad ng karaniwang ginagawa ngayon para sa mga multisigs). Bumubuo rin ang wallet ng isang hanay ng mga nonce na ibinabahagi din sa iba pang mga kalahok. Ang wallet ay maaaring makabuo ng mga nonce na ito gamit ang BIP32 hardened derivation. Nonces ay 32 bytes at kailangan mo ng dalawa sa kanila bawat lagda. Para sa mga hindi madalas gamitin na mga pitaka, ang lahat ng mga hindi kinakailangan na kailangan para sa buong buhay ng wallet ay maaaring ibahagi sa harap. Para sa mas madalas na ginagamit na mga pitaka (hal. LN routing node), ang bawat pitaka ay maaaring magpadala ng pirma nito para sa kasalukuyang transaksyon kasama ang mga nonce nito para sa susunod na transaksyon. Ang alinman sa mga pitaka ay maaaring makabuo ng isang pinagsamang pampublikong key sa pamamagitan ng pagsasama sa pubkey nito sa isang tiyak na BIP32 lalim kasama ang mga pubkey sa parehong lalim mula sa lahat ng iba pang mga pitaka sa samahang multisignature. Ang pinagsamang pampublikong key ay maaaring magamit upang makatanggap ng mga pagbabayad ng P2TR. Kapag ang isa sa mga pitaka ay nais na gugulin ang mga pondo, gumagamit ito ng isang PSBT -based na daloy ng trabaho na katulad ng gagamitin nito sa multisig na nakabatay sa script. Hindi tulad ng multisig, ginagamit ng wallet ang susunod na mga nonce at ang susunod na mga nonce ng lahat ng iba pang mga kalahok upang lumikha ng isang nakabahaging nonce ayon sa MuSig2 algorithm; lumilikha ito ng isang bahagyang lagda sa nonce na iyon at sa transaksyon. Kapag natanggap ng iba pang mga pitaka ang PSBT, ginagamit nila ang parehong pamamaraan. Ang mga bahagyang lagda ay pinagsama upang likhain ang pangwakas na lagda at ang transaksyon ay nai-broadcast.
Pag-sign ng threshold
Sa pamamagitan ng kanilang sarili, bibigyan ka lamang ng pamilya ng MuSig ng mga multisignature na scheme ng pag-sign n-of-n — bawat partido na nag-aambag ng isang susi patungo sa pinagsama-samang publikong susi ay dapat ding magbigay ng isang bahagyang lagda sa pangwakas na lagda. Ito ay gumagana nang perpekto bilang isang direktang kapalit para sa ilang paggamit ng multisig na nakabatay sa script ngayon, tulad ng paggastos ng 2-of-2 LN na mga output sa pagpopondo, ngunit ito ay isang pag-alis mula sa iba pang mga tanyag na patakaran tulad ng 2-of-3 multisig script na ginamit ng maraming mga exchange. magdadala ng parehong kahusayan at mga benepisyo sa privacy ng mga multisignature sa mga k-of-n na senaryo, ngunit may isang simpleng trick na maaaring magamit hanggang sa magagamit ang mga scheme na iyon.
ang mga kalahok ay malamang na mag-sign. Halimbawa, sa isang sitwasyon na 2-of-3, maaaring malaman na normal na magkasamang mag-sign sina Alice at Bob, habang pumipirma lamang si Carol kung ang isa sa iba ay hindi magagamit. Para sa hanay ng mga pangyayaring ito, ang pangunahing mga susi ay maaaring gumamit ng isang multisignature para sa taproot keypath na paggastos (hal sa pagitan nina Alice at Bob) at ang mga karagdagang resulta (sina Alice at Carol, o Bob at Carol) ay maaaring gumamit ng mga multisignature na may OP_CHECKSIG opcode sa magkakahiwalay na mga sangay sa isang puno ng tapscripts . Sa normal na kaso, ang nasa itaas ay mayroong eksaktong kahusayan at privacy bilang isang solong-sig o multisignature na transaksyon. Sa hindi normal na kaso, gumagana pa rin ang paggasta tulad ng inaasahan at mananatiling mas mahusay at pribado kaysa sa pag-publish ng iyong mga multisig parameter na onchain. isang href=”https://murchandamus.medium.com/2-of-3-multisig-inputs-using-pay-to-taproot-d5faf2312ba3″target=”_ blank”> scheme ay maaari ring magpatuloy na manatili ginagamit dahil nagbibigay ito ng onchain na patunay sa isang auditor (kung alam nila ang lahat ng mga pampublikong key ng mga kalahok) tungkol sa kung aling mga kaukulang pribadong key ang ginamit upang mag-sign. Mga bagong paglabas at magpapalabas ng mga kandidato para sa mga sikat na proyekto sa imprastraktura ng Bitcoin. Mangyaring isaalang-alang ang pag-upgrade sa mga bagong paglabas o pagtulong upang subukan ang mga kandidato sa paglabas.
C-Lightning 0.10.1rc2 ay isang kandidato para sa paglabas para sa isang pag-upgrade na naglalaman ng isang bilang ng mga bagong tampok, maraming mga pag-aayos ng bug, at ilang mga pag-update sa pagbuo ng mga protocol (kasama ang dalawahang pagpopondo at alok Mga kilalang pagbabago ng code at dokumentasyon
Mga kilalang pagbabago sa linggong ito sa Bitcoin Core , lt/eclair”target=”_ blank”> Eclair
Bitcoin Core # 22006 nagdaragdag ng dokumentasyon para sa User-Space, Statically Defined Tracing ( USDT) at ang unang tatlong mga tracepoint-bumuo ng suporta at macros kung saan idinagdag sa Bitcoin Core # 19866 . Ang mga gumagamit na nagtatayo ng Bitcoin Core na may naka-enable na pagsubaybay sa eBPF ay maaaring mag-hook sa mga tracepointer na may ibinigay na halimbawang mga script o sumulat ng kanilang sariling mga script ng pagsubaybay para sa higit na kakayahang masubaybayan sa node kapag nakakonekta ang isang bagong bloke, mga papasok na P2P na mensahe ay natanggap, at papalabas na mga mensahe ng P2P. Nagsasama rin ang dokumentasyon ng mga halimbawa ng paggamit at alituntunin para sa pagdaragdag ng mga bagong tracepoint. Pinapayagan ang Eclair # 1893 magkakahiwalay na pagsasaayos ng mga feerate para sa mga hindi na-announce na channel , inanunsyo na mga channel, at trampoline relay minimums. Nagtatakda din ang PR na ito ng iba’t ibang mga default na relay na nagpapa-feerate para sa mga hindi naipahayag na mga channel (0.01%) na kaibahan sa mga inihayag na channel (0.02%). Rust-Lightning # 967 ay nagdaragdag ng suporta para sa paggawa ng kusang-istilong mga pagbabayad na keyend sa pamamagitan ng tawag sa pagpapaandar ng function na thesend_spontaneous_payment. Sa pagbabagong ito, lahat ng apat na pagpapatupad ng LN na sakop namin ay magkakaroon ng suporta para sa keyend.
Nagsumite din ang may-akda ng kaukulang dokumentasyon (hindi pa na-integrate) sa mga pagbabayad na keyend bilang isang BLIP (Mga Panukala sa Pagpapaganda ng Bitcoin Lightning), isang iminungkahing paraan upang idokumento ang mga tampok at pinakamahusay na kasanayan na hindi kabilang bilang bahagi ng pagtutukoy ng LN BOLTs
Hanapin ang orihinal na post dito. direktang mag-subscribe sa newsletter ng Bitcoin Optech upang matanggap nang diretso ang nilalamang ito sa iyong inbox bawat buwan.
