[rpc] Allow fetching tx directly from specified block in getrawtransaction #10275

kallewoof · Apr 25, 2017

[Reviewer hint: use ?w=1 to avoid seeing a bunch of indentation changes.]

Presuming a user knows the block hash of the block containing a given transaction, this PR allows them to fetch the raw transaction, even without -txindex. It also enables support for getting transactions that are in orphaned blocks.

Note that supplying a block hash will override mempool and txindex support in GetTransaction. The rationale behind this is that a transaction may be in multiple places (orphaned blocks) and if the user supplies an explicit block hash it should be adhered to.

$ # a41.. is a tx inside an orphan block ..3c6f.. -- first try getting it normally
$ ./bitcoin-cli getrawtransaction a41e66ee1341aa9fb9475b98cfdc1fe1261faa56c0a49254f33065ec90f7cd79 1
error code: -5
error message:
No such mempool transaction. Use -txindex to enable blockchain transaction queries. Use gettransaction for wallet transactions.
$ # now try with block hash
$ ./bitcoin-cli getrawtransaction a41e66ee1341aa9fb9475b98cfdc1fe1261faa56c0a49254f33065ec90f7cd79 1 0000000000000000003c6fe479122bfa4a9187493937af1734e1e5cd9f198ec7
{
  "hex": "01000000014e7e81144e42f6d65550e59b715d470c9301fd7ac189[...]90488ac00000000",
  "inMainChain": false,
  "txid": "a41e66ee1341aa9fb9475b98cfdc1fe1261faa56c0a49254f33065ec90f7cd79",
  "hash": "a41e66ee1341aa9fb9475b98cfdc1fe1261faa56c0a49254f33065ec90f7cd79",
  "size": 225,
[...]
}
$ # another tx 6c66... in block 462000
$ ./bitcoin-cli getrawtransaction 6c66b98191e9d6cc671f6817142152ebf6c5cab2ef008397b5a71ac13255a735 1 00000000000000000217f2c12922e321f6d4aa933ce88005a9a493c503054a40
{
  "hex": "0200000004d157[...]88acaf0c0700",
  "inMainChain": true,
  "txid": "6c66b98191e9d6cc671f6817142152ebf6c5cab2ef008397b5a71ac13255a735",
  "hash": "6c66b98191e9d6cc671f6817142152ebf6c5cab2ef008397b5a71ac13255a735",
  "size": 666,
[...]
}
$

laanwj · Apr 25, 2017

laanwj reviewed Apr 25, 2017

View changes

This functionality could come in useful.

As for the API I prefer to not do any string combining/parsing here, this makes the API less clean to work with at least in my experience. I'd prefer to add an optional (can be null or missing) fromblock argument.

gmaxwell · Apr 25, 2017

gmaxwell reviewed Apr 25, 2017

View changes

Concept ACK. I've really wanted this before.

Allowing it work on orphan blocks is an interesting idea. I'm a little less sure about that-- I think it could allow it to return transactions that have never been validated, which would be somewhat surprising.

jonasschnelli · Apr 25, 2017

Nice feature!
I agree with @laanwj about the string parsing. The <block>:<txid> schematics looks good at first sight, but we are using JSON and should stay with JSON and don't add another form or key/value encoding.

kallewoof · Apr 26, 2017

Fair enough, I'll add a blockhash argument instead. I was kind of toying with the idea of a new standard for referencing transactions which included the block height (not hash) so everyone could always find a tx presuming they had the block in question, and that thought sort of seeped in here.

kallewoof · Apr 26, 2017

@gmaxwell

Allowing it work on orphan blocks is an interesting idea. I'm a little less sure about that-- I think it could allow it to return transactions that have never been validated, which would be somewhat surprising.

I just realized my logic was flawed on this. I am passing the block height only to the GetTransaction method, which means it will always pick the active chain at the given height. Either I throw when the block is not in the main chain (i.e. no support for orphaned blocks) or I move the height determine logic over to validation.cpp. I am leaning towards the latter, but feedback welcome.

Edit: passing CBlockIndex to GetTransaction seems like a great way to do this. Going with that.

kallewoof · Apr 26, 2017

The code now works as advertised (see updated OP).

History:

2017-04-25: 1 (block hash support in getrawtx)
2017-04-26: → 2⊱1 (bh:txid to 2 params) → 3 (fix fVerbose parsing) → 4⊱1 (switch to block index in GetTx)

jnewbery · May 2, 2017

jnewbery reviewed May 2, 2017

View changes

nit: You can replace this and the next three lines with:

} else {
    fVerbose = (request.params[1].get_bool());
}

since get_bool() does the type testing for you and throws the JSONRPCError if the type isn't a VBOOL.

Up to you whether you think that's clearer.

Ohh, good point! Thanks.
Edit: I don't want it to throw for null values though.

So I end up with

        if (request.params[1].isNum()) {
            fVerbose = (request.params[1].get_int() != 0);
        } else if (!request.params[1].isNull()) {
            fVerbose = (request.params[1].get_bool());
        }

jnewbery · May 2, 2017

utACK, but I think this deserves a new functional test case.

kallewoof · May 4, 2017

@jnewbery I agree. Will get to work on that.

[...]:

2017-05-04: 5⊱2 (improve fVerbose)

kallewoof · May 8, 2017

@jnewbery Added some tests to rawtransactions.py for the included blockhash variant (a6b8461).

[...]:

2017-05-08: 6 (tests)

jnewbery · May 15, 2017

jnewbery reviewed May 15, 2017

View changes

tested ACK the integration test in a6b8461 with a couple of nits.

nit: no need for brackets here. The following should do:

block1, block2 = self.nodes[2].generate(2)

nit: I think it's better to assert on the actual value here (ie verify that the getrawtransaction returned the correct transaction rather than returned anything). The following should do that:

assert_equal(self.nodes[0].getrawtransaction(tx, True, block1)['txid'], tx)

@jnewbery Good points, thanks. Addressed!

sipa · May 15, 2017

Is this still needed after #8704?

kallewoof · May 16, 2017

@sipa The use cases are quite different I think. #8704 lets you see all transactions in a given block. This lets you grab a transaction directly from a block without indexing.

sipa · May 16, 2017

@kallewoof #8704 does not require indexing either

kallewoof · May 16, 2017

Yeah, sorry, I meant that this is a way to get a specific transaction if you know the block hash, whereas #8704 shows you all transactions in the entire block. You get the info, but you have to wade through stuff to get it.

laanwj · May 16, 2017

In both cases the whole block has to be loaded from disk, and parsed, and searched linearly. The difference is whether the linear search step happens on the server or client.

I think both #8704 and this can be useful, but have to agree there's only superficial difference.

maaku · May 16, 2017

The difference between the two is the serialization and transmission and parsing of ~5MB of JSON data vs a few hundred bytes of hex encoded data. That's a 1,000x difference on the client side, and the same absolute improvement on the server -- although as a multiplier it'd be less since as you note the server still has to parse the block from disk. That's a nontrivial performance difference.

(Also, this would have greatly helped me in the past so another +1 from me.)

jnewbery · May 16, 2017

Agree with @maaku - simply encoding the data into 5MB of json could be time-consuming, during which time the cs_main lock is held. Having a command to return just a single transaction from a block seems very useful.

luke-jr · Jun 3, 2017

luke-jr suggested changes Jun 3, 2017

View changes

Should probably mention that it MUST be in that block in this case...

Whether the block specified is in the main chain or not... This could be false with the tx being still in the main chain!

Remove "in chain". Maybe "in database"?

luke-jr · Jun 3, 2017

Suggested message fix on my gettx-with-blockhash-0.14 branch (cherry-pick).

sipa · Jun 4, 2017

Needs rebase.

kallewoof · Jun 5, 2017

@luke-jr Thanks for the review! I cherry-picked your commit.

[...]:

2017-06-05: 7 (nits (luke-jr))

@sipa Rebased.

TheBlueMatt · Jun 7, 2017

TheBlueMatt reviewed Jun 7, 2017

View changes

You may wish to squash "[rpc] Fix fVerbose parsing (remove excess if cases and ensure null is…" and "[test] Updated rawtransactions.py to assert for adjusted exception.".
Generally we try to make sure that after each individual commit, at least it builds and all tests pass.

grammar nit: this reads funny to me, and could be a bit more explicit. Maybe:

"If the block which contains the transaction is known, its hash can be provided even for nodes without -txindex."
"Note that if a blockhash is provided, only it will be searched and if the transaction is in mempool, other blocks, or if this node does not have the given block available, the transaction will not be found."

Thanks, that looks better yeah. Adding with minor tweaks.

            "\nNOTE: By default this function only works for mempool transactions. If the -txindex option is\n"
            "enabled, it also works for blockchain transactions. If the block which contains the transaction\n"
            "is known, its hash can be provided even for nodes without -txindex. Note that if a blockhash is\n"
            "provided, only that block will be searched and if the transaction is in the mempool or other\n"
            "blocks, or if this node does not have the given block available, the transaction will not be found.\n"

Hmm, maybe say "if blockhash is specified" or otherwise mention this wont appear unless a blockhash is provided. Even better, fill it out if GetTransaction returns the blockhash cause it found it via UTXO/txindex.

I was sure I did, but guess not:

            "  \"inMainChain\": b,     (bool) Whether specified block is in the main chain or not (only present with explicit \"blockhash\" argument)\n"

I like the idea of including when able but will keep it out of this PR for now.

Hmm? Shouldn't we use the parameter's name here instead of "parameter 3"?

The general tendency seems to be to identify the parameter index so I stuck with that. I agree it may be better to be more descriptive though...

Maybe further update this error message, eg if (blockIndex) "No such transaction found in the provided block".

Yeah, I wanted to avoid ?:?:. Rewritten as:

    if (!GetTransaction(hash, tx, Params().GetConsensus(), hashBlock, true, blockIndex)) {
        std::string errmsg;
        if (blockIndex) {
            errmsg = "No such transaction found in the provided block";
        } else {
            errmsg = fTxIndex
              ? "No such mempool or blockchain transaction"
              : "No such mempool transaction. Use -txindex to enable blockchain transaction queries";
        }
        throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, errmsg + ". Use gettransaction for wallet transactions.");
    }

kallewoof · Jun 8, 2017

@TheBlueMatt Thanks for the review!

Generally we try to make sure that after each individual commit, at least it builds and all tests pass.

We try to keep tests as separate commits though, so that would assume tests and code changes come in pairs (tests will fail before test commit or after test commit and before change commit, obv). That was my intention with the split here. I may have screwed up. I'll double check and/or squash as appropriate.

Edit: I noticed the order was off (two fixes then two tests). Rearranged them. The commit/test pairs now pass make check individually (i.e. a43ec61 and 8f2ce52).

Edit 2: [...]:

2017-06-08: 8 (nits)

TheBlueMatt · Jun 22, 2017

utACK 8f2ce52

jonasschnelli · Jul 14, 2017

Needs rebase.

kallewoof · Jul 14, 2017

Rebased.

jonasschnelli · Jul 14, 2017

a) Is there a reason why mainchain height is not supported as alternative for the blockhash? Eventually with a security of only accepting heights of a hundred blocks below the tip as a reorganisation protection (but I'd prefer to not add this protection).

b) @kallewoof the idea about the standard for a transaction reference has already been worked into a BIP: bitcoin/bips#555 (maybe we can support this – if we agree on that BIP to be worth implementing – also via getrawtransaction).

kallewoof · Jul 14, 2017

@jonasschnelli Regarding height, I chose not to include it as it could potentially cause unexpected results when a reorg happens, but if people don't think that's an issue it should be fairly straightforward to allow for both.

Edit: as for the standard, that looks exciting for sure. If it matures enough and this PR isn't merged already I may take a stab at it.

jtimon · Jul 17, 2017

jtimon reviewed Jul 17, 2017

View changes

This may be confused with Params().NetworkIDString() == "main" (kind of like we do with "testnet" in getinfo).
Can we rename to "inActiveChain" or something of the sort?

jtimon · Jul 17, 2017

jtimon reviewed Jul 17, 2017

View changes

Perhaps the diff can be less disruptive by moving everything inside if (!blockIndex) {...} to a new static function defined right above instead of indenting all of it?

I'm not a huge fan of changing code just to make diffs smaller, and as I mention above, you can put ?w=1 to get diff without indentation changes.

jtimon · Jul 17, 2017

utACK 3ec2d28 besides small nits.

kallewoof · Jul 18, 2017

Addressed @jtimon nits.
@jonasschnelli I added support for supplying block height instead of block hash.

jtimon · Jul 18, 2017

I'm not sure about allowing the height.
One can always call getblockhash if he knows the txid and block height without knowing the block hash somehow.
That's not the case for the BIP proposal @jonasschnelli refers to, since they don't know the txid anyway (only block height and tx position). I suggest we leave the BIP discussion out of this PR, which in my opinion makes sense on its own. And also leave the height option for later (or never).

kallewoof · Jul 19, 2017

@jtimon It feels like a convenience thing that, IMO, getblock should have as well (i.e. allow both height number and block hash). I don't have a strong opinion on the subject though, and will drop the last 2 commits (height support) whenever this is ready for merging unless someone argues for block height support.

jtimon · Jul 20, 2017

Well, don't have a strong opinion on adding the block height either, if more people like it, let's keep it.
Or perhaps it can be proposed after this for both getrawtransaction and getblock at the same time?

instagibbs · Aug 23, 2017

concept ACK, needs rebase/squash, would review

kallewoof · Aug 24, 2017

@instagibbs Rebased & squashed; also removed block height option for now. Will push as separate PR if desirable.

instagibbs · Aug 24, 2017

instagibbs suggested changes Aug 24, 2017

View changes

Current behavior of GetTransaction means that even if you specify a block index, it still does all the other searches. This means that a user could specify an incorrect blockhash, and still return a valid result, with "inActive" == False(though it may actually be in the valid chain!).

As a user I would expect any call to fail if I simply gave the wrong blockhash, but that's simply my opinion.

maybe in_active_chain? I'm parsing this as "inactive chain"

in_active_chain to conform to new style guide and make easier to read.

should skip this logic if user has provided the blockhash?

This is inside the if (!blockIndex) block so it should never execute if a block hash was provided, no?

Oops! Not good at counting brackets.

instagibbs · Aug 25, 2017

I fail at counting brackets.

utACK 440123f

jnewbery · Sep 1, 2017

jnewbery reviewed Sep 1, 2017

View changes

A few nits inline.

I think you need to squash the first two commits to make the code and test changes atomic (otherwise the test fails on the intermediate 90e1408 commit)

nit: alignment

            "  \"in_active_chain\": b, (bool) Whether specified block is in the active chain or not (only present with explicit \"blockhash\" argument)\n"
            "  \"hex\" : \"data\",       (string) The serialized, hex-encoded data for 'txid'\n"

becomes

  "in_active_chain": b, (bool) Whether specified block is in the active chain or not (only present with explicit "blockhash" argument)
  "hex" : "data",       (string) The serialized, hex-encoded data for 'txid'

(two \ vs four \ means indentation diff in code)

Yes, of course you're correct. The size, vsize, version, ... fields below aren't aligned by the same logic, but that's beyond the scope of this PR. Please disregard my previous comment.

I think we would also hit this error if the block had been pruned. In that case, this error is misleading.

Is there any way to test above for whether the block has been pruned and error out before doing the transaction lookup?

Good point!

I added code (3c0cb43) that checks if pruning is enabled, and if it is, checks if the block is actually available by reading it from disk and setting the error message based on the results of that.

Lose the presumably :)

You need to make the matching error text longer to be non-ambiguous. This test will still pass if the node returns the error No such mempool or blockchain transaction (which would be incorrect behaviour)

Oops. Fixed, thanks.

kallewoof · Sep 4, 2017

@jnewbery Thanks for the review! I think I've addressed all your comments.

Edit: Actually I forgot about the commit merge. I try to keep tests and code changes as separate commits. Why would you want it to succeed between the test update? (Or am I confused about what you're asking?)

jnewbery · Sep 4, 2017

I try to keep tests and code changes as separate commits. Why would you want it to succeed between the test update? (Or am I confused about what you're asking?)

I think the principal is that each individual commit should be at least internally consistent (should build and pass its own tests). Your first commit updates the product code so the returned error changes, and your second commit updates the test code to pass with the new error string. That means that if I run the tests after the first commit they'll fail.

I understand the desire to structure the commits in a way that tells a story, but this breaks tools like git bisect that rely on commits to be internally consistent.

kallewoof · Sep 5, 2017

@jnewbery You can git bisect skip if you land on a commit squeezed in between tests. I don't really agree with squashing test updates and code changes together, personally. That's how I've always done it, anyway.

promag · Sep 5, 2017

I agree with @jnewbery, one commit should not break the code, tests including. If you revert that commit, codes stays green. IMO makes reviewing easier.

luke-jr · Sep 5, 2017

luke-jr suggested changes Sep 5, 2017

View changes

Use fHavePruned

Use !(pblockindex->nStatus & BLOCK_HAVE_DATA) && pblockindex->nTx > 0 (see getblock)

jtimon · Sep 5, 2017

I agree individual commits should never break the tests ideally. That doesn't mean that you can't introduce new functionality and its new tests in separated commits when that's not the case.
Needs rebase again.

jnewbery · Sep 5, 2017

Last two commits look good. For the pruning error, I think you can error out earlier by re-using the pruned test from getblock:

     if (fHavePruned && !(pblockindex->nStatus & BLOCK_HAVE_DATA) && pblockindex->nTx > 0)
        throw JSONRPCError(RPC_MISC_ERROR, "Block not available (pruned data)");

I don't really agree with squashing test updates and code changes together, personally.

ok. I think both ways are valid, and I've come across both before. I'm not sure if this project has a preferred style.

kallewoof · Sep 6, 2017

I'm merging those commits as it's not new functionality but just a fix that changes an error message.

kallewoof · Sep 6, 2017

@luke-jr Nice!

jnewbery · Sep 6, 2017

jnewbery reviewed Sep 6, 2017

View changes

supernit: Not finding a block because it's been pruned is not a RPC_INVALID_ADDRESS_OR_KEY error. It would more accurately be a RPC_MISC_ERROR.

My suggestion would be to do the pruned check above, immediately after the throw JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY, "Block hash not found"); line

Yeah, I was thinking about that too. Fixing.

jtimon · Sep 23, 2017

re-utACK 300a5f1

fanquake added the RPC/REST/ZMQ label Apr 25, 2017

jnewbery referenced this pull request May 23, 2017
Closed
RPC: getblock returns coinbase scriptsig #10385

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

[rpc] Allow getrawtransaction to take optional blockhash to fetch tra…
…nsaction from a block directly. Github-Pull: #10275 Rebased-From: 4d006e7

e096099

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

[rpc] Fix fVerbose parsing (remove excess if cases and ensure null is…
… accepted). Github-Pull: #10275 Rebased-From: 5b389a8

99dd1fc

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

[test] Updated rawtransactions.py to assert for adjusted exception.
Github-Pull: #10275 Rebased-From: 9f980f6

57cb225

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

[test] Add tests for getrawtransaction with block hash.
Github-Pull: #10275 Rebased-From: a6b8461

c188d00

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

f'test nits
Github-Pull: #10275 Rebased-From: 8f84e8c

675c1fe

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

[rpc] Fix fVerbose parsing (remove excess if cases and ensure null is…
… accepted). Github-Pull: #10275 Rebased-From: 4c41073

5dfa87a

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

[test] Updated rawtransactions.py to assert for adjusted exception.
Github-Pull: #10275 Rebased-From: a43ec61

f080d5f

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

[rpc] Allow getrawtransaction to take optional blockhash to fetch tra…
…nsaction from a block directly. Github-Pull: #10275 Rebased-From: 8485239

633d334

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

[test] Add tests for getrawtransaction with block hash.
Github-Pull: #10275 Rebased-From: 8f2ce52

c35815a

jtimon referenced this pull request Jul 18, 2017
Closed
[pull request idea] addressindex, spentindex, timestampindex (Bitcore patches) #10370

jnewbery referenced this pull request Sep 1, 2017
Closed
[trivial] [rpc] Fix getrawtransaction help for per-txout chainstate db #11213

+        +    uint256 hash;
+        +    int64_t blockHeight = -1;
+        +    bool inMainChain = true;
+        +    auto p = request.params[0].get_str().find(':');

-        -                fVerbose = true;
-        -            }
+        +            fVerbose = (request.params[1].get_int() != 0);
+        +        } else if (request.params[1].isBool()) {

+        +        # make a tx by sending then generate 2 blocks; block1 has the tx in it,
+        +        # presumably
+        +        tx = self.nodes[2].sendtoaddress(self.nodes[1].getnewaddress(), 1)
+        +        [ block1, block2 ] = self.nodes[2].generate(2)

+        +        [ block1, block2 ] = self.nodes[2].generate(2)
+        +        self.sync_all()
+        +        # We should be able to get the raw transaction by providing the correct block
+        +        assert self.nodes[0].getrawtransaction(tx, True, block1)

                      "\nNOTE: By default this function only works for mempool transactions. If the -txindex option is\n"
-        -            "enabled, it also works for blockchain transactions.\n"
+        +            "enabled, it also works for blockchain transactions. If the block hash is known, it can be provided\n"
+        +            "for nodes without -txindex.\n"

bitcoin/bitcoin

Join GitHub today

[rpc] Allow fetching tx directly from specified block in getrawtransaction #10275

Conversation

kallewoof commented Apr 25, 2017 • edited Edited 1 time kallewoof Apr 26, 2017

fanquake added the RPC/REST/ZMQ label Apr 25, 2017

laanwj reviewed Apr 25, 2017 View changes

laanwj Apr 25, 2017 • edited Edited 1 time laanwj Apr 25, 2017

gmaxwell reviewed Apr 25, 2017 View changes

jonasschnelli commented Apr 25, 2017

kallewoof commented Apr 26, 2017

kallewoof commented Apr 26, 2017 • edited Edited 1 time kallewoof Apr 26, 2017

kallewoof commented Apr 26, 2017 • edited Edited 1 time kallewoof Apr 26, 2017

jnewbery reviewed May 2, 2017 View changes

kallewoof May 4, 2017 • edited Edited 1 time kallewoof May 4, 2017

jnewbery commented May 2, 2017

kallewoof commented May 4, 2017

kallewoof commented May 8, 2017 • edited Edited 1 time kallewoof May 8, 2017

jnewbery reviewed May 15, 2017 View changes

sipa commented May 15, 2017

kallewoof commented May 16, 2017

sipa commented May 16, 2017

kallewoof commented May 16, 2017

laanwj commented May 16, 2017

maaku commented May 16, 2017

jnewbery commented May 16, 2017

jnewbery referenced this pull request May 23, 2017

luke-jr suggested changes Jun 3, 2017 View changes

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 3, 2017

luke-jr commented Jun 3, 2017

sipa commented Jun 4, 2017

kallewoof commented Jun 5, 2017

TheBlueMatt reviewed Jun 7, 2017 View changes

kallewoof Jun 8, 2017 • edited Edited 1 time kallewoof Jun 8, 2017

kallewoof commented Jun 8, 2017 • edited Edited 1 time kallewoof Jun 8, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Jun 15, 2017

TheBlueMatt commented Jun 22, 2017

jonasschnelli commented Jul 14, 2017

kallewoof commented Jul 14, 2017

jonasschnelli commented Jul 14, 2017

kallewoof commented Jul 14, 2017 • edited Edited 1 time kallewoof Jul 14, 2017

jtimon reviewed Jul 17, 2017 View changes

jtimon Jul 17, 2017 • edited Edited 1 time jtimon Jul 17, 2017

jtimon reviewed Jul 17, 2017 View changes

jtimon commented Jul 17, 2017

kallewoof commented Jul 18, 2017

jtimon commented Jul 18, 2017

jtimon referenced this pull request Jul 18, 2017

kallewoof commented Jul 19, 2017

jtimon commented Jul 20, 2017

instagibbs commented Aug 23, 2017

kallewoof commented Aug 24, 2017

instagibbs suggested changes Aug 24, 2017 View changes

instagibbs commented Aug 25, 2017

jnewbery referenced this pull request Sep 1, 2017

jnewbery reviewed Sep 1, 2017 View changes

kallewoof commented Sep 4, 2017 • edited Edited 1 time kallewoof Sep 4, 2017

jnewbery commented Sep 4, 2017

kallewoof commented Sep 5, 2017

promag commented Sep 5, 2017

luke-jr suggested changes Sep 5, 2017 View changes

jtimon commented Sep 5, 2017

jnewbery commented Sep 5, 2017

kallewoof commented Sep 6, 2017

kallewoof commented Sep 6, 2017

jnewbery reviewed Sep 6, 2017 View changes

jtimon commented Sep 23, 2017

kallewoof added some commits Apr 25, 2017

kallewoof commented Apr 25, 2017 •

Edited 1 time

kallewoof
Apr 26, 2017

laanwj reviewed Apr 25, 2017

View changes

laanwj Apr 25, 2017 •

Edited 1 time

laanwj
Apr 25, 2017

gmaxwell reviewed Apr 25, 2017

View changes

kallewoof commented Apr 26, 2017 •

Edited 1 time

kallewoof
Apr 26, 2017

kallewoof commented Apr 26, 2017 •

Edited 1 time

kallewoof
Apr 26, 2017

jnewbery reviewed May 2, 2017

View changes

kallewoof May 4, 2017 •

Edited 1 time

kallewoof
May 4, 2017

kallewoof commented May 8, 2017 •

Edited 1 time

kallewoof
May 8, 2017

jnewbery reviewed May 15, 2017

View changes

luke-jr suggested changes Jun 3, 2017

View changes

TheBlueMatt reviewed Jun 7, 2017

View changes

kallewoof Jun 8, 2017 •

Edited 1 time

kallewoof
Jun 8, 2017

kallewoof commented Jun 8, 2017 •

Edited 1 time

kallewoof
Jun 8, 2017

kallewoof commented Jul 14, 2017 •

Edited 1 time

kallewoof
Jul 14, 2017

jtimon reviewed Jul 17, 2017

View changes

jtimon Jul 17, 2017 •

Edited 1 time

jtimon
Jul 17, 2017

jtimon reviewed Jul 17, 2017

View changes

instagibbs suggested changes Aug 24, 2017

View changes

jnewbery reviewed Sep 1, 2017

View changes

kallewoof commented Sep 4, 2017 •

Edited 1 time

kallewoof
Sep 4, 2017

luke-jr suggested changes Sep 5, 2017

View changes

jnewbery reviewed Sep 6, 2017

View changes