diff options
| -rw-r--r-- | bip-0079.mediawiki | 16 | ||||
| -rw-r--r-- | bip-0084.mediawiki | 8 | ||||
| -rw-r--r-- | bip-0322.mediawiki | 63 |
3 files changed, 48 insertions, 39 deletions
diff --git a/bip-0079.mediawiki b/bip-0079.mediawiki index 7d0cc57..15948ad 100644 --- a/bip-0079.mediawiki +++ b/bip-0079.mediawiki @@ -14,9 +14,9 @@ ==Abstract== -The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardizes important properties that is expected of a useful currency. +The way bitcoin transactions are normally created leaks more information than desirable, and as a result has been exploited by unreasonably effective blockchain analysis techniques to jeopardize important properties that are expected of a useful currency. -Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants. +Bustapay is a simple and practical protocol for the sender and receiver of a payment to collaboratively sign a bitcoin transaction in such a way that busts some analysis assumptions to the immediate benefit of the sender and receiver. Furthermore it does so in such a way that gives a significant amount of control to the receiver to help manage their utxo set size, a constant problem for bitcoin merchants. ==Copyright== @@ -47,15 +47,15 @@ This is done via an HTTP POST request, sent to a "bustapay url" ====Step 3. Receiver processes the transaction and returns a partially signed coinjoin==== -The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to resign his own inputs. +The receiver validates the transaction, and pays himself. The receiver then adds one or more of his own inputs (known as the ''contributed inputs'') and (optionally) increases the output that pays himself (generally by the sum of the ''contributed inputs''). Doing so creates a ''partial transaction'', which the receiver returns to the sender. It is called such as it requires the sender to re-sign his own inputs. -====Step 4. Receiver validates, re-signs, and propagates on the bitcoin network==== +====Step 4. Sender validates, re-signs, and propagates on the bitcoin network==== -The receiver MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), resign its original inputs and propagates the final transaction over the bitcoin network. +The sender MUST validate the ''partial transaction'' was changed correctly and non-maliciously (to allow using potentially untrusted communication channels), re-sign its original inputs and propagate the final transaction over the bitcoin network. ====Step 5. Receiver observes the finalized transaction on the bitcoin network==== -Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout will propagate the original "template transaction" to ensure the payment happens and function a strong anti-DoS mechanism. +Once the receiver has seen the finalized transactions on the network (and has enough confirmations) it can process it like a normal payment for the sent amount (as opposed to the amount that it looks like on the network). If the receiver does not see the finalized transaction after a timeout, they will propagate the original "template transaction", which ensures the payment happens and functions a strong anti-DoS mechanism. == Specification == @@ -75,11 +75,11 @@ The receiver must add at least one input to the transaction (the "contributed in To prevent an attack where a receiver is continually sent variations of the same transaction to enumerate the receivers utxo set, it is essential that the receiver always returns the same contributed inputs when it's seen the same inputs. -It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as much the other transaction inputs if possible. +It is strongly preferable that the receiver makes an effort to pick a contributed input of the same type as the other transaction inputs if possible. === Output Adjustment === -After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* add or remove inputs, and *must not* ever decrease any output amount. +After adding inputs to the transaction, the receiver generally will want to adjust the output that pays himself by increasing it by the sum of the contributed input amounts (minus any fees he wants to contribute). However the only strict requirement is that the receiver *must never* remove inputs, and *must not* ever decrease any output amount. === Returning the partial transaction === diff --git a/bip-0084.mediawiki b/bip-0084.mediawiki index 340dff2..dc5a05d 100644 --- a/bip-0084.mediawiki +++ b/bip-0084.mediawiki @@ -51,6 +51,14 @@ To derive the P2WPKH address from the above calculated public key, we use the en scriptPubKey: 0 <20-byte-key-hash> (0x0014{20-byte-key-hash}) + +===Extended Key Version=== + +When serializing extended keys, this scheme uses alternate version bytes. Extended public keys use <code>0x04b24746</code> to produce a "zpub" prefix, and private keys use <code>0x04b2430c</code> to produce a "zprv" prefix. Testnet uses <code>0x045f1cf6</code> "vpub" and <code>0x045f18bc</code> "vprv." + +Additional registered version bytes are listed in [[https://github.com/satoshilabs/slips/blob/master/slip-0132.md|SLIP-0132]]. + + ==Backwards Compatibility== This BIP is not backwards compatible by design as described under [#considerations]. An incompatible wallet will not discover accounts at all and the user will notice that something is wrong. diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki index 5191143..606e2f7 100644 --- a/bip-0322.mediawiki +++ b/bip-0322.mediawiki @@ -23,9 +23,9 @@ The current message signing standard only works for P2PKH (1...) addresses. By e A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container. -Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds". +=== Common Header === -=== SignatureProof container === +A common header used for signature proofs and challenges is defined as follows: {|class="wikitable" style="text-align: center;" |- @@ -43,7 +43,9 @@ Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessa |Uint8||1||entries||Number of proof entries<ref><strong>Why support multiple proofs?</strong> In particular with proof of funds, it is non-trivial to check a large number of individual proofs (one per UTXO) for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref> |} -The above is followed by [entries] number of signature entries: +=== SignatureProof container === + +The signature proof begins with a common header, and is followed by [entries] number of signature entries: {|class="wikitable" style="text-align: center;" |- @@ -80,54 +82,53 @@ A verification call will return a result code according to the table below. |- |INVALID||One or more of the given proofs were invalid |- -|SPENT||One or more of the claimed UTXO:s has been spent -|- |ERROR||An error was encountered |} -== Signing and Verifying == +=== SignMessage serialization === -Let there be an empty set `inputs` which is populated and tested at each call to one of the actions below. +The SignMessage challenge begins with the common header, and is followed by [entries] entries: -=== Purpose: SignMessage === +{|class="wikitable" style="text-align: center;" +|- +!Type +!Length +!Name +!Comment +|- +|VarInt||1-8||spklen||ScriptPubKey length +|- +|Uint8*||[spklen]||spk||ScriptPubKey +|} -The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated. +=== Proving and Verifying === -# Return INVALID if scriptPubKey already exists in `inputs` set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 inputs unless they are all distinct</ref> -# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) -# Let sighash = sha256(sha256(scriptPubKey || pre-image)) +Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below. -=== Purpose: ProveFunds === +=== Common steps === -The "ProveFunds" purpose generates a sighash and a scriptPubKey from a transaction, an output index, and a message. For multiple simultaneous proofs, it also requires access to the ordered list of proofs. It emits a VALID verification result code unless otherwise stated. +A sighash is generated based on a scriptPubKey and a message. A VALID verification result code is emitted unless otherwise stated. -# Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent -# Return INVALID if the txid:vout pair already exists in `inputs` set, otherwise insert it -# Return SPENT if the txid/vout is not a valid UTXO according to a Bitcoin node<ref><strong>Synced up or not?</strong> A normal verifier would use a synced up node. An auditor checking records from a client that were submitted in the past want to use a node that is synced up to the block corresponding to the proof, or the proof will fail, even if it may have been valid at the time of creation.</ref> -# Extract scriptPubKey from transaction output -# Define the message pre-image as the concatenation of the following components:<ref><strong>Why not just the UTXO data?</strong> We want the verifier to be able to challenge the prover with a custom message to sign, or anyone can reuse the POF proof for a set of UTXO:s once they have seen it, and the funds have not yet been spent</ref> -#* the string "POF:" -#* the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD), including the null terminating character (i.e. write strlen(message) + 1 bytes, for a C string) -#* all transactions being proven for, as binary txid (little endian uint256) followed by index (little endian uint32), each separated by a single `0x00` byte +# Emits INVALID if scriptPubKey already exists in <code>inputs</code>set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 inputs unless they are all distinct</ref> +# Emits INVALID if the message is not a UTF-8 string encoded using Normalization Form Compatibility Decomposition (NFKD); note specifically that binary messages are not supported +# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, ''excluding'' the null terminating character (if any) # Let sighash = sha256(sha256(scriptPubKey || pre-image)) -=== Action: Sign === +=== Proving === -The "Sign" action takes as input a purpose. It returns a signature or fails. +Returns a signature or fails (emits INVALID). -# Obtain the sighash and scriptPubKey from the purpose; FAIL if not VALID # Derive the private key privkey for the scriptPubKey; FAIL if not VALID -# Generate and return a signature sig with privkey=privkey, sighash=sighash +# Generate a signature sig with privkey=privkey, sighash=sighash +# Return a SignatureProof container with the given signature -=== Action: Verify === +=== Verifying === -The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose. -It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR. +Emits one of INCONCLUSIVE, VALID, or INVALID. -# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID # If one or more of the standard flags are unknown, return INCONCLUSIVE # Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash -# Return VALID if verify succeeds, otherwise return INVALID +# Emit VALID if verify succeeds, otherwise emit INVALID === Multiple Proofs === |