Mambabasa: intermediate hanggang advanced

Nabanggit sa mga uri ng Bitcoin address ang Taproot. Uulitin lang natin na ang mga address ay konsepto sa ibabaw ng Bitcoin na ipinakilala ng mga wallet applications. Ang pagkakaroon ng bagong klase ng address ay dulot ng mga pagbabago sa loob ng consensus layer ng Bitcoin.

Dahil sa Taproot, maiging balikan natin ang kriptograpiya para sa isang uri ng digital signature algorithm: Schnorr signature.

Schnorr Signature Scheme

Isang motibo sa pagbuo ng Elliptic curve digital signature algorithm (ECDSA) ay ang copyright na naglimita sa paggamit ng Schnorr signatures. Sa ngayon, lumipas na ang copyright na ito, kaya bukas na sa lahat ang paggamit ng scheme.

Sa totoo lang, mas simple ang Schnorr signature scheme kesa sa ECDSA. Mas tipid ito sa komputasyon, palibhasa nga, ang ECDSA ay umiwas sa patent ng Schnorr signature scheme.

Balikan natin sina Alicia at Bob, at ang mga parameters, na sana pamilyar pa rin sayo. Iibahin lang natin ang notasyon kumpara sa Kabanta 3, para tutugma ito sa explanasyon ng BIP-0340, kung gusto mo mang pag-aralan pa ng mas malalim.

Alicia	Parameters	Bob
n	Finite Field order (alam ng lahat)	n
G	Generator (alam ng lahat)	G
dA	Private key	dB
PA = dAG	Public key (malalaman ng nakikipagtransaksyon)	PB = dBG

Tandaan na sa scheme na ito, kailangang maberipika ni Bob na alam ni Alicia ang private key, nang hindi ito naipapakita. At dapat ring non-interactive, o hindi kailangang magkasama o magkasabay sina Alicia at Bob na nakatutok sa transaksyon. Pwedeng maberipika ito ni Bob kahit kinabukasan na.

Ang susunod na talaan ay nagpapakita ng mga hakbang para maipatupad ang Schnorr signature scheme:

Alicia	Parameters/Exchange	Bob
r <— R{0, 1, …, n-1}	Nonce, pansamantalang private key na pipiliin na random / sikreto <—
R <— rG	Point generated na syang commitment sa transaksyon (parang pansamantalang public key); ito ay parte na ng signature / —
m	Message / ipapasa —>	m
e <— H(R,m)	Hash ng (R||message), gagamitin sa signature ni Alicia / —
s <— r + edA mod n	Parte ng signature na may marka ng private key dA ni Alicia / —
(R, s)	Signature / ipapasa —>	(R, s)
	Hash ng (R||message), na gagamitin naman ni Bob na pamberipika / —	h <— H(R,m)
	Verification equation / —	sG ≟ R + ePA

Ikumpara mo ang talaan na iyan dun sa talaan ng ECDSA sa Kabanata 3. Mas maiksi yung andito, diba?

Ang e ay lumalabas na “challenge” kung saan gagamitin ni Alicia para gumawa ng signature nang hindi sya makakadaya, at gagamitin naman ni Bob bilang pamberipika. At ang pagpatupad na ang e ay dapat hash ng R at mensahe (m) ang nagbibigay ng non-interactive property sa Schnorr signature scheme.

Tignan natin ang beripikasyon:
sG ≟ R + eP
(r + ed)G ≟ R + eP
rG + edG ≟ R + eP
R + eP = R + eP ✓

Mas madali itong nagawa, hindi ba?

Ang Schnorr signature scheme ay maaaring gamitin sa secp256k1 na syang elliptic curve (at group) na gamit sa pagpapatunay ng mga transaksyon sa Bitcoin. At ito pa, ang scheme na ito ay provably secure, hindi tulad ng ECDSA. Nabanggit rin sa nakaraang mga kabanata ang transaction malleability. Hindi ito problema sa Schnorr signature scheme.

Ang Schnorr signature scheme ay nagbigay ng posibilidad sa taproot. At naglaon ngang nangyari ang upgrade na ito. Bago natin talakayin iyon, ilatag muna natin ang pag-unlad ng isang advanced na transaksyon na unang ipinatupad nung 2011.

Multi signatures

Pag-usapan natin ang multi signatures o multisig para matunton ang kalamangan ng Taproot sa ibang iskema.

Ang konsepto ng multi signature ay hango sa pangangailangan ng higit sa isang awtorisasyon para magalaw ang pera, o anumang importanteng bagay. Halimbawa, ang pangangailangan ng presensya o lagda ng mga may-ari ng joint account. O kaya, isang kandado na nangangailangan ng maraming susi para mabuksan. Kagaya ng sa monasteryo sa Mt. Athos, na may mga pinapangalagaang Byzantine relics. Ang mga susi ay hiwa-hiwalay na hawak ng iba-ibang pinagkakatiwalaang monghe.

Sa Bitcoin, naimungkahi ang paggamit ng multi signature nung 2011.

Standard o Bare Multi signature

Ang probisyon para sa multi signature ay nag-umpisa sa paglabas ng BIP-0011. Ang standard na multi signature ay lantarang script na magiging komplikado o mahabang UTXO. Isasaad ang mga public keys sa output script at ang kondisyon na dapat masunod gamit operator na CHECKMULTISIG. At ang gagastos nito ay dapat mag input ng tamang bilang ng signatures. Halimbawa, kapag 2-of-3 multi signature, dapat 2 sa mga signatures na mabeberipika ng 2 sa 3 public keys ang ibigay. Pero hanggang 3 public keys lamang ang limitasyon ng ganitong scheme.

Ang problema sa bare multi signature ay ang pakikipagtransaksyon. Ang mahabang multi signature script ay walang “address” na katumbas. Kaya may iba na tinatawag na pay-to-multisignature (P2MS) ang mga ganitong script na pagpapasahan ng Bitcoin. Kung may balak man magpadala ng Bitcoin dito, dapat ay gumamit ng wallet software na may kakayahang gumawa ng custom scripts. At dahil mas mabigat ang script, mas mahal ang transaction fee ng magbabayad. Isa pang isyu ay maiipon ang mga custom scripts na iyon bilang malalaking UTXO. Nakakapuno ito ng mempool hanggat hindi ginagasta.

P2SH Multi signature

Nabanggit sa Kabanata 4 kung bakit nagkaroon ng pay-to-script hash (P2SH) na mga wallet. Ito ay para ang komplikasyon at fees ay pasanin ng nagmamay-ari ng Bitcoin address na may probisyong multi signature o mas komplikado pang script.

Sa pagpapatupad ng P2SH, hanggang 15 public keys ang pwede gawan ng multi signature script, nang hindi na kelangan mapuno ang mempool ng malalaking UTXO. Subalit, isisiwalat rin ang multi signature na script, kasama ang mga public keys na kalahok, kapag gagastusin na ang Bitcoin.

Ang operator na CHECKMULTISIG ay kayang tumanggap ng 20 public keys. Kaso sa programming language ng Bitcoin (tinatawag na Script), may limitasyon na 520 bytes kada push operation. Kaya, hindi masusulit ang 20 public keys. 15 public keys lang ang sagad.

Dahil ang multi signature ay mainam na seguridad para sa mga kayang magpatupad nito, patuloy ang naging pagtatrabaho ng mga developers para sa pagpapabuti ng konsepto at implementasyon. Sa susunod na soft fork, nagawan ng paraan ang limitasyong nabanggit.

SegWit Multisig

Kagaya ng napag-aralan sa Kabanata 4, ang SegWit ay paraan upang mas mapaigting ang seguridad ng mga transaksyon. Nagtalaga ng witness na istraktura, na hiniwalay sa input ng transakyon. Pero merong wTXID commitment sa coinbase, para maiwasan ang transaction malleability.

Ang locking script, na nakasanayang tawaging scriptPubKey, ay tinatawag na witness script magmula nung SegWit soft fork, lalo na kapag tumutukoy sa komplikadong script gaya ng multi signature.

Bukod dun, ang witness ay may tinalagang bagong script system, na hindi nalilimitahan ng orihinal na script system ng Bitcoin. May ibang validation logic na ipinatupad para sa witness. Ang pagpapabuting ito ay naglaan ng mga bagong posibilidad, tulad ng napag-usapang Schnorr Signature sa taproot soft fork (sumunod sa SegWit soft fork). Isa pa dito ay maaaring hanggang 10,000 bytes ang witness script!

Dahil dyan, kaya na rin hanggang 20 public keys ang gawan ng multi signature script. Masusulit ang CHECKMULTISIG. Ang 520 bytes na limitasyon ng push operation ay naiiwasan sa SegWit dahil sa witness validation logic.

Dahil sa bagong script system din, ay kaya nang maipatupad ang mga kakayahan ng sumunod na upgrade sa Bitcoin software, na tinatawag na Taproot. Isinabay dito ang paggamit ng isang magandang kakayahan ng Schnorr signature: kung saan ang grupo ng mga signers ay maaaring makagawa ng:

• Pinagsamang signature na kasinghaba lang ng isa
• Na nangangahulugang may katumbas sa pinagsamang private keys, na may katumbas na pinagsamang public keys

Ang mga multi signature scheme na ganito ay binansagang MuSig. Pag-usapan natin ito sa loob ng paksa ng Taproot.

Taproot

Ngayon, balikan natin ang Schnorr Signature scheme, at paano ito ginamit sa Taproot upgrade.

Aplikasyon sa Taproot ng Schnorr Signature Scheme

Sa paggamit ng Schnorr signature scheme sa taproot upgrade, iniba ang mga data na iniha-hash para mas maigting ang seguridad ng iskema. Ang mga notasyon ay base sa nakasulat sa BIP-0340.

Sa halip na R at m lang, ang data na dadaan sa SHA-256 ay: r, pk at m. At ang scheme sa wakas ay:

sG = R + tagged_hash(r||pk||m)P

• Tagged hashes: gumagamit ng ganito upang matukoy ang kontexto ng hashing. Matatandaan na ang SHA-256 ay gamit sa iba-ibang sangkap ng Bitcoin. Ang tagged hash ay ang paggamit ng dalawang SHA-256 ng “tag”, pagdudugtungin, ilalagay sa loob ng SHA-256 bilang umpisang data, bago pa sundan ng importanteng data na ilalagay sa hashing: SHA-256(tag)||SHA-256(tag). Ang tag ay naka-encode ng UTF-8. Ang tag na gamit sa challenge ng Schnorr signature scheme sa taproot ay: BIP0340/challenge. Kaya ang tagged hash na nakasulat sa taas ay tumutukoy sa:
  • hash_{BIP0340/challenge}(r||pk||m), o
  • SHA-256(SHA-256(BIP0340/challenge)||SHA-256(BIP0340/challenge)||r||pk||m)
• Key-prefixed Schnorr signatures: upang paigtingin ang seguridad laban sa “related-key attacks” inilalagay ang public key bago ang mensahe, sa data na idadaan sa hashing (ang challenge).
• pk: Sa halip na buong P (kasama ang x– at y-coordinate), prayoridad ang pagiging siksik, kaya gagamitin lang ang x-coordinate ng public key. At ang x-coordinate na ito ay ang syang tumutugma lamang sa y-coordinate na even. Ito ang pk na may habang 32 bytes.
• r: Ang r ay x-coordinate na may katumbas na even y-coordinate, ng napiling R.
• Dahil sa mga nabanggit, ang signature ay (r,s). Ang haba ng r at s ay tig-32 bytes. Kaya ang signature s ay 64-bytes.

Ang pk o x-coordinate ng even y-coordinate na “public key,” mapa isa lang o pinagsamang maraming public keys (MuSig), ay pwede nang tumayang witness script. Subalit, hindi pk ang ginagamit na witness script sa taproot. Sa halip, minodipikang public key ang gamit. Pag-uusapan natin yan sa mas huling bahagi ng seksyong ito.

32 bytes, o 256 bits lagi ang haba ng witness script. Kaya, isang katangian ng Taproot address ay parehas na 62 na karakter ang haba ng mga address sa kahit anong kaso ng witness script. Hindi agad matutukoy kung single sig, multisig o may anumang karagdagang script ito.

Bago natin talakayin ang MuSig, tandaan na ang implementasyon ng Schnorr signature scheme ang syang espesipikasyon para sa on-chain na transaksyon. At off-chain magaganap ang anumang komplikadong protocol para sa seguridad, gaya nga ng MuSig. Basta ang maipapasa sa blockchain ay ang public key (o locking script na mukang public key), at signature (o unlocking script na mukang signature), na handang magamit para sa mas simpleng beripikasyon ng ordinaryong Schnorr signature scheme.

Ano ang rogue key attack?

Naive Key Aggregation

Ipapakita natin kung paano ang simpleng key aggregation sa Schnorr signature scheme. Babalik tayo sa mga notasyong gamit sa bandang una ng kabanata ha, wag ka malilito sa variables. Ipagpalagay na may 2 partido na gustong pumirma sa iisang mensahe. Naka 2-of-2 multi signature bale.

Partido 1	Parameters	Partido 2
n	Finite Field order (alam ng lahat)	n
G	Generator (alam ng lahat)	G
d1	Private key	d2
P1 = d1G	Public key (malalaman ng nakikipagtransaksyon)	P1 = d1G
m	Message	m
r1 <— R{0, 1, …, n-1}	Private nonce, pansamantalang private key na pipiliin na random	r2 <— R{0, 1, …, n-1}
R1 <— r1G	Nonce, point generated na syang commitment sa transaksyon (parang pansamantalang public key)	R2 <— r2G
R’ = R1 + R2 P’ = P1 + P2	Bago umusad sa challenge, kelangan nang pagsamahin ang mga R at P, para sa iisang mensahe, m	R’ = R1 + R2 P’ = P1 + P2
e <— H(R’,P’,m)	Challenge, na key-prefixed hash ng (R’,P’,m). Kelangan pinagsamang R at P na para sa iisang m.	e <— H(R’,P’,m)
s1 <— r1 + hd1 mod n	Partial signature na may marka ng private key, s	s2 <— r2 + hd2 mod n

Kapag pinagsama ang 2 signatures, ito ay may katumbas. na:
(s₁ + s₂) = (r₁ + ed₁ + r₂ + ed₂)
(s₁ + s₂) = (r₁ + r₂) + e(d₁ + d₂)
s’ = r’ + ed’

Kaya kapag ini-multiply ng generator, G:
s’G = r’G + ed’G
s’G = R’ + eP’

At iyan ay mukang ordinaryong beripikasyon ng Schnorr signature, ‘di ba?

Pwede na bang gamitin ang simpleng addition ng mga signatures, nonces at public keys? Hindi. Dahil ito ay hindi sapat ang seguridad. Ito ay mabibiktima ng rogue key attack.

Ano ang rogue key attack? Kapag ang isang signer ay malisyoso, maaari nitong ideklara ang kanyang public key na may relasyon sa public key ng tapat na signer. Isang simpleng paraan ay: Halimbawa, ang partido 2 ay malisyoso. Maari nyang ideklara ang public key na:

P₂’ = P₂ – P₁
P’ = P₁ + (P₂ – P₁)
P’ = P₂

Kaya pwede nyang pirmahan ang mensahe gamit lamang ang kanyang public key.

Ang problemang ito ay niresolba ng MuSig.

MuSig1

Upang maiwasan ang rogue key attack, ipinakilala ng MuSig ang paggamit ng key aggregation coefficients. Gamit ang mga public keys at hash function, gagawa ng coefficient para sa bawat public key, a_i, bago kunin ang aggregated public key. Tignan uli natin sa 2 signers:

Partido 1	Parameters	Partido 2
a1 = Hagg(P1||P2||P1)	Key aggregation coefficient ai = Hagg(P1||P2||Pi)	a2 = Hagg(P1||P2||P2)

Ang aggregated public key ay magiging:

P’ = a₁P₁ + a₂P₂

Dahil sa paggamit ng one-way hash function, at lahat ng public keys sa komputasyon ng bawat coefficient, hindi madadaya ang public key para sa rogue key attack.

Tandaan: kailangang may key aggregation coefficient ring nakapaloob sa partial signature ng bawat partido, s_i, bago ito pagsamahin:

Partido 1	Parameters	Partido 2
s1 <- r1 + ea1d1 mod n	Partial signature na may marka ng private key, si	s2 <- r2 + ea2d2 mod n
s’ = s1 + s2	Aggregated partial signature, s’	s’ = s1 + s2

Titigil na sana sa kontribusyon na yan ang mga may-akda ng MuSig. Subalit, bago mailabas ang MuSig paper, may nagsabi sa mga may-akda ng posibleng atake sa iskema kahit pa may key aggregation coefficients. Kaya, nagdagdag ng mas una pang hakbang: nonce commitments. Ito naman ay ang pagbibigay ng hash ng mga nonce, bilang commitment, bago pa ipaalam ang nonce. Sa ganitong paraan, mabeberipika kung merong malisyosong signer na nag-iba ng nonce.

Partido 1	Parameters	Partido 2
Hcom(R1)	Nonce commitment, Hcom(Ri)	Hcom(R2)

Ito ang pagkakasunud-sunod ng iskema ng pagpirma base sa dami ng komunikasyon sa pagitan ng mga signers:

1. Kunin ang nonce, subalit ipaalam muna ang nonce commitments H_com(R_i).
2. Ipaalam na ang nonce, R_i, at kunin ang aggregated nonce R’, at saka kunin ang challenge, e.
3. Gumawa ng kani-kaniyang partial signature s_i, na mayroon ding napapaloob na key aggregation coefficient, a_i, ipaalam sa isa’t isa, para mapagsama bilang s’. Tapos, ipadala ang kabuuang aggregated signature (R’,s’) sa katransaksyon ng MuSig users.

Nilayon ng susunod na bersyon ng MuSig, na tanggalin ang nonce commitment na hakbang.

MuSig2

Upang tanggalin ang unang round (nonce commitment) sa MuSig1, iminungkahi sa MuSig2 ang pagkuha ng 2 nonces ng bawat signer, sa halip na isa lang. Napataas nito ang seguridad ng iskema. Ang paggamit ng key aggregation coefficients, a_i, ay nananatili sa MuSig2.

At ang pagsasama ng nonces ay gagamit ng iba pang nonce aggregation coefficient, b, na mula sa hashing ng kombinasyon ng mga nonces, aggregated public key, at mensahe.

Partido 1	Parameters	Partido 2
r1,1 <— R{0, 1, …, n-1} r1,2 <— R{0, 1, …, n-1}	2 private nonces kada signer, pansamantalang private keys na pipiliin na random, ri,j	r2,1 <— R{0, 1, …, n-1} r2,2 <— R{0, 1, …, n-1}
R1,1 <— r1,1G R1,2 <— r1,2G	2 nonces kada signer, points generated, Ri,j, na sangkap bago ang totoong commitment sa transaksyon	R2,1 <— r2,1G R2,2 <— r2,2G
R1 = R1,1 + R2,1 R2 = R1,2 + R2,2	Addition ng 2 grupo ng nonces, Rj	R1 = R1,1 + R2,1 R2 = R1,2 + R2,2
b = Hnon(R1||R2||P’||m) mod n	Nonce aggregation coefficient b = Hnon(R1||R2||P’||m) mod n	b = Hnon(R1||R2||P’||m) mod n

Gamit ang nakuhang b, kukunin ang pinakapinagsama, aggregated nonce ng signers: R’ = R₁ + bR₂

Partido 1	Parameters	Partido 2
R’ = R1 + bR2	Aggregated nonce, R’ = R1 + bR2	R’ = R1 + bR2

Ngayon, ang pagkuha ng partial signature ng bawat partido, s_i, ay magpapaloob na ng 2 coefficients: ang key aggregation, a_i, at nonce aggregation, b. (Tandaan: magkaiba ang a, parehas ang b.)

Partido 1	Parameters	Partido 2
s1 <- r1,1 + br1,2 + ea1d1 mod n	Partial signature na may marka ng private key, si	s2 <- r2,1 + br2,2 + ea2d2 mod n

Ito ang pagkakasunud-sunod ng iskema ng pagpirma sa MuSig2 base sa dami ng komunikasyon sa pagitan ng mga signers:

1. Kumuha at ipaalam ang 2 nonces, R_i,1 at R_i,2, kumuha ng nonce aggegation coefficient, b, kunin ang aggregated nonce R’, at saka kunin ang challenge, e.
2. Gumawa ng kani-kaniyang partial signature s_i, na mayroong napapaloob na key aggregation coefficient, a_i, at nonce aggregation coefficient, b, ipaalam sa isa’t isa, para mapagsama bilang s’. Tapos, ipadala ang kabuuang aggregated signature (R’,s’) sa katransaksyon ng MuSig users.

Sa taproot upgrade, hindi ginagamit ang operator na CHECKMULTISIG, at ang katumbas nitong CHECKMULTISIGVERIFY. Naka-disable pa nga ang mga ito. Sa halip, may dinagdag na CHECKSIGADD operator.

Key Path at Script Path

Ngayon naman, ay pag-usapan natin ang mismong katangian na taproot. Ano pa nga ba sa napag-usapan natin ang may ‘root’? Merkle root! At ang konseptong ito din ang pinagmulan ng taproot.

Ang mga iba-ibang kondisyon upang magasta ang isang UTXO (o Bitcoin na nakatali sa script) ay inaayos sa anyo ng Merkle Tree. Halimbawa, ang MuSig2 ay nakaispesipika para sa n-of-n multi signature (lahat dapat pumirma). Para mapagana sa t-of-n (halimbawa: 2-of-3 sa halip na 3-of-3) ito, maaaring gumawa ng ibang scripts, na alternatibong paraan para maaprubahan ang transaksyon. Paano gagawin iyon?

Ilalagay bilang alternatibong mga scripts ang mga kombinasyon ng 2 signers na posible kapag merong kabuuang 3. Bawat script ay 2-of-2 MuSig2 scheme. Halimbawa, sa 3 partido: A, B at C. May 3 kombinasyon ng tig-2 signers. A&B, B&C, A&C. At bubuuin ang kondisyon para maaaring gumasta gamit ang kahit anong 2-of-2 na kombinasyon. Kaya ang epekto ay parang 2-of-3 multi signature scheme.

Hindi ba mas mabigat ito? Mukha nga, pero, ang paggawa ng scheme na ito ay off-chain, gaya ng nasabi kanina bago ang diskusyon sa MuSig.

Ang mga iba-ibang scripts ay gagawan ng Merkle Tree, kung saan ang bawat script ay mapapaloob sa tapleaf. Sa ganitong paraan, magkakaroon ng kondisyon na parang OR – bawat script sa isang leaf ay magiging alternatibong paraan ng paggasta ng UTXO. Tignan natin ang ilustrasyon ng Merkle Tree at relasyon nito sa n-of-n na aggregated key:

Ang pinakadisenyo ng pagdeklara ng output key ay ganito:

Q = P + hash_TapTweak(p||k_m)G
Tapos kukunin ang x(Q) = q

Kung saan ang k_m ay ang root ng Merkle tree, na tumatayong commitment. Ang P ay internal public key, p ay ang x-coordinate nito, na syang taproot internal key. Ang Q ay tweaked o modified public key. At q ang x-coordinate nito, na syang idedeklarang taproot output key. At ito na ang i-eencode para maging Bitcoin wallet address.

Ang UTXO na nakatali sa q na ito ay pwedeng:

1. Direktang magasta sa pamamagitan ng pagbibigay ng signature na mabeberipika gamit ang Q. Ito ang key path. Ang signature na tinutukoy ay ang gagawin ng tweaked private key. Ano ito? Ito ang private key, d, na tugma sa P, pero dadagdagan ng parehas na tweak: d + hash_TapTweak(p||k_m)G.
2. Sa isang banda, maaaring gastahin ang UTXO gamit naman ang script path. Ito ay sa pamamagitan ng pagbibigay ng mga sumusunod:
   • Partikular na witness;
   • Ang katugma nitong witness script (locking script) sa partikular na leaf ng Merkle tree;
   • Control block, c, na naglalaman ng leaf version, internal key p (na pagkukuhanan ng P), at ang Merkle path na nagpapatunay na nag-commit nga ang Q sa leaf na iyon.

Sa ilustrasyon ng taproot paths, ipinakitang key path yung aggregated key ng lahat ng posibleng signers (gamit ang MuSig2). Hindi ito kelangan sundin lagi. Sa paggawa ng taproot address, dapat ay mapagdesisyunan ng mga partido kung ano sa mga scripts na may aggregated (o single) key ang may pinakamataas na posibilidad magamit. Ito ang gagamiting key path, na pagbabasehan ng taproot internal key, p. Ang ibang scripts ang iaayos sa Merkle Tree.

Eh paano kung:

1. Walang kondisyon na pwedeng pang internal key?
   • Ipipilit ang key path na sa realidad ay pinakamaliit ang posibilidad magamit. Ito ang naipakita nang halimbawa na pagkuha ng aggregated public key ng lahat ng signers – ang kondisyong n-of-n – at gamitin iyong internal key para sa key path.
   • Pwede rin na may pipiliing point sa secp256k1 curve na pagmumukaing internal key, pero sikretong mabeberipika ng mga nagmamay-ari ng address, na wala talagang key path na kondisyon.
2. Walang gusto o kelangan na script (halimbawa single sig lang pala)? Ang output key point ay Q = P + hash_TapTweak(p)G. Saka kukunin ang q na i-eencode sa anyo ng Bitcoin address.

Halimbawa ng Paggamit ng Multi signature Wallet

Maglatag tayo ng halimbawa kung paano bumuo ng multi signature address sa isang wallet. Ang set up na ito ay mainam na may iba-ibang wallet na magbibigay ng kani-kaniyang signature. Hindi yung nasa loob lang ng isang wallet lahat.

May mga wallet app na tulad ng Sparrow, kung saan iyon ang pwedeng gamiting platform sa pagkalap ng mga kelangang data sa mga indibidwal na wallet. Sila ang magiging awtoridad na panggagalingan ng signatures para mapagana ang send na transaksyon.

Ipagpalagay natin na

• May desktop wallet app kang gagamitin para bumuo ng multi-signature address, na 2-of-3
• May 3 magkakaiba/hiwalay na hardware wallets kang gagamiting pampirma

Ito ang mga hakbang para gumawa ng address na P2WSH:

1. Buksan ang desktop wallet app at gumawa ng bagong wallet.
2. Pangalanan ang wallet
3. Sa settings, piliin ang multi signature
4. Piliin ang klase ng script kung kelangan, halimbawa, P2WSH
5. Piliin kung anong iskema ng mga tagapirma. Halimbawa, 2-of-3 signers ang magpapabisa ng send transaction. Mula dito ay lalabas kung ilan ang blangkong keystore na kailangang punan.
6. Sa bawat isang keystore, piliin ang paraan kung paano ilalagay ang xpub (extended public key). Napag-usapan sa kabanata 4 kung ano ang xpub.
   • Gamit ang USB na koneksyon ng desktop at ng hardware wallet.
   • Kung air-gapped (iniiwasan ang koneksyon ng wire), pwedeng mag-import ng xpub file mula sa SD card ng isang hardware wallet, o kaya mag scan ng QR code. Depende ito sa kakayahan ng hardware wallet.
   • Pwede ka rin mag-import o gumawa ng bagong software wallet. Pero iniwasan natin ito sa halimbawa.
   • Sa bawat wallet, hanapin sa settings ang multi signature wallet, at piliin ang export xpub. Depende uli sa kakayahan ng wallet, pwede mag export sa pamamagitan ng USB, SD card o QR code.
7. Kapag kumpleto na ang xpubs, pwede mo na tapusin ang set up.
8. Maaari kang hingan din ng password, na tumutukoy sa desktop wallet na ginawa mo.
9. Dapat ay itago mo ang kopya ng output descriptor file. Nakalagay sa output descriptor ang mga xpubs at derivation paths, kung sakaling kelangan mong i set up uli ang wallet.
10. I-export mo ang multisig wallet sa bawat isang keystore. Ito ay para mai-set up mo ang multi signature wallet sa kada device. Maaari mong i-export bilang .txt file, na ipapasa sa wallet gamit ang SD card o USB connection, o kaya gumawa ng QR code na ii-scan ng wallet.

Kapag tatanggap ka ng satoshis/bitcoin, pipiliin mo lang ang Receive na button/tab sa iyong multisig wallet, at ipakita ang wallet address sa sinumang magbabayad/magbibigay sayo.

Subalit, kapag ikaw ang magpapadala ng satoshis, kelangan mong ihanda ang 2 hardware wallets na itinakda mong keystores.

• Piliin ang Send button/tab
• Ilalagay mo ang address na pagbibigyan, at ayusin ang mga settings kung meron, tulad ng pagbigay ng pangalan sa transaksyon, at anong fee ang gusto mo.
• Ipagpatuloy ang paggawa ng transaksyon sa paglalagay ng signatures. Pwedeng ilagay ang signature gamit ang pag-scan ng QR code, o kaya naman ay pag-save ng isang partially signed bitcoin transaction (PSBT).
• Ang partially signed bitcoin transaction (PSBT) ay isang file (.psbt) na naglalaman ng hindi pa kumpletong transaksyon. Mula sa desktop wallet, ipapasa mo sa hardware wallet para pirmahan. Kumpirmahin ang detalye bago aprubahan. Pagkapirma, ang hardware wallet ay magbibigay ng PSBT uli na pirmado nya, para naman mailipat mo sa desktop wallet.
• Kapag kumpleto na ang signatures, i-broadcast mo na ang transaksyon.

---

Napag-usapan natin ang ilan sa mga pag-unlad ng Bitcoin, na malaki na ang pagbabago mula noong unang implementasyon na nakalathala sa White Paper. Subalit marami pang ibang aspeto at komplikasyon na hindi na naisama dito. Limitado lang rin ang oras at kakayahan ng may akda. Kaya nasa iyo na para hanapin pa ang sagot sa iyong mga katanungan ukol sa Bitcoin.