สอบถามหน่อยครับ ธุรกรรมจาก Multisig Wallet

กับ ธุรกรรมจาก SingleSig Walelt

ถ้าจำนวน UTXO เท่ากันหมด ขนาดธุรกรรมนี้เท่ากันไหมหรอครับ

#Siamstr

Reply to this note

Please Login to reply.

Discussion

สงสัยเหมือนกันครับ

ไม่เท่าครับ เพราะ digital signatures ของ multisig ยาวกว่า

เคยเปรียบเทียบไหมครับ อยากรู้ว่าเยอะกว่าเยอะ ไหมครับ

ผมก็เคยสงสัย เลยลองเทสตั้งแต่สมัย fee 1 sat/vbyte ครับ 55555

Single Signature 1 UTXO ไป 1 UTXO (Native segwit) ขนาดธุรกรรม 204 byte (121.5 vbyte) ครับ

ส่วน Muti Signature 1 UTXO ไป 1 UTXO เหมือนกัน ขนาดธุรกรรม 338 byte (146.75 vbyte) ครับ

ทั้งนี้ขนาดของธุรกรรมขึ้นอยู่กับ จำนวน UTXO ทั้งฝั่ง Input และฝั่ง Output

ถ้าเป็น Mutisig ก็จะยาวกว่าเสมอ เพราะรายละเอียด Digital Signature ที่ต้องการจำนวนกุญแจเยอะกว่า (ถ้า Multisig 3-of-5 หรือ 8-of-10 ก็จะยิ่งยาวอย่างมีนัยสำคัญ) 🧡

ตอนปลดลอคจะใช้ multisig จะยาวกว่าเพราะ signature ยาวกว่า

เคยเปรียบเทียบไหมครับ อยากรู้ว่าเยอะกว่าเยอะ ไหมครับ

นั้นหมายถึงfee เยอะกว่าด้วยสินะ

ขอบคุณครับบบ

Jimmy song Notes Notes เมื่อวานครับ

ผม quote ไม่เป็น ขออนุญาต copy paste

Bare Multisig Outputs

-----------------------

Blocks are getting filled with bare multisig outputs and it's an obvious troll from people that hate Bitcoin. Let me explain.

Multisig currently can be done in many ways, but before p2sh (BIP0013), the only way to do multisig was through putting the many pubkeys on-chain. As ECDSA doesn't really let you aggregate keys, outputs had to specify something like "3-of-5 of these pubkeys." The normal UTXOs have the following number of bytes:

p2pkh:25

p2sh:23

p2wpkh:22

p2wsh:34

p2tr:34

By contrast the n in the k-of-n bare multisig determines the number of bytes and it's 5 + 34 * n (my math might be off, but around there). So for 3-of-5, it's upwards of 170 bytes. But that's using compressed keys. For uncompressed keys, you it's 5 + 66 * n or 335 bytes+, and worse, you can put in illegitimate uncompressed keys (keys that are provably have no private key) to add data to the chain

Why does this matter? Because these bytes stay in the UTXO set, which is what Bitcoin software optimizes for because that's how you validate that a transaction is a not double spend and satisfies the conditions of the smart contract that locked it.

What's worse, if the pubkeys are unspendable (uncompressed keys that are not real points on the secp256k1 curve), then they'll *never* be pruned. So the UTXO set grows larger and requires more resources for your typical node runner.

Interestingly, this was how the whitepaper was embedded into the Bitcoin blockchain by putting pieces of the whitepaper pdf in 64 byte chunks through uncompressed pubkeys. Luke's Eligius pool was one of the first to ban such transactions because they were clearly bloating not just the blockchain, but the UTXO set.

That's what these trolls are doing. They're adding to the UTXO set that's not easily prunable, though now, I'm guessing some people will add pruning for UTXOs with multisig outputs that don't have any legitimate keys.

ถามว่าเยอะกว่าเยอะไหม ก็ตามจำนวนเท่าของ sig เลยครับ

แต่ประโยชน์ก็ได้เพิ่มขึ้น อยู่ที่ว่าเราจะใช้ประโยชน์นั้นไหม

ถ้าเก็บเงินเป็นเวลานานต้องการส่งต่อให้ลูกหลานเป็นมรดกหรือเป็นองค์กรที่ต้องมีคนเก็บคีย์หลายคน หรือทำธุกรรมกับคนไม่เชื่อใจกัน การทำ Multisig ก็ได้ประโยชน์

แต่ถ้าเก็บเองคนเดียว ใช้เองแต่อยากเพิ่มความปลอดภัย ใช้ passphase กับ shamir ก็พอครับ

ขอบคุณครับ

จำนวนเท่าของ sig

สมมุติผมตั้ง 2/3 กับ 2/4 แบบนี้อิง 2 หรือ อิงจำนวนทั้งหมดครับ

ใช้ 2 sig ครับ

ไม่เท่ากันครับ ขึ้นจำนวน signature ที่ใช้ในการปลดล็อคธุรกรรม