joshua/dash-docs
1
0
Fork 0
mirror of https://github.com/seigler/dash-docs synced 2025-07-28 02:06:13 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Use Terms "Pubkey Script" And "Signature Script"

Browse source 
This modifies commits provided by @petertodd to use the terms "pubkey
script" and "signature script" instead of other terms.

* Rename "scriptPubKey" and "output script" to "pubkey script"
  (suggested by @luke-jr). We leave a token "scriptPubKey" at the point
  where we define pubkey script so that searchers can find it.

* Rename "scriptSig" to "signature script" (suggested by @luke-jr). We
  also leave a token "scriptSig" at this definition point.

* Rename "redeemScript" to "redeem script"

* Defined ECDSA on secp256k1 curve as the crypto used in the Transaction
  section and added references to secp256k1 private/public keys and
  signatures.

* Removed "The Parts Of A Transaction" illustration by commenting it out
  in the HTML. Shoehorning the pubkey/signature script terms into this
  image was becoming difficult, and I'm not very fond of that
  illustration anyway. I'll see if I can think of a nicer replacement
  illustration for some point in the future.

* Add a short paraphrased version @petertodd's description of scripts as
  generalized crypto.

* Updated all the illustrations which referred to either pubkey scripts
  or signature scripts to use these terms.
This commit is contained in:
David A. Harding 2014-09-20 15:07:42 -04:00
parent 89cb2fff08
commit 6afc6835bf
No known key found for this signature in database
GPG key ID: 4B29C30FF29EC4B7
29 changed files with 408 additions and 407 deletions
Download patch file Download diff file Expand all files Collapse all files

3
_includes/guide_operating_modes.md
View file

@ -68,7 +68,8 @@ Removal of elements can only be done by scrapping the bloom filter and re-creati
Rather than viewing the false positive rates as a liability, it is used to create a tunable parameter that represents the desired privacy level and bandwidth trade-off. A SPV client creates their Bloom filter and sends it to a full node using the message `filterload`, which sets the filter for which transactions are desired. The command `filteradd` allows addition of desired data to the filter without needing to send a totally new Bloom filter, and `filterclear` allows the connection to revert to standard block discovery mechanisms. If the filter has been loaded, then full nodes will send a modified form of blocks, called a merkleblock. The merkleblock is simply the block header with the merkle branch associated with the set Bloom filter.
An SPV client can not only add transactions as elements to the filter, but also public keys, data from scriptSig and scriptPubKeys, and more. This enables P2SH transaction finding.
An SPV client can not only add transactions as elements to the filter, but also public keys, data from signature
scripts and pubkey scripts, and more. This enables P2SH transaction finding.
If a user is more privacy-conscious, he can set the Bloom filter to include more false positives, at the expense of extra bandwidth used for transaction discovery. If a user is on a tight bandwidth budget, he can set the false-positive rate to low, knowing that this will allow full nodes a clear view of what transactions are associated with his client.