[rpc] listsinceblock should include lost transactions when parameter is a reorg'd block

[kallewoof]

The following scenario will not notify the caller of the fact tx0 has been dropped:

1. User 1 receives BTC in tx0 from utxo1 in block aa1.
2. User 2 receives BTC in tx1 from utxo1 (same) in block bb1
3. User 1 sees 2 confirmations at block aa3.
4. Reorg into bb chain.
5. User 1 asks listsinceblock aa3 and does not see that tx0 is now invalidated.

See listsinceblock.py commit for related test.

The proposed fix is to iterate from the given block down to the fork point, and to check each transaction in the blocks against the wallet, in addition to including all transactions from the fork point to the active chain tip (the current behavior). Any transactions that were present will now also be listed in the listsinceblock output in a new replaced array. This operation may be a bit heavy but the circumstances (and perceived frequency of occurrence) warrant it, I believe.

Example output:

{
  'transactions': [],
  'replaced': [
    {
      'walletconflicts': [],
      'vout': 1,
      'account': '',
      'timereceived': 1485234857,
      'time': 1485234857,
      'amount': '1.00000000',
      'bip125-replaceable': 'unknown',
      'trusted': False,
      'category': 'receive',
      'txid': 'ce673859a30dee1d2ebdb3c05f2eea7b1da54baf68f93bb8bfe37c5f09ed22ff',
      'address': 'miqEt4kWp9zSizwGGuUWLAmxEcTW9bFUnQ',
      'label': '',
      'confirmations': -7
    }
  ],
  'lastblock': '7a388f27d09e3699102a4ebf81597d974fc4c72093eeaa02adffbbf7527f6715'
}

I believe this addresses the comment by @luke-jr in #9516 (comment) but I could be wrong..

[jonasschnelli]

I'm not 100% sure if we want this. If we, we would need at least to updated the listsinceblock's RPC help message to mention that if one requests tx's from a block outside the main-chain, that the result will also contain transactions not in the main chain.

[kallewoof]

@jonasschnelli Updated the help output. I am not sure what the reasons for not wanting this are, unless you're referring to resource consumption. I think it's a rare (but important) enough case to warrant it.

It would definitely make it easier for RPC applications checking the validity of existing transactions to explicitly provide these when a reorg affects them. The only other alternative right now is to keep a list of transactions with confirmations less than some arbitrary number (100) and to loop through these every time a reorg is encountered to ensure they're actually still present.

Edit: one concern of my own is whether a naive implementation would ignore the confirmations value and simply think the transaction existed in the chain, even though the opposite is the case. I wondered if maybe a different key for the returned results should be used, e.g. "reorged" or something. I.e. you would get {"transactions": [list of txs that changed], "reorged": [list of txs that disappeared], "lastblock": <hash>}...

[jonasschnelli]

@kallewoof: I missed the point that if you pass in an orphan block to list since, you also get the transactions upwards the chain-fork on the main chain. At first sight, I though you get only tx from the re-orged-off chain in that case.

Concept ACK (and I think it would be clever to list them in an extra array element reorged:[].

[kallewoof]

@jonasschnelli Gotcha. I updated the OP to clarify that it's also including transactions from the fork point to the active chain tip. I also moved the off chain transactions into a new 'reorged' array. (f501acc & 461d5a3)

[ryanofsky]

utACK 461d5a3 with minor suggestions

[ryanofsky]

Really sending from node 1 here (even if key originally comes from node 2)

[ryanofsky]

unused variable

[ryanofsky]

Maybe condense this block to a single line, and add a check for txid2 (untested)

assert_equal(any(tx['txid'] == txid1 for tx in lsbres['reorged']), True)
assert_equal(any(tx['txid'] == txid2 for tx in lsbres['transactions']), True)

[kallewoof]

@ryanofsky Ahh, nice! I didn't know about any().

Since txid2 is not related to nodes[0], it will not list it anywhere so that second assert_equal will not be true.

Thanks for all the feedback! I believe everything you suggested is in 9caa0ec & 131df5a.

[ryanofsky]

Would s/back to the fork point/from blockhash back to the fork point/ to clarify, because it sounds to me like this is referring to transactions between the active tip and the fork point (making the rest of the sentence confusing).

[ryanofsky]

Need documentation update to accompany this.

[ryanofsky]

I think it would be helpful to add a comment about -depth here. I was staring at this a long time to figure out how it worked. Comment could say: "Pass -depth as minDepth to prevent any filtering in ListTransactions. (Works because tx can only conflict with transactions after pindex, so GetDepthInMainChain will always return at least (1-depth))."

[ryanofsky]

Maybe change tx0 and tx1 to tx1 and tx2 to match code. Also code is generating 6 and 7 blocks instead of 3 and 4, so maybe that could be changed to match the example.

[ryanofsky]

Would remove parentheses since (at minimum -depth) is the important part. Also, technically I believe the minimum is 1-depth. Maybe:

// Use -depth as minDepth parameter to ListTransactions to prevent incoming
// transactions from being filtered. These transactions have negative
// confirmations, but always greater than -depth.

[kallewoof]

@ryanofsky Thanks for all the feedback! Updated.

[gmaxwell]

Concept ACK.

[TheBlueMatt]

I'm not sure I'd call this a bugfix - we already correctly print transactions which were included in blocks from the common fork point from the blockhash provided to listsinceblock.

[TheBlueMatt]

I dont believe this prevents listing transactions which were on both sides of the fork? I'm pretty sure we dont want to list such transactions in a "reorged" list.

[kallewoof]

@TheBlueMatt I guess it comes down to what the user expects. I personally expected listsinceblock to show me anything I needed to keep an updated score of what's going on since the given block. In that sense, not showing a transaction vanishing would probably be considered a bug.

Regarding showing an existing transaction in both reorged and transactions, I patched this by ensuring that any tx shown from the main chain is skipped over in the reorged list. See the new test_double_send test.

[JeremyRubin]

I agree with Matt, this isn't a bugfix, it's feature :)

I think I'm in favor of adding this. I would be more supportive of naming them replaced rather than reorged if I understand the semantics properly. Strictly speaking, I'd say a reorged txn is any transaction that was between the old tip and the fork point?

I would also think maybe making this information available with a default false parameter may be a good idea to introduce less changes for current users/legacy code.

[kallewoof]

@JeremyRubin Changed as you said, except setting default of include_replaced to true as I think that will be the most useful case.

[laanwj]

Moving milestone to 0.15 as this was re-classified as a feature and the feature freeze is long past.

[luke-jr]

utACK as-is, with a few nits. (IMO this is a bug fix.)

[luke-jr]

IMO this PR doesn't need to modify ListTransactions, and this ought to be move to a separate PR.

[kallewoof]

For the case where tx0 is in reorged and main chain both (see test_double_send), both versions of the transaction will appear in the results (once in 'transactions' and once in 'replaced'). To prevent that, I check if ListTransactions appended to the transactions array -- if it did, I need to not include in replaced.

[luke-jr]

Not sure this needs to be optional...?

[kallewoof]

Me neither. It was mostly suggested as a way for legacy code to cope better, but only really crappy legacy code (that would break when a new key was added to an existing dictionary) would be affected I guess.

[luke-jr]

Why do we need ListTransactions's return value? If it doesn't get inserted here, it won't later-on either, right?

[kallewoof]

See above case with a tx being sent on both chains.

[luke-jr]

It occurs to me that the key "replaced" may not be ideal, since there is no guarantee these transactions are now conflicted and won't get re-mined. Perhaps "removed"?

[kallewoof]

I tried to find actual cases where this happened, but had a hard time finding a case that wasn't the cause of a double spend. It would require that the transaction is NOT in the mempool of the node, or it would appear as normal in transactions. There may be a case I haven't thought of though, so you may be right, removed is a safer bet for sure.

[luke-jr]

Two more "replaced" instances. Also need to update the named param list at the bottom of the file, and in rpc/client.cpp

[luke-jr]

"replaced"

[kallewoof]

Done

[luke-jr]

"replaced"

[kallewoof]

Done

[kallewoof]

@luke-jr Sorry about sloppiness, I thought I got all of them in the initial two squashme's.

[ryanofsky]

utACK ad57cef.

Comparing against previously ACKed 461d5a3, the both-sides dedup code and the new API tweaks and comments looked good.

[TheBlueMatt]

utACK ad57cef +/- some slight API nitpicks.

[TheBlueMatt]

Maybe instead of this and the next line,
"If "blockhash" is no longer a part of the main chain, transactions from the fork point onward are included.\n"
"Additionally, if include_removed is set, transactions affecting the wallet which were removed are returned in the "removed" array.\n"

[kallewoof]

Makes sense. Changed.

[TheBlueMatt]

Hmm, not sure how I feel about this. For pruning nodes, it may be more useful to return a partial list and a message indicating the results are incomplete rather than throw wholesale.

[kallewoof]

Isn't that slightly dangerous? I mean, if people don't realize the node only has a subset of all blocks in some cases, they might miss the "partial" flag and never realize they potentially missed something. Even if it's their own node. Someone could even time an attack based on that.

To take a step back, the situation here is that some software which uses listsinceblock believes the chain is on one chain when it is on another one. Presuming this fork is long, the node ends up pruning beyond the fork point. And/or, the node ends up pruning out the alt chain that was deactivated. It feels like the caller (requester) should blow up at this point and either require manual assistance, or fall back to scanning over all unsafe tx's, effectively "resetting" to the current chain tip.

[TheBlueMatt]

True. I'm not sure what the right answer here is...clearly we dont want it to be so easy to miss transactions, but on the other hand, it sucks to not have the option here. A different approach might be to iterate over mapWallet and find all transactions which have a hash of a disconnected block, which I believe is correct as long as the block was, at some point, on the active chain, though might not be if the user is calling listsinceblock on a block that was never the active chain.

[kallewoof]

Hm.. It almost feels like I can just get the block headers by iterating altchainindex up to the fork point and put those in a set and find the removed transactions in the initial mapWallet iteration. That way there's no need to read in the blocks at all and can get rid of listed as well. Will try that, thanks for the nudge!

[TheBlueMatt]

Yea, I was heasitant to recommend doing it alone because I'm not confident about how safe it is to make sure the wallet's data is always right, will have to think more and review once you have it coded :).

[TheBlueMatt]

There is a second con to ② - it cannot list transactions which went from confirmed to 0-conf, as they now have a hashBlock of null, which I think is somewhat of a blocker to using that approach. Another option is to have an optional parameter (default to off) which allows you to get partial-removed-data.

[kallewoof]

A 0-conf tx will be in the mempool right? Presuming it is, it will in fact be in the transactions array (I think).

The allow partial parameter makes sense to me. I think I'll do that for starters until we make a decision (which may be another PR).

[TheBlueMatt]

That isnt a guarantee, because mempool may be limited.

[kallewoof]

@TheBlueMatt I took the liberty to remove he allow_partial flag as I've seen more support for always throwing than for having the flag and only throwing sometimes. The unsquashed tree has everything in it still so it'd be no effort to resurrect this, if you or someone felt strongly enough about it.

[sipa]

I agree with (1), and not having allow_partial. We may want to document that this feature stops working with pruning.

[kallewoof]

@TheBlueMatt I didn't think about that.

But would the wallet actually do that to its own transaction? Throw out of mempool I mean.

[kallewoof]

s/wallet/node/

[sipa]

The wallet doesn't control the mempool, and the mempool behaves independently. Anything else would be a privacy leak, as the mempool is observable through the P2P network.

[luke-jr]

IMO if the stale block is pruned, throwing an exception is the right thing to do. The caller should be able to figure out its own rewinding back to the last common block.

(P.S. Perhaps the tests here should cover the case where there are three potential-chains involved?)

[luke-jr]

No else for please.

} else {
    for (const CTransactionRef& tx : block.vtx) {

[kallewoof]

Good point about testing 3 chains. Will add a test like that.

[kallewoof]

I just realized the split network feature in the QA framework only supports one split (2 chains) right now. I think I'll make a separate PR to extend that functionality and add more tests for 3+ chains after this is merged.

[kallewoof]

Squashed commits. Unsquashed branch preserved at https://github.com/kallewoof/bitcoin/tree/listsinceblock-include-lost-txs-unsquashed for comparison.

[MarcoFalke]

I just realized the split network feature in the QA framework only

supports one split (2 chains) right now. I think I'll make a separate PR to extend that functionality and add more tests for 3+ chains after this is merged. Yes, please. Also make sure the extended functionality does not depend on the number of nodes in regtest being exactly 4.

…

On Sun, Feb 26, 2017 at 2:10 AM, kallewoof ***@***.***> wrote: Squashed commits. Unsquashed branch preserved at https://github.com/kallewoof/bitcoin/tree/listsinceblock- include-lost-txs-unsquashed for comparison. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#9622 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGmv98uWx_PRJaQ16WpuPIQGTvhEo8Wks5rgNEBgaJpZM4Lr4lC> .

[kallewoof]

@MarcoFalke See #9872.

[jtimon]

Concept ACK. Agree with @luke-jr in throwing the exception.

[kallewoof]

Rebased.

[jnewbery]

👍 comments!

[jnewbery]

nit: it'd be nice to test this branch in the functional test, both with and without the partial flag.

[jnewbery]

Is it possible to use the sendtoaddress RPC here instead of {create,sign,send}rawtransaction? The rawtransaction RPCs force you to explicitly do things like set change addresses and make assumptions about fee rates, that could break this test in future.

[kallewoof]

Unfortunately sendtoaddress doesn't let me choose the UTXO so I don't think I can use it here.

[jnewbery]

Please don't use print() calls in test cases. Either remove the line entirely, or add a self.log.debug() call if you think this information will be useful for debugging in future.

There are several other instances of this below. I won't add additional review comments.

[kallewoof]

Removed all print()s. They seemed vaguely useful but not enough to warrant keeping them around long term.

[jnewbery]

If you're expecting this to work, can you assert on the returned value?

[kallewoof]

If the transaction cannot be gotten, an exception is raised (I swapped the txid out for a random hex below):

2017-04-13 02:22:05.191000 TestFramework (ERROR): JSONRPC error
Traceback (most recent call last):
  File "/Users/karljohan-alm/workspace/bitcoin-kw/test/functional/test_framework/test_framework.py", line 148, in main
    self.run_test()
  File "./listsinceblock.py", line 250, in run_test
    self.test_double_spend()
  File "./listsinceblock.py", line 155, in test_double_spend
    self.nodes[0].gettransaction("000000000009f75870f0ebe6f317af6928e3a74c676a60a0f11d3eab51c88ff3")
  File "/Users/karljohan-alm/workspace/bitcoin-kw/test/functional/test_framework/coverage.py", line 46, in __call__
    return_val = self.auth_service_proxy_instance.__call__(*args, **kwargs)
  File "/Users/karljohan-alm/workspace/bitcoin-kw/test/functional/test_framework/authproxy.py", line 153, in __call__
    raise JSONRPCException(response['error'])
test_framework.authproxy.JSONRPCException: Invalid or non-wallet transaction id (-5)
2017-04-13 02:22:05.193000 TestFramework (INFO): Stopping nodes
2017-04-13 02:22:14.337000 TestFramework (WARNING): Not cleaning up dir /var/folders/b8/znqr8hj918772gfmd875gzgdd3ypz1/T/test5fli8q5i/13217
2017-04-13 02:22:14.337000 TestFramework (ERROR): Test failed. Test logging available at /var/folders/b8/znqr8hj918772gfmd875gzgdd3ypz1/T/test5fli8q5i/13217/test_framework.log

Asserting on the returned value is thus not necessary but I'm adding a comment indicating this.

[jnewbery]

This comment is fine. Alternatively you could assert something like:

assert self.nodes[0].gettransaction(txid1)['txid'] == txid1, "gettransaction failed to find txid1 not found"

[kallewoof]

Ohh, I didn't realize assert also captured exceptions. Thanks, changed.

[jnewbery]

nit: no need for an assert_equal(True, True) here. Instead:

assert any(tx['txid'] == txid1 for tx in lsbres['removed']), "txid1 not found in listsinceblock removed list"

[jnewbery]

again, no need to assert_equal(False, False). Instead:

assert 'removed' not in lsbres2

In general, we use assert_equal when comparing two variables because it prints the values of those variables, ie assert_equal(x, y) will print the values of x and y if they're not equal, but assert x == y will not print the values of x and y. If you're asserting the truthiness of one variable, you can just assert on that explicitly.

[kallewoof]

I somehow skipped over this one. Fixed in squashed, unsquashed commit is kallewoof/bitcoin@72ec1ea

[jnewbery]

Great docstrings 👍

[jnewbery]

as above for assert_equal(False, False). There are more instances of this below. I won't add additional comments.

[jnewbery]

nit: I'd prefer run_test() to appear at the top of the test case, with the sub-tests below. When I come to read a test-case, it flows better for me if run test (which is called first) appears at the top.

[kallewoof]

Good idea. Changing.

[jnewbery]

I've only reviewed the test code. It's a shame that this makes the listsinceblock test runtime increase (from 32s to 72s on recent travis runs), although #10198 and #10082 will help with that.

One design comment: I'm not convinced it's a good idea to not including duplicate transactions in the removed array. I think that could be a trap for users. My expectation would be that I could periodically run this RPC to get the list of transactions since last time I ran the command (by passing in the lastblock value from the previous call). I'd expect to be able to keep a set of transactions, adding the transactions array to my set and subtracting the removed array. If you don't include the duplicate transactions in the removed array, then the user might end up with more than one instance of a transaction in their set.

Obviously the user should look out for duplicates and not add them to their set, but if they're doing something daft like keying off the blockhash and txid, then they'll get into this inconsistent state.

I don't think that's enough to block this PR, but I think it's considering.

[kallewoof]

@jnewbery Thanks a lot for the review! I've addressed most of your concerns, except for the nit about testing allow_partial flag.

Regarding duplicates in removed, I'm neutral personally. Allowing duplicates decreases the code size, so I'm all for the switch personally. (Clarification: I changed the code to allow duplicates.)

Unsquashed (kallewoof/bitcoin@8871340 is previous head): https://github.com/kallewoof/bitcoin/tree/listsinceblock-include-lost-txs-unsquashed

• kallewoof/bitcoin@c7adf4a addresses nits
• kallewoof/bitcoin@1283110 and kallewoof/bitcoin@2475789 (test tweak) fixes duplicates; if people oppose this change I can drop these commits easily enough

[luke-jr]

Do you plan to remove the allow_partial so it always throws an exception?

[kallewoof]

@luke-jr I would love to, personally. I wasn't sure if it was the agreed approach, in the end, but more people have agreed about throwing than not, so I'm going to remove it for now.

Edit: I removed the allow_partial functionality. (The unsquashed results are in the same spot (https://github.com/kallewoof/bitcoin/tree/listsinceblock-include-lost-txs-unsquashed) but since the end result was dropping of commits with some conflict fixes the unsquashed tree still has the allow_partial related commits.)

[jnewbery]

Thanks @kallewoof - I don't really mind too much either way. If I were coding this from scratch, I would prefer to show duplicates in removed, but I'm happy to go along with the consensus and since you've already put in the code to hide duplicates, that's also fine.

[kallewoof]

@jnewbery Duplicates are shown in removed now. What I removed was a different feature, where a user could pass in an 'allow partial' flag which would prevent the node from throwing an exception if a block couldn't be read (useful for pruned nodes), but several people preferred always throwing.

[kallewoof]

Realized I had missed one assert_equal(x, false) -> assert not x.

Unsquashed history:

• Mar 23: 1 → 2 → 3⊱1 → 4⊱1 → 5⊱1 → 6⊱1 → 7⊱1
• Apr 13: → 8⊱2 → 9⊱1 → 10⊱2 → 11⊱1
• Apr 17: → 12⊱2
• Apr 20: → 13⊱2

[jnewbery]

Looks good. A few nits but otherwise ACK a8c56bf

[jnewbery]

These variables might warrant their own comments now, since it's not immediately obvious what they're doing:

pindex - transactions from this block onwards should be included in the result. If the specified block was not in the main chain, pindex is the block where the chain forked
paltindex - used to count back from the specified block to the fork point to collect transactions for the removed array.

You can probably come up with better wording.

[jnewbery]

When adding RPCs or arguments, good advice is to treat null arguments the same as missing arguments: #10143 (comment)

I think that means this line would become:

bool include_removed = (request.params.size() < 4 || request.params[3].isNull() || request.params[3].get_bool());

[jnewbery]

Now that you've split this into sub-tests, can you move the lines:

self.nodes[2].generate(101)
self.sync_all()

into the run_test() function before calling test_reorg(). It's best if sub-tests have no shared state between them. You should be able to re-order or skip tests without breaking them, and generating the chain in test_reorg() breaks that assumption.

We want sub-tests to be as independent as possible so if they break it's easier to debug where the problem is.

[kallewoof]

Done - but some tweaking is necessary to make them truly independent of order (e.g. instead of asserting on getbalance()s, should just grab balance and compare). Will not do that work in this PR, but will try to address it asap unless someone else gets to it before me.

[jnewbery]

This comment is fine. Alternatively you could assert something like:

assert self.nodes[0].gettransaction(txid1)['txid'] == txid1, "gettransaction failed to find txid1 not found"

[jnewbery]

txid2 is unused so you don't need to assign it here.

[jnewbery]

consider using named arguments here so it's clear to the reader what the arguments are for (you can also omit the optional target_confirmations and include_watchonly arguments)

[kallewoof]

@jnewbery Thanks for feedback! I think I addressed all of the stuff you mentioned. Compare 14⊱1 & 15⊱2.

[...]:

• Apr 20: → 13⊱2
• Apr 21: → 14⊱1 → 15⊱2

[jnewbery]

Looks good. ReACK 4578a21

[kallewoof]

Rebased due to conflicts.

Edit: removed some irrelevant asserts that started causing errors in tests. (Not sure why a clean chain with generate(101) would yield 5100 BTC instead of 50, but no matter.)

[jnewbery]

Edit: removed some irrelevant asserts that started causing errors in tests. (Not sure why a clean chain with generate(101) would yield 5100 BTC instead of 50, but no matter.)

Looks like you've reintroduced the lines:

        self.nodes[2].generate(101)
        self.sync_all()

into the test_reorg() function, which means you're now generating 202 blocks (so node 2 now has 102 spendable coinbases = 5100 BTC).

I think this is just a bad rebase.

[kallewoof]

@jnewbery Ahh, thanks. Yeah, that is obviously it. I am just going to remove the double generate in test_reorg.

[...]:

• May 16: → 16⊱2

[sipa]

utACK 5d35204 with a few nits. I did not review the tests.

[sipa]

Nit: the request.params.size() > 0 check is superfluous with this, as the operator[] will always return a null UniValue if out of range. (and several other places)

[kallewoof]

Oh, I didn't know that. That makes things cleaner, thanks.

[sipa]

Nit: braces on the same line (and many other places).

[sipa]

I agree with (1), and not having allow_partial. We may want to document that this feature stops working with pruning.

[kallewoof]

@sipa Thanks for the review. I've addressed your nits in kallewoof/bitcoin@3a10e7c

[TheBlueMatt]

Can we add something to note that transactions which were re-added are included here anyway, and may have, at that point, positive confirmations value in this array?

[TheBlueMatt]

Hmm, technically -depth isnt sufficient here. In the rare case of a reorg-to-lower-block-height this would be insufficient. You already got the block from the chain, just call it - 1000000000 or so.

[TheBlueMatt]

This is wrong (and the check and later comment contradict this).

[TheBlueMatt]

Can you duplicate this loop for "removed", noting that the tx listed in "removed" should also have a confirmations of 2.

[kallewoof]

@TheBlueMatt Thanks for the review! I've addressed all of your nits, I believe. The unsquashed changes are in kallewoof/bitcoin@5166d0e and kallewoof/bitcoin@299c00c.

[TheBlueMatt]

I think this maybe missed 15, sadly. Its a nice change, but not a bugfix.

[kallewoof]

That's disheartening, but ah well.

[TheBlueMatt]

utACK d6115c2. Yea, Core has been in a near-constant state of growing pains for some time it seems. Recently its grown active enough to be just beyond the ability of any individual to keep up with everything, and so things occasionally move slower than they should :(. Anyway, up to @laanwj, this isnt a bugfix, but its pretty clean so maybe he's still willing to pull it for 15.

[kallewoof]

I'd say let's just push it to 16 milestone. I'll be noisy about it this time. :)

[TheBlueMatt]

Heh, yes, if things have been sitting for a while definitely be noisy!

…

On July 19, 2017 7:12:08 PM EDT, kallewoof ***@***.***> wrote: I'd say let's just push it to 16 milestone. I'll be noisy about it this time. :)

[laanwj]

Needs rebase.

I'd say let's just push it to 16 milestone. I'll be noisy about it this time. :)

Up to you, though given how long this has been open and how much interest and review this has I don't have a particular problem with merging this into 0.15 still.

[kallewoof]

@laanwj Rebased. And I'd love to have this in 15, personally. I just don't wanna rush anything for the sake of the PR being old.

[sipa]

utACK