bitcoin/bips
1
0
Fork 0
mirror of https://github.com/bitcoin/bips.git synced 2026-07-06 17:46:00 +00:00
Code Issues Releases Wiki Activity

[trivial] Correct typos across bips

Browse Source 
BIPs 11, 16, 61, 98, 116, 117, 143, 157
This commit is contained in:
Varunram
2018-04-14 11:16:32 +05:30
committed by Luke Dashjr
parent 5415dd806e
commit c3e8379b61
8 changed files with 12 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
bip-0116.mediawiki
View File

@@ -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.