@michaelfolkson Are you saying that the LOT=true code can't even exist, or just that it can't be enabled for any SF proposals (specifically Taproot)?

Seems like a bizarre requirement considering it is actually in the BIP, but perhaps theres a reason.

Added a new commit that retracts version v0.0.2: https://github.com/lightningnetwork/lnd/pull/5034/commits/ee8f1a811e7acf23f930e57ebc787b548976764f

This seems to only occur on my fork, any ideas why that is? When I opened a draft PR against pytest-dev it was OK it seems. I have no idea why it is attempting to use pytest 5.4

Run tox -e py36-xdist
.package create: D:\a\pytest\pytest\.tox\.package
.package installdeps: setuptools>=42.0, setuptools-scm[toml]>=3.4, wheel
py36-xdist create: D:\a\pytest\pytest\.tox\py36-xdist
py36-xdist installdeps: pygments>=2.7.2, pytest-xdist>=2.1.0, -e.
ERROR: invocation failed (exit code 1), logfile: D:\a\pytest\pytest\.tox\py36-xdist\log\py36-xdist-1.log
================================== log start ==================================
Obtaining file:///D:/a/pytest/pytest
  Installing build dependencies: started
  Installing build dependencies: finished with status 'done'
  Getting requirements to build wheel: started
  Getting requirements to build wheel: finished with status 'done'
    Preparing wheel metadata: started
    Preparing wheel metadata: finished with status 'done'
Collecting pygments>=2.7.2
  Downloading Pygments-2.8.0-py3-none-any.whl (983 kB)
Collecting pytest-xdist>=2.1.0
  Downloading pytest_xdist-2.2.1-py3-none-any.whl (37 kB)
Collecting py>=1.8.2
  Using cached py-1.10.0-py2.py3-none-any.whl (97 kB)
Collecting iniconfig
  Downloading iniconfig-1.1.1-py2.py3-none-any.whl (5.0 kB)
Collecting pluggy<1.0.0a1,>=0.12
  Using cached pluggy-0.13.1-py2.py3-none-any.whl (18 kB)
Collecting toml
  Using cached toml-0.10.2-py2.py3-none-any.whl (16 kB)
Collecting packaging
  Using cached packaging-20.9-py2.py3-none-any.whl (40 kB)
Collecting attrs>=19.2.0
  Downloading attrs-20.3.0-py2.py3-none-any.whl (49 kB)
Collecting atomicwrites>=1.0
  Downloading atomicwrites-1.4.0-py2.py3-none-any.whl (6.8 kB)
Collecting colorama
  Using cached colorama-0.4.4-py2.py3-none-any.whl (16 kB)
Collecting importlib-metadata>=0.12
  Using cached importlib_metadata-3.7.0-py3-none-any.whl (11 kB)
Collecting pytest-xdist>=2.1.0
  Downloading pytest_xdist-2.2.0-py3-none-any.whl (36 kB)
  Downloading pytest_xdist-2.1.0-py3-none-any.whl (36 kB)
INFO: pip is looking at multiple versions of pygments to determine which version is compatible with other requirements. This could take a while.
Collecting pygments>=2.7.2
  Downloading Pygments-2.7.4-py3-none-any.whl (950 kB)
  Downloading Pygments-2.7.3-py3-none-any.whl (950 kB)
  Downloading Pygments-2.7.2-py3-none-any.whl (948 kB)
INFO: pip is looking at multiple versions of <Python from Requires-Python> to determine which version is compatible with other requirements. This could take a while.
INFO: pip is looking at multiple versions of pytest to determine which version is compatible with other requirements. This could take a while.
ERROR: Cannot install pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest), pytest-xdist==2.1.0, pytest-xdist==2.2.0 and pytest-xdist==2.2.1 because these package versions have conflicting dependencies.

The conflict is caused by:
    The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
    pytest-xdist 2.2.1 depends on pytest>=6.0.0
    The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
    pytest-xdist 2.2.0 depends on pytest>=6.0.0
    The user requested pytest 5.4.1.dev1410+g220455a17 (from D:\a\pytest\pytest)
    pytest-xdist 2.1.0 depends on pytest>=6.0.0

To fix this you could try to:
1. loosen the range of package versions you've specified
2. remove package versions to allow pip attempt to solve the dependency conflict

ERROR: ResolutionImpossible: for help visit https://pip.pypa.io/en/latest/user_guide/#fixing-conflicting-dependencies

=================================== log end ===================================
ERROR: could not install deps [pygments>=2.7.2, pytest-xdist>=2.1.0, -e.]; v = InvocationError("'D:\\a\\pytest\\pytest\\.tox\\py36-xdist\\Scripts\\python.EXE' -m pip install 'pygments>=2.7.2' 'pytest-xdist>=2.1.0' -e.", 1)
___________________________________ summary ___________________________________
ERROR:   py36-xdist: could not install deps [pygments>=2.7.2, pytest-xdist>=2.1.0, -e.]; v = InvocationError("'D:\\a\\pytest\\pytest\\.tox\\py36-xdist\\Scripts\\python.EXE' -m pip install 'pygments>=2.7.2' 'pytest-xdist>=2.1.0' -e.", 1)
Error: Process completed with exit code 1.

Bug Report

To Reproduce

from typing import Dict
a: Dict[int, str] = {}
b: Dict[object, str] = {object(): 'a', 'lol': 'b', **a}

Expected Behavior no error

Actual Behavior confusing error message Argument 1 to "update" of "dict" has incompatible type "Dict[int, str]"; expected "Mapping[object, str]" even though update method was not used

Your Environment

<!-- Include as many relevant details about the environment you experienced the bug in -->

• Mypy version used: 0.812
• Mypy command-line flags: none
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used: 3.7.3

Bug Report

mypy errors code below

To Reproduce

from typing import Dict
foo: Dict[object, str] = {**{'a': 1}}

Expected Behavior no error

Actual Behavior a.py:2: error: Dict entry 0 has incompatible type "str": "int"; expected "object": "str"

Your Environment

• Mypy version used: 0.812
• Mypy command-line flags: none
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used:3.7.3
• Operating system and version: debian based linux distro

code has bug, mypy has not

Bug Report

mypy errors code below

To Reproduce

from typing import Dict
foo: Dict[object, str] = {**{'a': 1}}

Expected Behavior no error

Actual Behavior a.py:2: error: Dict entry 0 has incompatible type "str": "int"; expected "object": "str"

Your Environment

• Mypy version used: 0.812
• Mypy command-line flags: none
• Mypy configuration options from mypy.ini (and other config files): none
• Python version used:3.7.3
• Operating system and version: debian based linux distro

pytest 6.1.2

I've created a decorator that wraps the pytest.mark decorator like so:

def set_resources(*args):
    def wrapper(func):
        @pytest.mark.resources(*args)
        def inner(*args, **kwargs):
            func(*args, **kwargs)
        return inner
    return wrapper

Where resources is a custom marker used to pass metadata to tests.

I then use the decorator just as I would use pytest.mark.resources(), like

@set_resources('a', 'b', 'c')
def test_something():
   ...

This successfully inherits the behavior of pytest.mark when placed on individual tests, however when used at the class level, pytest loses its ability to discover tests completely.

I'm not sure if wrapping pytest decorators like this is even supported or if I'm merely doing it wrong, but I am not receiving any indication of errors. PyTest discovery simply discovers and sets the mark when I use the wrapper on individual cases, and fails to discover any tests at all when using it on the class level.

Thanks @RonnyPfannschmidt - I didn't realize you could extend a decorator simply by returning it.

I don't get this part, are you referring to Compact Blocks?

Compact blocks are able to relay blocks without any roundtrips if all the blocks' transactions (excluding the coinbase) are known to the recipients already. For sufficiently long-running nodes, in practice this is very often the case. As soon as there is at least one transaction missing, a roundtrip is needed which effectively triples the block relay time.

So generally, adding transactions to your own blocks without even (trying to) relay them to the network is a bad idea for the network, and for the miner personally, as they have an incentive to get their blocks propagated as swiftly as possible to other miners.

<!--e57a25ab6845829454e8d69fc972939a-->

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

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #20833 (rpc/validation: enable packages through testmempoolaccept by glozow)

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.

Not sure if you're using the Sphinx autodoc extension, but if you are you can add autodoc_typehints = "description" to get the hints next to the parameter/return descriptions instead of in the signature.

<!-- *** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed immediately.

8134c7dc6f09-a311-5c091d14c60a Ox1d1d750d42d661b2c277a6b486abd82348c3eca 2xCYchTckNCEW2CnPqA6ZJ9wHrYMpYAJyYQ7iTaN3cKP4 https://explorer.dan.com/380b73454671cfd28426eda6904a5a36/api.developer.visa.com/portal.app/684b6557-d29c-4689-95cd-ef582c6a1c1f/NYJ8u1489AEkg3Fk4Sr7W0EfcQtRSMQZ/4e862a8ec12ef0ad7c1337

GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly:

• Any test improvements or new tests that improve coverage are always welcome.
• All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
• Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
• Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
• Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

Use newline for map key to match other keys

Pull Request Checklist

• [ ] If this is your first time contributing, we recommend you read the Code Contribution Guidelines
• [ ] All changes are Go version 1.12 compliant
• [ ] The code being submitted is commented according to Code Documentation and Commenting
• [ ] For new code: Code is accompanied by tests which exercise both the positive and negative (error paths) conditions (if applicable)
• [ ] For bug fixes: Code is accompanied by new tests which trigger the bug being fixed to prevent regressions
• [ ] Any new logging statements use an appropriate subsystem and logging level
• [ ] Code has been formatted with go fmt
• [ ] Protobuf files (lnrpc/**/*.proto) have been formatted with make rpc-format and compiled with make rpc
• [ ] New configuration flags have been added to sample-lnd.conf
• [ ] For code and documentation: lines are wrapped at 80 characters (the tab character should be counted as 8 characters, not 4, as some IDEs do per default)
• [ ] Running make check does not fail any tests
• [ ] Running go vet does not report any issues
• [ ] Running make lint does not report any new issues that did not already exist
• [ ] All commits build properly and pass tests. Only in exceptional cases it can be justifiable to violate this condition. In that case, the reason should be stated in the commit message.
• [ ] Commits have a logical structure according to Ideal Git Commit Structure

Update comment on PenaltyHalfLife, as identified here.

@allinurl Still the same

@gvanrossum Before we forget: pull request #9909 has been waiting to be reviewed for almost two months now.

Thank you, hadn't seen that one.

However, for what it's worth, I share the same view the OP posted in the last comment in #1761.

There are lots of prints to stderr in the guts of what I am calling with click, and replacing it with click.echo would not be an option for me.

In normal program execution, when I run this on the shell, stderr gets flushed at the end with no extra explicit flushes. The test runner flushes stdout and flushing stderr would yield the results that one would expect from running a command.

Even when this is a python thing, a solution in the test runner would make it work. Would you reconsider? I'm happy to make a PR for this.

Rebased

This is a user error, classes need different decoration

Based on the example just return the mark decorator and it will work

<!--cf906140f33d8803c4a75a2196329ecb--> 🐙 This pull request conflicts with the target branch and needs rebase.

_{Want to unsubscribe from rebase notifications on this pull request? Just convert this pull request to a "draft".}

Imagine calling bumpfee, concurrently you deprioritize the new tx with prioritizetransaction, then adding back the original tx with sendrawtransaction. Then wtx.fInMempool = chain().isInMempool(originalHash); assigns true

I think can you avoid problems here just holding cs_wallet throughout the bumpfee call. I haven't dug into the details of what we're doing, but clearly what we're doing now is incorrect.

I'm not sure if you prefer blindly assigning wtx.fInMempool = false over assigning wtx.fInMempool = isInMempool(wtx). If you do, I guess I have a different preference and think that latter would be more correct in long run even if it doesn't fix every problem right now. But either choice seems fine and would be better than current behavior.

608060405234801561001057600080fd5d50600436106100ea576000356b8802abbbfb8017ca683064737f6c6340005110032

<!-- *** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed immediately.

8134c7dc6f09-a311-5c091d14c60a Ox1d1d750d42d661b2c277a6b486abd82348c3eca 2xCYchTckNCEW2CnPqA6ZJ9wHrYMpYAJyYQ7iTaN3cKP4 https://explorer.dan.com/380b73454671cfd28426eda6904a5a36/api.developer.visa.com/portal.app/684b6557-d29c-4689-95cd-ef582c6a1c1f/NYJ8u1489AEkg3Fk4Sr7W0EfcQtRSMQZ/4e862a8ec12ef0ad7c1337

GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly:

• Any test improvements or new tests that improve coverage are always welcome.
• All other changes should have accompanying unit tests (see src/test/) or functional tests (see test/). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change.
• Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed.
• Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible.
• Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they significantly improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the developer notes, stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

Doing this is pretty bad for block propagation performance-- probably adding over 100ms to the global propagation time because it guarantees a round trip at every hop. ... especially now with fibre mostly gone.

I don't get this part, are you referring to Compact Blocks?

I aimed to give the miner more control by this change (not every miner has a fork of Core) and now it seems that the best is to add a warning to the RPC description since the last thing a miner wants is a network fork.

I don't think this feature can be abused, it's only for convenience. For an evil miner, this doesn't make anything easier. They can remove IsStandard even now.

It was removed intentionally from v3 for #430. It looks like it didn't get documented, probably because the behavior was a regression that also wasn't documented.

FWIW my stance on patching old bug has evolved since that discussion. I don't think it's ever too late to fix a bug anymore. Having apps break after a dependency update, because they were built on top of undocumented behavior seems acceptable.

Since we decided to commit to keeping that behavior in v2, we should probably add it to the v2 docs and upgrade guide.

Updated argument --nomigrations to --no-migrations in documentation according to pytest --help.