[mempool] Allow one extra single-ancestor transaction per package #15681

TheBlueMatt · 2019-03-28T03:28:06Z

This implements the proposed policy change from [1], which allows
certain classes of contract protocols involving revocation
punishments to use CPFP. Note that some such use-cases may still
want some form of one-deep package relay, though even this alone
may greatly simplify some lightning fee negotiation.

[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

DrahtBot · 2019-03-28T05:51:07Z

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

#16409 (Remove mempool expiry, treat txs as replaceable instead by MarcoFalke)
#16401 (Package relay by sdaftuar)
#16400 ([refactor] Rewrite AcceptToMemoryPoolWorker() using smaller parts by sdaftuar)
#16398 (rpc: testmempoolaccept for list of transactions by MarcoFalke)
#15921 (Tidy up ValidationState interface by jnewbery)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

instagibbs · 2019-03-28T16:23:20Z

src/validation.cpp

+            // and has at most one ancestor (ie ancestor limit of 2, including
+            // the new transaction), allow it if its parent has exactly the
+            // descendant limit descendants.
+            if (nSize <= 10000 && !pool.CalculateMemPoolAncestors(entry, setAncestors, 2, 1000000, nLimitDescendants + 1, nLimitDescendantSize + 10000, errString)) {


I'm still chewing on the comment above, but doesn't this line let transactions >40k weight through no matter what?

Lol, oops, one of these days I'll learn to code.

did the tests work? ;D

@TheBlueMatt I have a spill-over question from the PR review club which covered this PR last week. I am unsure of why the LimitAncestorSize for the carve-out tx has been increased to the block-size.

EDIT: @harding has helped tidy up my understanding of this:

In the case of a (to-be-fee-bumped) LN parent TX with two hooks (A and B), which is close or equal to the descendant-size-limit, only a single (carve-out) child can be accepted, since the initial package size limit has been reached with the parent TX alone. This would seem like a race between A and B for the carve-out.

In regards to the 1M ancestor-size-limit for the carve-out, is it increased to 1M to prevent the ancestor-size-limit from interfering with the carve-out? I suppose this prevents a custom ancestor-size-limit setting from blocking the carve-out and subsequent network propagation.

Indeed, we don't really care about the size of the ancestor transaction here (its limited to the standard single-tx size limit, or 100k today), so I just set it to 1M, we already check that there is only, at max, one unconfirmed parent.

test/functional/mempool_package_onemore.py

TheBlueMatt · 2019-03-28T18:20:20Z

CC @rustyrussell.

test/functional/mempool_package_onemore.py

practicalswift · 2019-04-02T07:37:21Z

test/functional/mempool_package_onemore.py

+
+    # Build a transaction that spends parent_txid:vout
+    # Return amount sent
+    def chain_transaction(self, node, parent_txids, vouts, value, fee, num_outputs):


Nit: This method doesn't use self: could be made a function?

agree that this would be better as a function than a method

test/functional/mempool_package_onemore.py

src/validation.cpp

TheBlueMatt · 2019-07-02T02:13:17Z

Resolved comments.

rustyrussell

Concept Ack.

After much discussion, this does seem to be the minimal-intervention fix. Thanks Matt.

sdaftuar · 2019-07-03T18:30:48Z

Concept ACK.

I did some review and light testing, and I noticed that there seems to be a general problem with our RBF logic: if we have some parent transaction whose descendant count is maxed out in the mempool, then we're unable to rbf any child transaction, because we evaluate the descendant limits of a new transactions ancestors prior to looking at what might be evicted by that transaction. (However, we can generally RBF the parent itself!)

So in particular, that means that the new transaction that would be carved out by this policy would not be able to be RBF'ed in the situation that the parent transactions' descendant limit has been reached.

I'm guessing we may want to fix that to provide additional footgun protection to users that would take advantage of this new behavior, though I'll leave it to the PR author to decide if it is worth doing in this PR or separately.

ajtowns · 2019-07-08T09:15:32Z

Concept ACK. Might be worth adding an explicit test case for RBF case @sdaftuar points out:

         # But not if it chains directly off the first transaction
         self.chain_transaction(self.nodes[0], [chain[0][0]], [1], chain[0][1], fee, 1)
+
+        # Sadly, RBFing that should fail, however
+        assert_raises_rpc_error(-26, "too-long-mempool-chain", self.chain_transaction, 0, [chain[0][0]], [1], chain[0][1], fee*2, 1)
+
         # and the second chain should work just fine
         self.chain_transaction(self.nodes[0], [second_chain], [0], second_chain_value, fee, 1)

(means createrawtransaction needs to be called with replaceable=True as well)

Could change chain_transaction(self, node, ...) to always use node=self.nodes[0] which would simplify calls, and deal with @practicalswift's nit.

Could define a const for the 10k magic number. Is there any reason to have 1M instead of reusing nLimitAncestorSize? (Could not allow the carve out at all if nLimitAncestors <= 1 though that's probably getting a bit ridiculous)

I think this should work for two-party lightning channels, because the outputs will be a bunch of CSV-limited ones that won't be in the mempool, and one CPFP output for each party. So at most one output can be spammed, and that only up to the descendent limit, so the plus-one here should work fine. If there were three or more immediately-spendable outputs (for channel factories and multiparty eltoo eg), I don't think this would be enough. But that's fine today.

I guess it's not very useful to log when this carve out triggers -- it's meant to prevent attacks from being effective, so while it's there there won't be any attacks so it'll hardly ever be used, but if it weren't there there would be attacks and it would be useful.

Should this carve out be limited to only apply when it's actually raising the parent's effective fee rate? I think you'd have to loop over all the descendents of your parent, work out the best ancestor fee rate of any of them, then see if the new tx and the parent have a better combined fee rate than that. That seems like it would add a chunk of complexity though, so probably isn't worth it.

This seems like it's a sufficient workaround for current problems, and is a pretty minimal change, while doing anything much better would be lots more complicated. So: Approach ACK.

test/functional/mempool_package_onemore.py

ryanofsky

ACK f1facdd with minimal testing. I verified new test fails without policy change and succeeds with it. I left only minor review comments which can be ignored.

I do like ajtowns's RBF test from #15681 (comment), and think it'd be nice if that were added.

src/validation.cpp

ryanofsky · 2019-07-08T21:34:11Z

test/functional/mempool_package_onemore.py

+
+    # Build a transaction that spends parent_txid:vout
+    # Return amount sent
+    def chain_transaction(self, node, parent_txids, vouts, value, fee, num_outputs):


Not great how this function and the test setup here is mostly duplicated from mempool_packages.py. Someone could clean it up later, though.

ryanofsky · 2019-07-08T21:51:50Z

test/functional/mempool_package_onemore.py

+            vout = 0
+            value = sent_value
+            chain.append([txid, value])
+        for _ in range(MAX_ANCESTORS - 4):


Having two basically identical loops just to add an extra output to the first four transactions seems like an odd choice. Maybe prefer

for depth in range(MAX_ANCESTORS): num_outputs = 2 if depth < 4 else 1 ...

I find this more readable.

ryanofsky · 2019-07-08T21:52:55Z

test/functional/mempool_package_onemore.py

+            chain.append([txid, value])
+        (second_chain, second_chain_value) = self.chain_transaction(self.nodes[0], [utxo[1]['txid']], [utxo[1]['vout']], utxo[1]['amount'], fee, 1)
+
+        # Check mempool has MAX_ANCESTORS transactions in it, and descendant and ancestor


Stale comment from the old test, now MAX_ANCESTORS+1

ryanofsky · 2019-07-08T21:55:33Z

test/functional/mempool_package_onemore.py

+        # Adding one more transaction on to the chain should fail.
+        assert_raises_rpc_error(-26, "too-long-mempool-chain", self.chain_transaction, self.nodes[0], [txid], [0], value, fee, 1)
+        # ...even if it chains on from some point in the middle of the chain.
+        assert_raises_rpc_error(-26, "too-long-mempool-chain", self.chain_transaction, self.nodes[0], [chain[2][0]], [1], chain[2][1], fee, 1)


These tests would be more readable, and zip() above could be dropped if chain_transaction just took a list of txid/nout tuples

FWIW, I thought the way it is seemed more readable. YMMV obviously :)

ryanofsky · 2019-07-08T21:58:05Z

test/functional/mempool_package_onemore.py

+        for _ in range(MAX_ANCESTORS - 4):
+            (txid, sent_value) = self.chain_transaction(self.nodes[0], [txid], [0], value, fee, 1)
+            value = sent_value
+            chain.append([txid, value])


Imo, tests below would be more reable if this were

chain.append(txid) values.append(value)

to get rid of all the 0/1 indexing

+1, or used a namedtuple

This implements the proposed policy change from [1], which allows certain classes of contract protocols involving revocation punishments to use CPFP. Note that some such use-cases may still want some form of one-deep package relay, though even this alone may greatly simplify some lightning fee negotiation. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html

TheBlueMatt · 2019-07-09T19:46:55Z

@ajtowns I'd prefer to not add the proposed test change, as @sdaftuar's comment points out a critical limitation, and one I'd like to get resolved before this gets released, though not necessarily in this PR. I'd rather just fix the bug than add a test to ensure that the bug exists.

As for general policy questions: this doesn't result in any new transactions being accepted which violate min fee, nor does it change eviction criteria when mempool fills. What this does do, is tweak our already-somewhat-arbitrary-but-sadly-neccessary anti-DoS policies to allow one more (potentially-in-the-future) common case so that we can maximize fee revenue in the case this does get used. Thus, I don't see any reason to need to bend over backwards to make it more restrictive, if anything, less restrictive is better.

sdaftuar · 2019-07-12T15:05:55Z

ACK f1facdd

ryanofsky

utACK 50cede3. Changes since last review: adding EXTRA_DESCENDANT_TX_SIZE_LIMIT constant, changing max ancestor size from 1,000,000 to nLimitAncestorSize constant (101,000), fixing test comment and getting rid of unused test node.

ajtowns · 2019-07-16T11:02:48Z

ACK 50cede3 -- looked over code again, compared with previous commit, compiles, etc.

I think this is a sufficient improvement even with the problem @sdaftuar points out:

if there's no adversarial situation and you hit the descendent limit with low fee children just due to carelessness, this carveout can be used to RBF the first child (paying 25 times the feerate to account for the descendants' fees) and make CPFP actually work in ways where you can't do anything now
in the event of an adversarial situation with only two immediately spendable outputs, if you do the CPFP first, they can't block you from RBF'ing when you need to (they can't make use of the onemore carve out if they only have one output available -- they need to use it to hit the descant limit, at which point it's not available for onemore).
to DoS their channel partner, an adversary would need to be confident their partner will CPFP by too small an amount, and do their spam low-fee tx spamming before they do that. If the CPFP is a high enough amount, they'll likely lose the fees for their spam once the mempool clears out, making that not a free attack, as well.

It would obviously still be better to find a more general fix, but this seems to me a worthwhile improvement without introducing much of a maintenance cost.

ajtowns · 2019-07-16T11:12:13Z

Patch to mempool_package_onemore.py for checking the "can RBF if I've added too many descendants myself" case. Maybe useful for reviewers, not suitable for inclusion since it kills the checks for the intended usecase:

+++ b/test/functional/mempool_package_onemore.py
@@ -33,7 +33,7 @@ class MempoolPackagesTest(BitcoinTestFramework):
         outputs = {}
         for i in range(num_outputs):
             outputs[node.getnewaddress()] = send_value
-        rawtx = node.createrawtransaction(inputs, outputs)
+        rawtx = node.createrawtransaction(inputs, outputs, 0, True)
         signedtx = node.signrawtransactionwithwallet(rawtx)
         txid = node.sendrawtransaction(signedtx['hex'])
         fulltx = node.getrawtransaction(txid, 1)
@@ -74,6 +74,12 @@ class MempoolPackagesTest(BitcoinTestFramework):
         assert_raises_rpc_error(-26, "too-long-mempool-chain", self.chain_transaction, self.nodes[0], [chain[0][0], second_chain], [1, 0], chain[0][1] + second_chain_value, fee, 1)
         # ...especially if its > 40k weight
         assert_raises_rpc_error(-26, "too-long-mempool-chain", self.chain_transaction, self.nodes[0], [chain[0][0]], [1], chain[0][1], fee, 350)
+
+        # can even RBF the original tx
+        self.chain_transaction(self.nodes[0], [chain[0][0]], [0], chain[0][1], fee*25, 10)
+        assert_equal(len(self.nodes[0].getrawmempool(True)), 3) # parent, second_chain, RBF'd original
+        return
+
         # But not if it chains directly off the first transaction
         self.chain_transaction(self.nodes[0], [chain[0][0]], [1], chain[0][1], fee, 1)
         # and the second chain should work just fine

sdaftuar · 2019-07-19T17:45:51Z

ACK 50cede3

…er package 50cede3 [mempool] Allow one extra single-ancestor transaction per package (Matt Corallo) Pull request description: This implements the proposed policy change from [1], which allows certain classes of contract protocols involving revocation punishments to use CPFP. Note that some such use-cases may still want some form of one-deep package relay, though even this alone may greatly simplify some lightning fee negotiation. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html ACKs for top commit: ajtowns: ACK 50cede3 -- looked over code again, compared with previous commit, compiles, etc. sdaftuar: ACK 50cede3 ryanofsky: utACK 50cede3. Changes since last review: adding EXTRA_DESCENDANT_TX_SIZE_LIMIT constant, changing max ancestor size from 1,000,000 to nLimitAncestorSize constant (101,000), fixing test comment and getting rid of unused test node. Tree-SHA512: b052c2a0f384855572b4579310131897b612201214b5abbb225167224e4f550049e300b471dbf320928652571e92ca2d650050b7cf39ac92b3bc1d2bcd386c1c

jnewbery

Quick code-review ACK 50cede3.

There's one logging bug that I think we should fix. I've added a bunch of nits to the test, but I agree with other reviewers that we could probably avoid a bunch of test code duplication by merging mempool_package_onemore.py with mempool_packages.py.

jnewbery · 2019-07-22T20:16:23Z

src/validation.cpp

+            // outputs - one for each counterparty. For more info on the uses for
+            // this, see https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html
+            if (nSize >  EXTRA_DESCENDANT_TX_SIZE_LIMIT ||
+                    !pool.CalculateMemPoolAncestors(entry, setAncestors, 2, nLimitAncestorSize, nLimitDescendants + 1, nLimitDescendantSize + EXTRA_DESCENDANT_TX_SIZE_LIMIT, errString)) {


Passing errString through to the second call of CalculateMemPoolAncestors() means that the error string in the CValidationState object will be incorrect because of the changed ancestor/descendant size/count parameters. Really we should declare a dummy_error_string to pass into the second call, and use the original errString in the call to state.Invalid() below.

jnewbery · 2019-07-22T20:18:15Z

test/functional/mempool_package_onemore.py

+# file COPYING or http://www.opensource.org/licenses/mit-license.php.
+"""Test descendant package tracking carve-out allowing one final transaction in
+   an otherwise-full package as long as it has only one parent and is <= 10k in
+   size.


nit: virtual size (or define this in terms or transaction weight)

jnewbery · 2019-07-22T20:21:26Z

test/functional/mempool_package_onemore.py

+    def run_test(self):
+        # Mine some blocks and have them mature.
+        self.nodes[0].generate(101)
+        utxo = self.nodes[0].listunspent(10)


nit: it's preferable to use named transactions to make the test more readable.

jnewbery · 2019-07-22T20:22:45Z

test/functional/mempool_package_onemore.py

+MAX_ANCESTORS = 25
+MAX_DESCENDANTS = 25
+
+class MempoolPackagesTest(BitcoinTestFramework):


nit: name this class MempoolPackageOnemoreTest

jnewbery · 2019-07-22T20:22:51Z

test/functional/mempool_package_onemore.py

+
+    # Build a transaction that spends parent_txid:vout
+    # Return amount sent
+    def chain_transaction(self, node, parent_txids, vouts, value, fee, num_outputs):


agree that this would be better as a function than a method

jnewbery · 2019-07-22T20:23:44Z

test/functional/mempool_package_onemore.py

+    def run_test(self):
+        # Mine some blocks and have them mature.
+        self.nodes[0].generate(101)
+        utxo = self.nodes[0].listunspent(10)


nit: name this variable utxos or define it as self.nodes[0].listunspent(10)[0]

jnewbery · 2019-07-22T20:34:03Z

test/functional/mempool_package_onemore.py

+        for _ in range(MAX_ANCESTORS - 4):
+            (txid, sent_value) = self.chain_transaction(self.nodes[0], [txid], [0], value, fee, 1)
+            value = sent_value
+            chain.append([txid, value])


+1, or used a namedtuple

test/functional/mempool_package_onemore.py

…ction per package 50cede3 [mempool] Allow one extra single-ancestor transaction per package (Matt Corallo) Pull request description: This implements the proposed policy change from [1], which allows certain classes of contract protocols involving revocation punishments to use CPFP. Note that some such use-cases may still want some form of one-deep package relay, though even this alone may greatly simplify some lightning fee negotiation. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html ACKs for top commit: ajtowns: ACK 50cede3 -- looked over code again, compared with previous commit, compiles, etc. sdaftuar: ACK 50cede3 ryanofsky: utACK 50cede3. Changes since last review: adding EXTRA_DESCENDANT_TX_SIZE_LIMIT constant, changing max ancestor size from 1,000,000 to nLimitAncestorSize constant (101,000), fixing test comment and getting rid of unused test node. Tree-SHA512: b052c2a0f384855572b4579310131897b612201214b5abbb225167224e4f550049e300b471dbf320928652571e92ca2d650050b7cf39ac92b3bc1d2bcd386c1c

42a5e91 [mempool] log correct messages when CPFP fails (John Newbery) Pull request description: Fixes a logging issue introduced in #15681 ACKs for top commit: laanwj: ACK 42a5e91 (+utACK from bluematt that isn't registered because it has no commit id) Tree-SHA512: ff5f423cc4d22838eea00c5b1d39ceda89cd61474c72f256a97c698eb0ec3f2156a97139f537669376132902c1e3943bf84c356a4b98a9a306b4ec57302c2761

…ackage limits 5ce822e Conservatively accept RBF bumps bumping one tx at the package limits (Matt Corallo) Pull request description: Based on #15681, this adds support for some simple cases of RBF inside of large packages. Issue pointed out by sdaftuar in #15681, and this fix (or a broader one) is required ot make #15681 fully useful. Accept RBF bumps of single transactions (ie which evict exactly one transaction) even when that transaction is a member of a package which is currently at the package limit iff the new transaction does not add any additional mempool dependencies from the original. This could be made a bit looser in the future and still be safe, but for now this fixes the case that a transaction which was accepted by the carve-out rule will not be directly RBF'able ACKs for top commit: instagibbs: re-ACK 5ce822e ajtowns: ACK 5ce822e ; GetSizeWithDescendants is only change and makes sense sipa: Code review ACK 5ce822e. I haven't thought hard about the effect on potential DoS issues this policy change may have. Tree-SHA512: 1cee3bc57393940a30206679eb60c3ec8cb4f4825d27d40d1f062c86bd22542dd5944fa5567601c74c8d9fd425333ed3e686195170925cfc68777e861844bd55

ysangkok · 2019-11-09T19:28:09Z

just FYI: a lot of interesting comments on this PR available at: https://bitcoincore.reviews/15681.html

Summary: > To test the custom descendant limit on node1 (passed by the argument > -limitdescendantcount), we check for four conditions: > -> the # of txs in the node1 mempool is equal to the limit > (plus 1 for the parent tx, plus the # txs from the previous ancestor > test which are still in) > -> all txs in node1 mempool are a subset of txs in node0 mempool > -> part of the constructed descendant-chain (the first ones up to the > limit) are contained in node1 mempool > -> the remaining part of the constructed descendant-chain (all after the > first ones up to the limit) is *not* contained in node1 mempool Note: Core accepts one more descendant than we do, as of [[bitcoin/bitcoin#15681 | PR15681]] (change related to Lightning Network and bumping fees) This is backport of Core [[bitcoin/bitcoin#17461 | PR17461]] Test Plan: `ninja && test/functional/test_runner.py mempool_packages` Reviewers: #bitcoin_abc, majcosta Reviewed By: #bitcoin_abc, majcosta Differential Revision: https://reviews.bitcoinabc.org/D8770

…ction per package 50cede3 [mempool] Allow one extra single-ancestor transaction per package (Matt Corallo) Pull request description: This implements the proposed policy change from [1], which allows certain classes of contract protocols involving revocation punishments to use CPFP. Note that some such use-cases may still want some form of one-deep package relay, though even this alone may greatly simplify some lightning fee negotiation. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html ACKs for top commit: ajtowns: ACK 50cede3 -- looked over code again, compared with previous commit, compiles, etc. sdaftuar: ACK 50cede3 ryanofsky: utACK 50cede3. Changes since last review: adding EXTRA_DESCENDANT_TX_SIZE_LIMIT constant, changing max ancestor size from 1,000,000 to nLimitAncestorSize constant (101,000), fixing test comment and getting rid of unused test node. Tree-SHA512: b052c2a0f384855572b4579310131897b612201214b5abbb225167224e4f550049e300b471dbf320928652571e92ca2d650050b7cf39ac92b3bc1d2bcd386c1c

42a5e91 [mempool] log correct messages when CPFP fails (John Newbery) Pull request description: Fixes a logging issue introduced in bitcoin#15681 ACKs for top commit: laanwj: ACK 42a5e91 (+utACK from bluematt that isn't registered because it has no commit id) Tree-SHA512: ff5f423cc4d22838eea00c5b1d39ceda89cd61474c72f256a97c698eb0ec3f2156a97139f537669376132902c1e3943bf84c356a4b98a9a306b4ec57302c2761

…ction per package 50cede3 [mempool] Allow one extra single-ancestor transaction per package (Matt Corallo) Pull request description: This implements the proposed policy change from [1], which allows certain classes of contract protocols involving revocation punishments to use CPFP. Note that some such use-cases may still want some form of one-deep package relay, though even this alone may greatly simplify some lightning fee negotiation. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-November/016518.html ACKs for top commit: ajtowns: ACK 50cede3 -- looked over code again, compared with previous commit, compiles, etc. sdaftuar: ACK 50cede3 ryanofsky: utACK 50cede3. Changes since last review: adding EXTRA_DESCENDANT_TX_SIZE_LIMIT constant, changing max ancestor size from 1,000,000 to nLimitAncestorSize constant (101,000), fixing test comment and getting rid of unused test node. Tree-SHA512: b052c2a0f384855572b4579310131897b612201214b5abbb225167224e4f550049e300b471dbf320928652571e92ca2d650050b7cf39ac92b3bc1d2bcd386c1c

42a5e91 [mempool] log correct messages when CPFP fails (John Newbery) Pull request description: Fixes a logging issue introduced in bitcoin#15681 ACKs for top commit: laanwj: ACK 42a5e91 (+utACK from bluematt that isn't registered because it has no commit id) Tree-SHA512: ff5f423cc4d22838eea00c5b1d39ceda89cd61474c72f256a97c698eb0ec3f2156a97139f537669376132902c1e3943bf84c356a4b98a9a306b4ec57302c2761

fanquake added the Mempool label Mar 28, 2019

instagibbs reviewed Mar 28, 2019

View reviewed changes

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from e7e46b3 to a3053fd Compare March 28, 2019 17:06

instagibbs reviewed Mar 28, 2019

View reviewed changes

test/functional/mempool_package_onemore.py Show resolved Hide resolved

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from a3053fd to 87c902d Compare March 28, 2019 17:59

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from 87c902d to 891ae7b Compare March 28, 2019 18:29

practicalswift reviewed Apr 2, 2019

View reviewed changes

test/functional/mempool_package_onemore.py Outdated Show resolved Hide resolved

practicalswift reviewed Apr 2, 2019

View reviewed changes

test/functional/mempool_package_onemore.py Show resolved Hide resolved

morcos reviewed Apr 11, 2019

View reviewed changes

src/validation.cpp Show resolved Hide resolved

DrahtBot added the Needs rebase label May 4, 2019

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from 891ae7b to 69959a5 Compare June 5, 2019 12:04

DrahtBot removed the Needs rebase label Jun 5, 2019

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from 69959a5 to f1facdd Compare July 2, 2019 02:11

rustyrussell approved these changes Jul 2, 2019

View reviewed changes

ajtowns reviewed Jul 8, 2019

View reviewed changes

test/functional/mempool_package_onemore.py Outdated Show resolved Hide resolved

ryanofsky approved these changes Jul 8, 2019

View reviewed changes

TheBlueMatt force-pushed the 2019-03-lightning-policy branch from f1facdd to 50cede3 Compare July 9, 2019 19:46

ryanofsky approved these changes Jul 15, 2019

View reviewed changes

TheBlueMatt mentioned this pull request Jul 18, 2019

Conservatively accept RBF bumps bumping one tx at the package limits #16421

Merged

laanwj merged commit 50cede3 into bitcoin:master Jul 19, 2019

jnewbery reviewed Jul 22, 2019

View reviewed changes

jnewbery mentioned this pull request Jul 26, 2019

[mempool] log correct messages when CPFP fails #16471

Merged

maflcko mentioned this pull request Aug 1, 2019

[mempool] A single standard sized transaction should not preclude a CPFP #15046

Closed

joostjager mentioned this pull request Oct 28, 2019

Anchor outputs lightning/bolts#688

Merged

bitcoin locked as resolved and limited conversation to collaborators Feb 15, 2022

[mempool] Allow one extra single-ancestor transaction per package #15681

[mempool] Allow one extra single-ancestor transaction per package #15681

Uh oh!

Conversation

TheBlueMatt commented Mar 28, 2019

Uh oh!

DrahtBot commented Mar 28, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Conflicts

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!

jachiang Jul 1, 2019 • 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!

Uh oh!

TheBlueMatt commented Mar 28, 2019

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

TheBlueMatt commented Jul 2, 2019

Uh oh!

rustyrussell left a comment

Choose a reason for hiding this comment

Uh oh!

sdaftuar commented Jul 3, 2019

Uh oh!

ajtowns commented Jul 8, 2019

Uh oh!

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

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!

TheBlueMatt commented Jul 9, 2019

Uh oh!

sdaftuar commented Jul 12, 2019

Uh oh!

ryanofsky left a comment

Choose a reason for hiding this comment

Uh oh!

ajtowns commented Jul 16, 2019

Uh oh!

ajtowns commented Jul 16, 2019

Uh oh!

sdaftuar commented Jul 19, 2019

Uh oh!

jnewbery left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DrahtBot commented Mar 28, 2019 •

edited

Loading

jachiang Jul 1, 2019 •

edited

Loading