Revisions to BIP 174 #694

achow101 · 2018-06-28T02:55:04Z

Describes the changes to BIP 174 as discussed on the bitcoin-dev mailing list. There are new tests, updated formatting, and clarifications.

sipa · 2018-06-28T04:39:22Z

bip-0174.mediawiki


 The Combiner can accept 1 or many PSBTs.
 The Combiner must merge them into one PSBT (if possible), or fail.
 The resulting PSBT must contains all of the key-value pairs from each of the PSBTs.


Typo: contains

sipa · 2018-06-28T04:39:56Z

bip-0174.mediawiki

 The Combiner must merge them into one PSBT (if possible), or fail.
 The resulting PSBT must contains all of the key-value pairs from each of the PSBTs.
-The Combined must remove any duplicate key-value pairs, in accordance with the specification.
+The Combiner must remove any duplicate key-value pairs, in accordance with the specification.


Specify that it can pick arbitrarily in case of conflicts.

sipa · 2018-06-28T04:40:55Z

bip-0174.mediawiki

-For any input which has a complete set of signatures, the Finalizer must attempt to build the complete scriptSig and encode it into the network serialized transaction.
+The Input Finalizer must only accept a PSBT.
+For each input, the Input Finalizer determines if the input has enough data to pass validation. If it does, it must construct the scriptSig and scriptWitness and place them into the input key-value map.
+All other data except the UTXO in the input key-value map should be cleared from the PSBT. The UTXO should be kept to allow Transaction Extractors to verify the final network serialized transaction.


Specify that it should leave unknown fields untouched (these may serve a similar purpose to UTXOs in extensions).

sipa · 2018-06-28T04:42:48Z

bip-0174.mediawiki


 The Partially Signed Transaction format can be extended in the future by adding
 new types for key-value pairs. Backwards compatibilty will still be maintained as those new
 types will be ignored and passed-through by signers which do not know about them.


Perhaps mention that if ever the number of field types may run out, new extensions could start defining multi-byte type identifiers.

sipa · 2018-06-28T04:48:44Z

bip-0174.mediawiki

+A PSBT can be represented in two ways: in binary (as a file) or as a Base64 string using the encoding described in [https://tools.ietf.org/html/rfc4648#section-4 RFC4648].
+
+Binary PSBT files should use the <tt>.psbt</tt> file extension.
+The MIME type <tt>application/psbt</tt> can be used.


I don't think you can just start using a mime type without registration.

Practices around mime types are defined in https://tools.ietf.org/html/rfc6838, but I think it may be too early to go through the registration processes. I'm not sure what to do here, but perhaps just write "A mime type name will be added to this document after blabla"?

sipa · 2018-06-28T04:50:30Z

bip-0174.mediawiki

+* Type: Unsigned Transaction <tt>PSBT_GLOBAL_UNSIGNED_TX = 0x00</tt>
+** Key: None. The key must only contain the 1 byte type.
+*** <tt>{0x00}</tt>
+** Value: The transaction in network serialization. The scriptSigs and witnesses for each input must be empty. The transaction must be in the witness serialization format as defined in BIP 144. A PSBT must have a transaction, otherwise it is invalid.


If all witnesses are empty, BIP144 does not permit using extended serialization.

sipa · 2018-06-28T04:51:56Z

bip-0174.mediawiki

+* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
+** Key: None. The key must only contain the 1 byte type.
+***<tt>{0x00}</tt>
+** Value: The transaction in network serialization format the current input spends from.


Add a note that it may only be present for inputs which spend non-segwit outputs.

sipa · 2018-06-28T04:52:48Z

bip-0174.mediawiki

+* Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
+** Key: None. The key must only contain the 1 byte type.
+*** <tt>{0x01}</tt>
+** Value: The entire transaction output in network serialization which the current input spends from.


Add a note that it may only be present for inputs which spend segwit outputs (including P2SH embedded ones).

sipa · 2018-06-28T04:54:01Z

bip-0174.mediawiki

+* Type: Sighash Type <tt>PSBT_IN_SIGHASH_TYPE = 0x03</tt>
+** Key: None. The key must only contain the 1 byte type.
+*** <tt>{0x03}</tt>
+** Value: The 32-bit unsigned integer specifying the sighash type to be used for this input. Signatures for this input must use the sighash type, finalizers must fail to finalize inputs which have signatures that do not use the sighash type. Signers who cannot produce signatures with the sighash type must not provide a signature.


"that do not use" is confusing here. Perhaps "If present, finalizers must fail to finalize inputs which have signatures that don't match the specified sighash type" ?

sipa · 2018-06-28T04:55:02Z

bip-0174.mediawiki

+* Type:  BIP 32 Derivation Path <tt>PSBT_IN_BIP32_DERIVATION = 0x06</tt>
+** Key: The public key
+*** <tt>{0x06}|{public key}</tt>
+** Value: The master key fingerprint concatenated with the derivation path of the public key. The derivation path is represented as 32 bit unsigned integer indexes concatenated with each other. This must omit the index of the master key. Public keys are those that will be needed to sign this input.


Maybe explain that the term 'fingerprint' is used here as defined by BIP32.

I don't understand "This must omit the index of the master key".

sipa · 2018-06-29T01:41:16Z

bip-0174.mediawiki

+* Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
+** Key: None. The key must only contain the 1 byte type.
+***<tt>{0x00}</tt>
+** Value: The transaction in network serialization format the current input spends from. This should only be present for inputs which spend non-segwit outputs.


After discussing this more, perhaps it should be legal to include a non-witness UTXO even for witness inputs. The entity that adds the UTXO may not know it's a witness one (especially when it's P2SH embedded). But the entity that does know can always convert a PSBT_IN_NON_WITNESS_UTXO into a PSBT_IN_WITNESS_UTXO by extracting the right output.

sipa · 2018-06-29T17:41:59Z

bip-0174.mediawiki

-The Combined must remove any duplicate key-value pairs, in accordance with the specification.
+The resulting PSBT must contain all of the key-value pairs from each of the PSBTs.
+The Combiner must remove any duplicate key-value pairs, in accordance with the specification. It can pick arbitrarily when conflicts occur.
+A Combiner must not combine two different PSBTs. PSBTs can be uniquely identified by <tt>0x00</tt> global transaction typed key-value pair.


Perhaps add that a Combiner is allowed to detect inconsistencies in known fields when combining, but cannot do this for unknown fields.

sipa · 2018-06-29T17:46:04Z

bip-0174.mediawiki

+A PSBT can be represented in two ways: in binary (as a file) or as a Base64 string using the encoding described in [https://tools.ietf.org/html/rfc4648#section-4 RFC4648].
+
+Binary PSBT files should use the <tt>.psbt</tt> file extension.
+A MIME type name will be added to this document once one hs been registered.


sipa · 2018-06-29T17:55:48Z

bip-0174.mediawiki

 |-
 | Global
-| 0,1,2,3,4
+| 0


Could this be written as a table that includes the name or one-line description of the field? I expect that needing looking things up across BIPs may end up being a pain.

nvk · 2018-06-29T18:08:22Z

We will start implementing as soon as this gets merged.
Thanks for sorting it out so fast 👍

sipa · 2018-06-30T00:20:51Z

bip-0174.mediawiki

+* Bytes in Hex: <pre>70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f000000800000008001000080010304010000000001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88701042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f0000008000000080020000800103040100000000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000</pre>
+* Base64 String: <pre>cHNidP8BAJoCAAAAAljoeiG1ba8MI76OcHBFbDNvfLqlyHV5JPVFiHuyq911AAAAAAD/////g40EJ9DsZQpoqka7CwmK6kQiwHGyyng1Kgd5WdB86h0BAAAAAP////8CcKrwCAAAAAAWABTYXCtx0AYLCcmIauuBXlCZHdoSTQDh9QUAAAAAFgAUAK6pouXw+HaliN9VRuh0LR2HAI8AAAAAAAEAuwIAAAABqtc5MQGL0l+ErkALaISL4J23BurCrBgpi6vucatlb4sAAAAASEcwRAIgWPb8fGoz4bMVSNSByCbAFb0wE1qtQs1neQ2rZtKtJDsCIEoc7SYExnNbY5PltBaR3XiwDwxZQvufdRhW+qk4FX26Af7///8CgPD6AgAAAAAXqRQPuUY0IWlrgsgzryQceMF9295JNIfQ8gonAQAAABepFCnKdPigj4GZlCgYXJe12FLkBj9hh2UAAAABBEdSIQKVg785rgpgl0etGZrd1jT6YQhVnWxc05tMIYPxq5bgfyEC2rYf9JoU22p9ArDNH7t4/EsYMStbTlTa5Nui+/71NtdSriIGApWDvzmuCmCXR60Zmt3WNPphCFWdbFzTm0whg/GrluB/ENkMak8AAACAAAAAgAAAAIAiBgLath/0mhTban0CsM0fu3j8SxgxK1tOVNrk26L7/vU21xDZDGpPAAAAgAAAAIABAACAAQMEAQAAAAABASAAwusLAAAAABepFLf1+vQOPUClpFmx2zU18rcvqSHohwEEIgAgjCNTFzdDtZXftKB7crqOQuN5fadOh/59nXSX47ICiQMBBUdSIQMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3CECOt2QTz1tz1nduQaw3uI1Kbf/ue1Q5ehhUZJoYCIfDnNSriIGAjrdkE89bc9Z3bkGsN7iNSm3/7ntUOXoYVGSaGAiHw5zENkMak8AAACAAAAAgAMAAIAiBgMIncEMesbbVPkTKa9hczPbOIzq0MIx9yM3nRuZAwsC3BDZDGpPAAAAgAAAAIACAACAAQMEAQAAAAAiAgOppMN/WZbTqiXbrGtXCvBlA5RJKUJGCzVHU+2e7KWHcRDZDGpPAAAAgAAAAIAEAACAACICAn9jmXV9Lv9VoTatAsaEsYOLZVbl8bazQoKpS2tQBRCWENkMak8AAACAAAAAgAUAAIAA</pre>
+
+Given the above updated PSBT, a signer with the following keys:


Specify that this is only the case for signers which support SIGHASH_ALL signing for both P2PKH and P2WPKH spends, and use RFC6979 nonce generation.

achow101 · 2018-07-04T20:24:44Z

Clarified that keys must match the format. Clarified that combiners may check for inconsistencies in known types.

luke-jr · 2018-07-05T05:01:30Z

@achow101 Ready to merge then?

jb55 · 2018-07-05T18:26:12Z

@achow101 I'm having trouble with my deserializer, as far as I can tell, there is no way to tell when the array of input kv maps stops and the array of kv output maps starts?

with this psbt I got from the revised bip:

70736274ff01009a020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000000100bb0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f6187650000000104475221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae2206029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f10d90c6a4f000000800000008000000080220602dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d710d90c6a4f0000008000000080010000800001012000c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e88701042200208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903010547522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae2206023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7310d90c6a4f000000800000008003000080220603089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc10d90c6a4f00000080000000800200008000220203a9a4c37f5996d3aa25dbac6b570af0650394492942460b354753ed9eeca5877110d90c6a4f000000800000008004000080002202027f6399757d2eff55a136ad02c684b1838b6556e5f1b6b34282a94b6b5005109610d90c6a4f00000080000000800500008000

my parser spits out:

GLOBAL_UNSIGNED_TX (0)                                                                                 
	020000000258e87a21b56daf0c23be8e7070456c336f7cbaa5c8757924f545887bb2abdd750000000000ffffffff838d0427d0ec650a68aa46bb0b098aea4422c071b2ca78352a077959d07cea1d0100000000ffffffff0270aaf00800000000160014d85c2b71d0060b09c9886aeb815e50991dda124d00e1f5050000000016001400aea9a2e5f0f876a588df5546e8742d1d87008f00000000
IN_NON_WITNESS_UTXO (0)
	0200000001aad73931018bd25f84ae400b68848be09db706eac2ac18298babee71ab656f8b0000000048473044022058f6fc7c6a33e1b31548d481c826c015bd30135aad42cd67790dab66d2ad243b02204a1ced2604c6735b6393e5b41691dd78b00f0c5942fb9f751856faa938157dba01feffffff0280f0fa020000000017a9140fb9463421696b82c833af241c78c17ddbde493487d0f20a270100000017a91429ca74f8a08f81999428185c97b5d852e4063f618765000000
IN_REDEEM_SCRIPT (4)
	5221029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f2102dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d752ae
IN_BIP32_DERIVATION (6)
	029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f: d90c6a4f000000800000008000000080
IN_BIP32_DERIVATION (6)
	02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7: d90c6a4f000000800000008001000080
OUT_WITNESS_SCRIPT (1)
	00c2eb0b0000000017a914b7f5faf40e3d40a5a459b1db3535f2b72fa921e887
UNKNOWN_OUTPUT_TYPE (4)
	00208c2353173743b595dfb4a07b72ba8e42e3797da74e87fe7d9d7497e3b2028903
UNKNOWN_OUTPUT_TYPE (5)
	522103089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc21023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e7352ae
UNKNOWN_OUTPUT_TYPE (6)
	023add904f3d6dcf59ddb906b0dee23529b7ffb9ed50e5e86151926860221f0e73: d90c6a4f000000800000008003000080
UNKNOWN_OUTPUT_TYPE (6)
	03089dc10c7ac6db54f91329af617333db388cead0c231f723379d1b99030b02dc: d90c6a4f000000800000008002000080

it looks like it see's a zero byte after

IN_BIP32_DERIVATION (6)
	02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7: d90c6a4f000000800000008001000080

at this point my parser assumes the input kv-map has ended, and starts interpreting the new kv-map as the output map. but perhaps this is wrong, since we could be in the second input kv-map in the input kv-map array. given this, as far as I can tell, there's no way to tell when we have switched to the output key value map array? am I missing something?

achow101 · 2018-07-05T18:40:39Z

@jb55 The number of inputs and outputs are specified by the unsigned tx itself. You will need to partially deserialize it to know how many inputs and outputs.

@luke-jr I'm not sure. There's still discussion on the mailing list about this.

jb55 · 2018-07-05T18:41:11Z

@achow101 ah right. that makes sense, that was next on my todo. thanks!

Change from a global map with input data to a global k/v pair with input and output data. Add new types for finalized scriptSigs and scriptWitnesses. Redefined types to support new model Updated the formatting of the listing

… descriptions Add updater, transaction finalizer, and transaction extractor roles. Update the description of other roles to clarify Update extensibility section

achow101 · 2018-07-05T22:32:38Z

I have added a few changes that clarify that signers must check input txids for non-witness utxos and that a map must be provided for every input and output.

@luke-jr I think this is ready to be merged.

020628e Tests for PSBT (Andrew Chow) a4b06fb Create wallet RPCs for PSBT (Andrew Chow) c27fe41 Create utility RPCs for PSBT (Andrew Chow) 8b5ef27 SignPSBTInput wrapper function (Andrew Chow) 58a8e28 Refactor transaction creation and transaction funding logic (Andrew Chow) e9d86a4 Methods for interacting with PSBT structs (Andrew Chow) 12bcc64 Add pubkeys and whether input was witness to SignatureData (Andrew Chow) 41c607f Implement PSBT Structures and un/serialization methods per BIP 174 (Andrew Chow) Pull request description: This Pull Request fully implements the [updated](bitcoin/bips#694) BIP 174 specification. It is based upon #13425 which implements the majority of the signing logic. BIP 174 specifies a binary transaction format which contains the information necessary for a signer to produce signatures for the transaction and holds the signatures for an input while the input does not have a complete set of signatures. This PR contains structs for PSBT, serialization, and deserialzation code. Some changes to `SignatureData` have been made to support detection of UTXO type and storing public keys. *** Many RPCs have been added to handle PSBTs. `walletprocesspsbt` takes a PSBT format transaction, updates the PSBT with any inputs related to this wallet, signs, and finalizes the transaction. There is also an option to not sign and just update. `walletcreatefundedpsbt` creates a PSBT from user provided data in the same form as createrawtransaction. It also funds the transaction and takes an options argument in the same form as `fundrawtransaction`. The resulting PSBT is blank with no input or output data filled in. It is analogous to a combination of `createrawtransaction` and `fundrawtransaction` `decodepsbt` takes a PSBT and decodes it to JSON. It is analogous to `decoderawtransaction` `combinepsbt` takes multiple PSBTs for the same tx and combines them. It is analogous to `combinerawtransaction` `finalizepsbt` takes a PSBT and finalizes the inputs. If all inputs are final, it extracts the network serialized transaction and returns that instead of a PSBT unless instructed otherwise. `createpsbt` is like `createrawtransaction` but for PSBTs instead of raw transactions. `convertpsbt` takes a network serialized transaction and converts it into a psbt. The resulting psbt will lose all signature data and an explicit flag must be set to allow transactions with signature data to be converted. *** This supersedes #12136 Tree-SHA512: 1ac7a79e5bc669933f0a6fcc93ded55263fdde9e8c144a30266b13ef9f62aacf43edd4cbca1ffbe003090b067e9643c9298c79be69d7c1b10231b32acafb6338

achow101 mentioned this pull request Jun 28, 2018

BIP 174 PSBT Serializations and RPCs bitcoin/bitcoin#13557

Merged

sipa reviewed Jun 28, 2018

View reviewed changes

achow101 force-pushed the bip174-rev branch 2 times, most recently from 9721cb7 to 1874991 Compare June 28, 2018 18:34

sipa reviewed Jun 29, 2018

View reviewed changes

achow101 force-pushed the bip174-rev branch 2 times, most recently from 0c53930 to 414193c Compare June 29, 2018 01:50

sipa reviewed Jun 29, 2018

View reviewed changes

achow101 force-pushed the bip174-rev branch from 414193c to 63da954 Compare June 29, 2018 18:11

sipa reviewed Jun 30, 2018

View reviewed changes

achow101 force-pushed the bip174-rev branch 2 times, most recently from a63052a to 38f923d Compare July 4, 2018 20:23

achow101 added 5 commits July 5, 2018 15:27

Move global data to per-input and per-output data

bfae179

Change from a global map with input data to a global k/v pair with input and output data. Add new types for finalized scriptSigs and scriptWitnesses. Redefined types to support new model Updated the formatting of the listing

Clarify handling of duplicated keys

45df424

Add new responsibilities, update responsibility, update extensibility…

f515da0

… descriptions Add updater, transaction finalizer, and transaction extractor roles. Update the description of other roles to clarify Update extensibility section

Add sections for encoding, file extension, and mime-type

81c20a6

Update tests for new serialization

4fcd8bf

achow101 force-pushed the bip174-rev branch from 38f923d to 4fcd8bf Compare July 5, 2018 22:27

luke-jr merged commit 507383c into bitcoin:master Jul 6, 2018

HashUnlimited mentioned this pull request Sep 11, 2018

BIP 174 PSCT Serializations and RPCs chaincoin/chaincoin#543

Merged

Revisions to BIP 174 #694

Revisions to BIP 174 #694

Uh oh!

Conversation

achow101 commented Jun 28, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sipa Jun 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nvk commented Jun 29, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

achow101 commented Jul 4, 2018

Uh oh!

luke-jr commented Jul 5, 2018

Uh oh!

jb55 commented Jul 5, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

achow101 commented Jul 5, 2018

Uh oh!

jb55 commented Jul 5, 2018

sipa Jun 28, 2018 •

edited

Loading

jb55 commented Jul 5, 2018 •

edited

Loading