diff options
Diffstat (limited to 'bip-0116.mediawiki')
| -rw-r--r-- | bip-0116.mediawiki | 4 |
1 files changed, 2 insertions, 2 deletions
diff --git a/bip-0116.mediawiki b/bip-0116.mediawiki index 7f103ec..86b0f9a 100644 --- a/bip-0116.mediawiki +++ b/bip-0116.mediawiki @@ -69,7 +69,7 @@ A source of malleability in Merkle proofs could potentially lead to spend vulner For example, a compact 2-of-N policy could be written by using MERKLEBRANCHVERIFY to prove that two keys are extracted from the same tree, one at a time, then checking the proofs for bitwise equality to make sure the same entry wasn't used twice. With the vulnerable Merkle tree implementation there are privledged positions in unbalanced Merkle trees that allow multiple proofs to be constructed for the same, single entry. -BIP141 (Segregated Witness)[3] provides support for a powerful form of scirpt upgrades called script versioning, which is able to achieve the sort of upgrades which would previously have been hard-forks. +BIP141 (Segregated Witness)[3] provides support for a powerful form of script upgrades called script versioning, which is able to achieve the sort of upgrades which would previously have been hard-forks. If script versioning were used for deployment then MERKLEBRANCHVERIFY could be written to consume its inputs, which would provide a small 2-byte savings for many anticipated use cases. However the more familiar NOP-expansion soft-fork mechanism used by BIP65 (CHECKLOCKTIMEVERIFY)[5] and BIP112 (CHECKSEQUENCEVERIFY)[6] was chosen over script versioning for the following two reasons: @@ -99,7 +99,7 @@ The low-order bit of the first parameter, 2, is clear, meaning that there is one As described by Pieter Wuille[8] the 1-of-N scheme is particularly useful for constructing honeypots. The desire is to put a large bounty on a server, larger than the value of the server itself so that if the server is compromised it is highly likely that the hacker will claim the bitcoin, thereby revealing the intrusion. However if there are many servers, e.g. 1,000, it becomes excessively expensive to lock up separate bounties for each server. -It would be desireable if the same bounty was shared across multiple servers in such a way that the spend would reveal which server was compromised. +It would be desirable if the same bounty was shared across multiple servers in such a way that the spend would reveal which server was compromised. This is accomplished by generating 1,000 different keys, building a hash tree of these public keys, and placing each key and associated Merkle path on separate servers. When the honeypot is claimed, the (previous) owner of the coins can tell which server was compromised from the key and path used to claim the funds. |