highperfocused/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2025-03-17 21:32:50 +01:00
Code Issues Packages Projects Releases Wiki Activity

MULICHECKSIG -> CHECKMULTISIG

Browse Source 
n-of-m -> m-of-n

LN motivation

smaller SPV proof motivation
This commit is contained in:
Eric Lombrozo 2015-12-22 06:15:05 -05:00
parent 1cdf145b9b
commit f026c28da5
1 changed files with 4 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
bip-codeshark-jl2012-segwit.mediawiki
View File

@ -20,11 +20,11 @@ The entirety of the transaction's effects are determined by output consumption (
By removing this data from the transaction structure committed to the transaction merkle tree, several problems are fixed:
# '''Nonintentional malleability becomes impossible'''. Since signature data is no longer part of the transaction hash, changes to how the transaction was authorized is no longer relevant to transaction identification. As a solution of transaction malleability, this is superior to the canonical signature approach (BIP62):
#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or MULTICHECKSIG operation)
#* In the case of a n-of-m MULTICHECKSIG script, a transaction is malleable only with agreement of n private key holders (as opposed to only 1 private key holder with BIP62)
#* It prevents involuntary transaction malleability for any type of scripts, as long as all inputs are signed (with at least one CHECKSIG or CHECKMULTISIG operation)
#* In the case of an m-of-n CHECKMULTISIG script, a transaction is malleable only with agreement of m private key holders (as opposed to only 1 private key holder with BIP62)
#* It prevents involuntary transaction malleability due to unknown ECDSA signature malleability
#* It allows creation of unconfirmed transaction dependency chains without counterparty risk
# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction, instead of just to prove its existence. This also improves prviacy of SPV clients as using the same bandwidth they could request for more transactions for obscuration.
#* It allows creation of unconfirmed transaction dependency chains without counterparty risk, an important feature for offchain protocols such as the Lightning Network
# '''Transmission of signature data becomes optional'''. It is needed only if a peer is trying to validate a transaction instead of just checking its existence. This reduces the size of SPV proofs and potentially improves the privacy of SPV clients as they can download more transactions using the same bandwidth.
# '''Some constriants could be bypassed with a soft fork''' by moving part of the transaction data to a structure unknown to current protocol, for example:
#* Size of witness could be ignored / discounted when calculating the block size, effectively increasing the block size to some extent
#* Hard coded constants, such as maximum data push size (520 bytes) or sigops limit could be reevaluated or removed